VMware NSX 6.2 dropped yesterday with some pretty awesome features. I’ll be going through most features in separate posts and this one is for the Cross-vCenter feature. Before 6.2, the NSX Manager and vCenter had a one to one relationship, making certain dual datacenter designs quite difficult. Unless you had deployed stretched clusters, your network policies were linked to one site (unless you scripted your way out). With NSX 6.2, this changes in a big way.



NSX 6.2 introduces Cross-vCenter, which allows you to deploy multiple NSX Managers (up to eight!) that synchronise their configuration. The NSX Manager and vCenter relationship is still a one to one relationship, but the NSX Managers start talking to each other on the control-plane. To achieve this, a new concept is added named Universal. Of some of the existing components 6.2 introduces a Universal version:

  • Universal Controller: These controllers keep the metadata of the network (logical switches, distributed routers) throughout the Cross-vCenter environment.
  • Universal Transport Zone: Same as regular Transport Zone, only across all ESXi hosts that are linked to the Cross-vCenter environment. Unlike regular Transport Zones, there can only be one Universal Transport Zone.
  • Universal Logical Switch: This a Logical Switch (VXLAN) that spans multiple vCenters in the Cross-vCenter environment.
  • Universal Distributed Router: Distributed routing across the Cross-vCenter environment. Through Local Egress it is possible to have traffic exit the network on the site it originates, more on this later.
  • Universal Firewall Rules: This synchronises all Distributed Firewall rules, making it possible to have the same security policies applied on each site, without having to replicate the firewall rules manually.
  • Universal Security and Network Objects: Used to populate the Universal Firewall Rules; IP Sets, MAC Sets, Security Groups, Services, Service Groups.

NSX Managers: Primary and Secondary

So in 6.2 you can create a group of NSX Managers which exchange information to get to the point where you can have a distributed environment across vCenters. Do to this, you have a primary NSX Manager which handles the Universal Controllers. The secondary NSX Managers automatically import the Universal Controllers to receive their metadata. When installing Cross-vCenter NSX Managers, it’s pretty much the same as the regular NSX Manager installation. When deploying the first NSX Manager, you configure the regular items (SSO, vCenter link, host preparation, etc) with the addition of assigning it the primary role.



After assigning the primary role to the first NSX Manager, you can install the second NSX Manager and assign it as secondary, while giving it the IP address of the primary NSX Manager. This, and the documentation explaining the Cross-vCenter feature, leads me to believe you’re not creating an actual NSX Manager cluster and primary election can happen, but that the primary will always be the primary. I wonder how this will affect changes to the network when the primary is unavailable when you’re having a disaster and you have failed over to a secondary site. The test lab is currently upgrading, so I will report back! 😉

Local Egress

Due to the stretchy-ness of the Universal Distributed Router, VMware devised a way to keep originating traffic from crossing to another site to exit the virtual network called local egress. Local Egress makes use of secondary Universal Logical Distributed Router Appliances (good god the names and abbreviations on this thing!) located on each site. These secondary ULDRs tag the routes they get from the local Edge gateways with a Locale ID which is linked to the site. These Locale IDs are used to install the local routes on the ESXi hosts and route traffic upwards.



Fun facts

  • Local Egress has to be enabled on the creation of a Logical Distributed Router, you cannot change it after creating it.
  • Layer-2 bridging across the Cross-vCenter environment is not supported.
  • Universal Controllers maintain the metadata for the entire Cross-vCenter environment and the local sites in the environment. Secondary NSX Managers do not have controllers, apart from the inherited Universal Controllers.
  • You can only have one Universal Transport Zone, so choose carefully.
  • There are universal and local VXLAN Segment ID Pools and they cannot overlap (funky stuff will happen).
  • The Locale ID is by default the UUID of the NSX Manager. If you do not override the Locale ID (either on the ULDR, DRS Cluster or ESXi host), you cannot clone or deploy the NSX Manager from a template: use the OVA deployment.
  • Currently you can only create 1 Universal Distributed Firewall section and file rules under that section. Might get messy, hope that changes in the future!
  • Universal Objects can only be created from the primary NSX Manager.

 
That’s it for the Cross-vCenter for now, I’ll be back with more awesome features from NSX 6.2!



Share the wealth!