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
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:
-
Operating system: CentOS 7 (minimal)
-
Load balancer: NginX
Prerequisites
Install NginX
# 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.
# 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).
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.
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;
}