||Posted 4 years 17 days ago ago by Christian Burke 0 Comments
0 Loved 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.
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.
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.
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.