Load balancing Exchange Server 2016 (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 Load balancing Exchange Server 2016 (Part 1).

Introduction

In the first part of this article we explored how load balancing works in the latest iteration of Microsoft’s flagship messaging platform, Exchange 2016. In part two of this series we’ll examine some potential real-life configurations using a sample load balancer.

Implementing Simple Load Balancing

We’ll first look at the simplest configuration for load balancing in Exchange 2016, 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 be forwarding 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.51) 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: Selecting Standard Options for the Load Balancer

We’ll leave the SSL properties and advanced options at their defaults, then move onto 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/healthcheck.htm 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 IP

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.51, we’ll then configure our Mailbox servers to use these names, by visiting the Exchange Admin Center, and then navigating to Virtual Directories. Within Virtual Directories, click on the Configure External Access Domain button highlighted below:

Figure 7: Configuring the HTTPS namespaces

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: Configuring a single namespace and applying it to all servers

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

Figure 9: Editing the individual server Outlook Anywhere publishing

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 internal and external URL for Outlook Anywhere

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 have a number of different options available. We can use Layer 4 load balancing and use a separate name for each server and different corresponding IP address.

Alternatively, as we’ll describe here, we can use the same basic configuration used for the simple single server Layer 4 load balancing, and then add on some more intelligent features.

The feature we’ll add on using the KEMP load balancer is known as sub-virtual servers and requires the use of Layer 7 level load balancing. In essence, Layer 7 load balancing is able to examine the contents of the request, such as the URL specified, and then make intelligent decisions. Based on the URL provided, the Layer 7 load balancer is able to pass the request to a sub-virtual server which will then load-balance an individual service.

This has a number of benefits over and above the Layer 4 simple load balancer. Firstly, it provides service-level awareness, something we do not have with the configuration implemented above – we only have awareness for the service status of the Outlook on the web (OWA) service.

Secondly it only requires a single IP address. Layer 4 per-service load balancing requires multiple IP addresses as it is simply passing the request through as-is and is unable to make any intelligent services.

The great thing about what we’ll do now is that it doesn’t require any additional, special Exchange configuration. The changes we made earlier in this article to align the namespaces for HTTPS traffic for a single virtual IP all apply as-is for this example.

To get started though, let’s skip back to the KEMP load balancer and Add a new virtual service. We’ll create a new virtual service for Exchange 2016 HTTPS using our space VIP for this example implementation, 192.168.15.51, with basic options as shown below:

Figure 11: Creating a new virtual service

We will then examine the configuration for the newly created virtual service. As you’ll see when examining the configuration, the service type is set to HTTP/HTTPS and the Scheduling Method is set to Round Robin:

Figure 12: Viewing the newly created VS

Scroll down to the SubVSs section within the configuration, and choose Add new…

Figure 13: Creating a new virtual service

Upon choosing Add new a new sub virtual server will be shown. Using a similar process to the single Layer 4 load balancer, we’ll set a check URL for monitoring, and then add both real servers.

In the example below, we’re creating a sub virtual service for the MAPI protocol. We’ll specify the virtual directory check URL /mapi/healthcheck.htm and specify to use HTTP 1.1 and the GET method. When you’re finished, choose Add new to add the next one:

Figure 14

We’ll need to repeat this process a number of times. The table below shows the multiple services we’ll add and the corresponding check URLs:

Table 1

When you have finished creating each new sub virtual service, you should see each individual service listed. Each will be capable of monitoring an individual service.

Figure 15: Viewing individual status monitors

For the purposes of this article we will not go deeper on the KEMP specific details, as this is solely to illustrate the generic process. For the KEMP load balancer devices using this specific kind of per-service load balancing you’ll need to also import the specific SSL certificate used for the services, enable SSL re-encryption and configure sub virtual server rules to direct traffic based on the entered URL.

Summary

In part two of this series we’ve explored the simple load balancing configuration required to direct traffic to your Exchange 2016 organization using Layer 4 load balancing, which provides an efficient, simple form of load balancing. As a representative example we’ve also looked at how the KEMP load balancer can be used to perform Layer 7 based per-service monitoring of services, at the expense of complexity.

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 Load balancing Exchange Server 2016 (Part 1).