Piszki Lab | EN

My case study in the clouds…

vCloud Director 5.5: balancing traffic through the BIG-IP F5

| 0 comments

This topic has been moved online many times, but always worth remembering and refresh knowledge. Especially that new versions appear every now and then, often differing from each other quite a bit. Besides, is that vCloud Director is treated with a slight reluctance by VMware, does not mean that everyone suddenly moved to vCAC. Additionally, I will focus here quite heavily on the balancing traffic to access virtual machines through the Console Proxy (vmrc). On this subject it is difficult to find comprehensive information.

vcd16

In the first step, if you do not have, we need to generate the next cell for vCloud Director. All cell have to share, via NFS, the directory “transfer” (/opt/vmware/vcloud-director/data/transfer), so you need to think about where it was exported/mounted. This may be an external NAS server or directory exported from the first cell (in my case). Personally, I am running CentOS 6.4 as a platform for vCloud Director (instead of Red Hat), it makes easier to administration. Preparing the next cell is very simple, just clone the first one! Of course, the first time we run it in network isolation mode, turn off the vCD (service vmware-vcd stop), reconfigure the network card to the new IP address and enable network. On the first cell (our CentOS), if we do not have, install and run the NFS server:

yum install nfs-utils nfs-utils-lib
chkconfig nfs on
service rpcbind start
service nfs start

To /etc/exports we add the line:

/opt/vmware/vcloud-director/data/transfer       IP (rw,sync,no_root_squash,no_subtree_check)

And issue the following command: exportfs -a

At this point, we have exported NFS directory “transfer”. Copy the file  /opt/vmware/vcloud-director/etc/responses.properties (it contains a basic configuration that will be used by the next cell) to it. Now go into the preparation of SSL certificates for both nodes. This is a very important step and must be done correctly. Why do we need to make modifications to both cells? Because according to this KB, if we want to balance VMRC traffic connections, all cells should be shared SSL certificate for the Console Proxy. The host name in the certificate must match the vCD entry of public console proxy name:

vcd1

Otherwise we can meet up with the error “Exception during handshake: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown”. As always, the best solution is to have a wildcard certificate (pkcs12 format). Prepare certificates.ks based on pkcs12 (.pfx) is very simple:

Create empty keystore JCEKS:

keytool -keystore certificates.ks -storetype JCEKS -storepass xxxxxxx -genkey -keyalg RSA -keysize 2048 -alias http

keytool -delete -alias http -keystore certificates.ks

Import Root and Intermediate CA certificates (as many as you need, the alias name can be eg. Intermediate1, intermediate2 etc):

keytool -storetype JCEKS -storepass xxxxxxx -keystore certificates.ks –importcert –file ca1 –alias root

keytool -storetype JCEKS -storepass xxxxxxx -keystore certificates.ks -importcert -file ca2 -alias intermediate

And import a wildcard certificate with the key:

keytool -v -importkeystore -srckeystore pulab.pfx -srcstoretype PKCS12 -destkeystore certificates.ks -deststoretype JCEKS -alias http

keytool -v -importkeystore -srckeystore pulab.pfx -srcstoretype PKCS12 -destkeystore certificates.ks -deststoretype JCEKS –alias consoleproxy

And all this, on both cells disable vCloud Director service (service vmware-vcd stop), remove the old keystore file and run the /opt/vmware/vcloud-director/bin/configure. The program will detect the file change and proposes to use the new configuration. After running up the two cells should we see the following result:

vcd2

At this point, we can go to the F5 console. Prepare the appropriate configuration will start by creating the appropriate monitors, one for vCloud Director and the other for the Console Proxy:

vcd3

vcd4

In the next step we create persistence profile for vCD, Console Proxy does not need such a profile (we have two ways, cookie or source_addr):

vcd5

Now create a SSL profile for vCD, in our case we use, as usual, the same wildcard profile:

vcd6

Add more Nodes (at this stage ICMP is sufficiently monitor):

vcd7

Create the first pool for vCloud Director:

vcd8

vcd9

Create a second pool for Console Proxy:

vcd10

vcd11

At this stage, we have everything that is needed to create virtual servers. Be the first to create a VIP for vCloud Director:

vcd12

vcd13

This is the standard set for the web server, use the http profile allows you to use the security policy (ASM) in access to vCloud Director. Using SSL profile is not obligatory, we can make a full SSL transparent session to cells (if we have the same certificate for all). If you do not use directory synchronization between different clouds, you can use a separate SSL certificate signed by the local CA for each single node (and use SSL profile on F5). The last step is to create a VIP for the Console Proxy:

vcd14

vcd15

In this case we do not use the http profile, Console Proxy is not simply an HTTPS service.Therefore, we can not use the ASM for her! vCloud Director is a good piece of software and it’s worth to use it :-)

Rate this article:
[Total: 0    Average: 0/5]

Author: Piotr Pisz

Computer always, since I got a Commodore 64 at the end of primary school, through his beloved Amiga and Linux infinite number of consoles, until today, fully virtual day. Since 2001, Unix/Linux Systems Administrator, for seven years a faithful companion and protector of Solaris system, until his sad end. In the year 2011 came in the depths of virtualization, then smoothly ascended into the clouds and continues there today. Professionally working as Systems Architect in the Polish Security Printing Works.

Leave a Reply

Required fields are marked *.


.

Enjoyed the post? Support Piszki Lab | EN, click on the AD! :-)

.