Benefits of load balancing MagicMail
Load balancing the MagicMail email platform offers the following benefits:
- High Availability (HA): Load balancing ensures the email service remains continuously available, even if a server fails or needs maintenance. It automatically detects an unhealthy or offline server (due to hardware failure or a planned upgrade) and instantly redirects traffic to the remaining healthy servers, preventing service interruptions and downtime.
- Performance: The load balancer intelligently distributes incoming email traffic (like inbound SMTP, POP3, and IMAP connections) across a pool of multiple email servers, preventing any single server from becoming a bottleneck or getting overloaded during peak usage. This increases throughput and reduces email delivery or access latency.
- Scalability: It allows the MagicMail system to handle increased traffic and an expanding user base without a decline in performance.
About MagicMail
MagicMail is the carrier-grade email platform for ISPs and Telcos. It provides email identity security through secured mailbox access and tools for maintaining IP reputation for uninterrupted email deliveries.
Why Loadbalancer.org for MagicMail?
Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is designed to save time and money with a clever, not complex, WebUI.
Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.
And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent.
More on what’s possible with Loadbalancer.org.
How to load balance MagicMail
The load balancer can be deployed in four fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For MagicMail, Layer 4 NAT mode is recommended.
Virtual service (VIP) requirements
The following VIPs are required:
| Ref. | VIP Name | Mode | Port(s) | Persistence Mode | Health Check |
|---|---|---|---|---|---|
| VIP 1 | Co_SMTP | L4 NAT (TCP) | 25 | Source IP | Connect to Port |
| VIP 2 | Co_SUBMIT | L4 NAT (TCP) | 587 | Source IP | Connect to Port |
| VIP 3 | Co_SMTBS | L4 NAT (TCP) | 465 | Source IP | Connect to Port |
| VIP 4 | Co_HTTP | L4 NAT (TCP) | 80 | Source IP | Connect to Port |
| VIP 5 | Co_HTTPS | L4 NAT (TCP) | 443 | Source IP | Connect to Port |
| VIP 6 | Co_POP3 | L4 NAT (TCP) | 110 | Source IP | Connect to Port |
| VIP 7 | Co_IMAP | L4 NAT (TCP) | 143 | Source IP | Connect to Port |
| VIP 8 | Co_POP3S | L4 NAT (TCP) | 995 | Source IP | Connect to Port |
| VIP 9 | Co_IMAPS | L4 NAT (TCP) | 993 | Source IP | Connect to Port |
| VIP 10 | Co_RADIUS | L4 NAT (UDP) | 1812,1813, 1645,1646 | Source IP | Connect to Port |
| VIP 11 | Co_DNS | L4 NAT (TCP/UDP) | 53 | Source IP | Connect to Port |
| VIP 12 | Co_DNSDB | L4 NAT (TCP) | 5432 | Source IP | Connect to Port |
Load balancing deployment concept
Once the load balancer is deployed, clients connect to the Virtual Services (VIPs) rather than connecting directly to one of the MagicMail servers. These connections are then load balanced across the MagicMail servers to distribute the load according to the load balancing algorithm selected:
Note
The load balancer can be deployed as a single unit, although Loadbalancer.org recommends a clustered pair for resilience and high availability.
About Layer 4 NAT mode load balancing
This mode is a high performance solution, although not as fast as DR mode. It requires the implementation of a two-arm infrastructure with an internal and external subnet to carry out the translation (the same way a firewall works). Also, each Real Server must use the load balancer as the default gateway. Layer 4 NAT mode is transparent, i.e. the Real Servers will see the source IP address of the client.
The load balancer translates all requests from the Virtual Service to the Real Servers. NAT mode can be deployed in two-arm (using 2 interfaces), or one-arm (using 1 interface). If you want Real Servers to be accessible on their own IP address for non-load balanced services, e.g. RDP, you will need to setup individual SNAT and DNAT firewall script rules for each Real Server or add additional VIPs for this. Port translation is possible with Layer 4 NAT mode, e.g. VIP:80 → RIP:8080 is supported. NAT mode is transparent i.e. the Real Servers will see the source IP address of the client.
Load balancing topology
The load balancer translates all requests from the external Virtual Service to the internal Real Servers. Normally eth0 is used for the internal network and eth1 is used for the external network although this is not mandatory. If the Real Servers require Internet access, Autonat should be enabled using the WebUI option: Cluster Configuration > Layer 4 – Advanced Configuration, the external interface should be selected.
NAT mode can be deployed in the following ways:
- 2-arm (using 2 Interfaces), 2 subnets (as shown above) – One interface on the load balancer is connected to subnet1 and the second interface and Real Servers are connected to subnet2. The VIP is brought up in subnet1. The default gateway on the Real Servers is set to be an IP address in subnet2 on the load balancer. Clients can be located in subnet1 or any remote subnet provided they can route to the VIP.
- 2-arm (using 1 Interface), 2 subnets – same as above except that a single interface on the load balancer is allocated 2 IP addresses, one in each subnet.
- 1-arm (using 1 Interface), 1 subnet – Here, the VIP is brought up in the same subnet as the Real Servers. For clients located in remote networks the default gateway on the Real Servers must be set to be an IP address on the load balancer. For clients located on the same subnet, return traffic would normally be sent directly to the client bypassing the load balancer which would break NAT mode. To address this, the routing table on the Real Servers must be modified to force return traffic to go via the load balancer – For more details on ‘One-Arm NAT Mode’ refer to the administration manual.
If you want Real Servers to be accessible on their own IP address for non-load balanced services, e.g. SMTP or RDP, you will need to setup individual SNAT and DNAT firewall script rules for each Real Server or add additional VIPs for this – please refer to the administration manual for more details.
NAT mode is transparent, i.e. the Real Server will see the source IP address of the client. Port translation is possible in NAT mode, i.e. VIP:80 –> RIP:8080 is possible.
