IVA ДОКУМЕНТАЦИЯ
ОБНОВЛЕНИЯ

Архитектура кластера

В IVA Mail реализован симметричный динамический кластер с общим сетевым хранилищем. Кластер состоит из бэкенд- и фронтенд-узлов, совместно обслуживающих пользовательские подключения, данные и объекты системы.

Описание процедуры установки кластера приведено в разделе Кластерная установка.

Общая схема кластерной конфигурации

Схема кластерной конфигурации

Узлы кластера IVA Mail выполняют роли бэкенд и фронтенд. Фронтенд-узлы принимают внешние клиентские и почтовые подключения. Бэкенд-узлы работают с данными и общим хранилищем.

Если в кластере есть только бэкенд-узлы — кластер симметричный и каждый узел выполняет обе роли.

Архитектура ориентирована на горизонтальное масштабирование за счёт добавления бэкенд- и фронтенд-узлов.

Назначение компонентов

Фронтенд-узлы кластера

Фронтенд-узлы принимают клиентские и почтовые подключения и работают в режиме Active-Active.

Функции фронтенд-узлов:

  • приём клиентских подключений HTTP (JUMP, ActiveSync), IMAP и POP3 через балансировщик нагрузки;

  • приём входящих SMTP-подключений от внешних почтовых серверов;

  • терминация TLS;

  • обработка очередей сообщений и доставка исходящей почты;

  • получение данных аккаунтов и их папок с бэкенд-узлов через кластерное взаимодействие.

Фронтенд-узлы не подключаются к общему хранилищу и не могут быть диспетчером или резервом.

Сетевое взаимодействие фронтенд-узлов:

Направление Протокол и назначение

Клиенты → Фронтенд

HTTPS (JUMP, ActiveSync), IMAP, POP3.

Внешние почтовые серверы → Фронтенд

SMTP, входящая почта по MX-записям DNS.

Фронтенд ↔ Бэкенд

Кластерное взаимодействие (106/TCP, 80/TCP, 143/TCP, 25/TCP).

Фронтенд → Внешние почтовые серверы

SMTP, доставка исходящей почты.

Бэкенд-узлы кластера

Бэкенд-узлы обрабатывают запросы фронтенд-узлов, выполняют аутентификацию пользователей, работают с данными аккаунтов и их папками, а также с общим файловым хранилищем, участвуют в координации кластера.

Роли и состояния бэкенд-узлов

Все бэкенд-узлы симметричны, но логически могут находиться в одном из состояний:

Роль Назначение

Dispatcher (Диспетчер)

Основной управляющий узел кластера. Поддерживает образ кластера, координирует блокировки объектов, хранит таблицу узлов и управляет синхронизацией состояния.

Reserve (Резерв)

Резерв диспетчера, автоматически принимает его роль при отказе основного диспетчера.

Online (Онлайн)

Рабочий бэкенд-узел, обслуживающий клиентские подключения, объекты и пользовательские данные.

Offline (Оффлайн)

Бэкенд-узел, временно выведенный из состава кластера.

Назначение ролей происходит динамически и не требует ручной конфигурации.

Общее хранилище кластера

Рекомендуется использовать сетевое файловое хранилище, смонтированное ко всем бэкенд-узлам по протоколу NFSv3.

Все конфигурационные файлы и пользовательские данные кластерных доменов хранятся в единой кластерной директории Cluster.

На бэкенд-серверах эта директория представляет собой часть файловой системы СХД, смонтированную по протоколу NFS v3 в локальную точку монтирования операционной системы.

В рабочих директориях бэкенд-серверов (/var/ivamail) создаётся символьная ссылка Cluster, указывающая на эту точку монтирования. Благодаря этому все компоненты системы работают с каталогом /var/ivamail/Cluster как с единым логическим хранилищем, независимо от физической реализации.

Общее хранилище содержит:

  • heartbeat-файл hb.json;

  • индексы доменов;

  • данные кластерных объектов и доменов (включая настройки, правила и пр.);

  • метаданные блокировок.

Физически данные располагаются в общем файловом хранилище, однако логическая сериализация и контроль атомарности операций выполняются Dispatcher-узлом.

Взаимодействие узлов кластера

Модули и протоколы

Для взаимодействия узлов кластера используются модули CMD и HTTP.

