Best practices for Exchange clustering

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

    Requires Free Membership to View

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

    This was first published in October 2005

  • There are Comments. Add yours.

    TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

    REGISTER or login:

    Forgot Password?
    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
    Sort by: OldestNewest

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.