Równoważenie obciążenia w edycji open-source Zimbra za pomocą HAProxy

Jednym z głównych zadań podczas budowy rozbudowanych infrastruktur Zimbra OSE jest odpowiednie balansowanie obciążenia. Oprócz tego, że zwiększa odporność na awarie, bez balansowania obciążenia nie można zapewnić jednakowej responsywności usługi dla wszystkich użytkowników. Aby rozwiązać ten problem, wykorzystuje się load balancery – rozwiązania programowe i sprzętowe, które redistribuują zapytania między serwerami. Wśród nich znajdują się zarówno dość prymitywne, jak RoundRobin, który po prostu kieruje każde następne zapytanie do kolejnego serwera w liście, jak i bardziej zaawansowane, na przykład HAProxy, które jest szeroko stosowane w infrastrukturach obliczeniowych o wysokim obciążeniu z powodu wielu istotnych zalet. Przyjrzyjmy się, jak można zapewnić współpracę load balancera HAProxy i Zimbra OSE.

Zatem, w warunkach zadania mamy infrastrukturę Zimbra OSE, w której znajdują się dwa Zimbra Proxy, dwa serwery LDAP i LDAP Replica, cztery magazyny pocztowe z 1000 skrzynek pocztowych w każdym oraz trzy MTA. Biorąc pod uwagę, że mamy do czynienia z serwerem pocztowym, będzie on obsługiwał trzy rodzaje ruchu, które wymagają balansowania: HTTP do ładowania klienta webowego, a także POP i SMTP do przesyłania wiadomości e-mail. Przy tym ruch HTTP będzie kierowany do serwery Zimbra Proxy z adresami IP 192.168.0.57 i 192.168.0.58, a ruch SMTP będzie kierowany do serwerów MTA z adresami IP 192.168.0.77 i 192.168.0.78.

Jak już wspomniano, aby zapewnić równomierne rozdzielenie zapytań między serwery, użyjemy load balancera HAProxy, który będzie działał na węźle wejściowym infrastruktury Zimbra zarządzanej przez Ubuntu 18.04. Instalacja haproxy w tym systemie operacyjnym realizowana jest za pomocą polecenia sudo apt-get install haproxy. Następnie należy w pliku /etc/default/haproxy zmienić parametr ENABLED=0 na ENABLED=1. Teraz, aby upewnić się, że haproxy działa, wystarczy wpisać polecenie service haproxy. W przypadku, gdy ta usługa działa, będzie to widoczne w wyniku polecenia.

Jednym z głównych braków HAProxy jest to, że domyślnie nie przekazuje adresu IP podłączającego klienta, zastępując go własnym. Może to prowadzić do sytuacji, w których wiadomości wysyłane przez osoby trzecie nie będą mogły być zidentyfikowane. adresem IP, aby dodać go do czarnej listy. Niemniej jednak, ten problem można rozwiązać. W tym celu należy edytować plik /opt/zimbra/common/conf/master.cf.in na serwerach z Postfix i dodać do niego następujące linie:

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

Dzięki temu otworzymy porty 26, 466 i 588, które będą przyjmować przychodzący ruch z HAProxy. Po zapisaniu plików należy zrestartować Postfix na wszystkich serwerach za pomocą polecenia zmmtactl restart.

Następnie przystąpimy do konfiguracji HAProxy. W tym celu najpierw utworzymy kopię zapasową pliku z konfiguracjami cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak. Następnie otworzymy w edytorze tekstu plik źródłowy /etc/haproxy/haproxy.cfg i stopniowo dodamy do niego niezbędne ustawienia. Pierwszym blokiem będzie dodanie serwera odpowiedzialnego za logi, ustawienie maksymalnej liczby równoczesnych połączeń oraz wskazanie nazwy i grupy użytkownika, do którego będzie należał uruchamiany proces.

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

Liczba 5000 równoczesnych połączeń nie wzięła się znikąd. Ponieważ w naszej infrastrukturze jest 4000 skrzynek pocztowych, należy przewidzieć możliwość, że wszystkie one jednocześnie zalogują się do swojej poczty roboczej. Ponadto, warto zostawić niewielki zapas na wypadek, gdyby ich liczba wzrosła.

Teraz dodajmy blok z ustawieniami domyślnymi:

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

W tym bloku ustawiamy maksymalny czas oczekiwania klienta i serwera, aby przerywać połączenie po jego upływie, oraz określamy tryb działania HAProxy. W naszym przypadku load balancer działa w trybie TCP, co oznacza, że po prostu przesyła pakiety TCP, nie analizując ich zawartości.

Następnie dodamy reguły dla połączeń na różnych portach. Na przykład, jeśli port 25 jest używany do połączeń SMTP i przesyłania wiadomości e-mail, warto przekierować połączenia do MTA dostępnych w naszej infrastrukturze. Jeżeli jednak połączenie odbywa się na porcie 80, jest to żądanie http, które należy skierować do Zimbra Proxy.

Reguła dla portu 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

Reguła dla portu 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

Reguła dla portu 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

Reguła dla portu 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

Reguła dla portu 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

Zwróć uwagę, że w regułach do przesyłania pakietów TCP do MTA obok ich adresów widnieje parametr send-proxy. Jest to konieczne, aby, zgodnie z wprowadzonymi wcześniej zmianami w konfiguracji Postfix, razem z pakietami TCP przesyłany był także oryginalny adres IP nadawcy.

Teraz, kiedy wszystkie niezbędne zmiany w HAProxy zostały wprowadzone, można zrestartować usługę za pomocą polecenia service haproxy restart i przystąpić do jej użytkowania.

Wszelkie pytania dotyczące Zextras Suite można kierować do przedstawiciela firmy „Zextras” Ekateriny Triandafiliidi pod adresem e-mail katerina@zextras.com

Źródło: habr.com