Взгляд интегратора на отечественные почтовые системы

Привет, Хабр! Меня зовут Илья, и я работаю инженером в компании STEP LOGIC. За последнее время я и мои коллеги накопили определённый опыт развёртывания отечественных почтовых систем в кластерных конфигурациях, в т. ч. в промышленной эксплуатации. В этой статье я расскажу о нем и особенностях наиболее крупных и известных российских почтовых систем.

Я попытался как можно более беспристрастно изложить этот материал. Надеюсь, что он окажется полезным при выборе импортозамещающей почтовой системы.

В этой статье не будет сравнения с Exchange, поскольку:

а) полного аналога так и нет;

б) это означало бы расстановку приоритетов, а это противоречит принципу беспристрастности.

Предлагаю по прочтении сделать выводы самостоятельно.

Герои этой статьи:

1. RuPost Enterprise

2. Tegu Enterprise (МБК-Лаб)

3. VK WorkMail

4. Deepmail

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

1. Архитектура, компоненты

1.1.RuPost Enterprise

Примечание: редакция RuPost Standard не поддерживает кластерную конфигурацию, поэтому её не рассматриваем.

При разработке RuPost использовались следующие почтовые компоненты: postfix, dovecot. В качестве почтового Web-клиента используется SoGo, также входящий в комплект поставки. Web-сервер – nginx, используется как для SoGo, так и для Панели управления RuPost полностью собственной разработки.

Инсталляция RuPost на один узел, включающая вышеперечисленные компоненты, называется Экземпляром. Работать можно начиная с одного экземпляра, для кластерной конфигурации потребуется минимум 2 экземпляра.

Конфигурирование всех компонент экземпляра(ов) осуществляется централизовано из Панели управления посредством Конфигураций. Очень удобный механизм для таких операций, как обновление сертификатов, добавление доменов, полностью избавляющий от необходимости править вручную конфигурационные файлы компонент RuPost. Кроме того, со стороны RuPost осуществляется дополнительный контроль целостности конфигурационных файлов, позволяющий на минимальном уровне оповещать об их изменении, на максимальном – автоматически восстанавливать конфигурацию или останавливать узлы, где были обнаружены такие изменения.

Для работы продукта потребуется дополнительно установить/настроить PostgreSQL (он и только он, для хранения настроек, данных календаря и GAL, для построения кластера PostgreSQL я использовал оркестрацию Patroni и etcd), и следующие внешние сервисы: NFS (для хранения почты в формате Maildir), memcached (в основном кэширует пользовательские данные SoGo) и внешний балансировщик. Данные сервисы также желательно кластеризовать (я использовал haproxy + keepalived), варианты реализации – на усмотрение инсталлятора/заказчика.

По моему мнению, для реализации отказоустойчивого сервиса NFS оптимальным вариантом является экспорт NFS из СХД, обладающей собственными механизмами отказоустойчивости. Для адекватной работы Maildir на больших объёмах данных настоятельно рекомендуется использование SSD-дисков для экспорта NFS.

RuPost умеет работать с несколькими экземплярами хранилища Maildir, расположенного на NFS:

• мастер – основное рабочее хранилище;

• реплика – горячая реплика, в случае недоступности мастера RuPost переключается на работу с ней;

• бэкап – холодная реплика, основное её предназначение – выполнить консистентный бэкап хранилища на уровне файловой системы.

Для снижения нагрузки на PostgreSQL вендор рекомендует использовать Pgbouncer, но есть нюанс: реализованная вендором поддержка кластера Patroni не работает совместно с Pgbouncer (в момент настройки подключения к СУБД считывается конфиг Patroni по порту 8008, но сам Patroni ничего про Pgbouncer не знает, и продолжает обращаться к кластеру по порту 5432 вместо 6432). Воркэраунд был найден – настроил подключение к СУБД как к обычному PostgreSQL, но по порту 6432, а перенаправлением запросов в СУБД к текущему лидеру Patroni занимается дополнительный внешний балансировщик.

Нужно отметить, что для реализации отказоустойчивого сервиса memcached также требуется механизм кластеризации с vip-адресом, поскольку в текущей версии RuPost можно указать только один адрес. Впрочем, по результатам моего общения с вендором, данный момент взят на заметку и в будущих релизах можно ожидать возможность использования нескольких узлов memcached без дополнительных «танцев с бубном» – эту задачу возьмёт на себя RuPost.

Минимальный кластер для промышленной эксплуатации включает 13 хостов/виртуальных машин, а также тома NFS внешних СХД (узлы etcd отдельно от узлов PostgreSQL, все сервисы задублированы 2N, используются отдельные пары балансировщиков для запросов front-end (https, smtp/smtps, imaps, webdavs) и back-end (запросов к СУБД)). Внешние сервисы по отношению к почтовому кластеру, необходимые для его работы, – DNS, LDAP.

