JumalaSika ltd - Fotolia


Configure a geo load balancer for Exchange 2013

Once you've configured Exchange and installed a free load balancer, you'll need to configure the load balancer and Exchange virtual services.

Multisite availability is an important enabler for many highly available Exchange Server 2013 deployments. Creating a deployment that works in multiple data centers can help reduce the big risk that comes with having on-premises Exchange -- losing the email service because of a networking, power or other issue.

Multisite, multi-region availability can be difficult to achieve while keeping it affordable. But by using a free load balancer, you can configure a multisite geo load balancer that includes automatic failover and fail back.

For many organizations, geo load balancing is a good answer to this problem. We've already downloaded and installed the free load balancer after configuring Exchange and networking prerequisites. Now, we'll perform a basic geo load balancer configuration. This involves configuring the Exchange virtual services and then configuring a geographic load balancing.

Basic configuration on a geo load balancer

After installing load balancer appliances onto the virtual infrastructure, the devices need some basic configuration. By default, they'll usually obtain a dynamic host configuration protocol-based IP address; you may  reserve permanent IPs for the management interfaces, or you may assign and manually configure them.

For each geo load balancer, these addresses include:

To perform this configuration, log in to the load balancer at https://<your assigned ip>/ as bal and the password you've already chosen. Navigate to System Configuration and choose Interfaces. Add the correct configuration for each interface and then Save (Figure 1).

kemp loadmaster
Figure 1

These changes will be automatically applied, so navigate to the new IP address and log in again.

Configure the virtual service

Each load balancer can have more than one virtual service configured. The virtual service is the load balanced IP address and related configuration for publishing Exchange 2013.

The type of configuration we'll perform for this guide is straightforward -- we'll use the Network Layer 4 capabilities to publish Exchange 2013 in a simple way.

Many organizations need to use more complex rules to meet their needs, and the free load balancer in this example is compatible with Kemp's LoadMaster templates. These include specific templates for Exchange 2013 as well as for services such as Skype for Business (formerly Lync).

Create a virtual service for Exchange HTTP Secure (HTTPS) and Simple Mail Transfer Protocol on each load balancer. As an example, Table 1 shows the settings we'll use for the HTTPS service. These are intentionally basic to highlight geo load balancer functionality; most organizations have a slightly more complex configuration.

Table 1: Settings for the HTTPS service

Service Name Exchange
Virtual IP Address Assigned internal virtual IP for load balanced Exchange in this site
Port 443
Template N/A
Protocol TCP
Alternative Address DMZ virtual IP for load balanced Exchange in this site
SSL Acceleration Disabled
Persistence Mode None
Persistence Timeout N/A
Scheduling Method Round Robin
Real Server Check Method HTTPS Protocol
Real Server Check URL /ews/healthcheck.htm
Real Server Check using HTTP/1.1 Enabled
Real Server Check Host name Your Exchange HTTP address
Real Server HTTP Check Method Get
Real Server IP Addresses IP addresses of the Exchange Servers in this site

To create the virtual service, log in to the load balancer and navigate to Virtual Services. Choose Add new (Figure 2).  

kemp loadmaster add virtual server
Figure 2

After creating the virtual services, the Real Servers list should be populated. This list includes the configured real servers that the load balancer publishes; and the results of the real server check ensuring they're available.

Both load balancers at data center locations one and two should be configured at this point. You should be able to use them in production to load balance Exchange Servers, albeit using round robin DNS to inefficiently publish both sites. Before proceeding with the geo load balanced configuration, test that the virtual services work as expected.

Remember to test

After you've set up and configured geo load balancing in Exchange 2013, be sure to set up the load balancer in a test environment to make sure these changes will work in your Exchange setup.

Configure the geo load balancers

We need to implement two sets of changes to geographic load balancing: configure the load balancer appliances with a similar geo-failover setup and update DNS name server delegations.

The load balancers have two core concepts relevant to geographically dispersed Exchange deployments: clusters and global fully qualified domain names (FQDNs). The cluster represents an existing virtual service. Just like we've created a virtual service in each data center, we must create a cluster for each service on both load balancers. Specify the internal virtual IP (VIP) address for each cluster to monitor, a latitude/longitude to define the location and specify the load balancer type as local or remote (Table 2).

Table 2: Load balancer configurations

Load Balancer Cluster Name IP Address Location Type
Primary DC PrimaryExchange Internal VIP for Exchange in Primary DC 0°0'0"N 0°0'0"W Local
Primary DC FailoverExchange Internal VIP for Exchange in secondary DC 00'0"N 0°0'0"W Remote
Secondary DC PrimaryExchange Internal VIP for Exchange in Primary DC 0°0'0"N 0°0'0"W Remote
Secondary DC FailoverExchange Internal VIP for Exchange in secondary DC 0°0'0"N 0°0'0"W Local

We've chosen zero values for the location because we'll use it for geo-based failover to switch between data centers in our example. By specifying the physical latitude and longitude values of the data center location, we could choose to return the closest data center cluster to the client.

Here's a configuration of the primary Exchange cluster on the primary load balancer (Figure 3).

kemp loadmaster configured clusters
Figure 3

Next, configure the global FQDNs. This is the DNS configuration on each load balancer and defines which clusters the load balancer will choose to respond with based on the cluster's state or the client's location.

In this example, we'll choose to respond solely based on the cluster's state; specify the cluster weight to ensure the primary data center returns first and chooses to specify the FQDN as a fixed weight FQDN.

Each cluster is listed multiple times along with separate respond IP addresses. In our scenario, we have requests from internal and external clients. Based on the requester, we'll respond with either the internal VIP address or DMZ IP addresses. Choose Isolate Public/Private sites and provide a different Cluster Response IP address for each repeated cluster. The cluster response IP address is the one the client will use to connect, so external clients must represent the Internet IP address.

Global FQDNs Type Isolate Public / Private Sites Site Failure Handling Site Recovery Delay
Fixed Weighting Yes 1 minute Automatic
Cluster Name Cluster Response IP Cluster Weight
PrimaryExchange Primary DC Internal Exchange VIP 1000
PrimaryExchange Primary DC DMZ Exchange VIP 1000
FailoverExchange Failover DC Internal Exchange VIP 100
FailoverExchange Failover DC DMZ Exchange VIP 100

Here's an example of a completed Global FQDN configuration (Figure 4).

kemp loadmaster update DNS records
Figure 4

Updating DNS records

Once those changes are applied, the final step is updating internal and external DNS records with a name server delegation record for each Exchange FQDN; for example, this could be for autodiscover.lisajanedesigns.co.uk and mail.lisajanedesigns.co.uk.

The delegation record ensures that other DNS servers will directly query the load balancers for the correct DNS records for both records rather than rely on the DNS hosting provider for an answer.

DNS Servers DNS Names Record Type IP Addresses
External autodiscover.lisajanedesigns.co.uk
NS Both external DMZ VIPs for Primary and Failover DCs
Internal (e.g. AD) autodiscover.lisajanedesigns.co.uk
NS Both internal VIPs for Primary and Failover DCs

External DNS providers don't usually offer the option to directly add a DNS record in their web-based control panels, so you may need to raise a support request to create a delegation like that.

Within Active Directory (AD) DNS, you could instead choose to create a stub zone. This would provide an easily identifiable representation of the delegation in your AD DNS management snap-in, but it also correctly forwards requests onto the load balancers.

About the author: 
Steve Goodman is an Exchange MVP and is the head of unified communications at the U.K.'s leading Office 365 partner. Steve has worked in the IT industry for 16 years and has worked extensively with Microsoft Exchange since version 5.5. Steve is the author of a number of books about Exchange, regularly presents at conferences, co-hosts The UC Architects podcast and regularly blogs about Exchange Server, Office 365 and PowerShell at www.stevieg.org.

Next Steps

Exchange 2013 load balancing options

Use load balancing to ease workloads

Dig Deeper on Exchange Server setup and troubleshooting