The latest version of Microsoft Lync has a number of enhancements that improve performance and availability as well as help to minimize the impact of outages. Even with these improvements, there is still the need for load balancing Microsoft Lync in an enterprise architecture. DNS load balancing can provide higher availability and traffic distribution for certain services, while an external (hardware or software) load balancer is required for HTTP and mobility. For web services, Lync also requires a reverse proxy – a requirement that can be filled by an external load balancer.
Microsoft Lync is designed to take advantage of DNS load balancing for a portion of its environment, principally SIP and IM. One of the advantages that DNS load balancing offers is that it supports a number of Lync components with a simplicity that makes it easy to use and configure. However, this doesn’t change the fact that hardware load balancers would still be required for the following services and reasons:
- Load balancing traffic to the front end server HTTP/HTTPS
- Session based web connections not suitable for DNS load balancing
- Web services including downloads of the address book
- Meeting content
- Meeting dial-in URLs
In order to meet these requirements, you would need to deploy a simple hardware or even a virtual load balancer. One thing to keep in mind when choosing a load balancing solution is that the Windows network load balancer (WNLB) is not supported and cannot be used in this environment.
For a single Microsoft Lync site with edge services, it would be necessary to deploy load balancing services in three zones. This can be accomplished using one to three load balancers. If fewer than three are used, at least one of the load balancers will have to be multi-homed. This should be considered in the context of organization information security standards.
Because Microsoft Lync has very specific requirements when external load balancers are deployed, make sure that the vendor you choose has comprehensive support and documentation available to help guide you through the configuration. Also, remember that hardware load balancers should be deployed in high availability mode to avoid the risk of having a single point of failure in the network.
Microsoft Lync uses DNS round-robin for a number of its traffic distribution functions. It works by showing an initial list of the front-end or edge servers which are available to users. The moment the client successfully connects to Lync, it caches the IP address of each server in the pool. It is preferable that the user connects each time to the same server at login, using an algorithm that manages these connections. However, should the server become unavailable, the client will be connected automatically to another server in the pool – assuming they are leveraging a client that can support this functionality.
Third-party IM provider connections of legacy connections use DNS to access the load balancing Lync Pool. The edge/client server will make a connection with the first IP address that is offered after a DNS lookup. Automatic failover to an alternative server is not available should the server they have originally connected to go down. The same situation occurs for any external users who intend to connect to Microsoft Exchange based voicemail. When the server goes down, the session hangs up.
In summary, it is important to consider your load balancing requirements for Microsoft Lync and other services in a holistic way. DNS serves many of the requirements of Lync deployments. It is simple to deploy and effective in operation. Hardware or virtual load balancers can provide the broader load balancing requirements for your other network applications and services while addressing Lync services at the same time.