Introducing Load Balancing in Exchange Server 2013 (Part 1)

by Steve Goodman [Published on 18 Dec. 2012 / Last Updated on 18 Dec. 2012] 

In this two part article, we’ll examine layer-4 load balancing support in Exchange Server 2013 and explain how these changes along with a move to HTTPS-only client access simplify configuration and management of the new Exchange.

If you would like to read the next part in this article series please go to Introducing Load Balancing in Exchange Server 2013 (Part 2).

Introduction

In Exchange Server 2010 it's often said that the main skill administrators needed to learn when was how to deploy and manage load balancing. The concept of the RPC Client Access Array, the method used to distribute MAPI traffic between Client Access Servers was a common area of pain. Modern advances in Layer 7 load balancing also allowed for SSL offload, service level monitoring and load balancing and intelligent affinity using cookies to mitigate against some of Exchange 2010's shortcomings.

Putting all the above together, along making use of scarcely documented procedures such as implementing Kerberos for the newly deployed CAS arrays often meant that some of the key benefits associated with Exchange 2010, such as the ability to perform maintenance in-hours was never truly realised by all organizations - by the time the infrastructure and configuration to support load balancing was in place, managing switchovers at the load balancer level could be a daunting task.

For others the true benefits of using Load Balancers never entered the equation, as a Windows Network Load Balancing was used in many implementations as a cost saving measure, against the Exchange product team's recommendation.

Just like any new software release Exchange 2013 might seem initially more complicated, but all that new technology hidden away inside is actually all about making your life easier. In this article we'll look at how Load Balancing suddenly become the technology you just do - set and forget, rather than spend a lot of time researching before realising it's more complicated than you first thought.

Advertisement

Changes to Client Access

One of the biggest changes to Exchange 2013 is to the server roles. In Exchange 2007 and 2010, we've become familiar with the well-defined and discreet Client Access, Hub Transport, Mailbox and Unified Messaging Roles that can be deployed together, or apart.

In Exchange 2013, a new model is introduced where all the benefits of Microsoft's work to separate the roles is still present, but a Mailbox Server always includes all the functions to route mail, render web content and receive voicemail.

If you're wondering where that leaves the Client Access role - well that's there too, however it's primary role, even when combined with the mailbox role, is to authenticate clients and route requests to the correct mailbox server.

To put that a different way, when a user accesses a Client Access Server, it no longer renders OWA for them, and instead acts as a reverse proxy. After authenticating the user and determining which Mailbox Database their mailbox is located on, the CAS proxies the request to the back-end mailbox server that currently hosts that database. That mailbox server will render the OWA content, not the Client Access Server.

Another aspect we haven't mentioned is MAPI, or RPC client access, and there's a good reason for that. No longer do clients interact with Exchange using RPC, it's all over HTTPS. Outlook Anywhere is the protocol Outlook clients use to access their mailbox.

Improvements to Load Balancing

What we're getting at is the two key improvements in Exchange 2013 that make load balancing suddenly quite simple. HTTPS-only access from clients means that we've only got one protocol to consider, and HTTP is a great choice because it's failure states are well known, and clients typically respond in a uniform way.

The second improvement is to the way that affinity now works, and this is where it's really clever. As we've mentioned, one half of the equation is where OWA is rendered, on the same server that's hosting that user's mailbox database. Therefore if a client hits different Client Access servers there's no performance degradation as the session rendering OWA for that user is already up and running.

The other half of the equation is when it comes to forms-based authentication. The Exchange Team have solved this part of the equation by improving the way HTTP cookies are handled by Exchange. The authentication cookie is provided to use the user after logon, encrypted using the Client Access Server's SSL certificate. This enables a logged in user to resume that session on a different Client Access server without re-authentication; assuming servers share the same SSL certificate, and therefore are able to decrypt the authentication cookie the client presents.

Figure 1: Example request sequence for an OWA client

This now means that if desired, a DNS round robin could in theory be used entirely in place of a hardware load balancer - in fact it's almost as effective as using Windows Network Load balancing. It doesn't matter if the client reaches a different Client Access server on each request as the authentication is maintained and the session in progress will continue against the same back-end Mailbox server.  If one of the servers fail, then the HTTP client takes care of using DNS round robin to select the next server to access.

However, DNS round robin has it's downsides too, namely that there's no real load balancing per-se - different DNS servers will hand out ordered IP address lists in a different rotation and just like Windows Network Load balancing, we've not got any checks against the Client Access server itself. So if OWA , EWS or any other web application has a fault clients will still attempt to access that server and see an error message until an administrator resolves the issue.

Downsides of DNS round robin aside, this does demonstrate that the intelligence of the load balancer required in Exchange 2010, for example, the ability to pull apart the HTTPS connection and insert a cookie for affinity - all the expensive Layer 7 stuff are now not really required. Layer 4, which is sending on the TCP traffic itself is all we need.

In addition to just sending on that traffic, what we also want our Load Balancer to do is understand when a server is in some sort of failure state and react accordingly. In it's simplest scenario a Layer 4 load balancer can check a particular service, for example Outlook Web App, and if it's up and running send all the traffic to it.

What it can't do for a single HTTPS endpoint, or Virtual IP (VIP), is look at multiple services and if one service is down, such as EWS, only route traffic to ones with working EWS whilst still distributing traffic evenly for the remaining services. Layer 4 load balancing just doesn’t have that ability to look at what the client is requesting from the server and make decisions accordingly.

So we have a choice - firstly to assume that if our most important service is up, say OWA, then we'll class that Client Access server as available, or implement multiple VIPs tied to different names; one for each service. The latter is just a little complicated and effectively means we need an IP address assigned to each service like OWA or EWS.

Summary

In this article we've looked at the changes to client access in Exchange 2010 and how they affect the way Exchange services are accessed by end-users. We've also looked at how under the hood improvements affect load balancing in a big way, and really make low-cost load balancing a no brainer with Exchange 2013.

In the second part of this article, we'll look at how to implement both of these options against a low-cost Hardware Load Balancer.

If you would like to read the next part in this article series please go to Introducing Load Balancing in Exchange Server 2013 (Part 2).

Source: http://www.msexchange.org/articles-tutorials/exchange-server-2013/high-availability-recovery/introducing-load-balancing-exchange-server-2013-part1.html