2. vCloud Cell Design Examples : 2.1 Load Balanced Cell Configuration : 2.1.2 Example
   
2.1.2 Example
This example demonstrates how to set up load balanced vCloud Director cells. The following prerequisites align with and are explained in the setup considerations.
2.1.2.1. Prerequisites
*More than one vCloud Director supported cell server (Red Hat Enterprise Linux).
*Supported network latency (in this example, < 2ms RTT between vCloud Director cells). The environment must behave as though it is a single site (that is, low latency).
*Location and password of the keystore file that includes the SSL certificates for this server.
*Shared transfer storage space, mapped on each vCloud Director cell.
*Shared database instance.
*Network Time Protocol configured on each cell.
*Network load balancer device, and console and proxy health monitors.
*vCloud Director “Public Addresses” configuration.
2.1.2.2. Setup Considerations
*More than one vCloud Director cell is required. Multiple vCloud Director cells are desirable for redundancy, and to provide a sufficient number of console sessions.
*If the first vCloud Director cell is lagging due to too many console connections, adding more load balanced cells offloads the workload between the cells by providing more console connections.
*If the first cell becomes unavailable, users can no longer use the vCloud Director portal or console sessions. Having multiple, load balanced cells enables user sessions to be re-established across other cells.
In this example, the customer wants to gain vCloud Director cell redundancy by load balancing the cells. There is no need to get more console access connections because of the limited number of users accessing the vCloud Director portal or vCloud Director backspace-presented virtual machine consoles.
*Network latency between the cells must be low enough to perform as though the cells reside in the same datacenter (LAN speed). Cells must have low latency between each other and also between themselves and the shared database. This provides proper communication and updates between the cells, along with the cell to database traffic.
The customer is hosting all of the vCloud Director cells within two adjacent racks in a datacenter. This configuration has less than a 2ms round trip time (RTT) between the cells and corresponding services (database, vSphere, and so on).
*Certificates are generated when a vCloud Director cell is installed. See the vCloud Director Installation Guide for information about creating the proper certificates.
During the creation of the certificates, the HTTP and Console IP addresses are identified, along with the keystore location and password. Record this information. The default location is /opt/keystore/certificates.ks.
The customer wants to create an untrusted (self-signed) certificate using the following command. This command creates an untrusted certificate for the HTTP service in a keystore file named certificates.ks:
keytool -keystore certificates.ks -storetype JCEKS -storepass passwd
-genkey -keyalg RSA -alias http
The following table contains the customer-provided information used to populate the certificate as prompted during the certificate creation from the preceding command.
Certificate Prompted Question
Customer Answer
What is your first and last name?
Mycloud.example.com
What is the name of your organization unit?
IT
What is the name of your organization?
Example Company Name
What is the name of your city or locality?
Tucson
What is the name of your state or province?
Arizona
What is the two-letter country code for this unit?
US
 
The following command adds an untrusted certificate for the console proxy to the keystore file created in the previous step:
keytool -keystore certificates.ks -storetype JCEKS -storepass passwd
-genkey -keyalg RSA -alias consoleproxy
*For the transfer service, each server must mount an NFS or other shared storage volume at $VCLOUD_HOME/data/transfer, which is typically /opt/vmware/vcloud-director/data/transfer. This volume must have write permission for root.
NoteIn some lab and POC environments, it may be acceptable, though not recommended, to share a local NFS mount from one cell server to other cell servers. Keep in mind that if this NFS server becomes unavailable, functions and services using this share will become unavailable and copy operations in progress will fail.
*Database connection information and other reusable responses you supplied during the configuration are preserved in a file located at /opt/vmware/vcloud-director/etc/responses.properties on this server. Copy this file to each additional cell server before the configuration of the vCloud Director cell server software. This file is referenced during the initiation of the installation using this command:
installation-file -r path-to-response-file
*The Network Time Protocol (NTP) must be properly configured on each vCloud Director cell. vCloud Director cells with improperly configured NTP settings can have trouble connecting to ESXi hosts, the database instance, vCloud Networking and Security Manager, and other cells. If there is one cell in the group without the correct time and a user connects through this cell, actions will not complete correctly and many errors will occur. This is due to the time stamps from that cell trying to access the load balanced environment (other cells) and the shared database with time stamps that are not matching the times of the improperly configured cell.
*A network load balancer, whether physical or virtual, must be configured to proxy the HTTP and console connections for the vCloud Director environment. This section also includes setting up the health monitoring on the load balancer for the vCloud Director environment.
To configure the HTTP Portal connections
1. Copy the SSL certificate to the load balancer for the HTTP public URL (that is, https://mycloud.example.com).
2. Set up the Health Monitor on the Load Balancer (F5 Load Balancer in this customer example) using the following URL:
https://<Cell_Hostname>/cloud/server_status
3. Each node can have a hostname-based cert node1.example.com, node2.example.com, and so forth.
To configure the Console Proxy connections
1. Configure HTTPS pass-through for the console proxy connections. Each node should have the same host name in the certificate when it is generated (that is, http://mycloud.example.com). For more details, see the vCloud Director Installation and Configuration Guide. Console connections are load balanced. Because the certificates are the same for each cell console, they must be passed through the load balancer. Otherwise, each cell would need a unique certificate in the load balancer and a certificate mismatch error would occur.
2. Set up the Health Monitor on the Load Balancer (F5 in this customer example) using the following URL:
https:///sdk/vimServiceVersions.xml
3. Configure SSL persistence for the vCloud Director load balancer connections.
4. In the vCloud Director system administration section, there are fields for the vCloud Director public URL, console proxy address, and REST API base URL. If these fields are not updated with the load balancer public IP addresses/URLs, replies from the cell will reflect that of the individual cell and not that of the public URL information.
For example (from the vCloud Director Installation and Configuration Guide):
*When you create an organization, its organization URL includes the public web URL instead of the HTTP service IP address. vCloud Director also modifies the organization URLs of existing organizations.
*Remote console session tickets sent to the HTTP service IP address return the public console proxy address.
*XML responses from the REST API include the base URL and the transfer service uses the base URL as the upload target.
 
Public Addresses Field
Example Data
VCD public URL
http://mycloud.example.com
VCD public console proxy address
mycloud-console.example.com
VCD public REST API base URL
mycloud.example.com
 
*The VCD public URL requires HTTPS. This address is also set in the load balancer and DNS so that users can access the vCloud Director portal using this public URL.
*The VCD public console proxy address does not use HTTPS. This URL is also in DNS and on the load balancer in order to direct users to the appropriate cell for virtual machine console access.
*The VCD public REST API base URL is for users to access the load balance environment using the REST API.
The following figure shows traffic communication between the cells and ESXi hosts.
Figure 2. HTTPS and Console Proxy Connections
 
To access the console of a virtual machine, vCloud director uses the console proxy IP address of the vCloud Director cell server to connect directly (through the load balancer, in this case) to the ESXi host and attach the user to the console of the target virtual machine.
When a user connects to the vCloud Director portal, a different URL is used (also using the load balancer in this case) and the user connects through to the HTTPS vCloud Director portal hosted on the vCloud Director cells. All actions and commands executed within the vCloud Director portal are sent directly (transparent to the end user) to the relevant vCenter Server or, in some cases, directly to the ESXi host.
All vCloud Director cells in the same vCloud must access the same vCloud Director database. Each vCloud Director cell must also be configured for the same NFS mount point, which is used as vCloud Director transfer space.