Load Balancing Exchange 2007 Client Access Servers using Windows Network Load-Balancing Technology – Part 1: Overview of Windows NLB Clusters
July 5, 2011 Leave a comment
In this article I will show you how you can load-balance Exchange 2007 Client Access Servers (CAS) using Windows Network Load Balancing (NLB) technology. By implementing a load-balancing solution, you can distribute client workload among multiple servers and thereby increase performance and decrease downtime by eliminating the single point of failure that exists in a topology with only one single Client Access server.
Bear in mind that a load-balancing solution can also be accomplished using a 3rd party load-balancing solution, but as mentioned we will base this article on the NLB component in Windows Server 2003. NLB works well and should be a suitable solution for most enterprise organizations.
What is Network Load Balancing and how does it Work?
Network Load Balancing (NLB) technology can be used to distribute client requests across a set of servers. Windows NLB is often used to ensure that stateless applications such as IIS-based web servers can be scaled out by adding additional servers as client load increases. Doing so makes sure that clients always experience acceptable performance levels. In addition, it reduces downtime caused by a malfunctioning server as the end-users will never know that a particular member server in the Windows NLB is or has been down.
Windows NLB clusters can provide scalability for services and applications based both on TCP and UDP. On top of that you can have up to 32 servers in a Windows-based NLB cluster.
Windows NLB is included in both the Windows Server 2003 Standard and Enterprise edition (even the Web edition includes this component), and because Windows NLB is a standard component, it does not require you to use any special or specific server hardware for each member server in the NLB cluster.
When Windows NLB has been properly configured, all servers in the NLB cluster are represented by a single virtual IP address and by a fully qualified domain name (FQDN). When a client request comes in, it will be sent to all servers in the Windows NLB cluster. The client will then be mapped to a particular server and the request to the other servers will be dropped. Having said that, you can use affinity to direct specific client request to particular member servers. You can even configure each member server with a priority.
Figure 1.1 below shows a very simple setup consisting of two Exchange 2007 Client Access servers configured in a Windows NLB. Both Client Access servers accept the client requests and send them to the respective back-end servers depending on the type of request.
Figure 1.1: Load-Balanced Exchange 2007 Client Access Server topology
Unicast and Multicast Mode
A Windows NLB cluster can be configured in either unicast or multicast mode, where unicast is the default mode.
With the WNLB cluster configured in unicast mode, the MAC address of each server’s network adapter will be changed to a virtual cluster MAC address, which is the MAC address that will be used by all servers in the Windows NLB cluster. When unicast mode is enabled, clients can only connect to the servers using the cluster MAC address.
With the Windows NLB cluster configured in multicast mode, a multicast MAC address is added to the cluster adapter of each server in the cluster. Note that I write “is added”, as each server will retain their original MAC addresses.
A Windows NLB cluster, no matter what mode it is configured in, works with just a single network adapter installed in each server, but it is recommended to install a second network adapter in each server, in order to achieve optimal performance, and to separate ordinary and cluster related network traffic.
So what mode should I use for my Exchange 2007 Client Access solution and how many network adapters should I install in each Client Access server? Well, best practice recommendations are to install two network adapters and use unicast mode, so that the host and cluster network traffic are each separated in their own respective network adapter.
In addition to Windows NLB, you also have the option to use DNS round robin mechanisms to load balance the Client Access servers in your Exchange 2007 messaging environment, but the Windows NLB is recommended over DNS round robin as the latter only provides a minimum level of fault tolerance. The reason being that if a particular Client Access server does not respond to client requests, the client requests must be repeated until a server responds as information about client connections and unavailable Client Access servers are not maintained. Because the Windows NLB component is included in both the Windows Server 2003 Standard and Enterprise edition, there is really no excuse for choosing DNS round robin over WNLB.
Although the above might make it sound complex and time consuming to deploy a Windows NLB-based load-balancing solution, it is actually relatively easily to accomplish, as I will show you throughout this article series.
Purpose of the Client Access Server
Before we dive into the configuration part of Windows NLB clusters, I thought it would be a good idea to give you a brief description of what purpose Client Access servers have. This will give you a better understanding of why it is important to load-balance this Exchange 2007 server role.
The Client Access Server replaces the front-end server we know from Exchange 2000 and 2003 and adds some additional functionality. The Client Access server provides mailbox access for all types of Exchange clients except Outlook MAPI clients, which as most of you are aware, connect directly to the Mailbox Server. This means the Client Access server manages access for any user who accesses their mailbox using Outlook Anywhere (formerly known as RPC over HTTP), Outlook Web Access (OWA), Exchange ActiveSync (EAS), POP3 and last but not least IMAP4.
In addition to providing client access, the Client Access server is also responsible for providing access to things such as automatic profile configuration, free/busy information, Out of Office (OOF) messages, the Offline Address Book (OAB) as well as Unified Messaging (UM), but only with respect to Outlook 2007 and Outlook Web Access 2007 (and Windows Mobile 6.0 devices sometime in the future). These are the only two clients, which can take advantage of the new web-based Exchange Autodiscover and Availability service, which are responsible for providing access to the above mentioned client features.
Legacy clients such as Outlook 2003 and earlier, and Windows mobile 5.0 devices cannot use Autodiscover or availability service.
If you want to deploy the solution explained in this article series in your own lab environment, you will need the following:
- 1 server acting as Domain Controller (with the Microsoft CA component installed)
- 2 servers with the Client Access server roles deployed (two NICs in each)
- 1 server with the Mailbox and Hub Transport server roles deployed
- 1 Windows XP/Vista client with Outlook 2007 installed
Depending on your specific hardware specifications, you could install the Mailbox and Hub Transport server roles on the domain controller, but even in lab environments it is a good idea to keep the roles separated.
To get up to speed as quickly as possible, I recommend you use a virtual environment, and make use of a parent disk. This makes it a breeze to get your servers up and running by using linked clones.
You now know what a NLB cluster is all about and can begin to set up your lab environment. This will enable you to be ready for the next part of this article series which will provide you with step-by-step instructions to configure a Windows NLB cluster.