1.2.Tegu Enterprise (МБК-Лаб)

Примечание: редакция Tegu FreeWare не поддерживает кластерную конфигурацию, интеграцию со службой каталогов (LDAP), работу с СУБД и некоторые другие функции, поэтому её не рассматриваем.

«Почтовый сервер полностью собственной разработки, без заимствования сторонних кодов и библиотек» – декларирует производитель, и это, похоже, действительно так. Благодаря этому почтовый сервер совместим даже со старыми версиями Linux. Веб-сервер консоли управления Tegu встроен в сам бинарник, запуск которого настраивается как сервис.

Компактный размер дистрибутива – всего два бинарных файла и менее 60 Мб файлового пространства после распаковки архива – это впечатляет. Как следствие компактного исполняемого модуля и отсутствия необходимости обращения к стеку многочисленных внешних библиотек/модулей ожидается высокая скорость работы почтового сервера.

Для работы продукта также, как и для RuPost, потребуется дополнительно установить/настроить внешние компоненты:

• СУБД PostgreSQL или CockroachDB (абсолютно всё хранится там – настройки почтового сервера, само почтовое хранилище и очередь почтовых сообщений); 

• внешний балансировщик;

• опционально – почтовый веб-клиент. Заявлена поддержка Roundcube (строго определённой, не самой последней версии), Р7-Офис и NextCloud.

Для кластеризации PostgreSQL я использовал уже проверенную связку Patroni + etcd, для балансировщика haproxy + keepalived. Производитель Tegu «МБК-Лаб» не заявляет официально поддержку Patroni, однако такая конфигурация себя успешно зарекомендовала, в т. ч. и в промышленной эксплуатации.

CockroachDB является СУБД со встроенными механизмами кластеризации, требует 3 узла, только шифрованные протоколы и никаких дополнительных танцев с бубном в виде Patroni + etcd. Казалось бы, идеальный кандидат на замещение PostgreSQL. Однако есть одно «но»: отечественные, впрочем, как и другие производители ПО резервного копирования, не включают в свои решения поддержку CockroachDB. Есть встроенные в эту СУБД средства, но для промышленной эксплуатации хотелось бы большего.

Минимальный кластер для промышленной эксплуатации включает 13 хостов/виртуальных машин (узлы etcd отдельно от узлов PostgreSQL, все сервисы задублированы 2N, используются отдельные пары балансировщиков для запросов front-end (https, smtp/smtps, imaps, webdavs) и back-end (запросов к СУБД), узлы Roundcube). Внешние сервисы по отношению к почтовому кластеру, необходимые для его работы – DNS, LDAP.

1.3.Почта VK WorkSpace

Что касается Почты VK WorkSpace, на мой взгляд, правильнее говорить не как о почтовой системе, а как о части Экосистемы коммуникаций, которая включает в себя продукты VK WorkSpace (корпоративную почту, календарь, облачное хранилище, документы, мессенджер, видеоконференции, инструменты для управления проектами и задачами). Диск включён в поставку Почты VK WorkSpace, поэтому приобретая почтовую систему, бонусом получаем и облачное хранилище.

Стандартная архитектура для кластерной инсталляции включает всего 8 узлов: 2 узла фронтов, 2 узла баз данных, 3 узла хранения и 1 деплоер (наименования оригинальные, взяты из документации вендора).

Решение построено с использованием монолитной контейнерной архитектуры. Тип контейнеризации – Docker. Всего в этой почтовой системе свыше 400 видов контейнеров-сервисов. При установке на кластер из 8 узлов общее количество контейнеров составляет более 1000 (я насчитал 1138). При установке дополнительных продуктов (интеграция с VK Teams, Р7-Офис, внешними SIEM) их количество приближается к 1200.

Вместе с тем всё необходимое ПО есть в едином дистрибутиве, ничего дополнительно устанавливать не требуется – никаких зависимостей, библиотек и прочего. Размер дистрибутива превышает 22 Гб – к этому надо быть готовым.

Узел Деплоера (Deployer) выполняет, как следует из названия, развёртывание системы, добавление компонентов, обновления в ходе дальнейшей эксплуатации, а также функции мониторинга. Потеря работоспособности этого узла не влияет на текущую работоспособность почтовой системы (за исключением мониторинга), поэтому кластеризация узла с этой ролью не предусмотрена. По мнению производителя, достаточно иметь резервную копию этого узла и обеспечивать отказоустойчивость соответствующей ВМ средствами виртуализации.

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

Кластеризация контейнеров осуществляется средствами самих сервисов внутри этих контейнеров. Так, например, контейнер postgresql1 на 1-м узле баз данных кластеризуется с аналогичным контейнером postgresql2 на 2-м узле баз данных средствами всё того же Patroni, при этом в качестве распределённого хранилища типа ключ-значение используется инфраструктурный etcd (infraetcd), который поднят на 3-х узлах и обслуживает почти все сервисы.

