Exchange 2013 has reached RTM, and is now available for sale. In late February, we expect the Service Packs to be available that allow us to deploy Exchange 2013 into existing Exchange environments. With Exchange 2013, we will have several new options for load balancing the Client Access servers and I would like to quickly go over those options now.

Exchange 2013 Architecture

Exchange 2013 has been designed with some architecture changes from the previous versions of Exchange. One of the biggest changes is that Exchange 2013 has been released with only 2 server roles. Those roles are the Client Access Server and the Mailbox Server. The functionality of the Hub Transport and Unified Communications roles from the previous two versions has been added into these two roles. Additionally the CAS role been redesigned so that its only job is to proxy connections to the proper Mailbox Server. (There is a single instance where the CAS server redirects connections instead of proxying them, but that is not relevant to this post). In doing this redesign, one of Microsoft’s major goals was to enable better High Availability options for the CAS role.

Hardware Load Balancers

Microsoft Best Practices have recommended against using a Network Load Balanced cluster for the CAS role for the last two versions of Exchange. That recommendation remains the same for Exchange 2013. One of Microsoft’s objectives with this version of Exchange was to support lower cost hardware load balancer options.

The CAS array

If you’re familiar with Exchange 2010 and its deployment, you’ll probably expect that the first step in load balancing our CAS servers is going to be to create a CAS array. Best Practices for Exchange 2010 called for the creation of a CAS array. The CAS array did not provide any load balancing or high availability features, but instead just populated the name of the CAS array to the RpcClientAccessServer property of the mailbox databases. This value was in turn populated to the clients during the AutoDiscover process to tell the client where to connect.

An architecture change in Exchange 2013 now means that clients point to a unique GUID for each mailbox. The CAS server is able to perform an Active Directory lookup based on this GUID, and then find the correct mailbox server to target. All this means that the CAS array object is no longer used in Exchange 2013.

The Load Balancing Options

Another benefit of the architecture of Exchange 2013 is that we now have two better load balancing options. Those options are the less complex layer 4 load balancing, or the more resilient layer 7 load balancing.

Layer 4 Load Balancing

• Layer 4 load balancing refers to load balancing Exchange at the transport level.
• Layer 4 load balancing is easy to configure, and only requires two namespaces in most situations (A legacy name space is still needed for coexistence with Exchange 2007.)
• The downside to layer 4 load balancing is that the load balancers are not aware of individual service failures, they are only able to see service availability on a server-by-server basis. This means that if one of your CAS were to have a failure with just OWA, the entire server would be taken out of service, routing all traffic to other servers.

Layer 7 Load Balancing

• Layer 7 load balancing refers to load balancing at the application level. A load balancer in this configuration will be able to detect individual service failures, and route traffic accordingly. So if a single server were to have a failure in the IIS directory that runs OWA, the load balancer would be able to route OWA traffic away from that server while still leaving it available for EAS, Outlook, and all other types of traffic.
• A layer 7 load balancing configuration does require more complex hardware load balancers, along with the configuration of SSL offloading. This means that the deployment is going to be more time consuming, and will require more expensive hardware load balancers. Additionally it is necessary to more closely monitor the application of patches to servers in this configuration. Historically, patches have changed settings that can affect the operations of a server with SSL offloading configured.

The Third Option

The architecture of Exchange 2013 does provide for a third option, which I believe combines the best aspects of both of the previous options. The key to this third option is using layer 4 load balancing, but with multiple name spaces. Above I said that layer 4 load balancing only requires two namespaces, and that is correct. However, if additional name spaces (each with its own public IP address) are configured, then the hardware load balancers can be configured to recognize individual service failures without the added complexity of layer 7 load balancing.

Wrapping It Up

I have briefly touched on three different ways that Exchange 2013 CAS can be run behind a hardware load balancer to provide redundancy and resiliency for your deployment. There are several different factors that should go into deciding between these configurations options, and I’ve only had time to touch on a few of them here. In future posts I’ll talk about some of the considerations for multiple sites, and mailbox server high availability.