I have had several clients lately wanting to use a less-expensive, yet still fully supported, hardware load balancer (HLB) solution for their Lync high availability environment. For most deployments, DNSLB (domain name system load balancing) works great; however, an HLB solution is still needed to provide HTTPS which cannot use DNSLB. HLB solutions are expensive when used just for this purpose. If an HLB stack already exists in the environment; great, we can use that. But what about needing to emplace HLB just for this one purpose? Can we use a less expensive solution and achieve our goals?
In this post, I will explore using a virtual hardware load balancer to provide the load balancing needed by Lync. I chose to try Kemp for several reasons. First, I have some experience with the product line, and second, they provide almost a turn-key solution for my lab’s virtualization platform (VMware). Third, Kemp VLB is on Microsoft’s Lync Server 2010 Load Balancer Partners approved list for both Exchange 2010 and Lync Server 2010. First we will setup for full Lync Enterprise Edition HLB, then we will change to using DNSLB and having the HLB do just the web services.
I strongly recommend that all Lync documentation be reviewed before working the HLB into your environment. Microsoft provides online documentation for Lync. Of specific interest is the Load Balancer Requirements. Kemp also has an excellent document on how to use their products with Lync. The Kemp product documentation is outstanding on giving you an understanding of what is needed and how to achieve your goal. You should also get a firm handle on the differences between doing a two-arm and a one-arm HLB setup. Also be aware that the Kemp does not participate in the Lync 2010 Domain Name System Load Balancing (DNSLB).
Lync: my lab is two Lync Enterprise Edition Servers in one pool, one Lync Archiving/Monitor server, a SQL 2008 R2 cluster, and two Lync Edge servers in a pool. The lab internal IP is 220.127.116.11/24, and I have TMG between the lab and my office network which is 10.10.10.0/24. The 10.0.0.0/24 net is essentially the internet to my lab.
WebCompExt.Tsoorad.net: 18.104.22.168 (internal) and 10.10.10.58 (external)
Kemp VLB: 22.214.171.124
For this article, we will configure the Kemp for the Enterprise Lync Pool. Before we start, two Kemp documentation notes:
- Port 7069 is listed as a required service for the front-end pool. This was accurate for OCS 2007 R2 but is not used in Lync.
- Port 5074 is shown as a optional service; again, this was OCS 2007 R2 and Outside Voice Control was not part of Lync.
**Kemp says they will fix these two items in the next document version
Setup the Load Balancer
Setup of the Kemp VLB is as simple as putting the downloaded image in a location and pointing your virtualization solution to it. Kemp has a Microsoft Hyper-V version and two VMware versions. Pick your favorite and install. I suggest that you investigate the single-arm solution first as that is somewhat easier. If you choose a two-arm install, you will need to change the default gateway on all your servers. I changed the provisioning defaults on mine to 1GB RAM and 1 CPU core and it is running just fine. I also made a point of choosing the network for the virtual machine before I started it. The Kemp startup instructions are here. I changed the defaults on mine to 1GB RAM and 1 CPU core and it is running just fine. Once you get past the licensing routine, you can login to the VLB.
Full HLB Configuration
Using an hardware load balancer for all Lync 2010 services involves more than a few ports. However, the Kemp documentation in concert with the Microsoft online documentation covers everything you need to know to be successful. To avoid too much detail and tedious reading (and writing), all you need to do is follow the Kemp document for Lync 2010 configuration. Here is my working configuration that matches my lab diagram above.
Items of note:
Notice that these three items have a “+1” after the VIP:port (e.g. 126.96.36.199:443). What I did was to leverage the “extra ports” setting in the VIP construction and add a port to the base VIP so that the VIP is servicing more than one port. In case (1) and case (2), they are both web services that land on the same front end server, but on a different port. As an experiment, I put port 80 with 443 (internal traffic) and port 8080 with 4443 (external traffic). All four ports work just fine!
The Virtual Services is showing some of my services as down – mainly because I am not using CAC - I did not want to confuse things by leaving out a service for our example.
The Kemp also clearly shows a service as being up or down, and also which real server under the VIP is not online per service. So, before you jump all over the “extra ports” example above and lump everything onto one VIP, keep in mind that Lync has multiple things going on at one time and that is the best reason to keep things separate. Here is the same setup with one server offline. Note that 188.8.131.52 is shown in red across the board indicating that something is not quite right.
Kemp as part of Lync Server 2010 DNSLB
To use this same setup with Lync DNSLB is very simple. First, realize that all that is going to change from the Lync perspective is that the LyncPool that previously was IP 184.108.40.206 will now have DNS A records that point clients to 220.127.116.11 and 18.104.22.168 with a preference hash that the Lync 2010 client deciphers and uses to find the pool MEMBER server. The Lync web services get a new URL that is 22.214.171.124. Basically, if the traffic destined for the Lync Enterprise Pool is HTTP or HTTPS, it needs to land on the HLB first.
So here is the new lab diagram. Only one thing has changed: The LyncPool IP is now two IP’s.
The Kemp documentation does not cover setup for pure DNSLB; and it really does not need to do so – it is so simple, even *I* could do it. Here it is. Note that I pulled the 80 and 8080 services out to their own VIP.
For Lync Server 2010 to be highly available, there are two options: using pure Hardware Load Balancers or using Microsoft’s DNSLB. Either way, an HLB is needed for the Lync Web Services. If you want to reduce your costs and stay in a supported posture, Kemp is one solution that provides both. In addition, Kemp is very easy to use and comes in both appliance and virtual.