Узел баз данных (2 шт.) запускает порядка 140 контейнеров на каждом (в зависимости от установленных продуктов) с уникальными инстансами СУБД и вспомогательными сервисами, в числе которых MySQL, PosgreSQL, Scylla, Tarantool и Memcached (в терминологии VK последний также причисляется к БД). У каждого сервиса свой механизм обеспечения отказоустойчивости: PostgreSQL – Patroni, Memcached – Mcrouter, Tarantool – Overlord, Tarantool 2.10+ — RAFT, MySQL – Orchestrator.

Узел хранения (3 шт.) запускает порядка 60–70 контейнеров на каждом и обеспечивает хранение данных как файловой структуры в собственном формате, разработанном VK. Данные всегда хранятся в 2-х копиях на разных узлах с синхронной записью. Если один из 2-х узлов не доступен для конкретной пары дисков, доступный диск может работать только на чтение. Именно поэтому всегда используются 3 пары дисков, расположенные на 3-х узлах. И количество таких узлов может быть кратно только трём: 6, 9 и т. д. Такая архитектура хранения позволяет сохранить работоспособность при выходе из строя 1-го узла из 3-х: 1 пара дисков всегда будет доступна как на чтение, так и на запись, и запись новых данных будет осуществляться только на неё, а 2 пары дисков будут доступны только для чтения, сохраняя доступность всей остальной информации. Звучит мудрёно, поэтому вот картинка из документации вендора:

Узел фронт (2 шт.) – выполняет все прочие функции, не перечисленные выше: приёмку, отправку писем, их раскладку в хранилище и вытягивание оттуда, взаимодействие с СУБД, управление облачным хранением файлов, вэб-интерфейсами пользователя и администратора (отличный от интерфейса Деплоера). На каждом узле работает порядка 330–360 контейнеров в зависимости от установленных продуктов.

Несмотря на сложность такой конструкции, при определённых навыках и знаниях о внутренней архитектуре, развёртывание и эксплуатация этой системы не представляет собой невыполнимую задачу. Безусловно, потребуются знания Docker на уровне docker ps -a | grep Exit или journalctl -fu onpremise-container-<название сервиса>, но ничего нерешаемого нет, а внедрение и эксплуатация этой почтовой системы может превратится в увлекательнейшее путешествие, открывающее дверь в мир микросервисов))).

1.4.Deepmail

Почтовый сервер Deepmail от компании «Иридиум» использует такие основные компоненты, как dovecot, postfix, roundcube, gunicorn, redis. Применяется контейнеризация, все сервисы запускаются в Docker. Всего в сервере 12 контейнеров, что упрощает администрирование. Названия контейнеров интуитивно-понятные: например, внутри deepmail-imap запущен dovecot, deepmail-smtp, соответственно, postfix, а deepmail-webmail – это roundcube.

Для работы сервера потребуется дополнительно установить/настроить PostgreSQL или MySQL, также потребуется NFS для хранения почты в формате Maildir и внешний балансировщик. Данные сервисы также желательно кластеризовать, способы кластеризации аналогичны описанным выше.

При развёртывании необходимо самостоятельно установить Docker, на сервере СУБД самостоятельно создать пользователя и 2 базы: deepmail и deepmailweb.

Каких-либо встроенных в почтовый сервер механизмов репликации хранилища Maildir мной обнаружено не было. Судя по всему, инсталлятору/заказчику предлагается выбрать нужное решение на своё усмотрение.

Минимальный кластер для промышленной эксплуатации будет включать 2 узла Deepmail, 2 узла PostgreSQL, 3 узла etcd, 4 узла балансировщиков для запросов front-end и back-end – всего 11 узлов. Также потребуются дополнительные сервисы NFS, DNS, LDAP.

Почтовый сервер Deepmail также включает в себя модуль резервного копирования. Занятная штука, управляется исключительно из CLI, позволяет восстанавливать письма с гранулярностью до пользователя. Если хочется поиграть в хардкор, то такая возможность есть)). Однако, для промышленной эксплуатации системы с тысячами п/я CLI вряд ли подойдёт.

Вендор анонсировал, что в декабре в экосистему почтового сервера DeepMail войдет кроссплатформенный почтовый клиент, который будет функционировать под управлением ОС MS Windows, БазАЛЬТ, АСТРА, РедОС, Debian Linux, MacOS, а также на мобильных ОС Android и iOS.

На этом тему, связанную с архитектурой/компонентами рассматриваемых почтовых систем, считаю изложенной.

В следующей статье планирую изложить особенности взаимодействия и интеграции почтовых систем с каталогом LDAP. Интересных моментов там не меньше, чем в архитектуре, однако объём статьи не позволяет продолжить прямо здесь.

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

Продолжение следует…