Previously I’ve written about why the vSphere Web Client is a must when you upgrade to vSphere 5 and how to deploy the vSphere Web Client without having to purchase an additional Microsoft Windows Server License. This article will now reveal how you can increase the availability and scalability of the vSphere Web Client and also for the all important vSphere License Plug-in for an enterprise environment.  The design described in this article should allow you to scale to hundreds if not a few thousand concurrent vSphere Web Client Users.

Prerequisites

Before we get started there are a few prerequisites that need to be taken care of. For this solution to work you will need to have the following:

1. One or more vCenter Servers, preferably protected by vCenter Heartbeat
2. Two or more vSphere Web Client Servers, for this you can use the vCenter Virtual Appliance without the vCenter Services enabled, refer to my article titled Deploy vSphere Web Client without Additional Windows Server License for instructions
3. A load balancer that can load balance HTTPS traffic and must allow configuration of custom ports
4. A client computer that can be used to run the vSphere Web Client and the vSphere Full Client, which will be used for testing and must have the latest Adobe Flash player installed

vSphere Web Client Deployment

This diagram illustrates a logical design of how you might configure the various components to improve availability and scalability of the vSphere Web Client for a large environment.

Load Balancer Configuration

In the above design I’ve chosen to use the vCenter Virtual Appliance with the vCenter Services disabled to act as the vSphere Web Client Servers. I’ve used a F5 BIG-IP LTM VE to provide load balancing for the vSphere Web Client User access to the vSphere Web Client Servers, as well as for the vCenter Servers to access the vSphere License Plug-in. You can use any load balancer that will successfully load balance HTTPS traffic on port 9443, which is the port the vSphere Web Client uses.

You will need to ensure that you configure the correct persistence setting for client connections. For my lab configuration I chose to use cookie based persistence. This will have the effect of ensuring the browser used to authenticate will always be sent back to the same back end vSphere Web Client Servers (assuming it’s still available). If for some reason the vSphere Web Client Server that a user logged into is unavailable they will be directed to a surviving vSphere Web Client Server and be forced to log in again. This is because there is no session or connection sharing between the vSphere Web Client Server systems.

In order for vCenter to use the virtual IP on the F5 LTM to access the License Plug-in instead of an individual vSphere Web Client Server you need to be very careful with how you deploy and register the vSphere Web Client Servers. When you register the last vSphere Web Client Server to the vCenter Servers you will need to do it using the IP address that will eventually be used as the virtual IP on the load balancer. This is unless it is the Windows version of the vSphere Web Client, which allows you to specify the client URL. After the last vSphere Web Client Server is registered using the VIP of the load balancer you must change its IP address. You will need to wait until all the vSphere Web Client Servers are registered before setting up the nodes, pools, and virtual server profiles on the load balancer to prevent the possibility of an IP address conflict.

VMware Support’s stance on this configuration is as follows: If you have a fault and log a support request they may ask you to bypass the load balancer if they believe it is contributing to the problem. This is fair enough as they only support exactly what VMware have tested. The process to bypass the load balancer is very simple, you would disable the load balancer virtual server and pools, and then reconfigure one of the vSphere Web Client Servers with the IP address of the load balancer VIP. In other words the reverse of how you configured it in the final step above.

This screen shot below is an example virtual server configuration for the F5 BIG-IP LTM VE that I used to test the above design. The load balanced pool was configured to do a simple TCP healthcheck, and use least connections as the load balancing algorithm. You could write a customized healthcheck script to ensure the vSphere Web Client is really functioning as expected.

Testing vSphere Web Client and License Plug-in

To test the vSphere License Plug-in log into one of your vCenter Servers using the full vSphere Client. Navigate to Home > Administration > Licensing. Click on the Reporting Tab. Once the Reporting Tab is completely loaded right click anywhere in the screen and click settings. You should see the Adobe Flash Player Settings dialog box appear asking you if you want to allow <VIP Address of Load Balancer> to access your camera and microphone. If you do not see the VIP address of the load balancer here the vSphere Web Client has not been registered correctly.

To test the vSphere Web Client from a broswer navigate to https://<VIP of Load Balancer>:9443/vsphere-client. The vSphere Web Client should load successfully and you should be able to log into any of the registered vCenter Servers. You should be able to manage the vCenter Server as you normally would if there were only one vSphere Web Client.

vSphere Web Client Limits

This version of the vSphere Web Client is limited to connecting to 50 vCenter Servers concurrently. Each vSphere Web Client connects to the vCenter Server with one session per user. There is no current documented limit for the number of client connections to the vSphere Web Client. But the other important limit to consider is the number of connections to the vCenter Server, which is 100 as of vSphere 5.0.

A Final Word

Each vSphere Web Client Server can handle hundreds of individual users and connect to many individual vCenter Servers. With the above architecture you can scale out the vSphere Web Client systems to ensure your availability, performance, and scalability needs can be met. You will be able to potentially have thousands of individual users accessing the objects to which they have been authorized to manage. This might be as simple as viewing performance statistics and a VM console, or could be provisioning new VM’s. The choice is really yours. At least with this design you know that the service your users expect will be available when they want it.

You might also like to check out Joep Piscaer’s article Load Balancing the vSphere Web Client for some additional ideas on Geo Load Balancing for High Availability.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.