When NSX 6.2.0 came out, this provided us with some interesting options.
First of all, let me recap some of the new features in 6.2, as it is a very different beast than 6.1. However there are dozens of new features that I will not go into in this article that, although are very important, not as relevant to SRM implementations.
Cross vCenter Networking and Security
- NSX 6.2 with vSphere 6.0 supports Cross vCenter NSX where logical switches (LS), distributed logical routers (DLR) and distributed firewalls (DFW) can be deployed across multiple vCenters, thereby enabling logical networking and security for applications with workloads (VMs) that span multiple vCenters or multiple physical locations.
- Consistent firewall policy across multiple vCenters: Firewall Rule Sections in NSX can now be marked as “Universal” whereby the rules defined in these sections get replicated across multiple NSX managers. This simplifies the workflows involving defining consistent firewall policy spanning multiple NSX installations
- Cross vCenter vMotion with DFW: Virtual Machines that have policies defined in the “Universal” sections can be moved across hosts that belong to different vCenters with consistent security policy enforcement.
- Universal Security Groups: Security Groups in NSX 6.2 that are based on IP Address, IP Set, MAC Address and MAC Set can now be used in Universal rules, whereby the groups and group memberships are synced up across multiple NSX managers. This improves the consistency in object group definitions across multiple NSX managers, and enables consistent policy enforcement
- Universal Logical Switch (ULS): This new functionality introduced in NSX 6.2 as a part of Cross vCenter NSX allows creation of logical switches that can span multiple vCenters, allowing the network administrator to create a contiguous L2 domain for an application or tenant.
- Universal Distributed Logical Router (UDLR): This new functionality introduced in NSX 6.2 as a part of Cross vCenter NSX allows creation of distributed logical routers that can span multiple vCenters. The universal distributed logical routers enable routing across the universal logical switches described earlier. In addition, NSX UDLR is capable of localized north-south routing based on the physical location of the workloads.
The biggest problem with SRM has been that although the VMs can failover and fail-back without issue, the IP addressing, and DNS had to be modified in order for VMs to operate correctly. This could be done by orchestration and it’s built into SRM, but it increases the downtime during the failover process because every VM needs to boot up several times to apply the changes.
Now with NSX 6.2 and Universal objects, this is not the case anymore. This revolutionizes the DR process, reducing Recover Time Objectives (RTO) and simplifying runbooks.
Disaster Recovery Scenarios
Disaster Recovery solution with NSX is designed and tested to support the following failure and recovery conditions:
• Partial Application Failover – Only a part of application failed over from Protected to Recovery site. The application components on the Protected and Recovery site continue to function and communicate as before.
• Full Application Failover – Entire application failed over from the Protected site to the Recovery site .
• Site Failure – The entire site has failed including NSX components at the protected site. The application and NSX components are recovered at the recovery site.
This excerpt below is taken from the whitepaper describing the solution.
Read the full whitepaper here.
As outlined in the physical design, the solution leverages NSX 6.2 universal objects to create a single unified logical network that exists at both the Protected and Recovery site.
Protected applications are placed on a Universal Logical Switch which is connected to a Universal Distributed Logical Router. Security policies are configured using Universal Distributed Firewall rules.
This set-up ensures that the entire Logical Network (L2, L3, and Firewall) for the application spans seamlessly across both sites. When the application fails over, it gets placed on the same logical network as was on the recovery site and ensures the same consistent security policy via Universal Distributed Firewall Rules.
The logical objects are created only once on the Primary NSX Manager and are immediately synchronized to the Secondary NSX Manager(s); this leads to guaranteed correctness (since no manual intervention is needed) while the application’s networking and security is built automatically without modifying the underlying physical infrastructure.
Since the entire configuration is synchronized from Primary to Secondary NSX Manager(s) – loss of Primary NSX Manager (and associated Universal Controller Cluster) doesn’t lead to any loss on Logical Network and Security configuration for the application.
Universal Logical Switching across the two sites over Layer-3 physical fabric provides IP address preservation for the application while maintaining a stable and scalable physical underlay– allowing the application to failover without any remapping to a new IP subnet at the recovery site. The Universal DFW based security policies in place at the Recovery site will remain in force since the application IP address is fully preserved.