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 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.
[…] little while ago I posted an article outlining a design that provides a solution for Scalability and High Availability for the vSphere Web Client in vSphere 5 for enterprise environments. Many of these enterprise environments that might want scalability for […]
[…] without needing an additional Microsoft Windows License and then I used it with a load balancer to Increase vSphere Web Client Availability and Scalability. But a lack of documentation wasn’t going to stop me. Being a SLES based virtual appliance […]
Hello, I've been considering this with vSphere 5.1. Have you tried it yet? I think I figured out how to deploy the SSO and vSphere Web Client using the VCSA without enabling the embedded vCenter instance. I'll be happy to share the script once I get the last kinks worked out (hopefully tomorrow).
I'm somewhat concerned about the statement in VMware's documentation saying that a particular vCenter Server should only be registered with a single vSphere Web Client server. Have you noticed any problems running in this configuration?
"Register a given vCenter Server system with only one vSphere Web Client instance, rather than using multiple vSphere Web Client instances to manage that vCenter Server system."
http://pubs.vmware.com/vsphere-51/index.jsp?topic…
Thanks,
-Loren
Hi Loren, I can't say I've tried 5.1 in this configuration. But I haven't run into any problems with this configuration in vSphere 5 with multiple vSphere Web Clients managing the same vCenter. VMware probably hasn't tested this configuration extensively though, hence the recommendation.
Very helpful post Michael,
I was wondering you have ever considered extending the configuration to include the traffic for the VM console? I am currently looking at trying it out with the Citrix VPX LBs. Any thoughts or insight would be welcome.
Hi Mark, The trouble you'll face with the VM console is that it's direct to the hosts. So it doesn't really fit with load balancing.
Hi Loren,
Did you successfully get SSO working with Big-IP LTM? I am trying to do so and am having some difficulty finding any specific documentation relating to this configuration
Mike, not sure if you are still monitoring this article, but wanted to ask if the multiple vcenters going to the load balanced web client is better under 5.5? Additionally, what is missing is the reference to what do you do with the inventory service – does that get installed on a single server (single fault) if fails and the webclient is empty without the inventory service.
Hi Sherri, It's a bit easier on 5.5 and may become easier in the next release also. You can only have one inventory service, so it is a single point of failure. But the idea is that you'd have multiple vCenters behind the same set of Web Clients that are being load balanced. This area is getting a lot of attention from VMware to make things more highly available and a lot faster for administrators.