CMD используется для:

  • синхронизации состояния кластера;

  • передачи образа кластера;

  • регистрации узлов;

  • управления блокировками;

  • передачи команд между узлами;

  • координации обработки объектов.

HTTP используется для выполнения файловых операций.

Образ кластера

Dispatcher поддерживает единый логический образ кластера, включающий:

  • общий кластерный секрет;

  • список узлов кластера;

  • список кластерных доменов;

  • список объектов доменов;

  • таблицы маршрутизации.

Передача и запрос образа выполняются через кластерное взаимодействие.

Бэкенд-узлы могут читать часть данных напрямую из общего хранилища, однако проверка актуальности состояния выполняется через Dispatcher.

Общий секрет кластера

При первом запуске Dispatcher генерирует общий кластерный секрет.

Новые бэкенд-узлы:

  1. Выполняют согласование ключей.

  2. Получают секрет по CMD-соединению.

  3. Сохраняют его в локальных настройках.

При повторном запуске кластера первым должен запускаться бэкенд, содержащий актуальный кластерный секрет. Иначе возможна рассинхронизация состояния кластера.

Параметры кластерного взаимодействия описаны в разделе Настройки кластера.

Обработка подключений и объектов

Балансировка входящих подключений

Клиентские подключения по протоколам доступа принимает балансировщик нагрузки (например, HAProxy в режиме TCP или HTTP) и распределяет их между фронтенд-узлами по round-robin или другому алгоритму.

Рекомендуется балансировать входящие соединения по протоколам:

  • HTTP (для JUMP и ActiveSync);

  • IMAP и POP3.

SMTP-соединения целесообразно «балансировать» указанием IP-адресов или доменных имён фронтенд-узлов в MX-записях DNS.

Исходящие соединения SMTP, HTTP, LDAP, кластерного взаимодействия и другие не балансируются. Узлы устанавливают их от своего имени: исходящую почту отправляют фронтенд-узлы, к LDAP обращаются бэкенд-узлы.

Обработка клиентских подключений

Клиентские подключения принимает любой фронтенд-узел и передаёт запрос на бэкенд-узел через кластерное взаимодействие. После этого запрос:

  • либо обслуживается локально на бэкенд-узле;

  • либо проксируется к владельцу объекта (узлу, который его обрабатывает).

Блокировки объектов

Любая операция с объектами домена выполняется через механизм кластерных блокировок.

Принцип работы:

  1. Бэкенд запрашивает блокировку объекта у Dispatcher.

  2. Dispatcher атомарно регистрирует блокировку.

  3. После получения блокировки бэкенд выполняет обработку объекта.

Поддерживаются следующие типы блокировок:

  • временные;

  • рекурсивные (со счётчиком сессий).

Поведение при конфликте блокировок:

Ситуация Поведение

Объект свободен

Бэкенд получает блокировку и обрабатывает объект локально.

Объект уже заблокирован

Обработка выполняется удалённо через бэкенд-владельца объекта.

IMAP/JUMP-подключение

Соединение проксируется на бэкенд-владельца объекта.

SMTP-доставка

Используется удалённая папка владельца объекта.

Инициализация и отказоустойчивость кластера

Назначение Dispatcher (Диспетчер)

При запуске бэкенд-узел выполняет поиск активного Dispatcher.

Если Dispatcher отсутствует:

  1. Бэкенд пытается зарегистрировать себя в hb.json.

  2. Первый успешно зарегистрировавшийся бэкенд становится Dispatcher.

При отказе Dispatcher:

  1. Reserve автоматически принимает роль Dispatcher.

  2. Информация о новом состоянии рассылается бэкенд-узлам кластера.

Если Dispatcher и Reserve отсутствуют одновременно, выбор нового Dispatcher выполняется через запись в hb.json.

Назначение Reserve (Резерв)

Reserve назначается Dispatcher автоматически из списка доступных бэкенд-узлов.

При отказе Reserve:

  1. Dispatcher автоматически назначает новый резервный бэкенд;

  2. Информация о новом Reserve распространяется по кластеру.

Отказоустойчивость фронтенд-узлов

При отказе фронтенд-узла внешний балансировщик распределяет клиентские подключения на оставшиеся узлы. Входящие SMTP-подключения принимают узлы из остальных MX-записей. Роли диспетчера и резерва при этом не меняются.

Связанные разделы