If you’re running a multi-server Lync 2013 pool for any of your Lync roles, you’re probably already aware of the load balancing options available to you; DNS and HLB. The pro’s and con’s of each are outside the scope of this particular article, but are widely documented around the bazaars. Instead we’ll be looking at how we can hardware load balance our Lync Front End web services using a Kemp Technologies solution, and address this particular TechNet statement of fact regarding Lync architecture:
“A Front End pool can contain a maximum of twelve Front End Servers. Load balancing is required for multiple Front End Servers. For SIP traffic, we recommend DNS load balancing, but hardware load balancing is also supported. If you use DNS load balancing for SIP traffic, you still need a hardware load balancer for HTTP traffic“
This statement can be a little misleading if interpreted incorrectly. You don’t actually ‘need’ a hardware load balancer for HTTP if you’re balancing SIP with DNS, you can just choose not to balance HTTP at all, and in truth this goes on a lot with the smaller deployments. So lets assume we have DNS load balancing configured for our Front End pool, and we’re going to complete the solution by implementing a Kemp Virtual LoadMaster to balance Front End web services in our lab environment.
Kemp me up!
First we’ll visit Kemp Technologies and grab a free 30 day trial of a Kemp Virtual Load Master. Simply select your hypervisor of choice from those available (VMware Workstation in my case), and follow the onscreen prompts to complete the process. You’ll need to go ahead and create a Kemp account / ID as part of the procedure, as it’s this ID that will be used to activate your Virtual LoadMaster for it’s free 30 day trial. Despite not being able to spell the word ‘required’ under the memory requirements (see shameful screen shot) we’ll let them off and gladly accept their free offering!
Once you’ve downloaded your virtual machine, go ahead and power it on. I’d advise making a backup copy of the configuration and disk files, or taking a snap shot of the machine so you can start afresh any time. Once the boot process is complete you’ll be presented with the below login prompt – no GUI, don’t panic. We’re not even going to login here, instead we just need to note some details that are also present on the screen; the IP address, default username, and default password.
Go ahead and point your favorite web browser to the (now known) IP address of your appliance – in my case https://192.168.1.84 as indicated in the above image. Once agreeing to the EULA, you’ll be presented with the Licensing Screen. Enter your Kemp ID and password as defined when you downloaded the virtual load master and created your Kemp account – click License Now. Clicking OK to acknowledge the trial license expiry message will cause a credentials login box to appear – enter the username and password you noted earlier. Finally, we’ll be asked to enter a new password for security reasons, and then prompted to log back in with this password before being dropped at the LoadMaster landing page as below.
This device will be used to balance our Lync Front End web services traffic, and as such will sit on the same subnet as our Lync servers themselves. Lets perform some basic device configuration before we worry about anything else.
• System Configuration > Interfaces > eth0
Right now we’re using the management address that was provided to us at boot up. Change the interface address to one of your own choice with the appropriate mask and click ‘Set Address’ (192.168.1.115/24 in my case).
• System Configuration > Local DNS Configuration > Hostname Configuration
Replace the hostname with something that aligns with your own naming convention and click ‘Set Hostname’ (Gecko-VLM in my case).
• System Configuration > Local DNS Configuration > DNS Configuration
Under DNS NameServer add the IP addresses of your domain name servers, and in the DNS search domain enter your fully qualified active directory domain name.
• System Configuration > Route Management > Default Gateway
Enter the IP address of the default gateway and click ‘Set IPv4 Default Gateway’.
As well as the basic networking configuration, Kemp also have a couple of recommended global settings that should be in place when using their devices in a Lync environment.
• System Configuration > Miscellaneous Options > Network
Disable ‘Enable Server NAT’ which is ordinarily enabled by default.
• System Configuration > Miscellaneous Options > L7 Configuration
Enable ‘Drop Connections on RS Failure’ for faster fail over of services.
• System Configuration > Miscellaneous Options > L7 Configuration
Change the L7 Connection Drain Time to 86400 (1day).
Configuring Virtual Services
Next we’ll download the Lync 2013 Core Services Kemp Templates from the Kemp website and install them as below. These templates consist of virtual services for various scenarios that already have the recommended settings configured and have been tested as working solutions. They’re not unique to Lync, and indeed they’re not unique to Kemp Technologies either – other vendors also make use of this friendly configuration approach. In this instance there’s a template for Lync 2013 Web Services when the rest of your Front End services are being DNS load balanced – that’s exactly what we’re after.
• Virtual Services > Manage Templates
Click browse and locate the template file (.tmpl) downloaded in the previous step. Click Add New Template to install the Lync Core services templates onto the VLM. A summary of the 11 templates will appear, we’re interested in the ‘Lync Internal 2013 DNS’ template. This template assumes that our Lync 2013 internal environment is DNS load balanced. It therefor only contains the settings to deal with anything that can’t be DNS load balanced – our web services! (HTTP).
• Virtual Services > View / Modify Services
Click the ‘Add New’ button at the top left of the screen to launch to new virtual service parameter window. We’re creating a virtual service for our Lync web services, so we need to provide an IP address for said service. As far as our Lync clients are concerned, it will be this single address that’s servicing their web services requests – naturally it must be unique. In the ‘Use Template’ drop down box select ‘Lync Internal 2013 DNS’. We don’t need to add any other information in the remaining fields as the template will take care of this for us, but if you want to change the service name go ahead and do so (I tend to rename it to Lync Web Services). Click ‘Add this Virtual Service’ once complete.
Next we’ll be faced with the properties of a virtual service, but lets back out of here for a moment and get a high level view of the virtual services that were just created as a result of using the predefined template. Click the view / modify services link in the left menu under the virtual services node to gain an overview of your services as below.
Notice how the template has created two virtual services for us; HTTP and HTTPS. Not only that, but the properties of these services already have the recommended settings for balancing Lync web services. Its worth mentioning that even if you create your virtual services using templates, you can still jump in and edit the properties afterwards if there’s something you’d like to tweak. Lets examine virtual service 1 – the HTTP one.
The virtual IP address for the service is expressed as 192.168.1.116:80(+1). This indicates that the service is also listening on one other port in addition to 80, in this case 8080 for unencrypted external web service traffic. The same will be true of the HTTPS virtual service, a +1 indicating that it is also listening on 4443 for encrypted external web service traffic as well as 443. The status of both services is currently marked as down. Click modify on one of the services to access it’s properties page.
Expand the ‘Real Servers’ node at the bottom of the list and click ‘Add New’ to launch the real servers parameter window. Enter the IP address of a Lync Front End server in the real server address field and click ‘Add This Real Server’ (Do not change the port). Repeat the process for your remaining Front End servers. For the purposes of this lab I’ve added two real servers as seen below.
The Real Server Check Parameters are (once again) defined by the template that we’re using, asking the virtual service to use port 5061 as a keep-alive check against these servers. In the event there is no response from a server on 5061 it will be dropped as a forwarding option until such a time that it becomes responsive again. Click the view / modify services link in the left hand menu. Providing your Front Ends are up and running, we should now have an ‘Up’ status for the virtual service we’ve just modified the properties of. Repeat the process for the other virtual service that’s still down by adding in the real servers, and you should be left with something similar to below.
The Kemp Virtual LoadMaster is now ready to balance our Lync web service traffic. In my case I have a virtual service IP of 192.168.1.116. Web service traffic coming into this address will then be spread across my two real Front End servers; 192.168.1.111 and 192.168.1.112. On the Lync side then we just need to make sure that our internal web service traffic is indeed being pushed to the virtual service IP address. Launch Lync topology builder and edit the properties of your Front End pool to view the web services.
By default the Internal Web Services FQDN will be that of the pool itself. This is not good, and even if you’re not using a hardware load balancer, you should change this to point to just a single Front End server in your pool for persistence reasons. In our case though we need it to point to the virtual service IP for web services on our Kemp VLM. Either create, or edit your existing internal web services DNS A record to point to the Kemp Virtual web services address (In my case webinternal resolves to 192.168.1.116). Once the topology is published, all internal Lync client web traffic will now hit our Kemp on 192.168.1.116 and be spread across both our Front End servers – joy.
From an external perspective, in a non-load balanced scenario the Reverse Proxy is passing web traffic directly to the Front End servers. Change the rules accordingly so that it now passes the traffic to the Kemp VLM web services virtual IP address instead, and set the ‘forward host header’ to true – this will ensure that the original URL is forwarded.
Load balancing configuration varies massively depending on the environment in which its being implemented. Balancing web services alone is reasonably straight forward, but even then the virtual service settings tailored for one deployment might not be suitable for another. Here we’ve only configured the bare minimum in order to provide basic hardware load balancing of web services – so please don’t consider this de facto.
Finally, for anyone who is wondering about the previously required cookie based persistence for session affinity with Lync 2010 mobility, I leave you with this excerpt;
“Cookie-based affinity requirements are greatly reduced in Lync Server 2013 for Web services. If you are deploying Lync Server 2013 and will not retain any Lync Server 2010 Front End Servers or Front End pools, you do not need cookie-based persistence. However, if you will temporarily or permanently retain any Lync Server 2010 Front End Servers or Front End pools, you still use cookie-based persistence as it is deployed and configured for Lync Server 2010.
If you decide to use cookie-based affinity even though your deployment does not require it, there is no negative impact to doing so.”