vCloud Director 9.0: NSX Edge Gateway cluster placement
This post will highlight a long awaited feature, which is now available in vCloud Director 9.0.
We will depict how to enforce the placement of the NSX Edge Gateways in a resource pool, which ultimately leverages a specific vSphere Cluster.
It avoids having to spread all External VLANs across every Compute Cluster and enforce all the traffic connecting to the outside world would go through a specific location. (Cluster/TOR/Racks)
In the previous versions of vCloud Director, one thing we couldn’t accomplish easily was to ensure all N/S traffic from the NSX VXLAN overlay to the physical underlay/networks, which is usually VLAN Based AND at the same time keep the compute workloads VMs seperated as depicted in the vCAT-SP - Architecting a vCloud Director Solution / NSX Edge Cluster Design options
This should mitigate all the previous drawbacks & overhead when using this setup in a leaf & spine scenario. The below diagram shows the updated behavior when leveraging the feature.
You might have encountered 2 main following architectures with NSX:
- Management, Edge & Compute Clusters (requires at least 3 clusters)
- Collapsed Management/Edge & Compute Clusters (requires at least 2 clusters)
I will not go into details comparing the various pro/cons of both, but just to set a bit of background on why this new feature now exists. They each have benefits and disadvantages depicted in the NSX Design considerations section of the NSX Design Guide
Then what is expected with such a design is:
- N/S traffic goes through the Edge Cluster (VXLAN to VLAN traffic)
- E/W traffic goes through the DLR in the compute(s) clusters and also Edge Cluster (Note: Usually only VXLAN traffic)
So the good news, is that with vCloud Director 9.0 we can now achieve the same recommended design, let’s see how this can be implemented.
Taking a step back and mapping what we just explained to vCloud Director leveraging NSX, this is what it would look like.
The setup still requires some preparation but can be pretty flexible as shown in the above diagram. It relies on vCloud Metadata
key/values that will trigger and enable a specific placement algorithm engine once configured.
Note: This will deny any normal compute workloads to run in that specific resource pool
- Create a resource pool identifying the Provider VDC in the Edge Cluster on vSphere
- Each Resource Pool created previously will be added in the Provider vDC
- In my example you can see the following:
- There is 2 Provider VDCs, PvDC A and PvDC B, and we created 2 resource pools to match those in the Edge Cluster RP PvDC A and RP PvDC B
- Added the resource pool RP PvDC A to the PvDC A in vCloud Director
- Added the resource pool RP PvDC B to the PvDC B in vCloud Director
- In my example you can see the following:
in vCloud Director Edit the Provider vDC as a System Administrator and add the following metadata as a key/value pair with the MoRef ID of the resource pool matching the PvDC you are editing.
placement.resourcepool.edge = <resgroup-id>
resgroup-idManagement Object Reference Identifier value check the next section
Redeploy the Edge Gateways to force the new placement logic.
How to fetch the resource pool id ?
There are various ways to fetch those IDs, here are the most common ones you might be familiar with.
This is probably the easiest way for most people to gather the information.
Fetch the cluster and the resource pool objects
$cluster = Get-Cluster -Name "CAI Edge Cluster" $respool = $cluster | Get-ResourcePool -Name "PvDC-Cairo-EdgeRP"
Print the Management Object Reference
(Get-View $respool).MoRef Type Value ---- ----- ResourcePool resgroup-1527
The result is resgroup-1527.
From the vSphere Managed Object Browser (MOB)
This requires a bit of habit leveraing the MOB, but with a bit of tinkering, through the vSphere Object models you should find your clusters and the required information.
- Open a browser to your vcenter url: https://vcenter/mob
- Login with your environment credentials
- Navigate around ;-)
From the vCloud API
Sample request leveraging Postman:
Validating the configuration
Once the Provider VDC Metadata has been configured with the added metadata, head back to vCloud Director, and test that this new feature works as expected by redeploying an Edge Gateway. You should witness something similar to the following animated process.
You could easily automate the whole process, from setting the required metadata to the edges redeployment, leveraging both the vSphere & vCloud API.
Hope this helps.