Apr 182017
 

LastweekVMware announced the launch of vSAN 6.6. Even more so than previous releases, this is a feature-packed release with advanced enterprise features that make vSAN faster, more cost effective and more secure than ever before. This week on the vSpeaking Podcast we bring inPeter Koehlerfor Part 2 of our vSAN 6.6 coverage and walk us

The post vSpeaking Podcast Episode 41: vSAN 6.6 Part 2 appeared first on Virtual Blocks.

Mrz 242017
 

This month’s massive outage of Amazon Web Services&#rsquo; S3 (Simple Storage Service) platform, was if nothing else a reminder to us all that we need to have Disaster Recovery plans we can count on. This week we bring in one of VMware’s Disaster Recovery experts, GS Khalsa to discuss various aspects of Availability and Disaster

The post vSpeaking Podcast Episode 39: Disaster Recovery with GS Khalsa appeared first on Virtual Blocks.

Mrz 142017
 

Have you ever stopped to think what if conventional wisdom on the consumption of resources is wrong? This week on the Virtually Speaking Podcast we bring in one of VMware’s performance experts, Sr. Technical Marketing Manager Peter Koehler to break down some common misconceptions around storage performance and provide a deeper look into how vSAN

The post vSpeaking Podcast Episode 38: Storage Performance appeared first on Virtual Blocks.

Mrz 032017
 

  The previous postin this seriesdiscussed the recovery plan test process built into SRM. In this post I’ll talk about some alternative methods of testing SRM recovery plans as well as recommendations around SRM and testing. SRM has a robust method of testing the operation of a recovery plan non-disruptively. However, for some customers and

The post Recovery Testing and SRM pt 2 – Alternatives appeared first on Virtual Blocks.

vSpeaking Podcast Episode 37: Storage and Availability with Yanbing Li

 Allgemein, Knowledge Base, Site Recovery Manager, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für vSpeaking Podcast Episode 37: Storage and Availability with Yanbing Li
Feb 282017
 

A few weeks ago, VMware reported solid fourth quarter earnings of $441 million, or $1.04 a share, on revenue of $2.03 billion, up 9 percent from a year ago. Non-GAAP earnings were $1.43 a share. CEO Pat Gelsinger said VMware’s fourth quarter was “one of the most balanced quarters for VMware in years.” One of

The post vSpeaking Podcast Episode 37: Storage and Availability with Yanbing Li appeared first on Virtual Blocks.

vSpeaking Podcast Episode 37: Storage and Availability with Yanbing Li

 Allgemein, Knowledge Base, Site Recovery Manager, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für vSpeaking Podcast Episode 37: Storage and Availability with Yanbing Li
Feb 282017
 

A few weeks ago, VMware reported solid fourth quarter earnings of $441 million, or $1.04 a share, on revenue of $2.03 billion, up 9 percent from a year ago. Non-GAAP earnings were $1.43 a share. CEO Pat Gelsinger said VMware’s fourth quarter was “one of the most balanced quarters for VMware in years.” One of

The post vSpeaking Podcast Episode 37: Storage and Availability with Yanbing Li appeared first on Virtual Blocks.

Feb 112017
 

NSX-V 6.2 introduced the Cross-NSX feature to allow for NSX logical networking and security across multiple vCenter domains. The ability to apply consistent networking and security across vCenter domains provides for mulitple use cases for Cross-VC NSX: workload mobility, resource pooling, multi-site security, ease of automation across sites, and disaster avoidance/recovery. With the recent release of NSX-V 6.3, several enhancements have been added to the Cross-VC NSX feature to provide for additional capabilities and overall robustness of the solution. This blog post discusses the new Cross-VC NSX security enhancements in NSX-V 6.3.

The security enhancements for Cross-VC NSX can be grouped into two categories:

  1. General Enhancements (Apply Across both Active/Active and Active/Standby deployment models)
  2. Enhancements for Active/Standby Use Case

Active/Active and Active/Standby above refers to if the application is active at both sites or if it is active at one site and standby at another site (ex: disaster recovery). Enhancements for both of these respective categories are discussed in more detail below.

