I also published this blog post about mult-site options and Cross-VC NSX design on the VMware NSX Network Virtualization Blog on July 22, 2016. The full blog post is provided below and can also be seen on the VMware NSX Network Virtualization Blog site.
VMware NSX Network Virtualization Blog
Title: NSX-V: Multi-site Options and Cross-VC NSX Design Guide
Author: Humair Ahmed
Date Published: July 22, 2016
Check-out the new NSX-V Multi-site Options and Cross-VC NSX Design Guide. Feel free to provide me any feedback you may have.
The goal of this design guide is to outline several NSX solutions available for multi-site data center connectivity before digging deeper into the details of the Cross-VC NSX multi-site solution. Learn how Cross-VC NSX enables logical networking and security across multiple vCenter domains/sites and how it provides enhanced solutions for specific use cases. No longer is logical networking and security constrained to a single vCenter domain. Cross-VC NSX use cases, architecture, functionality, design, and failure/recovery scenarios are discussed in detail.
Outlined briefly below are several important use cases that Cross-VC NSX enables in regards to Application Continuity. For additional details on Cross-VC NSX and multi-site data center solutions see the NSX-V Multi-site Options and Cross-VC NSX Design Guide.
Use Case 1: Workload Mobility
Since logical networking and security can span multiple vCenter domains and multiple sites, Cross-VC NSX allows for enhanced workload mobility which can not only span multiple sites but also multiple vCenter domains across Active-Active data centers. Workloads can now move between vCenter domains/sites on demand for tasks such as data center migration, data center upgrades/security patches, disaster avoidance, etc. Workload mobility boundaries are no longer constrained by artificial vCenter boundaries as the IP address and security policies for the workload remain consistent across vCenter domains/sites.
Use Case 2: Resource Pooling
By enabling logical networking and security across multiple vCenters, Cross-VC NSX allows for the ability to access and pool resources from multiple vCenter domains. This allows for better utilization of resources across multiple vCenter domains or sites. If resources such as storage, CPU, or memory are low at one site, the workload can be deployed or migrated to another site while still utilizing the same logical networking and security. Resources are no longer isolated based on vCenter boundaries and idle capacity within another vCenter domain/site can be leveraged for better overall resource utilization.
Use Case 3: Unified Logical Networking and Security Policy
Cross-VC NSX enables a consistent security policy across vCenter boundaries and sites. NSX provides centralized management on the primary NSX manager for security rules across all vCenter domains/sites. Users are no longer required to manually replicate security policies across different domains/sites. The NSX Rest API can also be leveraged so that only one call to the primary NSX Manager at Site 1 results in a consistent security policy across all sites for the application; this is demonstrated in the figure below.
Use Case 4: Disaster Recovery
By enabling the span of logical networks and security across sites, Cross-VC NSX inherently provides features desired for disaster recovery. Since logical networking and security spans across sites, applications can recover at the recovery site upon a disaster recovery (DR) event and maintain their IP addresses. Further, security enforcement for the application is maintained due to the universal distributed firewall and security policies.
Also, using the Local Egress feature, NSX provides advanced control over egress traffic with cluster or host level granularity. This allows the selection of which set of ESGs are used for egress by traffic from the respective workloads. This can be a very powerful tool for various partial failure scenarios.
Additionally, Cross-VC NSX also improves upon the DR use case typically provided by VMware Site Recovery Manager (SRM). SRM has a 1:1 relationship to vCenter server and utilizes an active/standby model. All workloads are running on the active site with placeholder VMs at the standby recovery site in-case of failover.
NSX has tight product integration with SRM. For example, the source and destination networks for the VMs are automatically mapped if they’re connected to Cross-VC NSX networks. There is no longer a need to do any manual mapping as all networking and security services are synchronized across sites; NSX also ensures that workloads maintain their IP addresses when recovered. See this prior blog post for more information on DR with Cross-VC NSX and SRM.
Check-out the NSX-V Multi-site Options and Cross-VC NSX Design Guide for more details.
Follow me on Twitter: @Humair_Ahmed