Cross-vCenter NSX allows network virtualization and security policies across multiple vCenter Server systems to be managed centrally. Universal objects have been introduced; such as universal logical switches, universal logical routers, and universal distributed firewall rules. Universal objects are able to span multiple sites or vCenter Server instances, enhancing workload mobility by allowing cross vCenter and long distance vMotion for virtual machines, whilst keeping the same network settings and firewall rules.
The increased span of NSX logical networks across the environment means virtual machines are able to connect to the same network across different sites, with the same policies applied. This improves DR capabilities, overcomes scale limits of vCenter Server, and gives administrators more control over resource pooling and the separation of environments.
How Cross-vCenter NSX Works
Cross vCenter-NSX was introduced in NSX v6.2 and requires vSphere v6.0 or later. As normal NSX Manager is deployed with vCenter server in a 1:1 pairing. In a single site NSX deployment the NSX Manager is given the standalone role by default. When configuring cross-vCenter NSX one NSX Manager is assigned the primary role, and up to seven other NSX Managers are assigned the secondary role. NSX Managers configured for cross-vCenter NSX must all be running the same version.
The primary NSX Manager is responsible for deploying the Universal Controller Cluster, forming the control plane across the NSX Managers. The Universal Controller Cluster runs in the site of the primary NSX Manager. Universal objects are created on the primary NSX Manager and automatically synchronized across the multi-site NSX environment.
The secondary NSX Manager(s) synchronize with the primary using the Universal Synchronization Service. These sites do not run any NSX Controllers, although they can be redeployed easily in the event of a primary site outage. Before assigning the secondary role you should ensure there are no existing NSX Controllers deployed in the associated vCenter. The Segment ID Pool across multi-site NSX Managers must not overlap.
Local objects such as logical switches, logical routers, and Edge Service Gateways can still be deployed from each NSX Manager, although by design they are only local to the vCenter linked to that specific NSX Manager, and cannot be deployed or edited elsewhere.
If you are using vCenter enhanced linked mode then multiple NSX Manager instances are displayed within the same interface, or single pane of glass, when managing the Network & Security section of the vSphere web client. Enhanced linked mode is not a requirement for cross-vCenter NSX however, and vCenter Server systems not in enhanced linked mode can still be configured for cross-vCenter NSX. Without linking vCenter Server systems only the registered NSX Manager for the vCenter Server you are accessing will be visible in the vSphere web client, although universal objects can be created, and will still be synchronized across the NSX Managers assigned the primary and secondary roles.
Sites configured in a cross-vCenter NSX environment can use the same physical routers for egress traffic, or have the local egress feature enabled within a universal logical router. The local egress feature allows routes to be customized at host, cluster, or router level.
For more information on cross-vCenter NSX design see the following VMware blog posts:
- Cross-VC NSX: Multi-site Deployments with Ease and Flexibility
- NSX-V: Multi-site Options and Cross-VC NSX Design Guide
- Cross-VC NSX for Multi-site Solutions
For more information on NSX you may also want to review the following posts on this site: