Transport High Availability in Exchange 2013 (Part 5)

by [Published on 13 March 2014 / Last Updated on 13 March 2014]

In this previous part of this article series we started exploring how to achieve high availability for inbound and outbound e-mail flow. In this fifth and last part, we will continue and finish with inbound e-mail flow.

If you would like to read the other parts in this article series please go to:

Inbound Internet E-mails

As already mentioned, incoming e-mails from the Internet can be delivered to Exchange using a third-party smart host, a legacy Edge server or through a 2013 CAS server. When handling this traffic, administrators do not need to deploy a load balancing solution in order to distribute the load across the receiving servers - this can be accomplished by using DNS round robin and Mail eXchange (MX records) as described next.

When running a mail server, independently of its version or make, if it uses SMTP as the e-mail transfer mechanism, then DNS MX records need to be configured for the domain that will be receiving e-mail. An MX record is a particular type of DNS record that defines the name and the preference of one or more e-mail servers responsible for accepting e-mail for a particular domain. Without MX records, an organization is only capable of sending and receiving internal e-mails as other e-mail servers external to the organization will not know how to reach a server in order to deliver e-mail into the organization.

MX Records follow the format below where a value of 10 signifies the preference or order (between 0 to 65535) in which mailers select MX records when attempting mail delivery to the host:

domain.com. IN MX 10 host.domain.com

Multiple MX records can be used for a single domain, sorted in preference order. For example, if a domain has three MX records configured, a sending server will try to use all three records before queuing or rejecting the e-mail.

There are several different ways of configuring MX records to control inbound Internet mail flow. This configuration will depend on several factors, such as the number of datacenters where Exchange is deployed, the number of devices capable of routing Internet mail into the organization, etc. As this book is about high availability, let us assume a deployment with two datacenters with both locations capable of routing e-mails. There are three main possibilities for this scenario:

  1. One primary datacenter and a standby datacenter;
  2. Both datacenters are used for mail flow;
  3. Single MX record.

In a primary/standby datacenter scenario, organizations usually choose to have all inbound and outbound traffic flowing through the primary datacenter, with the standby only being used in a disaster recovery situation. To achieve this, we configure the MX records for the first datacenter with a lower cost. Assuming New York to be the primary datacenter and New Jersey the standby one, the DNS configuration would be as follows:

letsexchange.com.          IN MX 10 newyork.letsexchange.com
newyork.letsexchange.com   A <IP_Address_1>
newyork.letsexchange.com   A <IP_Address_2>
(...)
 
letsexchange.com.          IN MX 20 newjersey.letsexchange.com
newjersey.letsexchange.com A <IP_Address_3>
newjersey.letsexchange.com A <IP_Address_4>
(...)

With this configuration, both MX records are provided to the sending SMTP server, but the lowest-cost MX record (New York) is used first. When the address for newyork.letsexchange.com is resolved, DNS uses round robin to alternate between the address values that it returns, ensuring newyork.letsexchange.com hosts are used equally for receiving inbound e-mail. This approach guarantees that e-mail traffic is balanced efficiently across all mail hosts in the primary datacenter, whether these are 2010 Edge servers, 2013 CAS servers or third-party appliances. In case of a disaster, all that needs to be updated is the newjersey.letsexchange.com MX record so it has a lower cost than the New York record, so that all traffic is directed to the New Jersey datacenter. Alternatively, you can increase the cost of the newyork.letsexchange.com MX record.

Note that this scenario will increase the traffic on the WAN between the datacenters as some messages that enter the New York datacenter will be destined for recipients in New Jersey and vice versa.

For the second scenario, typically a primary/primary datacenter deployment where users are spread across both datacenters, both MX records are set to equal cost:

letsexchange.com.          IN MX 10 newyork.letsexchange.com
newyork.letsexchange.com   A <IP_Address_1>
newyork.letsexchange.com   A <IP_Address_2>
(...)
 
letsexchange.com.          IN MX 10 newjersey.letsexchange.com
newjersey.letsexchange.com A <IP_Address_3>
newjersey.letsexchange.com A <IP_Address_4>
(...)

By having both MX records with the same cost, both datacenters will be used to receive inbound Internet e-mail. Please note that depending on the sending SMTP server, this solution might not guarantee equal distribution of e-mail between the two datacenters as some Message Transfer Agents always pick the same MX record independently from how many MX records are configured for a domain. It does guarantee, however, equal distribution of e-mail for a particular MX record as scenario 1 does.

In case of a disaster with one of the datacenters, its MX record should be updated with a higher cost, or even deleted, so sending SMTP servers do not try to use it.

As for the third scenario, a single MX record can be used:

letsexchange.com.          IN MX 10 mail.letsexchange.com
mail.letsexchange.com      A <IP_Address_1>
mail.letsexchange.com      A <IP_Address_2>
mail.letsexchange.com      A <IP_Address_3>
mail.letsexchange.com      A <IP_Address_4>
(...)

With this configuration, the MX record references all mail hosts in both datacenters, ensuring an equal distribution of e-mail between all the hosts in both datacenters. This is usually the best approach when mail flow is desired to come into both datacenters. However, the first scenario is the best option when the objective is to ensure that e-mail flow is controlled in terms of datacenter usage.

In case of a disaster in this scenario, the records associated with hosts on the failed datacenter would need to be deleted from DNS and recreated once the datacenter is reactivated.

Although a load balancer is not strictly required, it can obviously be used to distribute incoming Internet e-mails, which will bring additional functionality and increase high availability due to its health check capabilities. In this case, a single MX record pointing to the load balancing solution is published. The load balancer then distributes incoming e-mails to all receiving servers listed in its configuration.

Despite of all the advantages of using a proper load balancing solution, there are some points to be aware of when using a physical/virtual load balancer for SMTP traffic:

  • Priority: there might be cases where a certain preferred server needs to be considered first for a new connection (if available). If this is not the case, then ensure that all receiving servers have the same priority or weight;
  • Load balancing method: in order to not create SMTP traffic imbalances, a suitable load balancing method (algorithm) should be used. Usually round robin is fine, but different ones might be used, especially if servers have different priorities. Always ensure whether the current configuration is the best suited;
  • Source IP address: ensure the Exchange servers see the source IP server for the reasons already discussed;
  • Health monitors: make sure the load balancer’s health monitors meet your requirements. For example, one that only establishes an SMTP connection to a server, waits for the SMTP banner to be returned or for a HELO response, and then disconnects might not be sufficient as it detects service failures but not back pressure for example;
  • Single point of failure: plan for a pair of load balancers so it does not become a single point of failure for all inbound e-mail traffic.

Conclusion

In this article series we explored all the improvements made by Exchange 2013 to transport high availability, namely to Shadow Redundancy and to Safety Net. Together, these two features guarantee that no e-mail is lost while in transit by keeping redundant copies of e-mails both before and after they are successfully delivered.

We also explored different methods used to load balance both inbound and outbound mail flow, increasing at the same time high availability by preventing single points of failure.

Although Shadow Redundancy and Safety Net do a great job out of the box, it is still important to ensure their configuration meets the Business requirements and to properly plan for inbound and outbound mail flow.

If you would like to read the other parts in this article series please go to:

Featured Links