Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.
A high availability cluster is one of the most complex types of Exchange setups. As such, there is a lot of room for mistakes during the planning and deployment phase. In this article, I discuss some best practices for creating an Exchange cluster.
If you take nothing else away from this article, please remember this one bit of advice: Don't let your cluster give you a false sense of security. I have seen way too many cases in which administrators have a sense of invincibility after deploying their first cluster.
Backup and recovery
Although a cluster will protect you against hardware failure, the Windows Cluster Service does little to protect the Exchange message databases. So make sure you continue to perform regular backups of your Exchange organization. I recommend backing up each node in the cluster individually.
Node configuration
You should also configure all nodes in the cluster identically. Given the cost of a clustered Exchange deployment, it is sometimes tempting to piggyback another application onto nodes within the cluster. But Exchange works best when it is the only application on the server.
Hardware and software
While I am on the subject of cluster node uniformity, each node in the cluster should ideally be running on the same hardware configuration. This isn't an absolute requirement, though, as long as the hardware conforms to Microsoft's Hardware Compatibility List for clustered environments.
A more stringent requirement is that each node in the cluster must be running identical versions of Windows Server and Exchange Server. Likewise, each node in the cluster should be running a common set of service packs and patches.
Front-end Exchange servers
Another important aspect of planning a cluster deployment is to use the appropriate types of clusters based on the server's role.
If you are clustering a front-end Exchange server, Microsoft recommends using network load balancing. There are a few different ways you can achieve load balancing for a front-end Exchange server. For example, you could set up a DNS round robin configuration, or you could use the Windows Network Load Balancing service.
Microsoft recommends you use no more than 32 nodes if you are load balancing a front-end Exchange server. In most cases though, 32 nodes is going to be overkill.
After all, a front-end Exchange server is really nothing more than a glorified IIS server; a single front-end server can handle a huge number of users. In all but the largest organizations, applying a load balancing configuration to front-end servers is done more to provide redundancy (high availability) than to ease the workload on an individual server.
If you do decide to load balance a front-end server, you may run into complications if your front-end servers are behind an ISA Server cluster. In environments in which ISA Server is clustered and a front-end Exchange server is also clustered, administrators usually end up having to create a one to one mapping between the ISA servers and the Exchange front-end servers.
Back-end Exchange servers
So what about the back end? You can't get away with using network load balancing for back-end Exchange servers. Instead, you have to use either the Windows Cluster Service or a hardware-implemented cluster.
When clustering a back-end Exchange server using the Windows Cluster Service, you're required to set up the cluster using either active/active or active/passive configuration. I strongly recommend using an active/passive configuration.
Currently, Microsoft supports active/active configuration in two-node clusters only. Larger clusters require active/passive configuration. Furthermore, sources at Microsoft have indicated that the next version of Exchange will not support active/active clusters at all.
If you do decide to create an active/active cluster, understand that each server in the cluster has its own Exchange virtual server. If a node in the cluster were to fail, then the remaining node would be stuck running its own Exchange virtual server and the virtual server from the failed server. So you need to make sure that the combined load of both virtual servers won't overload a node. Microsoft also recommends that an active/active cluster contains less than 1,900 mailboxes because of memory fragmentation issues.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Ask the Expert: Is clustering a good idea?
Learning Center: Exchange clustering 101 and 102
Chapter Download: Exchange performance and clusters
Reference Center: Exchange clustering tips and resources
