Understanding Lync DNS Load Balancing

In Microsoft Office Communications Server (OCS) 2007 R2 and earlier, the only supported load balancing solution is a hardware load balancer. Fortunately, Microsoft introduced DNS load balancing in Lync Server 2010.

DNS load balancing in Lync Server 2013 hasn't changed much from that in Lync Server 2010. I'll answer three questions commonly asked about the Lync DNS load balancing solution found in these two versions:

What Is Lync DNS Load Balancing?

Lync DNS load balancing balances the network traffic that's unique to Lync Server, such as Session Initiation Protocol (SIP) traffic and media traffic. With this out-of-the box solution, administrators can quickly ensure some resiliency for their Lync enterprise pools. However, all HTTP and HTTP Secure (HTTPS) traffic still needs to be balanced by a supported hardware- or software-based solution. Lync DNS load balancing is supported for Front End pools, Edge pools, Director pools, and stand-alone Mediation pools.

How Does Lync DNS Load Balancing Work?

Before I explain how Lync load balancing works, I want to first dispel a myth about it. Lync DNS load balancing is not the traditional round-robin DNS, with which most administrators are familiar.

The best way to show the difference between the two types of load balancing is with an example. Suppose that you have two Lync 2013 Front End Servers, each with their own respective IP address. The first Front End Server has an IP address of 10.10.10.1. The second Front End Server has an IP address of 10.10.10.2.

In the round-robin DNS approach, a Lync client would get back only one IP address when it's requesting to sign in. For instance, suppose that three Lync clients sent sign-in requests. The first client would receive the IP address of 10.10.10.1, the second client would get back 10.10.10.2, and the third client would receive 10.10.10.1.

Lync Server's way of handling DNS load balancing follows a different pattern. For starters, you need to configure a pool for DNS load balancing. Each Front End Server in the pool must have a Fully Qualified Domain Name (FQDN). The pool must also have a FQDN (e.g., Pool.contoso.com), which resolves to the physical IP addresses of the servers in the pool. Finally, the pool's Web Services needs a separate FQDN (e.g., Webinternal.contoso.com), which resolves to the virtual IP (VIP) address of the pool. Figure 1 shows a sample pool.

Figure 1: Pool Configured to Use Lync DNS Load Balancing

Table 1 shows the IP addresses for that pool.

In the Lync DNS load balancing approach, each Lync client gets back the IP addresses of all the Front End Servers when it's requesting to sign in. So, in this example, each client gets back the IP addresses of 10.10.10.1 and 10.10.10.2. The client would then try one of the IP addresses. If that connection fails, it would try the other IP address.

What Are the Caveats of Lync DNS Load Balancing?

Before implementing Lync DNS load balancing, you need to be aware of the following caveats:

A Good Start

Using the Lync DNS load balancing solution is pretty appealing, as it's ready to use right out of the box. It's a good solution to meet the immediate need of providing resiliency for Front End Servers. However, you can't totally escape from using a hardware- or software-based load balancing solution if you need to provide resiliency for HTTP and HTTPS traffic.