Microsoft encourages failover clustering to provide fault tolerance and redundancy for Exchange Server. However, neither the client access server nor the hub transport server roles support failover clustering in Exchange 2010 — only mailbox servers may be clustered.
To provide fault tolerance and redundancy for your hub transport servers, you must deploy one or more additional hub transport servers. When you do, Exchange 2010 automatically distributes the workload across your hub transport servers. This way, you don’t have to worry about building a cluster or configuring Exchange to use the new server.
While providing redundancy for the hub transport server role in Exchange 2010 is fairly simple, there are a couple of important factors to remember when it comes to effective load balancing.
Each mailbox server requires a hub transport server
The hub transport server resides at the Active Directory-site level. This means that every Active Directory (AD) site that contains an Exchange mailbox server also needs at least one hub transport server. You can’t set up a single hub transport server and expect it to service a multi-site.
Exchange Server deployment.
Because the hub transport server functions at the AD-site level, redundancy and fault tolerance must also occur there. Deploying redundant hub transport servers help provide load balancing and fault tolerance for a single site, not the entire Exchange Server organization.
The importance of Exchange Server 2010 Service Pack 1
The other important thing that you need to know about protecting the hub transport server role is that if you’re using Exchange Server 2010 and have hub transport servers in multiple sites, Exchange 2010 Service Pack 1 (SP1) is essential. If you haven’t installed Exchange 2010 SP1, a hub transport server failure will result in uneven workload distributions.
When Exchange 2010 routes messages to another AD site, it uses a technique similar to domain name system (DNS) round robin to distribute the load among the hub transport servers in the remote site. For example, if a remote site contains five hub transport servers, each server receives approximately 20% of the messages sent from the local site.
With that in mind, imagine that one of the five hub transport servers fails. The hub transport servers in the local site are completely unaware of the failure in the remote site. Therefore, the servers continue distributing the workload to all the remote hub transport servers. The connections to the offline hub transport server fail, but once the failure is detected, Exchange routes the messages to the next hub transport server.
The problem here is that the next hub transport server in line must take on the failed server’s workload in addition to its own. This behavior is normal for sites with only two hub transport servers, but for sites with three or more hub transport servers, it results in uneven load balancing. Consider our example: If a failure occurred in a site with five hub transport servers, one of the remaining servers would need to handle 40% of the total workload, while the three remaining servers still received only 20% of the total workload.
Exchange 2010 SP1 is essential because it includes a feature called the Healthy Server Selector, which tracks which Exchange servers are available. If a hub transport server in a remote site fails, the Healthy Server Selector discovers the failure and prevents the local hub transport servers from sending messages to the failed server until it comes back online. This helps Exchange ensure that workloads are evenly distributed among the remaining hub transport servers.
Filed under: Exchange