1.) General Enhancements (Apply Across both Active/Active and Active/Standby deployment models)

Figure 1: Cross-VC NSX Active/Standby and Active/Active Deployment Model

 
– Multiple Universal Sections for Universal Distributed Firewall (UDFW)

Prior to NSX 6.3, only one universal section was possible for UDFW; NSX 6.3 allows for multiple universal sections.

Figure 2: Multiple Universal Sections for UDFW

 
Multiple universal sections gives us efficiency in terms of the following:

  • If rules are modified/edited within a universal section, only UDFW rules for that section are synced to the Secondary NSX Managers
  • Rules can easily be organized per tenant/application

In addition to the above, with NSX-V 6.3, universal sections are always above local sections, even on the Primary NSX Manager. Prior, this was only the case on Secondary NSX Managers. On the Primary NSX Manager, it was still possible to move the local sections above the universal sections. For consistency, all universal sections must now be above the local sections. This makes sense from a security perspective where the local site security policies should never override the global security policies set by the global security admin.

– Enhancements to ApplyTo (Universal Security Groups can be used)

The ApplyTo feature is a critical feature used to efficiently apply security policies to only the VMs/workloads that require the policy; this feature helps in terms of performance and scalability. ApplyTo also works with UDFW, however, prior to NSX-V 6.3, UDFW could only use Universal Logical Switch with ApplyTo. In summary, this ApplyTo behavior had two affects:

  1. The most granular a universal security policy could be applied was at the Universal Logical Switch level, meaning all VMs/workloads on the Universal Logical switch would get the security policy applied to its vNIC
  2.  

  3. If a user wanted to deploy just security/micro-segmentation without deploying network virtualization, the user was not able to leverage ApplyTo since it only worked with Universal Logical Switch

With NSX-V 6.3, ApplyTo can now leverage Universal Security Groups (USGs) with new dynamic matching criteria of VM Name or static matching criteria of Universal Security Tag; this allows for more granular application of universal security policies at the VM level. Additionally, users can now leverage ApplyTo even in cases where network virtualization is not being utilized, for example, a deployment leveraging NSX just for the benefits of Cross-VC NSX multi-site security.

Figure 3: Leveraging Universal Security Group with ApplyTo in UDFW

 

2.) Enhancements for Active/Standby Use Case

Figure 4: Cross-VC NSX Active/Standby Deployment Model

 
– Universal Security Tags

Starting NSX-V 6.3, Cross-VC NSX supports Universal Security Tags. When a Universal Security Tag is created on the Primary NSX Manager, it’s automatically synced to the Secondary NSX Manager(s) as shown below.

Figure 5: Universal Security Tag Creation and Sync

 
As mentioned prior, these enhancements are more applicable to Active/Standby use cases such as disaster recovery (DR). So when a VM is vMotioned or recovered at a secondary site, the Secondary NSX Manager needs some method of attaching the correct security tag to the correct VM. The Unique ID Selection Criteria setting under Installation–>Management–>Actions on the Primary NSX Manager is used to achieve this as shown in Figure 6 below.

For the Unique ID Selection Criteria, Virtual Machine Instance UUID is typically sufficient for cases such as disaster recovery with VMware’s Site Recovery Manager (SRM) and vMotion. Virtual Machine Instance UUID is guaranteed to be unique for each VM within a specific vCenter; it’s not guaranteed to be unique across different vCenters, but it’s rare for there to be overlap since each Virtual Machine Instance UUID is also based on a unique vCenter ID. vSphere Replication and vMotion will both maintain the Virtual Machine Instance UUID of the VM at the recovery/secondary site. The user has the option to use different or multiple selection criteria based on their environment. If each VM in the environment has a unique VM name, VM name can also be used for the unique selection criteria to ensure the correct security tags are attached to the correct VMs.

Figure 6: Setting Unique Selection Criteria

 
Figure 7 below shows the flow in terms of utilizing Universal Security Tags for Active/Standby deployments.

Figure 7: Flow for Utilizing Universal Security Tags in Active/Standby Deployments

 
– Universal Security Group with New Matching Criteria

