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:
- One or more vCenter Servers, preferably protected by vCenter Heartbeat
- 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
- A load balancer that can load balance HTTPS traffic and must allow configuration of custom ports
- 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 l