{"id":682,"date":"2011-09-29T08:43:16","date_gmt":"2011-09-29T12:43:16","guid":{"rendered":"http:\/\/chriscolotti.us\/?p=682"},"modified":"2014-08-22T14:02:58","modified_gmt":"2014-08-22T18:02:58","slug":"how-to-configure-vcloud-director-load-balancing","status":"publish","type":"post","link":"https:\/\/chriscolotti.us\/vmware\/how-to-configure-vcloud-director-load-balancing\/","title":{"rendered":"How To: Configure vCloud Director Load Balancing"},"content":{"rendered":"
I\u00a0realized\u00a0yesterday in talking to a friend and\u00a0colleague\u00a0of mine that there is a lot of confusion about load balancing vCloud Director cells. \u00a0I had written a detailed post about considerations<\/a> and many of these were also incorporated into the new vCAT 2.0<\/a>. \u00a0However it seems there is still something lost in\u00a0translation\u00a0so I wanted to break it down to very some very simple\u00a0requirements\u00a0that are easy to follow. \u00a0Below is the requirements needed to get load balancing working. \u00a0Assuming you have a network admin to work with this will NOT be the\u00a0instructions\u00a0on configuring a specific load balancer, but these are the requirements you can give to your engineer. \u00a0You can change the hostnames of course these are just for illustration and to get the point\u00a0across.<\/p>\n Let’s start first by defining the DNS and IP address that are needed to make the configuration work, then we will go into the other items you need to get the network team rolling. \u00a0You need to have a little understanding of SSL\u00a0certificates\u00a0and client termination to understand this as well.<\/p>\n Be sure you setup the shared transfer storage per the documentation. \u00a0A key component of the multi-cell setup is that you have the transfer directory mapped to a shared location on each cell. \u00a0This is done by editing FSTAB to alter the mount point on the cells for \/opt\/vmware\/vcloud-director\/data\/transfer.<\/p>\n vCloud Director Cell HTTP DNS:\u00a0<\/strong><\/p>\n host1.companyname.com = HTTP IP address vCloud Director Cell Remote Console DNS:\u00a0<\/strong><\/p>\n host1-con.companyname.com = Console IP address Load Balancer DNS Entries<\/strong><\/p>\n vcloud.companyname.com = HTTP VIP IP address Now that we have defined the basic IP addresses we need, we need to also make sure the certificates are setup properly. \u00a0Assuming you want to use signed certificates here is what I have found works best for assigning the certificates.<\/p>\n HTTP Certificates (With SSL Offload for HTTP):<\/strong><\/p>\n For the individual Cells you want to issue a certificate that MATCHES the hostname above. \u00a0This will be used by the load balancer to connect via SSL to the hosts in the pool. \u00a0Also this will allow people to connect directly to a cell without a certificate error. \u00a0Then you can obtain a\u00a0certificate\u00a0for the Load Balancer VIP address to install directly onto the load balancer. \u00a0This will be the secure connection the clients use when connecting through the load balancer. \u00a0This setup ensures client to load balancer and load balancer to cell is encrypted.<\/p>\n Console Certificates (THIS CANNOT USE SSL OFFLOAD!!!):<\/strong><\/p>\n This is where people break things. \u00a0The Console Proxy port although on PORT 443 is NOT in fact an HTTPS web connection. \u00a0It is a pure socket connection. \u00a0For this reason you cannot do SSL offload and this VIP\/pool needs to be passthrough to work. \u00a0Therefore to avoid SSL certificate errors you do NOT want to issue the console proxy certificates\u00a0to the hostnames listed above. \u00a0You actually want BOTH console proxy ports to use the SAME certificate hostname of ‘vcloud-con.companyname.com<\/strong><\/em>‘. \u00a0This way when passthrough happens the clients will see the same certificate name presented to them.<\/p>\n HTTP Certificates (WITHOUT SSL Offload for HTTP):<\/strong><\/p>\n If for some reason you cannot or do not want to terminate client SSL on the load balancer and leverage SSL offload, then you can setup the HTTP certificates like the console proxy and do pass through. \u00a0Just like with the console proxy though you will need to install a certificate with the SAME hostname if you do not wat the clients to get browser errors. \u00a0However if you browse to a server directly you will get the name mismatch error.<\/p>\n Important NOTE:<\/strong> \u00a0These must be named EXACTLY as ‘http’ and ‘consoleproxy’, (Without the quotes), when you create the requests or if you use self signed. \u00a0vCloud Director is coded to only look for those certificate names. \u00a0Shout out to\u00a0Rajeev Karamchedu<\/a>\u00a0for pointing that out.<\/p>\n Lastly, for all this to work there is a requirement to update the administration settings for the Public Address URL’s. \u00a0This can be found under the Administration section. \u00a0However each of the three has a different syntax in order to work properly, and you can see the addresses are based on the above original configurations. \u00a0These need to be exact and you will notice the console proxy does NOT use “HTTP”<\/p>\nTransfer Storage<\/strong><\/h2>\n
IP Addresses and Host Names<\/strong><\/h2>\n
\nhost2.companyname.com\u00a0= HTTP IP address<\/p>\n
\nhost2-con.companyname.com\u00a0= Console IP address<\/p>\n
\nvcloud-con.companyname.com = \u00a0Console VIP IP address<\/p>\nSSL\u00a0Certificates<\/strong><\/h2>\n
vCloud Director Configuration<\/strong><\/h2>\n