In NSX-V 6.3, UDFW rules can now leverage Universal Security Groups with new matching criteria of:

  • VM Name (dynamic)
  • Universal Security Tag (static)

Since UDFW rules can now use Universal Security Groups based on VM Name and Universal Security Tag, security policies can be more fluid and not rely on IP addresses.

Figure 8: Using VM Name Matching Criteria in Universal Security Group

 

Figure 9: Using Universal Security Tag Matching Criteria in Universal Security Group

 
Figure 10 below shows, Universal Security Groups with matching criteria of Universal Security Tags being used in a UDFW rule.

Figure 10: Leveraging Universal Security Group with Universal Security Tag in UDFW Rule

 
As mentioned prior, it’s important to note enhancements listed here are applicable primarily for Active/Standby use cases such as DR. The reason for this is the local NSX Manager does not have visibility into the inventory of the other NSX Managers’ vCenters. Thus, when a security rule is utilized with the Universal Security Groups leveraging the new supported matching criteria of VM Name or Universal Security Tag in the source/destination fields, since the translation of the security group happens locally, only the VMs/workloads in the local vCenter will be found as members of the security group.

Thus, when leveraging Universal Security Groups with the new supported matching criteria, the entire application must be at the same site as shown below in Figure 11. For example, if the application is spanning across sites and there is Cross-VC traffic flows, the security policy for the application will not provide the desired results.

Figure 11: Entire Application Must be at Same Site When Using UDFW Rules Leveraging USGs with New Matching Criteria

 

For more information on NSX-V 6.3, check-out the NSX-V 6.3 documentation.
 

The post NSX-V 6.3: Cross-VC NSX Security Enhancements appeared first on The Network Virtualization Blog.

Feb 112017
 

NSX-V 6.2 introduced the Cross-NSX feature to allow for NSX logical networking and security across multiple vCenter domains. The ability to apply consistent networking and security across vCenter domains provides for mulitple use cases for Cross-VC NSX: workload mobility, resource pooling, multi-site security, ease of automation across sites, and disaster avoidance/recovery. With the recent release of NSX-V 6.3, several enhancements have been added to the Cross-VC NSX feature to provide for additional capabilities and overall robustness of the solution. This blog post discusses the new Cross-VC NSX security enhancements in NSX-V 6.3.

The security enhancements for Cross-VC NSX can be grouped into two categories:

  1. General Enhancements (Apply Across both Active/Active and Active/Standby deployment models)
  2. Enhancements for Active/Standby Use Case

Active/Active and Active/Standby above refers to if the application is active at both sites or if it is active at one site and standby at another site (ex: disaster recovery). Enhancements for both of these respective categories are discussed in more detail below.

1.) General Enhancements (Apply Across both Active/Active and Active/Standby deployment models)

Figure 1: Cross-VC NSX Active/Standby and Active/Active Deployment Model

 
– Multiple Universal Sections for Universal Distributed Firewall (UDFW)

Prior to NSX 6.3, only one universal section was possible for UDFW; NSX 6.3 allows for multiple universal sections.

Figure 2: Multiple Universal Sections for UDFW

 
Multiple universal sections gives us efficiency in terms of the following:

  • If rules are modified/edited within a universal section, only UDFW rules for that section are synced to the Secondary NSX Managers
  • Rules can easily be organized per tenant/application

In addition to the above, with NSX-V 6.3, universal sections are always above local sections, even on the Primary NSX Manager. Prior, this was only the case on Secondary NSX Managers. On the Primary NSX Manager, it was still possible to move the local sections above the universal sections. For consistency, all universal sections must now be above the local sections. This makes sense from a security perspective where the local site security policies should never override the global security policies set by the global security admin.

– Enhancements to ApplyTo (Universal Security Groups can be used)

The ApplyTo feature is a critical feature used to efficiently apply security policies to only the VMs/workloads that require the policy; this feature helps in terms of performance and scalability. ApplyTo also works with UDFW, however, prior to NSX-V 6.3, UDFW could only use Universal Logical Switch with ApplyTo. In summary, this ApplyTo behavior had two affects:

  1. The most granular a universal security policy could be applied was at the Universal Logical Switch level, meaning all VMs/workloads on the Universal Logical switch would get the security policy applied to its vNIC
  2.  

  3. If a user wanted to deploy just security/micro-segmentation without deploying network virtualization, the user was not able to leverage ApplyTo since it only worked with Universal Logical Switch

