L'une des principales tâches lors de la construction d'infrastructures Zimbra OSE à grande échelle est la gestion adéquate de l'équilibrage de charge. En plus d'améliorer la résilience du service, un équilibrage de charge est essentiel pour garantir la réactivité uniforme du service pour tous les utilisateurs. Pour résoudre cette problématique, des équilibreurs de charge sont utilisés, qui sont des solutions logicielles et matérielles redistribuant les requêtes entre les serveurs. Parmi eux, il y a des solutions assez simples, comme RoundRobin, qui dirige simplement chaque prochaine requête vers le serveur suivant dans la liste, ainsi que des solutions plus avancées, comme HAProxy, qui est largement utilisé dans des infrastructures de calcul à forte charge en raison de plusieurs avantages significatifs. Voyons comment assurer l'interaction entre l'équilibreur de charge HAProxy et Zimbra OSE.
Ainsi, selon les conditions du problème, nous disposons d'une infrastructure Zimbra OSE, comprenant deux Zimbra Proxy, deux serveurs LDAP et une réplique LDAP, quatre stockages de courrier avec 1000 boîtes aux lettres chacun et trois MTA. Étant donné que nous avons affaire à un serveur de messagerie, il recevra trois types de trafic nécessitant un équilibrage : HTTP pour le chargement du client web, ainsi que POP et SMTP pour l'envoi d'emails. Dans ce cas, le trafic HTTP sera dirigé vers serveurs les Zimbra Proxy avec les adresses IP 192.168.0.57 et 192.168.0.58, tandis que le trafic SMTP sera dirigé vers les serveurs MTA avec les adresses IP 192.168.0.77 et 192.168.0.78.
Comme mentionné précédemment, pour assurer une répartition uniforme des requêtes entre les serveurs, nous allons utiliser l'équilibreur de charge HAProxy, qui fonctionnera sur le nœud d'entrée de l'infrastructure Zimbra sous Ubuntu 18.04. L'installation de haproxy dans ce système d'exploitation se fait à l'aide de la commande sudo apt-get install haproxy. Ensuite, il est nécessaire de modifier le paramètre dans le fichier /etc/default/haproxy pour changer la valeur ENABLED=0 sur enENABLED=1 . Maintenant, pour s'assurer que haproxy fonctionne, il suffit de saisir la commande. Dans le cas où ce service est en cours d'exécution, cela se manifestera par la sortie de la commande.
L'un des principaux défauts de HAProxy est qu'il ne transmet pas par défaut l'adresse IP du client connecté, la remplaçant par sa propre adresse. Cela peut conduire à des situations où les emails envoyés par des malfaiteurs ne pourront pas être identifiés par. une adresse IP, afin de l'ajouter à la liste noire. Cela dit, ce problème peut être résolu. Pour cela, il est nécessaire de modifier le fichier /opt/zimbra/common/conf/master.cf.in sur les serveurs avec Postfix et d'y ajouter les lignes suivantes :
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_adjustCela nous permettra d'ouvrir les ports 26, 466 et 588, qui recevront le trafic entrant depuis HAProxy. Une fois les fichiers sauvegardés, il convient de redémarrer Postfix sur tous les serveurs à l'aide de la commande zmmtactl restart.
Ensuite, nous passerons à la configuration d'HAProxy. Pour cela, nous allons d'abord créer une copie de sauvegarde du fichier de configuration cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak. Puis, nous ouvrirons le fichier source dans un éditeur de texte /etc/haproxy/haproxy.cfg et commencerons à ajouter progressivement les configurations nécessaires. Le premier bloc consistera à ajouter le serveur qui enregistre les logs, à définir le nombre maximum de connexions simultanées, ainsi qu'à indiquer le nom et le groupe d'utilisateurs auxquels le processus exécutable sera associé.
global
user daemon
group daemon
daemon
log 127.0.0.1 daemon
maxconn 5000
chroot /var/lib/haproxyLe chiffre de 5000 connexions simultanées n'est pas anodin. Dans notre infrastructure, il y a 4000 boîtes aux lettres, il faut donc prévoir la possibilité que toutes se connectent en même temps à leur messagerie. De plus, il est nécessaire de laisser une petite marge au cas où leur nombre augmenterait.
Ajoutons maintenant un bloc avec les paramètres par défaut :
defaults
timeout client 1m
log global
mode tcp
timeout server 1m
timeout connect 5sDans ce bloc, on définit le temps maximum d'attente pour le client et le serveur, afin de rompre la connexion à l'expiration de ce délai, ainsi que le mode de fonctionnement de HAProxy. Dans notre cas, le répartiteur de charge fonctionne en mode TCP, c'est-à-dire qu'il achemine simplement les paquets TCP sans analyser leur contenu.
Ensuite, nous ajouterons des règles pour les connexions sur différents ports. Par exemple, si le port 25 est utilisé pour les connexions SMTP et l'envoi de courriels, il est judicieux de rediriger les connexions vers les MTA présents dans notre infrastructure. Si la connexion passe par le port 80, il s'agit d'une requête http, qui doit être redirigée vers Zimbra Proxy.
Règle pour le port 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-proxyRègle pour le port 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-proxyRègle pour le port 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-proxyRègle pour le port 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 checkRègle pour le port 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 checkNotez que dans les règles de redirection des paquets TCP vers le MTA, à côté de leurs adresses se trouve le paramètre send-proxy. Cela est nécessaire afin que, conformément aux modifications que nous avons apportées précédemment aux réglages de Postfix, l'adresse IP originale de son expéditeur soit également transférée avec les paquets TCP.
Maintenant que toutes les modifications nécessaires dans HAProxy ont été apportées, vous pouvez redémarrer le service avec la commande service haproxy restart et commencer à l'utiliser.
Pour toute question concernant Zextras Suite, vous pouvez contacter la représentante de la société « Zextras », Ekaterina Triandaphilidi, par e-mail à katerina@zextras.com.
Source : habr.com
