With thanks to many sources including: Michael Haines, Jesse Schachter, Zach Shepherd, Vegard Sagbakken, Trevor Gerdes, Michael Haines
Hello and welcome to the third vCloud Suite Digest, a compilation of common technical questions and answers on vCloud Suite architecture and implementation. Behind us is a legion of people a group of people far too numerous to mention (for us these are the unsung heroes of VMware) who provide definitive answers and guidance. People fixing problems on a daily basis, that don’t get half the spotlight that jumped up evangelists do. In this months edition we cover such topics as:
- vCloud Director Database Encryption
- vCloud Director Database Settings
- vCloud Director and NFS Transfer Share
- vCloud Director: Maximum Number of VMs
- vCloud Director: Sticky Sessions
- vCNS Edge Gateway: vNIC Maximum
- vCNS Edge Gateway Load Balancing
- vCloud Connector (vCC): Copying vApps from vCD 1.5 to 5.1
vCloud Director Database Encryption
Q. Doe VMware support encryption with MS SQL Server and the vCloud Database?
A. There are two types of security encryption in play here, 1- Protect the traffic between the vCloud Director application and the SQL Server (SSL) and 2- Store encrypted data in the database (TDE) which are outside of the application. Neither of these solutions requires any changes in vCloud Director. The change in case 1 is only in the connection string. All work for encrypting data or connections has to be performed by the database administrator.
vCloud Director Database Settings
Backstory: vCloud Director like many of our technologies uses a backend database within store the configuration of the “Cells” or “Servers” that make up a vCloud Director deployment. These database settings are configured during the installation with the .bin file.
Q. Where can I find the existing database settings within a vCD cell?
A. The database settings are not available within the vCD UI. However, you can look in the file /opt/vmware/vcloud-director/etc/global.properties.
In this case the global.properties file is taken from the vCloud Director virtual appliance that uses the built-in Oracle XE instance. Remember the vCD VA is not for production use – but for demos and evaluations.
vCloud Director and NFS Transfer Share
BackStory: In a multi-cell environment it possible configure a “NFS Transfer Share” which accessible to all the cells (or servers if you prefer!) in a vCloud deployment. This used as central point from which any cell can be used to move/copy VMs or vApps into vCloud Director – a good example of this would be transferring a .ISO or .OVF to into the vCloud Director catalog.
Q. What is the impact to a group of vCD cells if the NFS transfer share goes down?
A. The vCD cells will remain intact, but there will be interruption/failure of any uploads while the NFS storage is down. The 0-byte files in the cells sub-directory are used to verify that the transfer directory is writable; each cell attempts to create a file with its UUID during start-up to ensure that it can write to the spooling area. If this is successful, the cell also verifies that the other cells in the server group have created a similar file, so that it can confirm the transfer area is indeed shared. This allows the cell to log a clear error message, such as “Transfer spooling area is not writable” or “Warning: unable to verify the following cells share the transfer spooling area” early in the start-up process, simplifying the debugging process when things are failing. In the success case, “Successfully verified transfer spooling area” should be printed.
vCloud Director: Maximum Number of VMs
BackStory: vCloud Director has the concept of Organizations and Organization Virtual Datacenters. The Organization represents a logical construct such as the Test & Dev. Organization within a company for example, and this Organization can be granted access to one or many “virtual” datacenters. In fact what they gain access to is subset of compute resources from one of many VMware HA/DRS enabled clusters. When creating an Organization Virtual Datacenter you are confronted with a number of configuration options – one of them is the “maximum number of VMs” parameter. The option is displayed when during selection of an “Allocation Model”. These allocation models control how resources are reserved (if at all) and allow the System Administrator of vCloud Director to impose limits.
Q. What is the purpose of “Maximum number of VMs” in the Org VDC setup? This value does not seem to hinder consumers from adding/starting more VMs.
A. These settings affect only vApps that you start after specifying the value. vApps that are already running are not affected. The usage information that vCloud Director reports for this organization VDC does not reflect the new settings until all running vApps are stopped and started again.
A change was made with vCD 5.11 to the Allocation Pool model, which enables administrators to work around the maximum number of virtual machines on an organization VDC caused by the vCPU to MHz mapping parameter. This limit can now be worked around by setting a low vCPU to MHz mapping without CPU limiting virtual machines in the organization VDC.
vCloud Director: Sticky Sessions
BackStory: In multi-cell environment – as with any web-service – it common for it be fronted by a load-balancer. Most modern load-balancers not only distribute the inbound requests, but can also detect node failure – and direct inbound requests away from failed nodes, to ones that are active. They also assist greatly in service availability during periods of maintenance. It allows a System Administrator to take nodes offline for a period, and have inbound requests directly elsewhere. Most load-balancers allow for both each requests to serviced by any node in the “pool” or they can be configured to re-use existing sessions – these are sometime referred informally to as “sticky sessions” because once a node has been selected from the pool the end-user returns to the same server in the pool. In the context of vCloud Director there are two main inbound connections made – first to the web-service itself – and secondly to the “Console Proxy” which is used to establish a “Remote Console” (VMRC) window on a VM within a vApp.
In the background is the main vCloud Director web-portal, and in the foreground a Remote Console window has been opened on a VM called “corphqcs01”.
Q. Should vCD sessions be sticky when placed behind a load balancer?
A. For vCD Remote Console connections the load balancer does NOT need to be configured for sticky sessions, as the Console Proxy is completely stateless. VMRC establishes four connections to vCenter and ESX in order to display a remote console. Each of these connections can go through a different Console Proxy instance and VMRC would work just fine. In contrast, the vCD UI and API endpoint it is recommended to be setup with sticky sessions, mostly for performance reasons.
vCNS Edge Gateway: vNIC Maximum
BackStory: With the release of vCloud Suite 5.1 the maximum number of virtual NICs support by the Edge Gateway (which provides firewall, NAT, load-balancing and VPN functionality) has increased.
Q. Is there any way to extend the 10 vNIC maximum configuration?
A. This limitation is not in Edge Gateway limit as such, but an aspect of how vSphere implements VLAN tagging for a VM with multiple virtual NICS. Theoretically, you could go beyond this by implementing VLAN guest tagging (VGT) and have 10vNICs with multiple vLANs on each vNIC.
vCNS Edge Gateway Load Balancing
BackStory: The vCNS Edge Gateway has always had a load-balancing function – but in previous releases this was limited to port 80/443. In vCloud Suite 5.1 the Edge Gateway was upgraded to support any TCP port for load-balancing functionality. As an example of load-balancing I wrote two blogposts – one on load-balancing a simple web-server and another on load-balancing a Horizon View implementation.
By default when an Edge Gateway is deployed for an Organization it uses as least two virtual NICs. One connected to the “External Network” and the other connected to the “Organization Network”. This way VMs and vApps in the Organization Network are able to communicate to the outside world based on the NAT and Firewall configuration.
Q. Can the vCNS Edge load balancer inspect and discriminate specific applications, e.g. only those using HTTPS?
A. We now provide more protocol support (not just HTTP and HTTPS). There is now session persistence and additional load balancer algorithms. However, in vCNS v 5.1.2, HTTPS mode is simply HTTPS pass-through, which is a Layer 4 load balancer and not at Layer 7. SSL pass-through simply means that the load balancer will treat the HTTPS traffic as TCP traffic and hence will not inspect the content.
vCloud Connector (vCC): Copying vApps from vCD 1.5 to 5.1
BackStory: vCloud Connector (vCC) is free tool that allows for the copy/move of VMs and vApp to/from vSphere and private or public vCloud Director environment. It was recently updated on the 21st Dec of 2012 and support two new features – content library and stretched deploy. The Content Library allows for the sync of vApp Template from one catalog to another – even if those catalogs reside in the public cloud. The stretch deploy feature allows you to take one or more VMs within vApp and move them out to a public cloud. The stretch deploy feature automates both the move and the establishment of a VPN configuration between the private and public cloud – this allows the VM that resides in the public cloud to continue to communicate to its peers in the private cloud. I’ve a number of blogpost about configuring vCC for private and public – and using the primary features:
Part 48: My vCloud Journey Journal – vCloud Connector 2.0 Private Configuration
Part 61: My vCloud Journey Journal – vCloud Connector 2.0 Public Configuration
Part 62: My vCloud Journey Journal: Using vCloud Connector 2.0
Q. When I use vCC 2.0 to copy a vApp from vCD 1.5 to vCD 5.1, I notice that some settings are not preserved. Is this to be expected?
A. Yes – This is to be expected. vApp network resets the ”Connection” setting, so no external net routing is kept. This has to be manually reconfigured. The vApp network resets the “Firewall” settings. This has to be reconfigured manually. Additionally, “Guest OS customization” is enabled on each VM in vApp, causing VMs to reset when vApp is started. Finally, “Virtual CPU hot add” and “Memory hot add” is disabled on each VM.