Balanceo de carga en Zimbra Open-Source Edition con HAProxy

Una de las principales tareas al construir infraestructuras masivas de Zimbra OSE es la correcta distribución de la carga. Además de aumentar la resistencia del servicio, sin balanceo de carga es imposible garantizar la misma capacidad de respuesta del servicio para todos los usuarios. Para resolver esta tarea, se utilizan balanceadores de carga, que son soluciones tanto de software como de hardware que redistribuyen las solicitudes entre los servidores. Entre ellos hay opciones bastante primitivas, como RoundRobin, que simplemente dirige cada solicitud siguiente al siguiente servidor de la lista, así como soluciones más avanzadas, como HAProxy, que se aplica ampliamente en infraestructuras computacionales con alta carga debido a varias ventajas significativas. Veamos cómo se puede garantizar la interoperabilidad entre el balanceador de carga HAProxy y Zimbra OSE.

Balanceo de carga en Zimbra Open-Source Edition con HAProxy

Así que, según las condiciones del problema, tenemos una infraestructura Zimbra OSE que cuenta con dos Zimbra Proxy, dos servidores LDAP y LDAP Replica, cuatro almacenes de correo con 1000 buzones de correo en cada uno y tres MTA. Dado que estamos tratando con un servidor de correo, recibirá tres tipos de tráfico que necesitan ser balanceados: HTTP para cargar el cliente web, así como POP y SMTP para el envío de correos electrónicos. En este caso, el tráfico HTTP se enviará a servidores Zimbra Proxy con las direcciones IP 192.168.0.57 y 192.168.0.58, mientras que el tráfico SMTP se enviará a los servidores MTA con las direcciones IP 192.168.0.77 y 192.168.0.78.

Como se mencionó anteriormente, para asegurar una distribución equitativa de las solicitudes entre los servidores, utilizaremos el balanceador de carga HAProxy, que funcionará en el nodo de entrada de la infraestructura de Zimbra bajo Ubuntu 18.04. La instalación de haproxy en este sistema operativo se realiza mediante el siguiente comando sudo apt-get install haproxy. Después de eso, es necesario en el archivo /etc/default/haproxy cambiar el parámetro ENABLED=0 en ENABLED=1. Ahora, para asegurarnos de que haproxy está funcionando, basta con ingresar el comando service haproxy. Si este servicio está funcionando, se podrá comprender a partir de la salida del comando.

Una de las principales desventajas de HAProxy es que, por defecto, no transmite la dirección IP del cliente conectado, sustituyéndola por la suya propia. Esto puede llevar a situaciones en las que los correos enviados por atacantes no se puedan identificar. IP, para agregarlo a la lista negra. Sin embargo, este problema se puede resolver. Para ello, es necesario editar el archivo /opt/zimbra/common/conf/master.cf.in en servidores con Postfix y añadir las siguientes líneas:

26      inet  n       -       n       -       1       postscreen
        -o postscreen_upstream_proxy_protocol=haproxy
 
466    inet  n       -       n       -       -       smtpd
%%uncomment SERVICE:opendkim%%  -o content_filter=scan:[%%zimbraLocalBindAddress%%]:10030
        -o smtpd_tls_wrappermode=yes
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_client_restrictions=
        -o smtpd_data_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_recipient_restrictions=
        -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
        -o syslog_name=postfix/smtps
        -o milter_macro_daemon_name=ORIGINATING
        -o smtpd_upstream_proxy_protocol=haproxy
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_filter=[%%zimbraLocalBindAddress%%]:10027
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_options=speed_adjust
 
588 inet n      -       n       -       -       smtpd
%%uncomment SERVICE:opendkim%%  -o content_filter=scan:[%%zimbraLocalBindAddress%%]:10030
        -o smtpd_etrn_restrictions=reject
        -o smtpd_sasl_auth_enable=%%zimbraMtaSaslAuthEnable%%
        -o smtpd_tls_security_level=%%zimbraMtaTlsSecurityLevel%%
        -o smtpd_client_restrictions=permit_sasl_authenticated,reject
        -o smtpd_data_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_recipient_restrictions=
        -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
        -o syslog_name=postfix/submission
        -o milter_macro_daemon_name=ORIGINATING
        -o smtpd_upstream_proxy_protocol=haproxy
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_filter=[%%zimbraLocalBindAddress%%]:10027
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_options=speed_adjust