With NSX-V 6.3, ApplyTo can now leverage Universal Security Groups (USGs) with new dynamic matching criteria of VM Name or static matching criteria of Universal Security Tag; this allows for more granular application of universal security policies at the VM level. Additionally, users can now leverage ApplyTo even in cases where network virtualization is not being utilized, for example, a deployment leveraging NSX just for the benefits of Cross-VC NSX multi-site security.

Figure 3: Leveraging Universal Security Group with ApplyTo in UDFW

 

2.) Enhancements for Active/Standby Use Case

Figure 4: Cross-VC NSX Active/Standby Deployment Model

 
– Universal Security Tags

Starting NSX-V 6.3, Cross-VC NSX supports Universal Security Tags. When a Universal Security Tag is created on the Primary NSX Manager, it’s automatically synced to the Secondary NSX Manager(s) as shown below.

Figure 5: Universal Security Tag Creation and Sync

 
As mentioned prior, these enhancements are more applicable to Active/Standby use cases such as disaster recovery (DR). So when a VM is vMotioned or recovered at a secondary site, the Secondary NSX Manager needs some method of attaching the correct security tag to the correct VM. The Unique ID Selection Criteria setting under Installation–>Management–>Actions on the Primary NSX Manager is used to achieve this as shown in Figure 6 below.

For the Unique ID Selection Criteria, Virtual Machine Instance UUID is typically sufficient for cases such as disaster recovery with VMware’s Site Recovery Manager (SRM) and vMotion. Virtual Machine Instance UUID is guaranteed to be unique for each VM within a specific vCenter; it’s not guaranteed to be unique across different vCenters, but it’s rare for there to be overlap since each Virtual Machine Instance UUID is also based on a unique vCenter ID. vSphere Replication and vMotion will both maintain the Virtual Machine Instance UUID of the VM at the recovery/secondary site. The user has the option to use different or multiple selection criteria based on their environment. If each VM in the environment has a unique VM name, VM name can also be used for the unique selection criteria to ensure the correct security tags are attached to the correct VMs.

Figure 6: Setting Unique Selection Criteria

 
Figure 7 below shows the flow in terms of utilizing Universal Security Tags for Active/Standby deployments.

Figure 7: Flow for Utilizing Universal Security Tags in Active/Standby Deployments

 
– Universal Security Group with New Matching Criteria

In NSX-V 6.3, UDFW rules can now leverage Universal Security Groups with new matching criteria of:

  • VM Name (dynamic)
  • Universal Security Tag (static)

Since UDFW rules can now use Universal Security Groups based on VM Name and Universal Security Tag, security policies can be more fluid and not rely on IP addresses.

Figure 8: Using VM Name Matching Criteria in Universal Security Group

 

Figure 9: Using Universal Security Tag Matching Criteria in Universal Security Group

 
Figure 10 below shows, Universal Security Groups with matching criteria of Universal Security Tags being used in a UDFW rule.

Figure 10: Leveraging Universal Security Group with Universal Security Tag in UDFW Rule

 
As mentioned prior, it’s important to note enhancements listed here are applicable primarily for Active/Standby use cases such as DR. The reason for this is the local NSX Manager does not have visibility into the inventory of the other NSX Managers’ vCenters. Thus, when a security rule is utilized with the Universal Security Groups leveraging the new supported matching criteria of VM Name or Universal Security Tag in the source/destination fields, since the translation of the security group happens locally, only the VMs/workloads in the local vCenter will be found as members of the security group.

Thus, when leveraging Universal Security Groups with the new supported matching criteria, the entire application must be at the same site as shown below in Figure 11. For example, if the application is spanning across sites and there is Cross-VC traffic flows, the security policy for the application will not provide the desired results.

