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:
- An IP address, subnet mask and gateway address on the internal local area network interface;
- An IP address, subnet mask and gateway address on the demilitarized zone (DMZ) interface; and
- Primary and secondary domain name system (DNS) server addresses.
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).
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
|Virtual IP Address||Assigned internal virtual IP for load balanced Exchange in this site|
|Alternative Address||DMZ virtual IP for load balanced Exchange in this site|
|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).
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).
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).
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|
|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.
Exchange 2013 load balancing options
Use load balancing to ease workloads