Search

Lync 2013 Hardware Load Balancing vs DNS Load Balancing

Posted 4 years 21 days ago ago by Christian Burke     0 Comments

10 Loved it Love It Hate It

When considering High Availability, the question about whether to use Hardware Load Balancing or DNS Load Balancing (or BOTH! – my personal favorite) always comes up. Here is a list of important factors when architecting a Highly Available Lync 2013 Enterprise deployment.

HTTP/HTTPS Services

The main things that HTTP(S) is used for is downloading the address book, accessing certain types of shared content (for example, PowerPoint slides uploaded into a meeting), web-based meeting connectivity, group expansion, and device updates (there are a few other items as well).

If you don't have Hardware Load Balancing for HTTP(S) then you'll have to point to a single server, which will give you a single point of failure. When that server is down, those services will be unavailable

HTTP/HTTPS Session State

Both HTTP and HTTPS are session-state–oriented protocols. This means that if I start a conversation with Server A, Client A needs to continue to talk with Server A to complete the entire request. With DNS load balancing, there is no sticky-session state that can be set up. As a result, there is no way to ensure that a session is going to be continued on Server A.

HLB specifically addresses this session problem by caching the client-server state information; when the next request comes in from Client A, the HLB refers it back to Server A–regardless of whether Server A is busy. It waits and sends the request when possible. Hence, for Web-based traffic, DNS load balancing is not a solution.

So bottom line, if DNS is used without HLB HTTP/HTTPS traffic will have a pretty good chance to fail even if all your servers are up and running.

Reliance on the Endpoint

DNS Load Balancing relies on the client or endpoint to decide the availability of the servers in each pool. If the endpoint does not have the ability to DNS Load Balance, then it will merely select the first server in the pool. If that server is unavailable, the endpoint will not connect.

Hardware Load Balancing puts the decision of server availability in a pool on a single device, the HLB, and relieves the endpoint of that duty.

Federation Restrictions

Using DNS load balancing on your Edge Servers causes a loss of failover ability in the following scenarios:

  • Federation with organizations that are running versions of Office Communications Server released prior to Lync Server 2010.
  • Instant message exchange with users of public instant messaging (IM) services, such as Windows Live, AOL, and Yahoo!, in addition to XMPP-based providers and servers, such as Google Talk.

These scenarios will work as long as all Edge Servers in the pool are up and running, but if one Edge Server is unavailable, any requests for these scenarios that are sent to it will fail, instead of routing to another Edge Server.

Exchange Server UM

If you are using Exchange UM, you must use a minimum of Exchange 2010 SP1 to get support for Lync Server DNS load balancing. If you use an earlier version of Exchange, your users will not have failover capabilities for these Exchange UM scenarios:

  • Playing their Enterprise Voicemail on their phone
  • Transferring calls from an Exchange UM Auto Attendant

All other Exchange UM scenarios will work properly.

Configuration Restrictions

Some basic guidelines must be followed when using Hardware Load Balancing for Edge services:

  • Each external-facing Edge service needs a publicly routable virtual IP address. It’s true, there is ZERO way around it
  • Each Edge Server needs three publicly routable IP addresses assigned.
  • The internal Edge interface and external Edge interface must use the same type of load balancing. You cannot use DNS load balancing on one interface and hardware load balancing on the other.


About the Author

No Comments


Add Comment

Enter the name you would like to appear on the comment.
(required)
Enter the email you would like to use to get updates. You email is not visible and can not be used by other users.
(required)
If you have a website, enter the url here. Ex: www.site.com
Enter you comment help.

CAPTCHA image
Enter the code shown above in the box below
 
  Post Comment
Christian Burke is currently employed by and provides Unified Communications solutions for Microsoft Corporation.  With his primary focus as a Lync Voice Technology Solutions Professional, he is dedicated to designing and building cutting edge Lync infrastructure for clients around the world.  He created this blog to document some of the many processes he has grown familiar with over the past few years.  He knows that blogs, especially for Lync where good documentation is dodgy at best, are a crucial information source for building the perfect Lync system.  So, this blog is his contribution.  Enjoy.
Copyright 2017 by xLync.com