DNS load balancing is introduced in Communications Server “14”. The objective of DNS load balancing is to reduce the need for a Hardware Load Balancer (HLB) for SIP-based load balancing. HLB is both expensive and hard to configure. In addition, HLBs aren’t application-aware; they cannot support “connection draining,” a new feature in Communications Server “14”.
(...)
How Does DNS Load Balancing Work—in Practice?
The client queries DNS to resolve the FQDN of the pool (for example, pool.contoso.com) similar to Office Communications Server 2007 R2. Instead of returning the virtual IP address of the hardware load balancer, the DNS query returns the list of front-end server FQDNs as shown in Table 1. With previous versions of Office Communications Server, this query would return the IP address of the hardware load balancer.
In Communications Server, the DNS query returns the list, {192.168.1.1, 192.168.1.2, 192.168.1.3, 192.168.1.4}, to the client. The order in which these are returned to the client is irrelevant. The client chooses an IP address from the list at random, and then attempt to connect to the front-end server. If the connection fails, the client continues down the list in a random fashion until a successful connection to the pool is achieved or the list is empty.
Client Registration
With previous versions of Office Communications Server, the client would be able to successfully connect to a front-end server. It would then register the client’s SIP URI into the single-shared registration database that is stored on the back-end server running Microsoft SQL Server. However, in Communications Server, each front-end server in a pool has a completely independent registration database. Each user is assigned a predefined registration database (that is, registrar) that they should connect to. This registrar assignment is calculated by a hash value of the user’s SIP URI. Therefore, it is highly likely that a randomly selected front-end server is the incorrect server for the client to connect to. In this example, there is a 75 percent chance the client would randomly contact the wrong server. In other words, there is a 25 percent chance that the correct server was reached on the first attempt. No SIP redirect would be required.
Summary
DNS load balancing is only part of the client connectivity matrix. The internal hashing and distribution of the client registration information is the other part. The two mechanisms work together to determine how a client connects to a pool.
DNS load balancing does not remove the dependency on hardware load balancers completely; however, hardware load balancing is still required for load balancing Web traffic (such as address book services) used in Communications Server. By eliminating the need to load balance SIP traffic by using a hardware load balancer, the complexity of configuring a pool or bank of Edge Servers is significantly reduced.
Keep in mind that the hardware load balancer is still required when operating in a mixed Communications Server and legacy environment (Office Communications Server 2007 R2 or Office Communications Server 2007).
I think this is a great new feature in MCS, it allow us to deploy older or cheaper HLBs, since all we need HLBs for now is for web traffic, no need for two fancy F5 ($$) just for OCS.
No comments:
Post a Comment