Figure 11: Entire Application Must be at Same Site When Using UDFW Rules Leveraging USGs with New Matching Criteria

 

For more information on NSX-V 6.3, check-out the NSX-V 6.3 documentation.
 

The post NSX-V 6.3: Cross-VC NSX Security Enhancements appeared first on The Network Virtualization Blog.

Feb 092017
 

A question came up recently from a customer that went something like this: “I am looking for an active/active configuration for disaster avoidance and disaster recovery with a recovery time objective of 0 minutes and a recovery point objective of 0 minutes. Is this something I can achieve with VMware vSAN and/or Site Recovery Manager

The post vSAN and SRM RPO and RTO appeared first on Virtual Blocks.

Jan 282017
 

The other day I saw NetApp announced a new Storage Replication Adapter for VMware Site Recovery Manager so I reached out to my NetApp buddyChris Gebhardt for more details. Chris shared the following information so I thought I would pass it along. By Chris Gebhardt, Principle Technical Marketing Engineer at NetApp For those who may

The post NetApp SRA 4.0 for Site Recovery Manager appeared first on Virtual Blocks.

Jan 202017
 

VMware vSphere Replication 6.5 is the latest version of vSphere Replication (VR) released with vSphere 6.5, vCenter Server 6.5, and Site Recovery Manager (SRM) 6.5. VR is a host-based virtual machine (VM) replication solution that works with nearly any storage type supported by vSphere. VR is deployed as a virtual appliance using an Open Virtualization

The post OVF Choices When Deploying vSphere Replication 6.5 appeared first on Virtual Blocks.

Jan 202017
 

To answer the question in the title, very fast. Here is a 2 minutevideo I recently recorded showing SRM recovering 1000 VMs in less than 26 minutes. This was done with SRM 6.5, vSphere Replication 6.5 and vSAN 6.5. It isn’t so much to show what results you will achieve, rather what vSphere, vSAN, vCenter,

The post How fast can you recover 1000 VMs with SRM? appeared first on Virtual Blocks.

Jan 102017
 

In this post, I’ll briefly expand on the benefits of utilizing NSX as part of a disaster recovery (DR) solution. For additional information check out my prior multi-site and disaster recovery with NSX posts on the VMware Network Virtualization blog. Additionally, I recently presented at 2016 US VMworld and Europe VMworld on multi-site and disaster recovery solutions and recorded sessions can be viewed here: US VMworld, Europe VMworld.

Prior NSX Multi-site and Disaster Recovery Posts:

  • Cross-VC NSX for Multi-site Solutions
  • Enhanced Disaster Recovery with Cross-VC NSX and SRM
  • NSX-V: Multi-site Options and Cross-VC NSX Design Guide
  • Cross-VC NSX: Multi-site Deployments with Ease and Flexibility
  • Multi-site with Cross-VC NSX: Consistent Security and Micro-segmentation Across Sites
  • Multi-site with Cross-VC NSX and Palo Alto Networks Security

