Introducing Load Balancing in Exchange Server 2013 (Part 2)

If you would like to be notified of when Steve Goodman releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.

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

Introduction

In the first part of this article, we looked at the improvements in Exchange 2013 at the client access level, both in the changes to roles, back-end rendering of OWA on the new mailbox role and removing the need for session affinity to individual Client Access servers.

In the final part of this series, we’ll look at the practical side of implementing these new features using a low cost hardware load balancer, making use of Layer 4 load balancing features.

Implementing Simple Load Balancing

We’ll first look at the simplest configuration for load balancing in Exchange 2013, using a KEMP load balancer as an example to try out the configuration on.

In our example, we’ll be using a single HTTPS namespace for services like OWA, EWS, OAB and ActiveSync along with our AutoDiscover namespace.

These two names will share Virtual IP (VIP) using the same SAN certificate. We’ll move forward using Layer 4, and performing a check against the OWA URL. On the back-end we’ve just got two client access servers to load balance:

Figure 1: Single VIP Load Balancing

To add our single service, we’ll log into our blank load balancer, and choose to add a new service, specifying our single VIP (in this case 192.168.15.17) along with the HTTPS port, TCP port 443:

Figure 2: Creating the initial VIP

Next, we’ll choose to inform the load balancer under the heading Standard Options that the service is Layer 4 by deselecting Force L7. We’ll also make sure affinity is switched off by selecting None within Persistence Options, and leave Round Robin as the scheduling method to distribute load:

Figure 3: Configuring the VIP to use Layer 4 Load Balancing

We’ll leave the SSL properties and advanced options at their defaults, then move on to adding our Client Access servers under the heading Real Servers.

First, we’ll define what to monitor by ensuring that within Real Server Check Parameters, the HTTPS Protocol is defined and the URL is configured. We’ll use /owa/auth/logon.aspx as the URL then ensure we save that setting by choosing Set URL:

Figure 4: Configuring the OWA check URL

Next choose Add New and then on the page that follows, enter the IP address of your first Client Access server in the field Real Server Address. Leave all other options as their defaults, and choose Add this real server to save the configuration. Repeat the process for each Client Access server.

Figure 5: Adding Client Access Servers

After adding both of our client access servers, choose View/Modify Services to list the VIPs. We should see our new VIP listed, along with each Client Access server under the Real Servers column. If all is well, the status should show in green as Up:

Figure 6: Completed Load Balancer configuration for a single VIP

After ensuring that DNS records for our HTTPS namespaces – mail.stevieg.org and autodiscover.stevieg.org are configured to point at our VIP of 192.168.15.17, we’ll then configure our only Client Access servers to use these names, by visiting the Exchange Admin Center, and then navigating to Servers. Within Servers, click on the Configure External Access Domain button highlighted below:

Figure 7: Configuring the HTTPS namespaces within the Exchange Admin Center

Next, we’ll select both of our servers hosting the Client Access role and enter our primary HTTPS name, then choose Save to implement our configuration of OWA, ECP, OAB, EWS and ActiveSync virtual directories.

Figure 8: Applying the single HTTPS namespace to all web services

Finally, we’ll configure Outlook Anywhere by returning to the Servers page and choosing each server one by one and selecting the Edit icon highlighted below:

Figure 9: Editing the individual Exchange Server properties

We’ll then navigate to the Outlook Anywhere tab of Server Properties window and enter our HTTPS namespace, mail.stevieg.org for both the internal and external names:

Figure 10: Configuring the Outlook Anywhere internal and external URL

After saving the configuration, along with performing an iisreset /noforce against these servers, we should have a complete configuration.

Implementing Per-Service Load Balancing

With per-service load balancing we gain the benefits of simple Layer 4 load balancing and individual service level high availability, at the expense of using multiple IP addresses and names:

Figure 11: An overview of per-service configuration

To get started, we’ll need to use multiple names on our Subject Alternative Name (SAN) SSL certificate, with appropriate DNS entries configured, for example:

• mail.stevieg.org for Outlook Web App
• autodiscover.stevieg.org for our standard AutoDiscover namespace
• ews.stevieg.org for Exchange Web Services
• eas.stevieg.org for Exchange ActiveSync
• outlook.stevieg.org for Outlook Anywhere
• oab.stevieg.org for the Offline Address Book

We’ll then build upon the configuration we’ve done to present Outlook Web App above to configure additional Virtual IPs. We’ll select our single VIP from the list and choose Modify within the KEMP load balancer:

Figure 12: Selecting the existing single VIP within the Load Balancer

We’ll then choose Duplicate VIP to create a copy of this service including duplicating the configuration and configured Client Access servers:

Figure 13: Duplicating the existing VIP configuration

After duplicating our first VIP, we’ll give it an appropriate service name, then scroll down to the Real Servers section and change the Real Server Check Parameters and set the URL to one appropriate for the service, in this case for AutoDiscover, /autodiscover/autodiscover.xml and then select Set URL:

Figure 14: Altering the per-service URL to test

We’ll then repeat this process for each service as follows

Table 1

N.B. These parameters are subject to change as Microsoft is currently working with Load Balancer vendors to determine optimum configurations.

After configuring each service, we should see a multitude of services listed:

Figure 15: Finished configuration for multiple per-service VIPs

To make use of this configuration we can again build upon the work we’ve done to present a single OWA URL and just implement the deviations from this configuration by altering each service’s External URL. To do this, we’ll visit the Exchange Admin Center and navigate to Servers, then choose Virtual Directories.

After selecting all virtual directories for a particular service, we’ll use the Bulk Edit options to update the External URL for each service one by one:

Figure 16: Bulk editing web services within the Exchange Admin Center

For each service that requires modification, we’ll update the External URL as follows:

Table 2

After updating the External URLs for each service, except Autodiscover – which we can leave as-is, we can then repeat the process in the previous section to set the Outlook Anywhere HTTPS namespace to our dedicated Outlook Anywhere name.

Summary

In this two-part article we’ve looked at the improvements Exchange 2013 brings to load balancing allowing simpler load balancers to be used whilst at the same time providing better throughput. We’ve also seen that the configuration required and is a lot simpler than Exchange 2010 and provides a much better level of reliability. Although to get the best from a load balancer you might need to look at multiple namespaces, the simplicity overall is certainly worth it.

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