Strategies and Best Practices for Deploying a Load Balancer for Email
There are specific situations where it makes sense to deploy a load balancer and times when deploying a load balancer can actually lower the reliability and service level of an email infrastructure. Often times network hardware that supports load-balancing servers is deployed at the network edge on the Internet gateway. The network gear is often performing network address translation for the Internet gateway email servers and a network administrator will just as a matter of course set up hardware load-balancing as well. This can be a mistake.
The most common configuration error we see is a single DNS MX record pointed to a virtual IP address (VIP) that then is load-balanced across many email servers for handling inbound mail from the Internet. To understand the problem with this configuration you have to understand how email routing on the Internet works. When a mail transfer agent (MTA) has a piece of mail to deliver to a remote destination, the MTA will look up in DNS the MX records for that destination. Each MX record has a priority associated with it. The higher priority servers—ones with lower MX priority numbers—are tried first. If the first one does not respond, the one with the next-lowest priority is tried (or one with the same priority), and this continues through the chain of MX records for the destination. If a company has only a single DNS record, and lets say a server behind that load balancer will accept an SMTP connection, but cannot actually accept mail, the sending MTA will time out, and because there is only one DNS record, no subsequent attempts to other servers will be tried, before the mail is queued for later delivery. Thus the inbound email service level is degraded because there is only one MX record in DNS.
Instead of load-balancing multiple servers behind a single virtual IP address, it is better have an address for each server that is NAT’ed and have MX records defined for each. In order to spread the load among multiple servers, have multiple MX records with the same priority. In practice you will see loads within 10% of each other across the machines, because most modern implementations of DNS address resolution have either a sequential or random selection algorithm for deciding which MX record to use when presented with multiple.
Where to Deploy a Load Balancer
There are two places where it makes sense to have a load balancer: (1) when you have email clients connecting directly to SMTP MTAs, i.e, when POP or IMAP servers are deployed for email within an organization rather than a groupware product like Exchange or Notes, (2) when you have applications injecting high rates of email into an outbound MTA infrastructure for sendmail email, i.e., bulk emailing applications. In both cases, the problem being solved is that the applications used for sending email are not MX record aware and will not use them. Email clients like Outlook Express, Thunderbird, Pine, etc., do not consult MX records in order to submit email to a mail submission agent (MSA). It makes sense to define a VIP for a set of servers that are acting as MSAs in order to load balance email traffic and to provide some resiliency to email traffic should an MSA fail. In the case of email-generating applications, they too usually are configured to submit email to a specific address. Even if the application were MX aware, due to the high volume of injection you never want an injecting application to have to make the multiple connection attempts when submitting email. Since the machines submitting the SMTP email are under your administrative control, you can restart jobs or clear email queues manually if you experience the error condition described above when an MTA accepts the STMP connection, but hangs.
Best Practices for Email Load Balancers
In general the best practices for deploying load balancers in the email infrastructure are:
1. Deploy a load balancer for mail submission agents that accept email messages from internal email clients
2. Deploy a load balancer for MTA infrastructures used by high volume email generating applications
3. On the inbound Internet gateway, use multiple MX records to do the load balancing
With these recommendations, you will be leveraging the technologies for their appropriate uses. Service levels will be maximized while providing the most robust configuration to handle outages.