VMware Cloud Director is a Telco Cloud component that functions as an interface to VNF services. It uses vCenter Server and NSX Manager to orchestrate compute, storage, and networking from a single programmable interface.
Cloud Director Cell Design
The Cloud Director design is based on two deployment components: database nodes (primary and secondary nodes) and cells.
The Cloud Director database cluster must be deployed in a HA cluster. It leverages an embedded postgreSQL database and incorporates replication to provide a highly-available cluster of Cloud Director appliances.
The database cluster must be configured in 3 nodes: one Primary Node and two secondary nodes. Additional scaling of the Cloud Director deployment can be achieved by deploying individual application cells.
Each server in the group runs a collection of services called a VMware Cloud Director cell. All cells share a single VMware Cloud Director database, transfer server storage, and connect to the vSphere and network resources. The installation and configuration process of VMware Cloud Director creates the cells, connects them to the shared database, and transfers server storage.
As opposed to the database nodes, Cloud Director cells provide the cloud management components. In a stateless appliance, all updates from the cells are written to the postgres database stored in the HA database cluster.
The cells communicate with each other through an ActiveMQ message bus on the primary interface. They also share a common Cloud Director database where the cells persist configuration and state data. The transfer service requires that all cells have access to a common NFS mount.
VMware Cloud Director appliances come in different sizes (medium, large, and extra-large). The recommended deployment size for Cloud Director is large. If Cloud Director is integrated with Aria Operations, extra-large is recommended.
All Cloud Director cells provide the portal, API, and VMware Remote Console (VMRC) access. Thus, a load balancer must be deployed to load balance the traffic between the cells.
Any load balancer can be used as long as it is configured for sticky sessions to reduce the Cloud Director session database API calls. However, the recommended load balancer is NSX Advanced Load Balancer. The Load Balancer configuration can terminate the SSL and re-create new SSL connections to the Cloud Director cells based on the algorithm such as least_connections.
Both the Cloud Director API and the Remote Console share the same port, so separate certificates are no longer necessary.
Design Recommendation |
Design Justification |
Design Implication |
|---|---|---|
Deploy nodes using the VMware Cloud Director Appliance. |
Ensures a consistent deployment across cells. |
None |
Deploy at least 3 database nodes: one Primary and two Secondary of extra-large size. |
Provides resiliency across nodes and tolerates node failure |
Consumes more resources in the management cluster |
Configure VMware Cloud Director for manual Primary Cell failover. |
Simplifies the BCDR configuration and process |
Can increase the downtime of VMware Cloud Director by eliminating automated failover of the Primary Cell. |
Ensure that cells can communicate with each other through the message bus on the primary network interface. |
Ensures that cells do not enter a split-brain state. |
None |
Use the same consoleproxy certificate on all cells. |
Ensures that users can connect to the consoleproxy service regardless of the cell they are connected to. |
You must manually install the certificate on each cell. |
Verify that the cell transfer share is accessible for all cells. |
Required for the proper functioning of VMware Cloud Director. |
None |
Configure NTP for all Database nodes, cells, and NFS server |
Ensures accurate clocking across all components, including NFS |
None |
Attribute |
Specification |
|---|---|
Overall Appliance Size |
Extra Large |
Database Cells |
|
Number of vCPUs |
24 |
Memory |
32 GB |
Disk Space |
Minimum 120 GB |
Cell Appliance |
|
Number of vCPUs |
8 |
Memory |
8 GB |
Disk Space |
Minimum 120 GB |
Cloud Director NFS - Transfer Storage
Cloud Director requires an NFS volume to act as a shared storage to all nodes within a Cloud Director deployment. This shared storage is used for cluster management and providing temporary storage for uploads, downloads, and in some conditions catalog storage.
One of the common approaches to provide the NFS storage is by using vSAN File Services. Use vSAN File Services to provide NFS 3.0 / 4.x shares that can be leveraged by the Cloud Director deployment. Other approaches include external storage arrays providing NFS capabilities.
The solution that you use must be highly available.
The transfer storage is used when multiple cells are deployed. In this case, the Cloud Director cells use the NFS server as a shared, temporary repository for all uploads, downloads, and cloning operations. The data is removed from the transfer storage location when the operation is complete. However, the overall size of the NFS storage depends on the number of concurrent operations and the workload size.
Authentication
You can integrate VMware Cloud Director with an external identity provider and import users and groups to your organizations. You can configure an LDAP server connection at a system or organization level and a SAML integration at an organizational level.
LDAP Server: You can configure an organization to use the system LDAP connection as a shared source of users and groups. An organization can also use a separate LDAP connection as a private source of users and groups.
SAML Identity Provider: To import users and groups from a SAML identity provider to your system organization, you must configure your system organization with this SAML identity provider. Imported users can log in to the system organization with the credentials established in the SAML identity provider.
To configure VMware Cloud Director with a SAML identity provider, establish a mutual trust by exchanging SAML service provider and identity provider metadata.
Design Recommendation |
Design Justification |
Design Implication |
|---|---|---|
Use the default VMware Cloud Director roles, unless necessary. |
Simplifies the user rights management and configuration |
Custom roles might be required for some cases where the built-in roles do not work. |
Configure a system LDAP connection. |
|
Requires manual user import and role assignment |
Use the system LDAP connection for organizations. |
|
Requires manual user import and role assignment |
Cloud Director Scaling Considerations
A single Cloud Director deployment manages resources from multiple data centers. While all the Cloud Director nodes must reside in a single management domain due to latency constraints, the vCenter Servers that the Cloud Director manages can be distributed geographically.
Considerations for managing remote resource vCenter Servers:
vCenter Server and ESXi Latency: Maximum 150ms RTT between Cloud Director cells and vCenter servers / ESXi hosts.
NSX Latency: Maximum 150ms RTT between Cloud Director cells and NSX Managers.
Cloud Director supports scale-up and scale-out models. When a large deployment size is used, the cloud director cell can be taken out of service, powered off, and resized. Upon reboot, the node is reconfigured to reflect the new sizing.
The most common approach to scaling is to add more cells to the system. The recommended number of cells is n+1, where n is the number of resource vCenter Servers managed by Cloud Director.
