Балансування навантаження в Zimbra Open-Source Edition за допомогою HAProxy

Одним із головних завдань при побудові масштабних інфраструктур Zimbra OSE є грамотне балансування навантаження. Крім того, що вона підвищує стійкість до відмови сервісу, без балансування навантаження неможливо забезпечити однакову чуйність сервісу для всіх користувачів. Для того, щоб вирішити це завдання, використовуються балансувальники навантаження - програмні та апаратні рішення, що перерозподіляють запити між серверами. Серед них є як досить примітивні, на кшталт RoundRobin, який просто кожен наступний запит надсилає наступному в списку серверу, а є й більш просунуті, наприклад HAProxy, який широко застосовується у високонавантажених обчислювальних інфраструктурах через значні переваги. Давайте подивимося на те, як можна забезпечити спільну роботу балансувальника навантаження HAProxy і Zimbra OSE.

Отже, за умовами завдання нам дана інфраструктура Zimbra OSE, в якій є два Zimbra Proxy, два сервери LDAP та LDAP Replica, чотири поштові сховища з 1000 поштових скриньок на кожній та три MTA. Враховуючи те, що ми маємо справу з поштовим сервером, на нього надходитиме три види трафіку, що потребує балансування: HTTP для завантаження веб-клієнта, а також POP та SMTP для пересилання електронної пошти. При цьому HTTP-трафік йтиме на сервери Zimbra Proxy з ip-адресами 192.168.0.57 та 192.168.0.58, а трафік SMTP йтиме на MTA-сервери з ip-адресами 192.168.0.77 та 192.168.0.78.

Як уже говорилося, для забезпечення рівномірного розподілу запитів між серверами ми використовуватимемо балансувальник навантаження HAProxy, який працюватиме на вхідному вузлі інфраструктури Zimbra під керуванням Ubuntu 18.04. Установка haproxy у цій операційній системі здійснюється за допомогою команди sudo apt-get install haproxy. Після цього необхідно у файлі /etc/default/haproxy змінити параметр УВІМКНЕНО=0 на УВІМКНЕНО=1. Тепер, щоб переконатися в тому, що haproxy працює, достатньо ввести команду service haproxy. Якщо ця служба працює, це буде зрозуміло з висновку команди.

Одним з основних недоліків HAProxy є те, що він за умовчанням не передає IP-адресу клієнта, що підключається, замінюючи його своїм власним. Це може призвести до ситуацій, коли надіслані зловмисниками листи не можна буде ідентифікувати за IP-адресою, щоб додати його до чорного списку. Втім, це питання можна вирішити. Для цього потрібно відредагувати файл /opt/zimbra/common/conf/master.cf.in на серверах з Postfix і додати до нього наступні рядки:

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

За рахунок цього ми відкриємо порти 26, 466 та 588, які прийматимуть вхідний трафік з HAProxy. Після збереження файлів слід перезапустити Postfix на всіх серверах за допомогою команди zmmtactl restart.

Після цього приступимо до налаштування HAProxy. Для цього спершу створимо резервну копію файлу з налаштуваннями cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak. Потім відкриємо у текстовому редакторі вихідний файл /etc/haproxy/haproxy.cfg і почнемо поетапно додавати до нього необхідні налаштування. Першим блоком стане додавання сервера, що знімає логи, встановлення максимально дозволеної кількості одночасних підключень, а також вказівку імені та групи користувача, до якого буде належати виконуваний процес.

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

Цифра в 5000 одночасних підключень з'явилася недарма. Оскільки в нашій інфраструктурі 4000 скриньок, необхідно передбачити ймовірність того, що всі вони одночасно зайдуть у свою робочу пошту. Крім того, необхідно залишити невеликий запас на той випадок, якщо їхня кількість збільшиться.

Тепер додамо блок із налаштуваннями за замовчуванням:

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

У цьому блоці задається максимальний час очікування клієнта та сервера, щоб розривати з'єднання при його закінченні, а також задається режим роботи HAProxy. У нашому випадку балансувальник навантаження працює в режимі TCP, тобто просто передає пакети TCP, не аналізуючи їх вміст.

Далі ми додамо правила для з'єднань різних портах. Наприклад, якщо порт 25 використовується для SMTP-з'єднань та передачі пошти, то є сенс перенаправляти підключення до нього на MTA, наявні в нашій інфраструктурі. Якщо ж з'єднання йде на порту 80, це http-запит, який необхідно переправити на Zimbra Proxy.

Правило для порту 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

Правило для порту 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

Правило для порту 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

Правило для порту 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

Правило для порту 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

Зверніть увагу, що в правилах для пересилання TCP-пакетів до MTA поруч із їх адресами стоїть параметр send-proxy. Це потрібно для того, щоб, відповідно до внесених раніше змін у налаштування Postfix, разом з TCP-пакетами пересилалася і оригінальна IP-адреса його відправника.

Тепер, коли всі необхідні зміни до HAProxy внесені, можна перезапустити сервіс за допомогою команди service haproxy restart та приступати до його використання.

З усіх питань, пов'язаних з Zextras Suite ви можете звернутися до Представника компанії «Zextras» Катерини Тріандафіліді електронною поштою [захищено електронною поштою]

Джерело: habr.com