Load Balancing is a not a good to have requirement for any Enterprise Edition pool but it is a must to have requirement. In layman language if you have more than one server in a group/pool which are responsible for same service, you need a method to balance the traffic among those servers.
If you have a Standard Edition deployment then obviously you don’t need any load balancing method because each server is responsible for a specific set of users.
Now, it is very important to understand which kind of traffic you deal with when you deploy enterprise edition pool.
Server-to-server traffic: Server-to-server traffic doesn’t need any external load balancing method; it uses topology-aware load balancing. Lync/Skype4B is intelligent enough to handle traffic between servers. Servers read the Central Management store which are part of the published topology and obtain the FQDNs of servers in the topology to distribute the traffic among the servers. It is an automatic process and doesn’t need any external intervention.
Client-to-server traffic: Client-to-server traffic is an important configuration part after Lync/Skype4B pool deployment. Planning and decision making is a key for client-to-server traffic which decides how the traffic will route from end-users to the servers. Simply, the traffic can be divided into two part i.e. Non-web (Non-HTTP/HTTPS) traffic and Web (HTTP/HTTPS) traffic. Based on the traffic, you can decide the load balancing methodology. Lync/Skype4B supports two types of load balancing:
- DNS Load Balancing
- Hardware Load Balancing
HLB supports both the traffic web and non-web while DNS load balacing supports only non-web (Non-HTTP/HTTPS) traffic. Therefore, there are two ways to configuring load balancing.
First Method (Mixed mode configuration): HLB for web traffic and DNS load balancing for rest of the traffic. This a best method to choose as it reduces dependency on HLB and simplify the solution using DNS for most of the traffic. You can use this method for all the internal servers pool as well as for Edge pools. But there are some caveats which you have to consider while planning this method for Edge pools:
- You need HLB if you are federating with OCS and OCS R2 or federating for PIC connectivity.
- You need HLB if you are using Exchange UM services with prior to Exchange 2010 SP1 (applicable only for remote users).
Second Method (Only HLB configuration): Full-fledged HLB deployment. It caters all the services but you need expertise to configure and manage the HLB and it is not as simple as DNS load balancing. Please follow all the best practices which are required for HLB. Review the Microsoft technet article for load balancing and vendor specific document for best practices.
You must use the same type of load balancing method for internal and external interface of Edge servers. NAT is not supported on both internal and external firewall for Skype4B traffic.
Now, we should talk about the web services. There are different types of web services: (i) Internal Web Services (ii) External Web Services (iii) Office Web Apps. You deploy reverse proxy for external web services which include external web url, meet and dial-in url while internal users directly go to the IIS for internal web services. Office Web Apps url can be published through reverse proxy. You should use source address affinity for internal web services only not for external web services.
Finally, I believe you can choose the best load balancing option for your deployment 🙂
Please write your comments or concern so that other readers can take the full benefit of this article.