[This is pre-release documentation and subject to change in future releases. This topic's current status is: Milestone-Ready]

Topic Last Modified: 2010-07-15

Communications 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 Communications Server, such as SIP traffic and media traffic. If you deploy DNS load balancing, you can eliminate the need for some hardware load balancers, and greatly reduce the administration overhead related to some of the hardware load balancers you will still need to deploy.

DNS load balancing is supported for Front End pools, Edge Server pools, Director pools, and standalone 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 will still need to also use hardware load balancers for these pools, but only for HTTP and Distributed Component Object Model (DCOM) traffic. The hardware load balancer will be used for HTTP traffic from clients over ports 443 and 80, and for DCOM traffic over port 135 from administrators performing user moves.

Although you will still need hardware load balancers for these pools, their setup and administration will be primarily for HTTP traffic, which the administrators of hardware load balancers are accustomed to.

DNS Load Balancing and Downlevel Computers

DNS load balancing is supported only by servers running Communications Server 2010 and Communications Server 2010 clients. Older clients and server can still connect to Front End pools and Director 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 downlevel clients or servers, or will soon be migrating these computers to Communications Server 2010, this may be tolerable. Alternatively, you may achieve load balancing of connections from older clients and server by implementing DNS round robin on the DNS Server. In this case, the DNS Server will reply back with a different order of Front End IPs every time a DNS query reaches it, and this in turn will ensure that connections from downlevel computers are load balanced.

Additionally, if you are using Exchange UM, only Exchange 2010 SP1 interoperates with Communications Server DNS load balancing. If you use a previous version of Exchange, you will not have failover capabilities for users using Exchange UM capabilities, such as playing their Enterprise Voice voicemail through their mailbox.

The following table summarizes the considerations for deciding whether to deploy DNS Load balancing on a Front End pool.

DNS load balancing 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 Communications Server 2010 clients.

Yes

Yes

Many users homed in the pool still running older clients.

Yes

Yes

Interoperates only with other Communications Server 2010 servers.

Yes

Yes

Interoperates with many servers running earlier versions of Communications Server.

Yes

Yes

Running Exchange UM with Exchange 2010 SP1 (or not running Exchange UM)

Yes

Yes

Running Exchange UM with earlier versions of Exchange

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 pool1.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 web1.contoso.com), which resolves to virtual IP address of the pool.

    In topology designer, 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 checkbox 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 pool1.contoso.com) to the IP addresses of all the servers in the pool (such as 192.168.1.1, 192.168.1.2, and so on).

DNS Load Balancing on Edge Server Pools

You can deploy DNS load balancing on either the external interface of your Edge Servers, the internal interface, or both. If you do, you must be aware of some considerations.

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

  • Federation with organizations that are running previous versions of Communications Server.

  • Instant message exchange with users of public instant messaging (IM) services, such as Windows Live, AOL, and Yahoo!, as well as XMPP-based providers and servers, such as Google Talk and Jabber.

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

Using DNS load balancing on the internal interface of the Edge Servers causes a loss of failover ability when external users use Exchange UM features. For example, when one of your users checks voicemail while outside your organization’s firewalls, if their request goes to an Edge Server that is down, the request will fail instead of going through another Edge Server.

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 Access Edge service, you need one entry for each server in the pool. Each entry must resolve the FQDN of the Access Edge service (such as sipcontoso.com) to the IP address of the Access Edge service on one of the Edge Servers in the pool.

  • For the Web Conferencing Edge service, you need one entry for each server in the pool. Each entry must resolve the FQDN of the Web Conferencing Edge service (such as webconfcontoso.com) to the IP address of the Web Conferencing Edge service on one of the Edge Servers in the pool.

  • For the A/V Conferencing Edge service, you need one entry for each server in the pool. Each entry must resolve the FQDN of the A/V Conferencing Edge service (such as avcontoso.com) to the IP address of the A/V Conferencing 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 need one DNS entry for each Edge Server in the pool. Each entry should resolve the internal FQDN of the Edge Server pool (such as sipinternal.com) to the IP address of one of the Edge Servers in the pool.

Using DNS Load Balancing on Mediation Server Pools

You can use DNS load balancing on standalone Mediation Server pools without need for a hardware load balancer. 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 (such as mediationpool1.contoso.com) to the IP addresses of all the servers in the pool (such as 192.168.1.1, 192.168.1.2, and so on).