The Hurricane MTA Server (HMS), when administered by an email deliverability professional, is able to efficiently process large volumes of email messages. While the HMS is a powerful system by itself, if there is a need to scale to truly large volumes of email, one is not enough. When using two or more Hurricane MTA Servers to handle a single mail stream a couple of questions arise:
1) How can email be spread out across all HMS systems in order to maximize efficiency and minimize strain on any one system?
2) How can the outage of one or more HMS systems be seamlessly handled and therefore invisible to users and processes injecting email into the network?
The answer to both of these questions is load balancing. There are multiple approaches to load balancing a set of HMS which vary in scalability, seamlessness, and cost. Here are several solutions, from the simplest to the most complete (and complex):
Scenario #1: Simple Failover
In the case where only one HMS is needed, we provide High Availability HMS licenses in order to avoid a long downtime in case of a system failure. These licenses allow for a second HMS running on a separate system but not processing traffic. In the case where the first HMS fails, a health monitor could be configured to detect the outage, and in response, update DNS or other settings in order to redirect traffic to the failover system. While this is not load balancing, it is the simplest scenario in which traffic is managed across multiple Hurricane MTAs.
Scenario #2: Single Hurricane Load Balancer
The Hurricane Load Balancer (HLB) is a product that manages connections to two or more HMS. When a user connects to a HLB, the load balancer will attempt to connect to one of the HMS systems it is balancing. If a connection fails, the HLB will attempt to connect to another HMS, while maintaining the user connection so that no errors are experienced. If a HMS becomes unreachable, the HLB will remove it from its load balanced pool of HMS. The HLB will then periodically check if the unresponsive MTA is alive again, reintroducing it to the load balanced pool upon a success.
By using a HLB and 2+ HMS, we end up with an email delivery network that can efficiently utilize multiple Hurricane MTAs and also seamlessly handle individual systems being unresponsive or offline. However, we now have a new single point of failure: the HLB itself.
Scenario #3: DNS Load Balancing with Multiple Hurricane Load Balancers
In order to address possible outages of a HLB, we can introduce DNS load balancing. There are many ways to implement this, with one of the more robust implementations provided by AWS Route 53. Multiple DNS entries for a single domain can be created in Route 53. Each of these entries has a weight, which allows Route 53 to do round-robin DNS load balancing across all entries.
For example, let us say we have two HLBs running at 10.0.0.1 and 10.0.0.2. If we created two DNS entries (one for each IP) with a weight of 50, every request would have a 50/50 chance of hitting either HLB. Since there is now load balancing at the DNS level, even the loss of a HLB will mean that DNS lookup attempts should result in a connection being made to an active HLB. This HLB will then negotiate an inbound connection to one of its HMS systems, handling any connectivity issues at that level. The end result is a system comprised of at least 4 Hurricane MTA Servers that is robust to failure and utilizes every node in the network for processing inbound email traffic.
More Load Balancing – HMS web services
The HMS provides many features, some of which communicate in protocols other than SMTP. Both the Injection API and the Engagement Tracking web application function using HTTP, and it can be useful to also load balance these sub-applications. We do not sell a custom software load balancer for these services like we do for SMTP, as most load balancing can be done at the DNS level. As before, with a service such as AWS Route 53, multiple Injection API (or Engagement Tracking) endpoints can be configured to use a weighted round-robin DNS for a single domain.
In conclusion, combining HTTP load balancing via DNS with the SMTP load balancing described in scenario #3 allows for a simple yet robust way to manage networks of Hurricane MTA Servers and their related services.
