Tuesday, February 7, 2012

Hardware Load Balancers in Lync

Over the past while, I've come across several Enterprise Edition Lync deployments done by other companies that utilized hardware load balancers for all Lync services.  In every case, the reason given for using the hardware load balancers was "so we could have high-availability".  They were shocked to find out that hardware load balancing all Lync services is actually not recommended in a wide variety of scenarios and they could have saved themselves a lot of time and money.

When I design a highly-available Lync deployment, I ask four questions whose answers determine where hardware load balancers are required:
  1. Will the majority of internal clients be running Lync?
  2. Will the majority of external clients be running Lync?
  3. Do you require high-availability when federating with companies running OCS 2007 R2 or older, or MSN/Yahoo!/AOL/GoogleTalk/Jabber?
  4. Do your external users need to play messages on their phone during a failover?
If the answer to #1 is "No", then I recommend against using hardware load balancing (HLB) for all internal Lync front-end pools.  If the answer to #2, #3 and #4 are also "No", then I recommend against using HLB for edge servers as well.

Before I go on, I should stress that HLBs are still required for load balancing HTTP/HTTPS traffic to the front-end servers.  Since web connections are session based, they are not suitable for DNS load balancing.  So, for your web services (which includes address book downloads, meeting content and meet/dialin URLs), you will still need a simple HLB solution, which can be provided by either hardware or even a dedicated software-based load balancer (but don't use Windows NLB, its not supported)

Using hardware load balancers in Lync can be a costly endeavour for many reasons:

  • For a full HLB solution for a single Lync site with edge services, you would need an HLB for the front-end pool, an HLB for the internal interfaces on your edge pools and an HLB for the external interfaces on your edge pool.  That's 3 HLBs.
  • Many HLBs are not well suited to real-time communication.  HLBs that support real-time media are much more expensive than one used only for web traffic balancing.  
  • Configuring the load balancers to work with Lync is much more complicated and extends the implementation time. It can also complicate troubleshooting connectivity issues. 
  • Putting additional hardware between your users and the servers also introduces additional network latency, which is something you want to minimize where possible.  
  • Finally, the HLBs themselves can be a single point of failure, unless you deploy multiple nodes.
Lync can use DNS load balancing to provide high availability.  That term is misleading, because it implies that  DNS is responsible for load balancing, which is not true (or possible, since you can only do DNS round-robin in most cases).  DNS is only used to present the initial list of available front-end or edge servers (depending on if the user is internal or external).  Once the Lync client successfully connects to Lync, it caches the IP address of each server in the pool.  The user will preferably connect to the same server at each login (calculated using an algorithm described here), but if that server is unavailable, the client will automatically and seamlessly connect to another server in the pool.  The same is also true for federated connections from other companies, as long as they are using Lync for their edge servers.   

For legacy connections or 3rd party IM provider connections to a DNS load balanced Lync pool, the clients/edge server will only connect to the first IP address that is returned from a DNS lookup.  Should that server go down, they will not failover to an alternate server.  The same is true for external users who try to listen to Exchange-based voicemail messages during a failover.  If legacy/3rd party connections or external access to voicemail (and remember that voicemail messages are always accessible via Outlook) are important, then this is the ONLY reason I would deploy HLB on your edge servers.  In most cases, the company accepts the reduced potential for legacy high-availability in return for a simpler, cheaper and more reliable solution.

So before you go and drop a ton of money on hardware load balancers, make sure you understand the built-in high-availability capabilities in Lync first, so you can make an informed decision.

For more information on DNS load balancing in Lync, check out these links:
Lync DNS Load Balancing on Technet
Lync DNS Load Balancing on NextHop


  1. Hi Ken, I was wondering if you could please let me know if in the case of DNS load balancing once the client has established a connection a front end server are all web services connections then targeted to this server only? The question I am trying to find an answer for is can DNS load balancing be used without a hardware load balancer for web services. Any help would be much appreciated.

    1. Hi there,
      Web services cannot use DNS load balancing due to the nature of HTTP/HTTPS connections. If you have multiple front-end servers, you should have a hardware load balancer to provide high availability for web services. If you're really strapped, you can point DNS to one of the front-ends and switch as necessary, but you lose automatic high availability and the Lync client may not check for the changed IP and have to restart in the event of a failover.



  2. Hi Ken,
    Great article and thanks for it. Quick Question, hopefully not a silly one. For the mobility services to work efficiently do you need HLB ? I'm running 2 front ends.

    1. Yes, for mobility services to be load balanced you will need a HLB. Mobility services are done via HTTPS, so can't be load balanced via DNS load balancing.


  3. Hi Ken,

    Given the changes in mobility service and external clients connecting using UCWA for Audio/Video traffic as well, I believe the hardware load-balancers play a more crucial role here that ever before. I also see Microsoft pushing them more towards F5 LTM and Citrix Netscaler kind of devices (Kemp, I am not sure, would scare for such workload) for such complex workloads.

    Ho do you see the changes impacting capacity planning and architectural changes?


    1. Hey Animesh,
      With the new A/V mobility components, all mobile-based A/V media traffic will still use the edge servers, so there shouldn't be much additional load on your load balancers web traffic wise.


  4. good article although i think you may need to revist your answer to Question 1

    "If the answer to #1 is "No", then I recommend against using hardware load balancing (HLB) for all internal Lync front-end pools"

  5. Hi Ken, do you have any articles on how to setup your NLB for Lync, i.e. the HTTP/HTTPS services ? I am not sure I get what you mean by HLB for HTTP/HTTPS .. if I configure pool.contoso.com to be on the HLB, then all traffic will flow through the HLB (at least that is my understanding).