Uma das principais tarefas na construção de grandes infraestruturas Zimbra OSE é um balanceamento de carga adequado. Além de aumentar a resiliência do serviço, sem balanceamento de carga não é possível garantir uma mesma capacidade de resposta do serviço para todos os usuários. Para resolver essa questão, são utilizados balanceadores de carga - soluções, tanto de software quanto de hardware, que redistribuem as solicitações entre os servidores. Entre eles, existem opções bastante primitivas, como o RoundRobin, que apenas direciona cada nova solicitação ao próximo servidor da lista, e opções mais avançadas, como o HAProxy, amplamente utilizado em infraestruturas computacionais de alta carga por suas várias vantagens. Vamos ver como é possível garantir a colaboração entre o balanceador de carga HAProxy e o Zimbra OSE.
Assim, conforme a tarefa, temos uma infraestrutura Zimbra OSE, onde existem dois Zimbra Proxy, dois servidores LDAP e um Replica LDAP, quatro repositórios de e-mails com 1000 caixas de correio cada e três MTAs. Considerando que lidamos com um servidor de e-mail, ele receberá três tipos de tráfego que precisam de balanceamento: HTTP para carregar o cliente web, além de POP e SMTP para envio de e-mails. Neste caso, o tráfego HTTP irá para servidores Zimbra Proxy com endereços IP 192.168.0.57 e 192.168.0.58, enquanto o tráfego SMTP será direcionado para os servidores MTA com endereços IP 192.168.0.77 e 192.168.0.78.
Como mencionado, para garantir uma distribuição uniforme das solicitações entre os servidores, utilizaremos o balanceador de carga HAProxy, que operará no nó de entrada da infraestrutura Zimbra sob Ubuntu 18.04. A instalação do haproxy neste sistema operacional é realizada através do comando sudo apt-get install haproxy. Após isso, é necessário no arquivo /etc/default/haproxy alterar o parâmetro ENABLED=0 para ENABLED=1. Agora, para verificar se o haproxy está funcionando, basta digitar o comando service haproxy. Caso este serviço esteja ativo, isso será indicado pela saída do comando.
Uma das principais desvantagens do HAProxy é que, por padrão, ele não transmite o endereço IP do cliente conectado, substituindo-o pelo seu próprio. Isso pode levar a situações em que os e-mails enviados por invasores não podem ser identificados. endereço IP, para adicioná-lo à lista negra. No entanto, essa questão pode ser resolvida. Para isso, é necessário editar o arquivo /opt/zimbra/common/conf/master.cf.in nos servidores com Postfix e adicionar as seguintes linhas:
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_adjustCom isso, abriremos as portas 26, 466 e 588, que receberão o tráfego de entrada do HAProxy. Após salvar os arquivos, será necessário reiniciar o Postfix em todos os servidores com o comando zmmtactl restart.
Depois disso, começaremos a configurar o HAProxy. Para isso, primeiramente, criaremos uma cópia de segurança do arquivo de configurações cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak. Em seguida, abriremos o arquivo original em um editor de texto /etc/haproxy/haproxy.cfg e começaremos a adicionar as configurações necessárias, etapa por etapa. O primeiro bloco será a adição do servidor que captura logs, a configuração do número máximo de conexões simultâneas, e a designação do nome e grupo de usuário ao qual o processo executável pertencerá.
global
user daemon
group daemon
daemon
log 127.0.0.1 daemon
maxconn 5000
chroot /var/lib/haproxyO número 5000 de conexões simultâneas foi escolhido por uma razão específica. Como em nossa infraestrutura existem 4000 caixas de correio, é necessário prever a possibilidade de que todas elas acessem sua conta de e-mail ao mesmo tempo. Além disso, é importante deixar uma margem na eventualidade de que esse número aumente.
Agora vamos adicionar um bloco com as configurações padrão:
defaults
timeout client 1m
log global
mode tcp
timeout server 1m
timeout connect 5sNeste bloco, é definido o tempo máximo de espera do cliente e do servidor, que interrompe a conexão quando expira, assim como o modo de operação do HAProxy. No nosso caso, o balanceador de carga opera em modo TCP, ou seja, apenas transmite pacotes TCP sem analisar seu conteúdo.
Em seguida, adicionaremos regras para conexões em várias portas. Por exemplo, se a porta 25 é usada para conexões SMTP e envio de e-mails, faz sentido redirecionar as conexões para o MTA que temos em nossa infraestrutura. Se a conexão estiver na porta 80, isso será uma requisição http, que deve ser redirecionada para o Zimbra Proxy.
Regra para a porta 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-proxyRegra para a porta 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-proxyRegra para a porta 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-proxyRegra para a porta 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 checkRegra para a porta 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 checkObserve que, nas regras para o redirecionamento de pacotes TCP para o MTA, ao lado de seus endereços, está o parâmetro send-proxy. Isso é necessário para garantir que, de acordo com as configurações que alteramos anteriormente no Postfix, o endereço IP original do remetente seja enviado junto com os pacotes TCP.
Agora, quando todas as alterações necessárias no HAProxy foram feitas, podemos reiniciar o serviço usando o comando service haproxy restart e começar a utilizá-lo.
Para qualquer questão relacionada ao Zextras Suite, você pode entrar em contato com a representante da empresa «Zextras», Ekaterina Triandafiliadi, pelo e-mail katerina@zextras.com
Fonte: habr.com
