Topic Last Modified: 2011-04-11
Even when you deploy DNS load balancing, you need hardware load balancers to load balance the HTTP traffic to the Front End pools and Director pools.
Additionally, we deployed hardware load balancers in the perimeter network for the reverse proxy servers.
To provide the highest level of load balancing and high availability, a pair of hardware load balancers (HLBs) were deployed with a Global Server Load Balancer (GSLB) at each site. With all the load balancers in constant communication with each other regarding site and server health, no single device failure at either central site would cause a service disruption for any of the users who are currently connected.
This test scenario employed the use of both global server (the F5 BIG-IP GTM) and local server (the F5 BIG-IP LTM) HLBs. The global server load balancers were implemented to manage traffic to each site based upon central site availability and health, while the local server load balancers managed connections within each site to the local servers. This implementation has the following advantages:
- Fully-meshed system for the highest level of fault tolerance at
a local and global level.
- Complete segmentation of internal and external traffic within
the central site.
- The ability, if you want, to leverage the hardware to load
balance all connections to Front End Servers, Edge Servers, and
Directors.
Although optimal from some perspectives, this deployment does have two distinct disadvantages: you need to purchase more HLBs, and the numerous devices create a more complex configuration to manage. Consolidation of the load balancing infrastructure is definitely possible and in some environments is beneficial. For instance, many deployment designs include a single HLB instance or pair in each central site. Although the HLB spans multiple subnets in this design, the load balancing logic remains the same. F5 produced architectural guidance that explores the tradeoffs between different network designs. For details, see http://go.microsoft.com/fwlink/?LinkId=212143. For more details about deployments leveraging HLBs for Lync Server without GSLBs, see the Office Communications Server 2007 R2 Site Resiliency white paper at http://go.microsoft.com/fwlink/?LinkId=211387. The deployments described in that white paper also provide a valid reference architecture for Lync Server 2010.
By leveraging both local and global load balancers, we achieved both server and site resiliency while using a single URL for users to connect to. The GTM resolves a single URL to different IP addresses based on the selected load balancing algorithm and availability of global services. By having the authoritative Windows DNS servers (contoso.com) delegate the URL (pool.contoso.com) to the GTM, users connecting to pool.contoso.com are sent to the appropriate site at the time of DNS resolution. The local server load balancer then gets the connection and load balances it to the appropriate server.
The HLBs were configured to monitor the Front End Pool members by using an HTTP or HTTPS monitor, which gives the load balancers the best information about the health and performance of the servers. The HLBs then use this information to load balance the incoming connections to the best local Front End. Using a feature called Feature Priority Activation, we also configured the HLBs to proxy connections to the other central site if all the local Front Ends reached capacity or no longer functioned.
The global server load balancers (GTM) were configured to monitor the HLBs in each site and to direct users to the best performing site. The GTM can be configured to send all users to a specific site in the case of active/standby central sites (as was the case for this test), or load balance users between the sites for active/active deployments. If one site reaches capacity or becomes unavailable, the GTM directs users to the other available site(s).