Lync HLB Edge

Lync Server 2010 has two modes of load balancing:  DNSLB (Domain Name System Load Balancing) and it also support hardware load balancing (HLB).  DNSLB works really well; however, there are some limitations regarding the Lync Edge when it comes to load balancing.  Specifically, because DNSLB is implemented at the client level, if your DNSLB is broken due to a server outage, then the remote users on downlevel clients, federated partners using OCS R2 (or earlier), XMPP clients, etc., may not work because they cannot find the second server; this is especially evident if the first server in the DNS records is the server that fails.  External Exchange UM sessions may also fail to work for the same reason.  Many implementations are therefore done with HLB on the Edge.  In a previous article, I showed how to setup a Kemp Load Balancer to support these two high availability modes for internal operations with Lync Server.  In this article, I will demonstrate HLB for the Lync 2010 Edge.

The Setup

Setting up the Lync Edge HLB is really all about understanding your network and the relationships between NICs on real servers versus IP on HLB VIP, IP on public edges of firewall/routers, and how traffic needs to flow from device to server to device to server.  And where traffic needs to go on the inside versus where the traffic needs to go when headed outside.  Clear as mud?  Excellent!

Kemp publishes a very nice document on “how to” accomplish HLB and Lync with their products.  Just so you can follow along, my lab is setup for the alternate deployment method shown on page 25.  I am using one Kemp VLB for both internal and external HLB functions. I am also using all roles consolidated and there are no directors.

My lab does not have a security issue as I address all security before traffic enters my lab net.  You should evaluate your risk and implement accordingly.  FWIW, I always advise clients to double firewall and use a set of HLB in the perimeter net for Lync (and OCS)(and everything else that needs it) along with internal HLB.  YMMV.

Here is how I have the lab setup for this exercise:

This illustrates what the Kemp documentation refers to as a “one-arm” deployment.

The Kemp documentation, along with the Microsoft Lync Server online documentation for Edge deployments, provides all the guidance you need.  I won’t try to duplicate those instructions here; instead, here is what my Kemp looks like after working through the configuration guide.

LyncEdgePool.tsoorad.net: 1.1.1.65 (Edge internal VIP on VLB)

     LyncEdge.tsoorad.net: 1.1.1.60 (Edge Server1 internal NIC)

     LyncEdge2.tsoorad.net: 1.1.1.61 (Edge Server2 internal NIC)

SIP.tsoorad.net: 10.10.10.60 (VIP on the VLB)

     SIP.tsoorad.net: 10.10.10.63 (Edge Server 1 external NIC)

     SIP.tsoorad.net: 10.10.10.66 (Edge Server 2 external NIC)

WC.tsoorad.net: 10.10.10.61 (VIP on the VLB)

     WC.tsoorad.net: 10.10.10.67 (Edge Server 1 external NIC)

     WC.tsoorad.net: 10.10.10.64 (Edge Server 2 external NIC)

AV.tsoorad.net: 10.10.10.62 (VIP on the VLB)

     AV.tsoorad.net: 10.10.10.65 (Edge Server 1 external NIC)

     AV.tsoorad.net: 10.10.10.68 (Edge Server 2 external NIC)

Observe that I am using the same LB as the previous article; I have added another NIC to the VM, bridged that NIC to the proper subnet, and started configuring.

Errata

As with all things, nothing is perfect.  The following items in the Kemp guide are noted for consideration and clarity.

Starting with section 8.2 (page 36) step 15, the guide says “For each Front-End server…”  It should really say Edge Server.  If you refer to the IP addresses given in the guide, and look at page 35, the guide clearly wants Edge server not Front-end, and common sense dictates the same.  This comment is made for each subsequent Real Server setup for Edge Services.

On page 26, section 5.1 (General Configuration – Disable Global SNAT) the option for “enable SNAT” is unchecked.  However, when doing the Edge external services for AV on page 42, in sections 9.6 and 9.7, the guide instructs us to “Select the Use Address for SNAT checkbox” – ooops!  Unless you go back and set the global to “ENABLE SNAT” the option does not show up in the Virtual Server Standard Options.  After enabling that option in the System Configuration | Miscellaneous Options | Network Options, THEN I got the check box for the Virtual Service | Standard Options.

Luckily, in response to my support request, the folks at Kemp support sent me an excellent description of how to find the check box in each location.

Summary

All in all, an almost painless evolution.  It literally took me longer to reconfigure my lab to support this exercise than it did to configure the Kemp to provide a full HLB Edge solution.  With the exception of the missing check box for SNAT and the mis-labeling of server IP to use, everything went as advertised.  If you need a high-availability solution for your environment that is fully supported by both the third-party and by Microsoft, this might be a good choice for your deployment.  For what is it worth, Kemp is also on the Exchange OIP, and I could easily use this same VLB for my Exchange deployment.

YMMV.