5.6.2 High availability

LB/HA Core servers

LB/HA of Core servers is supported out of the box. For details see 3.7 Server profiles.

LB/HA MetaDefender Email Gateway Security servers

images/inline/442e4f65ea2d2cb44e2cc31c39cc1e0eb91777dd.png

In this scenario a load balancer (Load balancer A in the figure above) will be set up to balance the email traffic between two MetaDefender Email Gateway Security instances.

Load balancer

The following software will be used on Load balancer A:

  1. Operating system: CentOS 7 (minimal)

  2. Load balancer: NginX

Prerequisites

Install NginX

Prerequisites
# yum install epel-release
# yum install nginx

Disable SELinux

For the sake of POC and simplicity SELinux will be disabled here.

In a production environment SELinux must not be disabled.

Disable SELinux
# vi /etc/sysconfig/selinux
...
SELINUX=disabled
...

The system must be restarted this configuration to make effect.

NginX configuration

NginX will be configured making changes in its configuration file.

# vi /etc/nginx/nginx.conf

Failover setup

With the configuration below two MetaDefender Email Gateway Security instances are configured in a failover fashion. The second server receives traffic only when the first server is unreachable (consecutively for three seconds for three times).

Failover
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
 
# Load dynamic modules. See /usr/share/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;
 
events {
worker_connections 1024;
}
 
stream{
upstream cluster_mdemailsecurity_smtp {
server mdemailsecurity1.example.com:10025 max_fails=3 fail_timeout=3s;
server mdemailsecurity2.example.com:10025 backup;
}
server {
listen 10025;
proxy_pass cluster_mdemailsecurity_smtp;
}
}

Load balancing setup

With the configuration below two MetaDefender Email Gateway Security instances are configured in a load balancing fashion. The first server receives five times much traffic than the second server.

Load balancing
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
 
# Load dynamic modules. See /usr/share/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;
 
events {
worker_connections 1024;
}
 
stream{
upstream cluster_mdemailsecurity_smtp {
server mdemailsecurity1.example.com:10025 weight=1;
server mdemailsecurity2.example.com:10025 weight=4;
}
server {
listen 10025;
proxy_pass cluster_mdemailsecurity_smtp;
}
}

The backend name ( cluster_mdemailsecurity_smtp ) can be replaced with a name of any choice.

All backend servers are defined by their internal DNS hostnames in the examples above, but IP addresses may be used instead.

Backup servers

Directive backup.

The backup server will only handle traffic when the other node goes down, and will remain idle when the other node is healthy.

Passive health check

Directives:

  • max_fails
  • fail_timeout

Define the conditions when the switchover must happen.

https://www.nginx.com/resources/admin-guide/http-health-check/

Weight values

Directive weight.

The lower the value, the more traffic the server will receive relative to the other servers. mdemailsecurity2 will be assigned a higher weight of 4 to minimize its load. It will receive every 5th (1+4) connection.

Marking a Server as down (offline)

When there is a need to bring one of the servers down for emergency maintenance without impacting the users, the down directive will allow doing this:

upstream cluster_mdemailsecurity_smtp {
server mdemailsecurity1.example.com:10025 max_fails=3 fail_timeout=3s down;
server mdemailsecurity2.example.com:10025 backup;
check interval=5000 rise=2 fall=5 timeout=2000 type=smtp;
}