I have implemented a vSphere Web Client solution recently for my own (small and non-profit) hosting environment.

I wanted to give users access to their vSphere VMs without requiring the full-blown vSphere Client. I’ve been trying to get WSX working as a stand-alone Web App (using William’s fantastic how-to), but it seems WSX still contains some bugs on vCenter communication. For now, I chose to use the vSphere Web Client for my users.

Design

Although the physical servers are situated in the datacenter (primary site), the vCenter Server is placed on a machine in my home network (secondary site), because the physical hardware is rather restricted (only two boxes with 16GB RAM each). I run Vyatta site-to-site OpenVPN between sites.

For argument’s sake, I want the Web Client to be load balanced and highly available. This way, I get to play around with KEMP’s technology and create a geo-redundant load balanced vSphere Web Client. I understand that there are lots of SPOFs and supportability issues in this scenario, but that’s beyond the scope of this discussion.
After evaluating both pfSense (Viktor van den Berg wrote a nice how-to here) and the KEMP Virtual LoadMaster (nice tutorial by Eric Sloof here), I decided to use the KEMP VLM for (geo-)redundancy and load balancing.

Implementation

vSphere Web Client

First, I installed two Windows boxes with the vSphere Web Client. These machines (vwc01 and vwc02) are placed on two separate sites but are both connected to a single vCenter instance, vc01.

Interfaces vwc01 vwc02
Local Area Connection 10.10.20.21/24 10.10.20.22/24

vCenter Server and Database

Again, I am creating a load balanced vSphere Web Client for fun, so I realize I have a couple of SPOFs left. Primarily, the vCenter Server and Database are a SPOF, especially since it runs on a separate site. This makes the site-to-site OpenVPN a major SPOF as well. If the link between sites fails, all components are quite useless. The LoadMaster and vSphere Web Client in the datacenter can’t connect to the vCenter Server, and while the ones in my home network will still function, there wouldn’t be any ESXi-hosts for vCenter to connect to. But again, I do realize this and really just want to create some KEMP setups for me to play around with.

Interfaces vc01
Local Area Connection 10.10.20.30

KEMP Virtual LoadMaster HA

I configured the KEMP VMs with the following interface parameters:

Interfaces vlm01 vlm02
eth0 10.10.20.128/24 10.10.20.129/24
eth1 10.10.30.128/24 10.10.30.129/24
HA Shared IP 10.10.30.120 10.10.30.120
HA Partner IP 10.10.30.129 10.10.30.128
HA Checks eth1 eth1

I’m using 10.10.30.0/24 for heartbeat only, it is a separated and isolated network. 10.10.20.0/24 is the network where all services reside. For simplicity, I used a stretched VLAN between sites. I could’ve created two separate networks, but as this is just an exercise in ‘getting it to work’ more than anything else.

And HA parameters:

HA Parameters vlm01 vlm02
HA Mode HA (First) Mode HA (Second) Mode
HA Version Upgraded (CARP)
HA Timeout 9 seconds
HA Initial Wait Time 0
HA Virtual ID 2
HA Update Interface Eth1: 10.10.30.120

This results in a fully functioning HA pair:

 on vlm01

 on vlm02

KEMP Virtual LoadMaster Virtual Services

Next, I created a ‘virtual service’ to enable vSphere Web Client load balancing.

  • Virtual Address: 10.10.20.20
  • Port: 9443
  • Name: vSphere Web Client
  • Protocol: tcp

I then modified the service settings:

  • Service Type: HTTP/HTTPS
  • Persistence Mode: Source IP Address
  • Persistence Timeout: 1 Day
  • Scheduling Method: weighted response time
  • SSL Acceleration: Enabled (incl. Reencrypt)

Finally, I added the ‘Real Servers’ and their ‘Check Parameters’:

  • Check HTTPS Protocol on Port 9443
  • Check URL: /vsphere-client
  • Real Server Address: 10.10.20.21 and 10.10.20.22, the IP-addresses for either vSphere Web Client VM.
  • Real Server Port: 9443
We can view some statistics about the Virtual Services and Real Servers:


Client Access

I registered the virtual service IP address (10.10.20.20) in my local DNS (client.virtuallifestyle.nl) in order for my users to easily connect to the vSphere Web Client.

To check if the KEMP VLM really is load balancing:

Breaking stuff

Now, this blogpost wouldn’t be as fun if I just left it at this. I obviously need to break stuff:
Here’s what happens when I disable one of the vSphere Web Client nodes:

Likewise, here’s what happens when I disable one of the KEMP Virtual LoadMaster nodes:

Guess what happens if the primary site fails completely:

Lastly, here’s what happens when I disable one of the vSphere Web Client nodes and one of the KEMP Virtual LoadMaster nodes across sites (i.e. vWC01 and VLM02):

Concluding

The point of this exercise was to find out if I could create a geo-redundant configuration of a stateless application like the vSphere Web Client using KEMP’s Virtual LoadMaster. Even though this implementation does have a bunch of rough edges (razor-sharp ones at that), but it definitely works. The VLM’s installation and configuration, even in a CARP HA scenario is a laugh and can be completed in under 5 minutes while delivering a powerful set of load balancing and redundancy functionality.

Dave Stork has published a couple of posts (‘Differences in Exchange Load Balancing recommendations by Microsoft and vendors‘ and ‘Exchange, Load balancers and recommendations‘) on using LoadMaster in Microsoft Exchange environments. Please read up on his experiences, tips and tricks, it’s well worth the read!