Con esto, abriremos los puertos 26, 466 y 588, que aceptarán el tráfico entrante desde HAProxy. Después de guardar los archivos, se debe reiniciar Postfix en todos los servidores usando el comando zmmtactl restart.

Después de esto, procederemos a configurar HAProxy. Para ello, primero crearemos una copia de seguridad del archivo de configuración cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak. Luego abriremos el archivo original en un editor de texto /etc/haproxy/haproxy.cfg y comenzaremos a añadir gradualmente los ajustes necesarios. El primer bloque consistirá en añadir el servidor que registre los logs, establecer el número máximo permitido de conexiones simultáneas, así como indicar el nombre y el grupo de usuario al que pertenecerá el proceso ejecutable.

global
    user daemon
    group daemon
    daemon
    log 127.0.0.1 daemon
    maxconn 5000
    chroot /var/lib/haproxy

El número de 5000 conexiones simultáneas no es casualidad. Dado que en nuestra infraestructura hay 4000 buzones de correo, es necesario prever la posibilidad de que todos ellos accedan a su correo de trabajo al mismo tiempo. Además, hay que dejar un pequeño margen en caso de que aumente su número.

Ahora añadiremos un bloque con la configuración por defecto:

defaults
        timeout client 1m
        log global
        mode tcp
        timeout server 1m
        timeout connect 5s

En este bloque se establece el tiempo máximo de espera para el cliente y el servidor, para romper la conexión cuando expire, así como el modo de operación de HAProxy. En nuestro caso, el balanceador de carga opera en modo TCP, es decir, simplemente transmite paquetes TCP sin analizar su contenido.

A continuación, agregaremos reglas para conexiones en diferentes puertos. Por ejemplo, si el puerto 25 se utiliza para conexiones SMTP y envío de correo, tiene sentido redirigir las conexiones a él hacia el MTA que tenemos en nuestra infraestructura. Sin embargo, si la conexión se realiza en el puerto 80, es una solicitud http que debe ser redirigida a Zimbra Proxy.

Regla para el puerto 25:

frontend smtp-25
bind *:27
default_backend backend-smtp-25
 
backend backend-smtp-25
server mta1 192.168.0.77:26 send-proxy
server mta2 192.168.0.78:26 send-proxy

Regla para el puerto 465:

frontend smtp-465
bind *:467
default_backend backend-smtp-465

backend backend-smtp-465
server mta1 192.168.0.77:466 send-proxy
server mta2 192.168.0.78:466 send-proxy

Regla para el puerto 587:

frontend smtp-587
bind *:589
default_backend backend-smtp-587
 
backend backend-smtp-587
server mail1 192.168.0.77:588 send-proxy
server mail2 192.168.0.78:588 send-proxy

Regla para el puerto 80:

frontend http-80
bind    *:80
default_backend http-80
 
backend http-80
mode tcp
server zproxy1 192.168.0.57:80 check
server zproxy2 192.168.0.58:80 check

Regla para el puerto 443:

frontend https
bind  *:443
default_backend https-443
 
backend https-443
mode tcp
server zproxy1 192.168.0.57:80 check
server zproxy2 192.168.0.58:80 check

Tenga en cuenta que en las reglas para la transferencia de paquetes TCP al MTA, junto a sus direcciones se encuentra el parámetro send-proxy. Esto es necesario para que, de acuerdo con los cambios que realizamos anteriormente en la configuración de Postfix, se transfiera junto con los paquetes TCP la dirección IP original del remitente.

Ahora que todos los cambios necesarios en HAProxy han sido realizados, se puede reiniciar el servicio mediante el comando service haproxy restart y proceder a su uso.

Para cualquier pregunta relacionada con Zextras Suite, puede ponerse en contacto con la representante de la empresa "Zextras" Ekaterina Triandafiliidi al correo electrónico katerina@zextras.com

Fuente: habr.com

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster