NSX-T federation is one of the new features introduced in NSX-T 3.0, and it allows you to manage multiple NSX-T Data Center environments with a single pane of glass. Federation allows you to stretch NSX-T deployments over multiple sites and/or towards the public cloud while keeping a single pane of management. Federation can be compared with the Cross-vCenter feature of NSX-V, where universal objects span more than one site.
NSX-T Federation Components/Architecture/Topology
With the NSX-T Federation, the concept of a Global Manager (GM) is introduced, which enables a single pane of glass for all connected NSX-T managers. A global manager is an NSX-T manager deployed with the role “Global”. Objects created from the Global Manager console are called global objects and pushed to the connected local NSX-T Managers.
The below diagram shows the high-level architecture of the NSX-T Federation
You can create networking constructs (T0/T1 gateways, segments, etc.) from Global Manager that can be stretched across one or more locations. Also, you can create a networking object directly on the local NSX manager, but local objects will not appear on the Global Manager.
An example of a stretched T0 gateway across all locations.
An example of a stretched T0 gateway across a subset of locations.
NSX-T Federation Use Cases
The main goal of NSX-T Federation is to enable multi-site NSX-T deployments, where the management, control, and data planes are distributed over multiple locations. A few advantages that you get from the NSX-T Federation are:
Centralized Configuration & Security Enforcement
Federation simplifies the operational management of an NSX-T deployment and reduces administrative overhead greatly.
Although the NSX-T management plane is distributed across sites, it is managed as a single entity. Objects are created ‘globally’ and replicated to each connected site automatically, which reduces the burden of manually creating the objects and configuration at each site individually. This helps to achieve uniformity across the sites, lowers the operational impact significantly, and improves security as security policies are uniformly enforced at each connected site.
Simplified Disaster Recovery
The NSX-T Federation enables the stretching of logical segments and logical routers across connected sites. In the case of a disaster, you can seamlessly recover your virtual machines on the DR site without having to deal with network modifications for the recovered VMs. Since segments are stretched, you don’t have to re-ip your workloads in a DR scenario, which greatly enhances RTO objectives and lowers the operational burden.
Simplified Security
The Security Group concept is not new, and it’s been around since the evolution of NSX (V/T). Security groups are a real savior when designing micro-segmentation or creating firewall rules. VMs can added to a security group directly or dynamically using membership criteria (Security Tagging, name-based membership, etc)
NSX-T also introduced the concept of global and regional security groups. The main difference between the two is the width of the span. Some Security Groups can be made available across all connected sites, and some can only be available on selected sites. This can be extremely helpful when designing firewall rules (infra-based and app-based).
For core infrastructure objects (AD, DNS, NTP, etc.), you can create security groups that span across all sites, and for workloads, you can create application-based firewall rules that span across a single site.
Note: Security Group Objects can be created globally, regionally, and locally, but can be utilized together under the same firewall rules.
There is more to cover about the NSX-T federation, but I will discuss it in future posts of this series.
And that’s it for this post.
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing 🙂