Jednym z głównych zadań podczas budowania wielkoskalowej infrastruktury Zimbra OSE jest odpowiednie równoważenie obciążenia. Oprócz tego, że zwiększa to odporność usługi na awarie, bez równoważenia obciążenia nie jest możliwe zapewnienie takiej samej responsywności usługi dla wszystkich użytkowników. Aby rozwiązać ten problem, stosuje się moduły równoważenia obciążenia - rozwiązania programowe i sprzętowe, które redystrybuują żądania pomiędzy serwerami. Są wśród nich dość prymitywne, jak RoundRobin, który po prostu wysyła każde kolejne żądanie do kolejnego serwera na liście, ale są też bardziej zaawansowane, jak np. HAProxy, który jest szeroko stosowany w infrastrukturach obliczeniowych o dużym obciążeniu ze względu na szereg istotnych zalet. Przyjrzyjmy się, jak można sprawić, aby moduł równoważenia obciążenia HAProxy i Zimbra OSE współpracowały ze sobą.
Zatem zgodnie z warunkami zadania dostajemy infrastrukturę Zimbra OSE, na którą składają się dwa serwery Zimbra Proxy, dwa serwery LDAP i LDAP Replica, cztery magazyny pocztowe po 1000 skrzynek pocztowych każdy oraz trzy MTA. Biorąc pod uwagę, że mamy do czynienia z serwerem pocztowym, będzie on odbierał trzy rodzaje ruchu, które wymagają zrównoważenia: HTTP do pobrania klienta WWW, a także POP i SMTP do wysyłania wiadomości e-mail. W tym przypadku ruch HTTP będzie kierowany do serwerów Zimbra Proxy o adresach IP 192.168.0.57 i 192.168.0.58, a ruch SMTP będzie kierowany do serwerów MTA o adresach IP 192.168.0.77 i 192.168.0.78.
Jak już wspomniano, aby zapewnić równomierną dystrybucję żądań pomiędzy serwerami, użyjemy modułu równoważenia obciążenia HAProxy, który będzie działał w węźle wejściowym infrastruktury Zimbra z systemem Ubuntu 18.04. Instalacja haproxy w tym systemie operacyjnym odbywa się za pomocą polecenia sudo apt-get zainstaluj haproxy. Następnie potrzebujesz w pliku /etc/default/haproxy zmień parametr WŁĄCZONE = 0 na WŁĄCZONE = 1. Teraz, aby upewnić się, że haproxy działa, wystarczy wpisać polecenie obsługa haproxy. Jeśli ta usługa jest uruchomiona, będzie to jasne z wyniku polecenia.
Jedną z głównych wad HAProxy jest to, że domyślnie nie przesyła adresu IP łączącego się klienta, zastępując go własnym. Może to prowadzić do sytuacji, w których e-maile wysyłane przez atakujących nie mogą zostać zidentyfikowane na podstawie adresu IP w celu dodania ich do czarnej listy. Jednak ten problem można rozwiązać. Aby to zrobić, musisz edytować plik /opt/zimbra/common/conf/master.cf.in na serwerach z Postfixem i dodaj 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_adjustW związku z tym otworzymy porty 26, 466 i 588, które będą odbierać ruch przychodzący z HAProxy. Po zapisaniu plików powinieneś zrestartować Postfix na wszystkich serwerach za pomocą polecenia zmmtactl restart.
Następnie zacznijmy konfigurować HAProxy. Aby to zrobić, najpierw utwórz kopię zapasową pliku ustawień cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak. Następnie otwórz plik źródłowy w edytorze tekstu /etc/haproxy/haproxy.cfg i zacznij krok po kroku dodawać do niego niezbędne ustawienia. Pierwszym blokiem będzie dodanie serwera pobierającego logi, ustawienie maksymalnej dozwolonej liczby jednoczesnych połączeń oraz określenie nazwy i grupy użytkownika, do którego będzie należeć wykonujący się proces.
global
user daemon
group daemon
daemon
log 127.0.0.1 daemon
maxconn 5000
chroot /var/lib/haproxyNie bez powodu pojawiła się liczba 5000 tysięcy jednoczesnych połączeń. Ponieważ w naszej infrastrukturze mamy 4000 skrzynek pocztowych, musimy rozważyć możliwość, że wszyscy będą mieli dostęp do swojej służbowej poczty e-mail w tym samym czasie. Ponadto konieczne jest pozostawienie niewielkiej rezerwy na wypadek wzrostu ich liczby.
Dodajmy teraz blok z ustawieniami domyślnymi:
defaults
timeout client 1m
log global
mode tcp
timeout server 1m
timeout connect 5sTen blok ustawia maksymalny limit czasu dla klienta i serwera na zamknięcie połączenia po jego wygaśnięciu, a także ustawia tryb działania HAProxy. W naszym przypadku moduł równoważenia obciążenia działa w trybie TCP, czyli po prostu przesyła pakiety TCP bez analizy ich zawartości.
Następnie dodamy reguły dla połączeń na różnych portach. Przykładowo, jeśli port 25 jest używany do połączeń SMTP i poczty, wówczas sensowne jest przekazywanie połączeń na niego do MTA dostępnych w naszej infrastrukturze. Jeśli połączenie odbywa się na porcie 80, jest to żądanie http, które należy przekazać do serwera proxy Zimbra.
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-proxyReguł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-proxyReguł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-proxyReguł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 checkReguł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 checkNależy pamiętać, że w zasadach przekazywania pakietów TCP do MTA obok ich adresów znajduje się parametr wyślij-proxy. Jest to konieczne, aby zgodnie ze zmianami, które dokonaliśmy wcześniej w ustawieniach Postfixa, wraz z pakietami TCP przesyłany był oryginalny adres IP jego nadawcy.
Teraz, gdy wszystkie niezbędne zmiany zostały wprowadzone w HAProxy, możesz ponownie uruchomić usługę za pomocą polecenia ponowne uruchomienie usługi haproxy i zacznij z niego korzystać.
W przypadku wszystkich pytań związanych z Zextras Suite, możesz skontaktować się z przedstawicielem Zextras Ekaterina Triandafilidi przez e-mail [email chroniony]
Źródło: www.habr.com