As discussed in prior Cross-VC NSX/multi-site blogs, Cross-VC NSX allows for NSX logical networking and security across multiple vCenter domains which may also be across multiple sites. The benefits of this capability are immediately clear in terms of workload mobility, resource pooling, central management and application of consistent security policies across vCenter domains/sites, and disaster recovery. More details on these use cases can be found in the prior Cross-VC NSX blogs listed below or in the recently published NSX-V: Multi-site Options and Cross-VC NSX Design Guide. This blog post, focuses on the ease and flexibility in terms of application of Cross-VC NSX for multi-site.
In this example, vCenter, the primary NSX Manager, and the Universal Controller Cluster (UCC) is deployed at site 1. A secondary NSX Manager which is registered with the primary NSX Manager is deployed at site 2 along with its corresponding vCenter. For a quick overview on primary NSM Manager, secondary NSX Manager, and the UCC see this prior blog. For more detailed information, see the NSX-V: Multi-site Options and Cross-VC NSX Design Guide.
Figure 2 below displays the primary and secondary NSX Managers and corresponding UCC cluster and connectivity. The UCC is deployed from the primary NSX Manager and is deployed at site 1 within the vCenter the primary NSX Manager is linked to. Only three universal controllers exist at the primary site which manage all universal and local objects for all vCenter domains within the Cross-VC NSX deployment. However, in Figure 2 below you can see within the NSX GUI NSX Controllers Node section under Installation the connectivity status is shown from all controllers to all NSX Managers.
As you can see from Figure 3 below, The UCC is deployed in the Edge cluster at site 1.
Once NSX is configured and primary NSX Manager, secondary NSX Manager, and UCC deployed, one can easily start creating logical networks across sites within seconds with the click of a button.
If a tenant wants to achieve Active/Active deployments where active workloads for the same segment sit at both sites, this can easily be done because logical L2 spans across both sites. Further, since Cross-VC NSX expands logical networking and security across vCenter domains, workloads can easily move between the vCenter domains across sites without any change in application IP address or security policies. Figure 5 below shows Universal Distributed Firewall rules applied under the Universal Section.
If the same tenant wants only site 1 to be the egress for North/South traffic, this can easily be done by deploying a Universal Control VM, which is the control plane for the Universal Distributed Logical Router (UDLR), at the primary site and using routing metric/weight to ensure all North/South traffic takes the route through site 1 Edge Service Gateways (ESGs). The Universal Control VM peers with ESGs at both site 1 and site 2.
In this model North/South traffic follows an active/passive model where site 1 ESGs are active and site 2 ESGs are passive for North/South traffic. Having a single site as the Ingress/Egress point for North/South traffic simplifies deployment and operations and may be a requirement for cases where stateful services are utilized North/South and asymmetric traffic flows must be avoided. Such a deployment is shown below.
If a tenant wants Active/Active North/South traffic flow and is not concerned about asymmetric traffic flow or has a solution for controlling ingress traffic, the Local Egress feature can be used to provide site-specific North/South traffic flow. The Local Egress feature can be enabled when creating a UDLR.
Local Egress allows control of what routes are provided to ESXi hosts based on a unique identifier, the Locale ID. All hosts within a NSX Manager domain have the same Locale ID; by default, it’s the UUID of the site-local NSX Manager. The Universal Control VM at each site learns routes from the physical network via the site-local ESGs. The UCC then learns the best forwarding paths with associated Locale ID from each site’s Universal Control VM. Finally, the UCC distributes the best forwarding path information to ESXi hosts with matching Locale ID. This process allows for site-local egress. Such a deployment using Local Egress is shown below. Note, in this deployment model, a Universal Control VM exists at each site.
As you can see, Cross-VC NSX provides flexibility and multiple deployment options. In fact, it’s also possible to deploy a NSX environment with multiple tenants where some tenants are using Active/Passive site egress and others are using Active/Active site egress. Such a deployment is shown below where Tenant 1 and Tenant 2 use the same UDLR and a single Universal Control VM with Active/Passive site egress. Tenant 3 uses a different UDLR with Local Egress and correspondingly a different Universal Control VM on site 1 and site 2; this allows for Active/Active site egress. In this case there are no overlapping IP addresses between tenants. Separate UDLRs and ESGs can also be used for each tenant if overlapping IP addresses or additional isolation is a requirement.
To close, if you plan on attending VMworld 2016, and, if you would like more information on Cross-VC NSX and multi-site, please be sure to attend the below sessions where the fundamentals of Cross-VC NSX and additional details will be discussed. In each session, a demo will also be shown to provide more clarity and further expand on discussion points. Hope to see you there!
VMworld 2016 Sessions for Multi-Site with Cross-VC NSX: