Cross-VC NSX: Simplicity and Flexibility for Multiple Deployments

As you know, Cross-VC NSX enables multi-site functionality — it provides centralized vertical routing between logical networks deployed in NSX domains and external physical network infrastructure.

The benefits of this feature are clear at a glance - we are talking about mobility, workload distribution, creating resource pools, centralized management and applying security policies for vCenter domains / sites, and disaster recovery. This article is not devoted to the study of detailed technical indicators, and the ease and flexibility in terms of applying Cross-VC NSX for several sites.


In this example, vCenter, the main NSX Manager, and the Universal Controller Cluster (UCC) are deployed at site 1. A secondary NSX Manager, registered with the primary NSX Manager, is deployed at site 2 with the appropriate vCenter.

Picture 1
')
Figure 2 shows NSX managers with the primary and secondary roles, as well as the corresponding UCC clusters and interconnections. The Universal Controller Cluster is deployed from the NSX Manager with the “primary” role on site 1 inside the vCenter, to which the NSX Manager with the “primary” role is linked.

On the main site there are only 3 universal controllers that control all universal and local objects for all vCenter domains within the Cross-VC NSX deployment. However, in Figure 2, inside the NSX Controllers Node section, the status of all controllers pertaining to all NSX Managers.

Figure 2

As you can see in Figure 3, the Universal Controller Cluster is deployed in the Edge cluster on site 1.

Figure 3

Once the NSX configurations are configured, the “primary” and “secondary” roles for the NSX Manager are selected, and the UCC is deployed, you can begin to create logical networks connecting different sites with a single click of a button.

Figure 4

If a user wants to get Active / Active deployments, where the active workloads for the same segment are on both sites (configuration with a single high availability server), this can be easily done using logical intervals on both sites. In addition, since Cross-VC NSX extends logical networks and security to all vCenter domains, workloads can easily be moved between vCenter domains across all sites without any changes in IP addresses or security policies.

Figure 5 shows the application of the Universal Distributed Firewall rules to the Universal Section.

Figure 5

If the user wants only site 1 to serve as an exit for North / South traffic, this can be done by deploying the Universal Control VM, which is located on the Universal Distributed Logical Router (UDLR) management layer on the main site, as well as using routing " metric / weight ”to ensure that all North / South traffic passes through the Edge Service Gateways (ESGs) site 1.

In this model, North / South traffic corresponds to the active / passive model, where Edge Service Gateways on site 1 are active and Edge Service Gateways on site 2 are passive on North / South traffic.

The existence of a single site at the Ingress / Egress point for North / South traffic simplifies the process of deploying and taking further action and may be required for cases where tracking services use North / South traffic and it is necessary to avoid asymmetric traffic flows. An example of such a deployment is shown below.

Figure 6

If a user needs Active / Active North / South traffic flows and is not disturbed by the asymmetry of traffic flows, or he has some solution for controlling incoming traffic, then Local can be used to provide North / South traffic flow specific to a particular site. Egress. It is activated when creating a UDLR.

Local Egress allows you to control which routes are provided for ESXi hosts, based on a unique identifier, the so-called Locale ID. All hosts within the NSX Manager domain have the same Locale ID; the default is the UUID of the NSX Manager on the local site.

The Universal Control VM on each site examines routes from the physical network through the ESG of the local site. UCC then examines the best routes with the companion Locale ID from the Universal Control VM of each site. Finally, the UCC distributes information about the best routes to ESXi hosts with the corresponding Locale ID. Such a deployment using Local Egress is shown below. Note that in this deployment model, Universal Control VM is present at each site.

Figure 7

As you can see, the Cross-VC NSX provides flexibility and capabilities for multiple deployments. In fact, this way you can deploy the NSX infrastructure for several users, while some users will use the Active / Passive scheme, while others will use the Active / Active scheme. Such a deployment is shown below: User 1 and User 2 use the same UDLR and a single Universal Control VM with an Active / Passive scheme. User 3 uses a different UDLR with Local Egress and, accordingly, another Universal Control VM for site 1 and site 2; this makes the Active / Active scheme possible. In this case, the IP addresses of users do not overlap. Separate UDLR and ESG can also be used for each user if IP address overlap or additional isolation is required.

Figure 8