Setting up, configuring and maintaining load balancing for Exchange 2010 required a reasonable amount of skill to configure properly, especially if configured for services such as SSL offload. In Exchange 2013, load balancing was simplified considerably and it also reduced the number of roles, resulting in just Client Access and Mailbox roles.
In this series we will examine how best to publish and monitor Exchange 2016 services.
Load Balancing in Exchange 2016 is simpler than previous versions. With a consolidation in the number of Exchange Server roles in Microsoft’s newest version of Exchange there are less decisions to make, and the way that traffic affinity is handled within Exchange makes it very simple to reliably load balance traffic.
If you are migrating from a previous version, then things have changed considerably. In Exchange 2010, the version you may be leaving behind, load balancing was often painful. Not only did web-based traffic require load balancing, but MAPI traffic required load balancing too, when using a Client Access Array. To make matters more complex, affinity between servers was required for most protocols.
Exchange 2016 simplifies things further and has a single role – the Mailbox role. The single role server provides all the functionality Exchange 2013 multi-role servers provided effectively allowing any inbound client traffic to connect to any Exchange mailbox server and route to the server currently hosting the active mailbox being accessed.
This means in Exchange 2016 the decisions for load balancing are very simple and it’s reasonably hard to make a bad decision. You can complicate it, but should you wish to make Load Balancing very simple you can do so.
In this article we’ll look at how Load Balancing works in Exchange 2016 and provide a sample implementation using a real-world load balancer.
Changes to how clients access Exchange 2016
One of the biggest changes to Exchange 2016 is to the server roles. In Exchange 2010, the familiar Client Access, Hub Transport, Mailbox and Unified Messaging Roles can be deployed together, or apart. In Exchange 2013 the roles were consolidated to just the Client Access role and Mailbox role.
Exchange 2016 consolidates these roles further to just the Mailbox role. Inside a Mailbox server, the Client Access proxy components introduced in Exchange 2013 are still present, along with the underlying full Client Access, Transport, Mailbox and Unified Messaging components. However, a Mailbox server always contains these multiple roles and cannot be split. Effectively, Microsoft are mandating multi-role servers for new deployments.
In Exchange 2013 the Client Access role did something very special. It ensured that when a user attempted to access their mailbox, the request was proxied back to the Mailbox server actively serving the users mailbox. This always ensured that services like Outlook on the Web were always rendered for the user on the mailbox server itself, removing the need for affinity.
The Exchange 2016 mailbox role now includes the same functionality, meaning that if two servers host different mailboxes they will proxy traffic for each other when required. The mailbox server hosting the active copy of the mailbox will serve the user accessing it, even if the user connects to another mailbox server.
Finally all client traffic from native Exchange clients like Outlook connect over HTTP/HTTPS. No client connectivity directly via MAPI is allowed.
Improvements to Load Balancing
These make load balancing for Exchange 2016 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. As Outlook on the web is rendered on the same server that's hosting that user's mailbox database it doesn’t matter which mailbox server the load balancer directs traffic to. These have no notable performance impact if the load balancer directs traffic to another server because the OWA session is already running.
The challenge for session affinity when using forms-based authentication has also been solved. Previously it was essential to use affinity to avoid re-prompting for login when the load balancer redirected traffic to another server. This was solved in Exchange 2013 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 for a client accessing Exchange 2016
The new simplified infrastructure provides us the opportunity to make load balancing as simple as it possibly can – if desired, we can use DNS round robin, a technique that simply provides the client with the IP address of every mailbox server, and let the HTTP client do the rest. If one Exchange server fails completely, then the protocol is smart enough to attempt connection to another server.
There are a number of downsides to DNS round robin. It is not actually load balancing the traffic and there are no guarantees that each server will receive its fair share. It also has no service level monitoring, meaning that if a single service is failed, for example Outlook on the web, clients will simply see the error page rather than be automatically directed to another server. Finally it requires more external IP addresses when publishing externally, as each individual Exchange server will require an external IP address.
These reasons typically mean that a load balancer is very desirable when publishing Exchange 2016 to clients.
We will want a load balancer to monitor each Exchange client facing service and if a failure does occur, direct traffic to another server and take that service offline. We will also want the load balancer to perform some level of distribution of load to ensure that one particular mailbox server is not proxying the majority of client access.
When load balancing services using a load balancer we can utilize either Layer 4 or Layer 7 load balancing. Layer 4 load balancers do not look at the contents of the traffic and simply send the traffic onto the configured destination. Layer 7 load balancers have the ability to inspect the content of the traffic and direct accordingly.
A layer 4 load balancer requires less resources to perform well, but has a trade-off. When using a single IP address, it can only monitor a single service (such as Outlook on the web, ActiveSync, MAPI-HTTP etc) meaning that although the configuration is very simple, there is a risk one service may fail and although the server is available, clients may still connect to the failed service.
This typically means that a resilient Layer 4 implementation requires multiple IP addresses configured along with separate HTTP names configured per service (such as owa.contoso.com, eas.contoso.com, mapi.contoso.com). This allows service level monitoring information to be used.
A layer 7 load balancer trades off the raw performance benefits of layer 4 load balancing for the simplicity of having a single HTTP name (such as mail.contoso.com) with the benefits of per-service monitoring.
Layer 7 load balancers understand the HTTP path being accessed (such as /owa, /Microsoft-Server-ActiveSync, /mapi) and can then direct traffic only to working servers based on monitoring data. This means only a single IP address is required.
SummaryIn part of this series we’ve looked at how clients access Exchange 2016 and the various options available for configuring load balancing. In the next part in this series, we’ll configure simple load balancing using a Layer 4 load balancer.
If you would like to read the first part in this article series please go to Load balancing Exchange Server 2016 (Part 2).