With disaster recovery, two challenges in general are:

    1. Recovering the application with the same IP address at the recovery site; this is important because typically there are other dependencies on this IP address such as possibly security, load balancer configs, DNS, application dependencies, etc.
    2. Ensuring security for the application is in place for the application upon disaster recovery; traditional solutions rely on manually updating or syncing security policies across the protected and recovery sites which is cumbersome and operationally challenging, time consuming, and also error-prone.

    If we look at traditional DR solutions we’ll find they’re not holistic solutions. For example, to allow for maintaining an applications’ IP address and to support scenarios such as partial application failure, L2 extension is desired.

    To achieve L2 extension traditional networking approaches such as simple L2 over dark fiber, VPLS over MPLS backbone, hardware based solutions such as OTV, etc., are leveraged. However, this does not address the security or automation aspects. These traditional methods are only focused on the network and per-device configuration and lack the automation and flexibility needed. Thus these traditional solutions are also complex and operationally challenging.

    Leveraging NSX for multi-site solutions and specific use cases like disaster avoidance and disaster recovery, provide the following benefits in general:

    • decoupling from physical infrastructure
    • ease of deployment and use
    • flexibility
    • high degree of automation
    • rapid application deployment/recovery and productivity
    • extensive partner ecosystem for services
    • integration with other DR & SDDC components (Site Recovery Manager (SRM), vSphere hypervisor, vRealize Suite, etc.)

    More specifically, as shown in the below figure, when leveraging the Cross-VC NSX feature for multi-site and disaster recovery, we can easily have L2 extension over an L3 underlay across vCenter domains. These vCenter domains may also be across multiple sites.

    Figure 1: Disaster Recovery with Cross-VC NSX and SRM

    DR orchestration tools such as SRM require two vCenters (one for each site) for additional segmentation. As such Cross-VC NSX, which allows for consistent logical networking and security across multiple vCenter domains/sites, is a perfect fit for the DR use case. This allows our DR orchestration tool, such as SRM, to recover the workloads at the recovery site while maintaining the IP address.

    Further, Cross-VC NSX allows for central management of security policies at the protected site and ensures consistent security policies across the protected and recovery sites. In effect, we are also achieving an enhanced security model with micro-segmentation across sites. See the following prior post on the VMware Network Virtualization blog site: Multi-site with Cross-VC NSX: Consistent Security and Micro-segmentation Across Sites

    In addition, SRM has integration with NSX where if Storage Policy Protection Groups (SPPGs) are used in SRM, automatic mapping can be done between networks at the protected site and recovery site as shown below. SPPGs allows automating and more easily protecting workloads by simply selecting a storage policy when deploying respective workload; the workload will automatically be protected and deployed on a protected datastore.

    Figure 2: Automatic Network Mapping with Storage Policy Protection Groups (SPPGs)

    vSphere replication can also be used instead of array based replication and allows for selectively replicating on a per VM basis and also requires no dependency on having the same hardware vendor storage at both the the protected and recovery sites. A diagram of an example DR deployment leveraging Cross-VC NSX, 3rd party security services for advanced security (Palo Alto Networks in this example), vSphere replication, and SRM is shown below.

    Figure 3: Example NSX + SRM DR Deployment

    One of the key benefits of the NSX + SRM DR solution is how easily you can setup test networks and test recovery plans with no disruption to the production environment. NSX can be used to easily create test networks which SRM can utilize when testing recovery plans.

    SRM can use the same logical networks to failover applications upon an actual disaster; however, for testing of recovery plans, SRM can be configured to use the test networks created by NSX. Using a dedicated test network to test recovery plans allows for testing in an isolated environment while maintaining the same application IP addresses and security policies at the recovery site; this can be done with no disruption to the production environment.

    The below two figures show test universal logical switches and a test universal distributed logical router (DLR) created with NSX which will be used by SRM when testing recovery plans. Since seperate logical switches and DLR are used for testing, overlapping IPs with applications on the production network can exist. East-West connectivity and traffic flow can be tested here easily via test DLR. If North/South testing is also required, you will want to create a duplicate network for upstream as well as to not disrupt production traffic.

    Figure 4: Test Universal Logical Networks

     

    Figure 5: Test Universal Distributed Logical Router

    The figure below shows the configuration within SRM which shows the same production logical networks will be used at the recovery site upon disaster recovery, and, for testing of recovery plans, the test logical networks will be utilized.

    Figure 6: SRM Network Mapping Configuration

    Now when we run the test of the recovery plan within SRM, the NSX test logical networks will be utilized without any disruption to our production environment as shown in the figure below. We can quickly create as many test networks as needed with NSX for different application/tenant environments and easily test numerous recovery plans.

    Figure 7: Testing SRM Recovery Plan

    Trying to accomplish this without network virtualization would be time consuming and error-prone where configuration would involve new VLANs created on the physical network, VRFs utilized for overlapping IPs or remapping networks, routing updates, and updating and ensuring correct security policies are in place at the recovery site. With NSX, the entire process is greatly simplified and automated.

    Additionally, within SRM, priorities and dependencies can be used as shown below to orchestrate the order of when workloads/apps should be recovered. For example, in the below figure priorities are used to ensure the DB tier is recovered first, second the App tier, and finally the Web tier; this is done to ensure that when the Web application is recovered, the required backend services are in place so the application does not throw errors and works correctly.

    Figure 8: Using Priorities in SRM

    For a quick overview with walkthrough and demo of the NSX + SRM Disaster Recovery solution, please make sure to checkout the video at the top of this post. Additional information and hands-on-lab on multi-site and disaster recovery with NSX can be found at the below links.

    • Prior multi-site and disaster recovery posts on the VMware Network Virtualization blog
    • NSX-V Multi-site Options and Cross-VC NSX Design Guide
    • Disaster Recovery with NSX and SRM
    • HOL-1725-USE-2 – VMware NSX Multi-Site DR with SRM

    The post VMware NSX and SRM: Disaster Recovery Overview and Demo appeared first on The Network Virtualization Blog.

    Jan 102017
     

    In this post, I’ll briefly expand on the benefits of utilizing NSX as part of a disaster recovery (DR) solution. For additional information check out my prior multi-site and disaster recovery with NSX posts on the VMware Network Virtualization blog. Additionally, I recently presented at 2016 US VMworld and Europe VMworld on multi-site and disaster recovery solutions and recorded sessions can be viewed here: US VMworld, Europe VMworld.

    Prior NSX Multi-site and Disaster Recovery Posts:

    • Cross-VC NSX for Multi-site Solutions
    • Enhanced Disaster Recovery with Cross-VC NSX and SRM
    • NSX-V: Multi-site Options and Cross-VC NSX Design Guide
    • Cross-VC NSX: Multi-site Deployments with Ease and Flexibility
    • Multi-site with Cross-VC NSX: Consistent Security and Micro-segmentation Across Sites
    • Multi-site with Cross-VC NSX and Palo Alto Networks Security

    With disaster recovery, two challenges in general are:

      1. Recovering the application with the same IP address at the recovery site; this is important because typically there are other dependencies on this IP address such as possibly security, load balancer configs, DNS, application dependencies, etc.
      2. Ensuring security for the application is in place for the application upon disaster recovery; traditional solutions rely on manually updating or syncing security policies across the protected and recovery sites which is cumbersome and operationally challenging, time consuming, and also error-prone.

      If we look at traditional DR solutions we’ll find they’re not holistic solutions. For example, to allow for maintaining an applications’ IP address and to support scenarios such as partial application failure, L2 extension is desired.

      To achieve L2 extension traditional networking approaches such as simple L2 over dark fiber, VPLS over MPLS backbone, hardware based solutions such as OTV, etc., are leveraged. However, this does not address the security or automation aspects. These traditional methods are only focused on the network and per-device configuration and lack the automation and flexibility needed. Thus these traditional solutions are also complex and operationally challenging.

      Leveraging NSX for multi-site solutions and specific use cases like disaster avoidance and disaster recovery, provide the following benefits in general:

      • decoupling from physical infrastructure
      • ease of deployment and use
      • flexibility
      • high degree of automation
      • rapid application deployment/recovery and productivity
      • extensive partner ecosystem for services
      • integration with other DR & SDDC components (Site Recovery Manager (SRM), vSphere hypervisor, vRealize Suite, etc.)

      More specifically, as shown in the below figure, when leveraging the Cross-VC NSX feature for multi-site and disaster recovery, we can easily have L2 extension over an L3 underlay across vCenter domains. These vCenter domains may also be across multiple sites.

      Figure 1: Disaster Recovery with Cross-VC NSX and SRM

      DR orchestration tools such as SRM require two vCenters (one for each site) for additional segmentation. As such Cross-VC NSX, which allows for consistent logical networking and security across multiple vCenter domains/sites, is a perfect fit for the DR use case. This allows our DR orchestration tool, such as SRM, to recover the workloads at the recovery site while maintaining the IP address.

      Further, Cross-VC NSX allows for central management of security policies at the protected site and ensures consistent security policies across the protected and recovery sites. In effect, we are also achieving an enhanced security model with micro-segmentation across sites. See the following prior post on the VMware Network Virtualization blog site: Multi-site with Cross-VC NSX: Consistent Security and Micro-segmentation Across Sites

      In addition, SRM has integration with NSX where if Storage Policy Protection Groups (SPPGs) are used in SRM, automatic mapping can be done between networks at the protected site and recovery site as shown below. SPPGs allows automating and more easily protecting workloads by simply selecting a storage policy when deploying respective workload; the workload will automatically be protected and deployed on a protected datastore.

      Figure 2: Automatic Network Mapping with Storage Policy Protection Groups (SPPGs)

      vSphere replication can also be used instead of array based replication and allows for selectively replicating on a per VM basis and also requires no dependency on having the same hardware vendor storage at both the the protected and recovery sites. A diagram of an example DR deployment leveraging Cross-VC NSX, 3rd party security services for advanced security (Palo Alto Networks in this example), vSphere replication, and SRM is shown below.

      Figure 3: Example NSX + SRM DR Deployment

      One of the key benefits of the NSX + SRM DR solution is how easily you can setup test networks and test recovery plans with no disruption to the production environment. NSX can be used to easily create test networks which SRM can utilize when testing recovery plans.

      SRM can use the same logical networks to failover applications upon an actual disaster; however, for testing of recovery plans, SRM can be configured to use the test networks created by NSX. Using a dedicated test network to test recovery plans allows for testing in an isolated environment while maintaining the same application IP addresses and security policies at the recovery site; this can be done with no disruption to the production environment.

      The below two figures show test universal logical switches and a test universal distributed logical router (DLR) created with NSX which will be used by SRM when testing recovery plans. Since seperate logical switches and DLR are used for testing, overlapping IPs with applications on the production network can exist. East-West connectivity and traffic flow can be tested here easily via test DLR. If North/South testing is also required, you will want to create a duplicate network for upstream as well as to not disrupt production traffic.

      Figure 4: Test Universal Logical Networks

       

      Figure 5: Test Universal Distributed Logical Router

      The figure below shows the configuration within SRM which shows the same production logical networks will be used at the recovery site upon disaster recovery, and, for testing of recovery plans, the test logical networks will be utilized.

      Figure 6: SRM Network Mapping Configuration

      Now when we run the test of the recovery plan within SRM, the NSX test logical networks will be utilized without any disruption to our production environment as shown in the figure below. We can quickly create as many test networks as needed with NSX for different application/tenant environments and easily test numerous recovery plans.

      Figure 7: Testing SRM Recovery Plan

      Trying to accomplish this without network virtualization would be time consuming and error-prone where configuration would involve new VLANs created on the physical network, VRFs utilized for overlapping IPs or remapping networks, routing updates, and updating and ensuring correct security policies are in place at the recovery site. With NSX, the entire process is greatly simplified and automated.

      Additionally, within SRM, priorities and dependencies can be used as shown below to orchestrate the order of when workloads/apps should be recovered. For example, in the below figure priorities are used to ensure the DB tier is recovered first, second the App tier, and finally the Web tier; this is done to ensure that when the Web application is recovered, the required backend services are in place so the application does not throw errors and works correctly.

      Figure 8: Using Priorities in SRM

      For a quick overview with walkthrough and demo of the NSX + SRM Disaster Recovery solution, please make sure to checkout the video at the top of this post. Additional information and hands-on-lab on multi-site and disaster recovery with NSX can be found at the below links.

      • Prior multi-site and disaster recovery posts on the VMware Network Virtualization blog
      • NSX-V Multi-site Options and Cross-VC NSX Design Guide
      • Disaster Recovery with NSX and SRM
      • HOL-1725-USE-2 – VMware NSX Multi-Site DR with SRM

      The post VMware NSX and SRM: Disaster Recovery Overview and Demo appeared first on The Network Virtualization Blog.

      Nov 122016
       

      Storage Policy-Based Protection Groups (SPPGs) are a very helpfulto Site Recovery Manager and I wrote a detailed post about them here. Just as a quick reminder of what they are, SPPGs makethe protection of VMs and datastores simple and dynamic. Need to protect a VM? Associate it with a storage policy and place it onto

      The post SRM SPPG Resources appeared first on Virtual Blocks.