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

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

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

В качестве общего хранилища используется сетевой файловый ресурс (например, NFS), подключённый ко всем узлам кластера.

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

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

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

Клиентские подключения к серверу могут выполняться по следующим протоколам:

  • JUMP (HTTPS);

  • IMAP;

  • POP3;

  • ActiveSync (HTTPS);

  • DAV-протоколы (HTTPS).

Передача подключений между узлами может выполняться через внешний балансировщик нагрузки уровня L3-L4.

Взаимодействие между узлами осуществляется через внутренний CMD-протокол.

Архитектура backend-узлов

Все backend-узлы кластера являются симметричными и могут выполнять одинаковые функции. При этом логически каждый backend может находиться в одном из состояний:

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

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

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

Reserve (Резерв)

Резервный backend-узел. Автоматически принимает роль Dispatcher при отказе основного диспетчера.

Online (Онлайн)

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

Offline (Оффлайн)

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

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

Для запуска сервера в режиме backend используется параметр командной строки:

--backend

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

В качестве общего хранилища рекомендуется использовать сетевую файловую систему NFS.

На каждом backend-узле общее хранилище подключается в базовой директории сервера как символьная ссылка:

Cluster

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

  • heartbeat-файл hb.json;

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

  • данные кластерных объектов;

  • конфигурацию кластерных доменов;

  • почтовые правила;

  • маршрутизацию;

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

  • служебные данные синхронизации.

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

Инициализация кластера

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

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

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

  1. backend пытается зарегистрировать себя в hb.json.

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

При отказе Dispatcher:

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

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

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

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

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

При отказе Reserve:

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

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

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

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

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

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

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

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

  • маршрутизацию;

  • настройки взаимодействия узлов.

Передача данных между backend-узлами выполняется через CMD и HTTP протоколы.

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

Межкластерное взаимодействие

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

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

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

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

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

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

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

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

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

  • выполнения файловых операций.

Настройки CMD

Основные параметры CMD:

Параметр Описание

Адрес сервера в кластере

IP-адрес текущего backend-узла.

Порт для CMD

Порт CMD-модуля для взаимодействия backend-узлов. По умолчанию используется порт 106.

Шифрование

Включает TLS-шифрование CMD и HTTP соединений между backend-узлами.

Пароль

Пароль кластерной аутентификации backend-узлов.
Порт CMD и параметры шифрования должны совпадать на всех backend-узлах кластера.

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

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

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

  1. backend запрашивает блокировку объекта у Dispatcher.

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

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

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

  • временные;

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

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

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

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

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

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

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

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

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

SMTP-доставка

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

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

Клиентское подключение может быть принято любым backend-узлом кластера.

После принятия подключения backend:

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

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

Поддерживается:

  • IMAP;

  • POP3;

  • JUMP;

  • ActiveSync;

  • DAV-протоколы.

Балансировка нагрузки

Для распределения клиентских подключений рекомендуется использовать внешний балансировщик нагрузки L3-L4, например: HAProxy в режиме TCP.

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

  • HTTP/HTTPS;

  • IMAP;

  • POP3;

  • ActiveSync;

  • DAV.

SMTP рекомендуется распределять через MX-записи DNS.

Исходящие подключения SMTP, HTTP, LDAP, CMD и другие межсерверные соединения не балансируются и выполняются backend-узлами напрямую.

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

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

Новые backend-узлы:

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

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

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

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

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