4.7 vCloud Director environment
It’s out of the scope of this book to fully describe a VMware vCloud Director environment; instead, we will give some useful information about the architecture and the networking parts.
In terms of architecture, what has been said for a vSphere environment is also valid here: essentially, from an architecture point of view vCloud Director is an addition on top of vSphere, so the same notes in regards to servers and storage can also be applied to vCloud Director.
One notable difference is the placement of the resource pools used to contain the virtual machines replicated from tenants:
4.21: Resource pools in a mixed vSphere-vCloud environment
Cloud Connect Replication for vSphere creates one resource pool at the root level of the cluster (which is, remember, the boundary of a Hardware Plan) and then every Hardware Plan is created as a child object of this starting pool.
With vCloud Director, each Organization vDC (virtual DataCenter) is controlled using resource pools directly created at the root of the Cluster.
From a operational point of view, there is however no difference in the behaviour: each resource pool has CPU and Memory limits, that equals to the same limit applied either to a Hardware Plan (for vSphere) or a Org vDC (for vCloud Director):
4.22: Limits applied to a Hardware Plan via Resource pools
Also for the networking part, vCloud Director leverages the same connections available in the underlying vSphere, but it then applies its NSX technology onto it. Veeam Cloud Connect in fact supports vCloud Director from version 8.10 and up, that is every version where VMware NSX is the only available networking technology; said in other terms, Cloud Connect doesn’t support VMware vShield.
When vCloud Director is used, Veeam Cloud Connect doesn’t creates its own portgroups backed with VLANs, but connects virtual machines to one of the Organization networks, that are virtual wires in the NSX infrastrucure (and have no VLAN id):
4.23: NSX virtual wires