DNS Load Balancing
Topic Last Modified: 2012-10-17
Microsoft Lync Server 2010 introduces DNS load balancing, a software solution that can greatly reduce the administration overhead for load balancing on your network. DNS load balancing balances the network traffic that is unique to Lync Server 2010, such as SIP traffic and media traffic.
If you deploy DNS load balancing, your organization’s administration overhead for hardware load balancers will be greatly reduced. Additionally, complex troubleshooting of problems related to misconfiguration of load balancers for SIP traffic will be eliminated. You can also prevent server connections so that you can take servers offline. DNS load balancing also ensures that hardware load balancer problems do not affect elements of SIP traffic such as basic call routing.
If you use DNS load balancing, you may also be able to purchase lower-cost hardware load balancers than if you used the hardware load balancers for all types of traffic. You should use load balancers that have passed interoperability qualification testing with Lync Server 2010. For details about load balancer interoperability testing, see "Lync Server 2010 Load Balancer Partners" at https://go.microsoft.com/fwlink/p/?LinkId=202452.
DNS load balancing is supported for Front End pools, Edge Server pools, Director pools, and stand-alone Mediation Server pools.
DNS Load Balancing on Front End Pools and Director Pools
You can use DNS load balancing for the SIP traffic on Front End pools and Director pools. With DNS load balancing deployed, you still need to also use hardware load balancers for these pools, but only for client-to-server HTTPS traffic. The hardware load balancer is used for HTTPS traffic from clients over ports 443 and 80.
Although you still need hardware load balancers for these pools, their setup and administration will be primarily for HTTPS traffic, which the administrators of hardware load balancers are accustomed to.
DNS Load Balancing and Supporting Older Clients and Servers
DNS load balancing supports automatic failover only for servers running Lync Server 2010 and Lync Server 2010 clients. Earlier versions of clients and Office Communications Server can still connect to pools running DNS load balancing, but if they cannot make a connection to the first server that DNS load balancing refers them to, they are unable to fail over to another server in the pool. If you have only a few clients or servers running earlier versions, or will soon be migrating these computers to Lync Server 2010, this may be tolerable.
Additionally, if you are using Exchange UM, only Exchange 2010 SP1 or latest service pack has built-in support for Lync Server 2010 DNS load balancing. If you use an earlier version of Exchange, you will not have failover capabilities for these Exchange UM scenarios:
Playing their Enterprise Voice voice mail on their phone
Transferring calls from an Exchange UM Auto Attendant
All other Exchange UM scenarios will work properly.
The following table summarizes the considerations for deciding whether to deploy DNS Load balancing on a Front End pool.
DNS Load Balancing on Front End Pool Decision Guidelines
| Situation | DNS load balancing supported? | DNS load balancing recommended? | Hardware load balancer (only) recommended? |
|---|---|---|---|
All or most users homed in the pool run Lync Server 2010 clients. |
Yes |
Yes |
|
Many users homed in the pool still running older clients. |
Yes |
Yes |
|
Interoperates only with other servers running Lync Server 2010. |
Yes |
Yes |
|
Interoperates with many servers running earlier versions of Office Communications Server. |
Yes |
Yes |
|
Running Exchange UM with Exchange 2010 SP1 (or not running Exchange UM) |
Yes |
Yes |
Deploying DNS Load Balancing on Front End Pools and Director Pools
Deploying DNS load balancing on Front End pools and Director pools requires you to perform a couple of extra steps with FQDNs and DNS records.
A pool that uses DNS load balancing must have two FQDNs: the regular pool FQDN that is used by DNS load balancing (such as pool01.contoso.com), and resolves to the physical IPs of the servers in the pool, and another FQDN for the pool’s Web services (such as web01.contoso.com), which resolves to virtual IP address of the pool.
In Topology Builder, if you want to deploy DNS load balancing for a pool, to create this extra FQDN for the pool’s Web services you must select the Override internal Web Services pool FQDN check box and type the FQDN, in the Specify the Web Services URLs for this Pool page.
To support the FQDN used by DNS load balancing, you must provision DNS to resolve the pool FQDN (such as pool01.contoso.com) to the IP addresses of all the servers in the pool (for example, 192.168.1.1, 192.168.1.2, and so on). You should include only the IP addresses of servers that are currently deployed.
DNS Load Balancing on Edge Server Pools
You can deploy DNS load balancing on Edge Server pools. If you do, you must be aware of some considerations.
Using DNS load balancing on your Edge Servers causes a loss of failover ability in the following scenarios:
Federation with organizations that are running previous versions of Office Communications Server.
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 and Jabber.
Note
To use XMPP, you must install the XMPP Gateway. You can download the XMPP Gateway from the Microsoft Download Center at https://go.microsoft.com/fwlink/p/?LinkId=204552. After you install the XMPP Gateway, you must install the hotfix, which you can download from https://go.microsoft.com/fwlink/p/?LinkId=204561.
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.
Using DNS load balancing also causes a loss of failover ability for these Exchange UM scenarios for remote Exchange UM users:
Playing their Enterprise Voice voice mail on their phone
Transferring calls from an Exchange UM Auto Attendant
All other Exchange UM scenarios will work properly.
The internal Edge interface and external Edge interface must use the same type of load balancing. You cannot use DNS load balancing on one Edge interface and hardware load balancing on the other Edge interface.
Deploying DNS Load Balancing on Edge Server Pools
To deploy DNS load balancing on the external interface of your Edge Server pool, you need the following DNS entries:
For the Lync Server Access Edge service, you need one entry for each server in the pool. Each entry must resolve the FQDN of the Lync Server Access Edge service (for example, sip.contoso.com) to the IP address of the Lync Server Access Edge service on one of the Edge Servers in the pool.
For the Lync Server Web Conferencing Edge service, you need one entry for each server in the pool. Each entry must resolve the FQDN of the Lync Server Web Conferencing Edge service (for example, webconf.contoso.com) to the IP address of the Lync Server Web Conferencing Edge service on one of the Edge Servers in the pool.
For the Lync Server Audio/Video Edge service, you need one entry for each server in the pool. Each entry must resolve the FQDN of the Lync Server Audio/Video Edge service (for example, av.contoso.com) to the IP address of the Lync Server A/V Edge service on one of the Edge Servers in the pool.
To deploy DNS load balancing on the internal interface of your Edge Server pool, you must add one DNS A record, which resolves the internal FQDN of the Edge Server pool to the IP address of each server in the pool.
Using DNS Load Balancing on Mediation Server Pools
You can use DNS load balancing on stand-alone Mediation Server pools. All SIP and media traffic is balanced by DNS load balancing.
To deploy DNS load balancing on a Mediation Server pool, you must provision DNS to resolve the pool FQDN (for example, mediationpool1.contoso.com) to the IP addresses of all the servers in the pool (for example, 192.168.1.1, 192.168.1.2, and so on).