NSX Multi-Site Architecture

NSX Multi-Site Capabilities

Most enterprise deployments of vSphere and NSX have multiple sites and multiple vCenter Servers.  Luckily, NSX is capable of fitting into a multi-site architecture and reducing some of the duplicative complexities associated with such an architecture.

NSX can run in a multi-site fashion, with highly available a universal controller cluster (runs at a single site) and an NSX manager running at each location.  The NSX manager runs a universal synchronization service that is responsible for replicating changes between sites and making all sites compatible with each other.

Once a multi-site NSX implementation is deployed, NSX is capable of creating universal objects that automatically get synchronized across sites:

  • Universal Logical Switch
  • Universal Distributed Logical Router
  • Universal Distributed Firewall
  • Universal Transport Zone

Much as you would expect, these universal constructs act identically to their local counterparts, with the exception being that they are automatically created and synchronized across site boundaries.

Multi-Site Use Cases

The NSX multi-site architecture enables a number of use cases involving spanning network constructs across sites.  The most widely sought after use case is the ability to stretch layer-2 networks across sites and move workloads between sites seamlessly without making changes to IP addressing, DNS entries, etc.

Using a stretched subnet joined across sites through the use of a universal logical switch, workloads can be vMotioned between vCenter servers, yet maintain network configuration with no changes necessary to keep the workload functioning as normal.

As an extension of this same idea, disaster recovery can be better achieved by coupling the NSX multi-site design with VMware Site Recovery Manager.  Once networking is stretched across vCenter servers and sites, SRM can layer on top to manage the orchestrated failover of protected workloads across sites.  The networking and connectivity aspects of the failover are now simplified due to the availability of the required networking being native to each site.

Implementing Networking and Security Policy Consistency Across Sites

Because the NSX multi-site architecture spans vCenter Server and site boundaries, it becomes much simpler to implement a set of networking constructs and policies and flow them down to each site.  No longer are you required to manage each site independently and deal with the consequences of misconfigurations at remote sites causing erratic behavior, or worse – security breaches due to misconfigured security policies.

The NSX universal distributed firewall can aid in the implementation of universal security groups and firewall rules that help ensure network security is enforced consistently across the enterprise.  With the added capability to move workloads around seamlessly, this particular feature becomes much more important as the security policy enforcement can now follow the workload wherever it roams across the network.

Components For a Multi-Site NSX Architecture

The components required to implement a multi-site architecture are essentially exactly the same as would be necessary to implement multiple single-site architectures.  Once site will deploy the highly available 3-node universal controller cluster.  Every site, including the primary and secondary sites, will have an NSX manager deployed.  Each site is defined by having a vCenter Server installed at that site.  Thus, each site’s NSX manager is paired to the local vCenter Server at that site and is setup as a secondary NSX manager in the multi-site configuration. 

It is possible to implement local egress at the secondary sites using locally deployed NSX Edge Services Gateways.  This allows for traffic to avoid traversing WAN links when unnecessary in order to egress the virtual environment.  For example, without local egress being deployed, traffic might have to route from site B to site A in order to egress the virtual environment, and then traverse the WAN from site A back to Site B in order to access the final destination.  With local egress enabled, this extra set of hops is circumvented and the traffic is able to egress locally, providing additional efficiency.

After the basic installation is complete, one or more universal transport zones will be configured, with clusters joined to them as they would be in a normal transport zone configuration.  Universal Distributed Logical Routers and Universal Logical Switches are layered on top to complete the basic building blocks of the distributed configuration.  Under the hood, these objects are identical to the local component versions, but are automatically created and synchronized across the multi-site architecture.  This is a similar capability to how vSphere Distributed Virtual Switches operate – their configuration is managed centrally, but they are implemented on each host as a local entity.


Leave a comment