Introduction
Exchange is the “killer app” for most organizations. Without e-mail, productivity slows and in some cases grinds to a halt. This is especially true for remote users whose only communications with the home office might be through email. Front-end servers are easily overloaded and with the growing popularity of remote access options such as OWA, OMA, RPC and EAS, load balancing front-end servers is starting to become more popular in an effort to increase performance and provide high availability.
Administrators have two ways to load balance Exchange servers, depending on the base operating system installed.
- Round Robin DNS
- Network Load Balancing
Each has its pros and cons and we will look at both methods, which will allow you to choose which method suits your organization best.
Round Robin DNS
Round Robin DNS is the easiest method available to load balance web servers. An Exchange server really is nothing more than a web server and round robin DNS is a simple solution you can use to load balance the front-end servers. Round robin works by assigning multiple IP addresses to the fully qualified domain name (FQDN) of a resource. The IP addresses are rotated so that one server IP address is handed out first, then the next request is given the next IP in the list. This repeats as each DNS resolution is handled, moving down the list of IP addresses until you get to the end of the list, which starts the whole process over. Another upside is that you don’t need any special hardware; the standard network interface card in any server will work.
The following diagram (Figure 1) shows our demo scenario that includes the DNS server and the three front-end Exchange servers.
Figure 1: Round Robin Scenario
To configure round robin for this Exchange organization, open up the DNS Management MMC and right-click on the DNS server; choose Properties. Click on the Advanced tab and check the box next to Enable Round Robin (see Figure 2).
Figure 2: Enable Round Robin
Now drill down to the forward lookup zone and create an A(Host) record for each front-end server with the same FQDN. In this case I am creating three A records for owa.thelazyadmin.lab each with an IP address from one of the Exchange front-end servers (see Figure 3).
Figure 3: A(Host) Records
That is it! DNS round robin will now spread the requests out between the three Exchange front-end servers. If you are using BIND DNS servers (version 9.x) the concept is the same, just create multiple A(Host) records for the FQDN.
Before we get too excited about how easy this was to configure and all the positive things that will happen with this configuration, there are some things that you should be aware of.
Round Robin DNS is not fault tolerant. If a user receives the IP address of a down server, they will get an error message. This is usually resolved by refreshing a few times, but they may have to go a step further and purge the local DNS cache before they get the IP address of a functional server. For this reason a low TTL value is recommended.
Each front-end server should be running the same base operating system and Exchange version including service packs and hot fixes. Also if you are provisioning OWA features, you need to ensure you configure each front-end identically as well.
Since everything is handled by DNS, you need to configure a monitoring method to notify administrators if a front-end node is unavailable. Unlike a cluster configuration, there is no built in monitoring service that can notify administrators of a downed node.
Network Load Balancing
The other option you have to load balance your Exchange front-end is Network Load Balancing (NLB). Network Load Balancing is a Microsoft clustering technology that is included in Windows 2000 Advanced Server and all editions of Windows Server 2003. NLB works by using an algorithm to provide load balancing and high availability.
Typically, two nodes cannot share an IP address. If you have ever given two computers the same IP address, you have seen the issues this can cause. The Network Load Balancing Service solves this problem by redirecting the traffic to the shared IP address to one of the nodes in the cluster. It also monitors the state and the load on each node allowing it to send traffic to the least busy node, and skip any nodes that are unavailable.
One other thing you need to implement a NLB cluster is an extra network card in each front-end server. NLB requires each node in the cluster to have two IP addresses. Technically you can do this with a single network card, but a second network card simplifies things greatly. With two NICs installed in each front-end server we are ready to go. The following diagram is a typical front-end NLB cluster configuration (see Figure 4). Doesn’t look much different from the round robin scenario, the only real difference is that each front-end server has a second NIC and IP address.
Figure 4: NLB Scenario
Again, each front-end server should be running the same base operating system and Exchange version including service packs and hot fixes and, if you are provisioning OWA features, you need to ensure you configure each front-end identically as well.
There are two tasks involved in creating a NLB cluster for your Exchange front-end.
- Configure NLB on each front-end server
- Configure a DNS record for the NLB cluster
To configure NLB on each front-end server, open up the properties of the NIC you will be using for the NLB cluster. Check the box next to Network Load Balancing, and then with that option highlighted, press the Properties button. Under the Cluster Parameters tab, enter a unique IP address for the cluster. This will be the IP address that DNS will point clients to. Enter the subnet mask and the FQDN of the cluster. Leave the cluster in Unicast mode and leave remote control disabled. See figure 5 for a sample configuration.
Figure 5: Cluster Parameters
Next, click on the Host Parameters tab and select a Priority. Each node in the NLB cluster will need a unique Priority and it can range anywhere from 1 to 32. Next enter the nodes IP address (the unique NLB IP) and the subnet mask. Leave Initial Host State as Started. See figure 6 for a sample configuration.
Figure 6: Host Parameters
The last checkbox next to Retain suspended state after computer restarts can be checked if you desire. If you do check it you will have to re-enable the node if it has been restarted. Click OK until you exit the network card properties. Repeat these steps on the other nodes in the NLB cluster making sure you use a unique Priority for each. Once complete, test it out by pinging the cluster IP address.
The last step is to create a DNS A(Host) record for the cluster IP. Open up the DNS Management MMC and drill down to the forward lookup zone. Add an A(Host) record that points to the cluster IP and give it a unique name. Close the DNS Management MMC and test it out by pinging the FQDN.
Conclusion
That is all there is to load balancing your Exchange front-end servers. If you can, use NLB, it is the more robust of the two methods and offers high availability features you can’t get with Round Robin DNS. Both methods are easily expandable, simply add another server to the farm and add it to the round robin DNS list, or the NLB cluster. The only limitation is that NLB only supports up to 32 nodes.
For more information on clustering Exchange server check out these MSExchange.org articles:
Implementing a Two Node Cluster with Windows 2003 Enterprise
http://www.msexchange.org/tutorials/Implementing-Two-Node-Cluster-Windows-2003-Enterprise.html
Just say NO to A/A
http://www.msexchange.org/tutorials/NO-Active-Active-Cluster.html
