With vCloud Director for Service Providers 9.0 come a lot of new features most of which have already been greatly summarised by Tom Fojta in this article vCloud Director 9 What’s New as well as this official white paper
In this article I’m focusing on the “edge gateways placement engine” a long awaited features which allows vCD to place the ESGs on a dedicated edge cluster instead. My friend Timo Sugliani already wrote a great post detailing how it works and how to configure it vCloud Director 9.0: NSX Edge Gateway cluster placement
Basically using vCD metadata properties at the Provider VDC level (or Org VDC) we can specify a destination vSphere resource pool where vCD (provided all resource requirements are satisfied) will provision the edges. Offical documentation references:
- Add a Resource Pool to a Provider VDC from vCloud Director Administrator Guide
- Using vCloud Director Metadata to Control Edge Gateway Placement (KB 2151398)
Design Consideration and Implementation Notes
Neither the documentation nor the KB article discuss requirements or design consideration to be aware of when implementing this feature which is the reason why I wrote this post.
- Storage Policies: double check the Storage Policies available on the Edge cluster; if vCD can’t find available datastore to deploy the edges then when you try to redeploy the edge you will get this error which is a bit generic and not really telling what’s wrong:
- Distributed Switches (vDS): are you stretching one vDS across Compute and Edge cluster or do you have two different vDS? I think the latter is the most common scenario in which case you need to think about the External Networks you have (or have not) presented in vCD. Remember: edges ultimately will egress northbound via external networks mapped to (one or more) port groups. If you don’t have a valid external network mapping to the edge cluster you will likely get the following warning:
- The resource pool you add into the PVDC for the edges will exclusively be used to deploy edges meaning that no other VMs will be deployed there. So take into account the amount of resources assigned to it and whether or not you want to allow limits and expendable reservations.
Migration scenario (from Compute to Edge cluster)
If you’re going to migrate existing edges deployed on a Compute cluster to a new Edge cluster you need to carefully plan the External Networks swap. Assuming you have configured the metadata property correctly on the PVDC ( placement.resourcepool.edge = <resource-pool-id> ) the moment you swap on vCD the external networks from the compute to the edge cluster you should expect an automatic edge redeployment and, more precisely, the edge will be deployed on the cluster where the external network is attached to. Here’s an example how:
- Organization VDC VMware-PAYG-VDC with edge vmware-org-esg-01 deployed on the Compute_A cluster
vSphere cluster view - External Networks mapping only to Compute cluster
- Edge resource pool added
- IP pool sub-allocation configured for vmware-org-esg-01
- NAT and static routing configured on vmware-org-esg-01
- Metadata property configured on PVDCA
- Resource pool id resgroup-277 maps to resource pool ESGs-PVDC-A. My Edge cluster is in reality a collapsed Management-Edge
Please note: although you specify the resource pool id of ESGs-PVDC-A vCD will create a child resource pool System vDC where edges will be placed - Now we add the Edge cluster external network, in my case HQ-Access-Edge and HQ-Access-MPLS making sure they have the same network specification of the existing ones
- We’re ready to migrate. Back to the edge at the same time we remove the Compute external networks and add the Edge ones, making sure the default gateway is kept the same and the ip pool sub-allocation is reconfigured the same as before. Here’s a gif showing the process:
- The ESG start redeploying into the Management-Edge cluster
and here we have it: the edge is now running on the Management-Edge cluster under the ESGs-PVDC-A resource pool
- Back to vCD we can see the NAT rules as well as static routing have been migrated successfully
I hope you found this useful.
Coming up next
I’m already working on a PowerShell script to automated this process, stay tuned! 🙂
4 Trackbacks