В условиях санкционных рисков и строгих требований к локализации данных импортозамещение корпоративной почты становится критическим для непрерывности бизнеса. На примере RuPost 4.0 IT-World анализирует, как отечественное решение отвечает на ключевые вызовы: обеспечивает отказоустойчивость предприятия, бесшовную интеграцию в ИТ-ландшафт и безопасную миграцию с зарубежных платформ.
Импортозамещение корпоративной почты — это уже не проект «на всякий случай», а задача непрерывности бизнеса. Риски санкций и зависимости от иностранных вендоров сочетаются с обязательствами по контролю и локализации данных, а вместе с ними — с требованиями к высокой доступности и предсказуемой эксплуатации. Поэтому для ИТ-директора важны ответы на три вопроса: выдержит ли система масштабы и отказоустойчивость реального предприятия, насколько прозрачно она встраивается в существующие каталоги, мониторинг и регламенты и как безболезненно пройти миграцию с Exchange и других зарубежных решений. С RuPost 4.0 на все три вопроса есть предметные, технологически выверенные ответы.
Архитектура высокой доступности
RuPost — корпоративный почтовый сервер на Linux, изначально спроектированный под высокую доступность и большие инсталляции. В основе — равнозначные узлы, работающие в режиме Active-Active без роли специфичных серверов. В основе отдельных компонентов лежат популярные во всем мире открытые решения и технологии. Так, веб-терминация выполнена на Nginx, транспорт на Postfix, доступ к ящикам реализован через Dovecot, календарь/контакты и веб-клиент основаны на SOGo. Архитектура не фиксирует пользователя за одним «хозяином» базы, как это делает Exchange, и потому избегает избыточных прокси-переадресаций и сложного раскладывания ящиков по множеству почтовых баз. Пользователь попадает на любой узел кластера, а система прозрачно управляет распределением и ребалансировкой. Так, неактивные IMAP-сессии штатно сбрасываются ночью (по умолчанию в 02:00) и нагрузка выравнивается без вмешательства администратора и без заметных эффектов для пользователей.
Ключ к устойчивости — модель хранения. RuPost использует Maildir на сетевом хранилище через NFS, где каждое письмо — отдельный файл. Это важное отличие от монолитной почтовой БД, где сбой записи одного сообщения не «роняет» всю базу, а затрагивает только конкретный файл. Поверх этого введены понятные ИТ-команде сущности. К примеру, пространство хранения с репликацией мастер — slave/backup и MailStore — как набор уникальных NFS-точек монтирования. Горячие реплики (slave) имеют настраиваемые «веса» — приоритеты, что позволяет, в частности, разгрузить мастер и строить цепочку репликаций рационально. В свою очередь, холодная реплика (backup) служит источником для резервного копирования и не участвует в работе с пользователями. В результате для достижения требуемого RPO/RTO обычно нужно меньше копий, чем в моделях, где все ящики упакованы в единые базы.
Инфраструктурно RuPost опирается на зрелые кирпичи Linux-мира. Хранилище — NFS поверх SDS или аппаратных СХД: DRBD с кластерной файловой системой уровня OCFS2, ZFS/вендорные NAS/SAN, аппаратные клоны и инкрементальные репликации. В качестве базы данных используется PostgreSQL/Tantor в HA-конфигурации на Patroni с распределенным хранилищем конфигурации (etcd/Consul/ZooKeeper/Kubernetes) и режимом Failsafe, который удержит лидерство узла при проблемах с DCS, если прямая связность с репликами сохранена. Такой подход снимает единственные точки отказа как на уровне приложений, так и на уровне данных. Отдельно стоит заметить практический нюанс: встроенная файловая репликация через NFS-клиент уместна для небольших объемов и «подкрашивания» изменений, но первичные копии и крупные обновления эффективнее передавать по схеме «сервер-сервер» (rsync) или средствами SDS/СХД — так можно избежать лишнего сетевого трафика и достичь нужной скорости.
С эксплуатационной стороны система ведет себя предсказуемо и «говорит» с администратором понятными сигналами. Встроенный мониторинг закрывает четыре уровня: геокластер, кластер, инфраструктуру и отдельный экземпляр. На площадках регулярно проверяются сетевые порты почтовых сервисов; сбойный узел автоматически выводится из балансировщика, его очереди доставки эвакуируются, а подключенные IMAP-клиенты перераспределяются на работающие узлы с учетом текущей нагрузки. На инфраструктурном уровне контролируются DNS-записи, доступ к LDAP и права сервисных учетных записей, состояние СУБД и кластера Patroni, NFS-маунты, Memcached. Для NFS очередей есть автоматическое переключение на резервную точку монтирования при сбоях. В сумме это не просто «метрики на графиках», а замкнутый контур, который сначала снижает ущерб от сбоя, а затем информирует оператора.
Сравнение с Exchange и эффективность миграции
Если смотреть на миграцию через призму Exchange, различие в архитектуре объясняет, почему переход получается менее болезненным, чем кажется. В Exchange сервер MBX эксклюзивно работает со своей Mailbox Database, запросы не «своих» пользователей проксируются, а устойчивость строится на множественных копиях этих баз и механике DAG, который ограничен 16 узлами. В RuPost несколько узлов одновременно обслуживают один и тот же MailSpace по NFS, без эксклюзивного «владения» базой и без лимита на размер кластера. Это облегчает горизонтальное масштабирование, выравнивает нагрузку без сложной «нарезки» почтовых баз и уменьшает количество реплик, необходимых для заданного уровня доступности. Для организаций, где Exchange уже выстроен по Preferred Architecture Microsoft, переход на Preferred Architecture RuPost — это смена технологии при сохранении дисциплины проектирования HA/DR, а не перестройка процессов с нуля.
Что нового в RuPost 4.0
В версии 4.0 RuPost сделал качественный шаг в сторону геораспределенных организаций. Появился геокластер — федерация самостоятельных сайтов RuPost в разных ЦОДах под единым доменом и общей адресной книгой. Ведущий сайт содержит карту принадлежности ящиков, параметры площадок и распространяет настройки. В случае его недоступности роль можно оперативно передать другому сайту, а после восстановления «бывший лидер» автоматом принимает актуальные политики. Входящая почта принимается на любой сайт и автоматически маршрутизируется на «домашний» сайт нужного ящика. Исходящий межсайтовый трафик идет по внутренним каналам, а при разрыве — через внешние адреса площадок. Ящики можно переносить между сайтами прозрачно, включая сценарии общих ящиков, в составе которых пользователи находятся на разных площадках. Административная панель геокластера дает целостную картину статусов, а механизм принудительной подтяжки настроек после падения площадки помогает быстро вернуть консистентность.
Помимо геокластера, версия 4.0 закрывает ряд эксплуатационных задач. Появилось автоматическое переключение на горячую реплику при наличии синхронной внешней репликации со стороны хранилища, снижена память, требуемая холодной реплике, добавлены настройки максимального размера письма и дробные квоты. В ядро транспорта интегрирован собственный Milter-сервис, добавлена поддержка SPF и управляющий переключатель postscreen. На стороне клиентов внедрена Kerberos-аутентификация в SOGo с разделением с OpenID. Для автоматизации администрирования доступен HTTP API управления ящиками, обновлен редактор атрибутов глобальной адресной книги, реализована групповая политика автоподписей, упростились сценарии обновления списка «отправителей без авторизации» без полного переразвертывания. Что касается мониторинга, разработчики объявили об интеграции с Zabbix и продуктом «Группы Астра» Astra Monitoring.
Практика внедрения: подтверждение промышленной зрелости
Практика внедрений подтверждает, что эти решения работают не только на слайдах презентаций. Так, Уральский завод гражданской авиации успешно переводит массовое замещение на RuPost с MS Exchange. Детский лагерь «Артек» ушел с Exchange на отечественный сервер. Концерн «НПО “Аврора”» и холдинг «ТАГРАС» консолидировали почтовые системы на RuPost. «Мосводосток», ФГБУ «Центр Агроаналитики», Всероссийский музей декоративно-прикладного и народного искусства, авиакомпания «Якутия», «ВИЛО РУС», Администрация Пскова и крупнейшая аптечная сеть Сибири «Губернские аптеки» — это примеры из разных отраслей и масштабов, что важно для оценки применимости. Общий знаменатель у этих проектов один: сначала обследование и выбор топологии по Preferred Architecture, затем пилот и сосуществование, поэтапный перенос, отладка мониторинга и процедур switchover/failover. Никакой «магии» — инженерная дисциплина плюс инструменты, которые это поддерживают.
Геокластер: работа в распределённых организациях
С точки зрения топологий поддержаны два рабочих шаблона. Базовая «равный к равному» дает автономность каждому сайту на вход/выход из внешнего мира и межсайтовую маршрутизацию по внутренней сети при нормальном состоянии. Модель «звезда» вводит центральный сайт как единый релей для входящей/исходящей почты и централизованную точку пользовательского доступа, что упрощает контроль ИБ-политик на периметре. На уровне отдельного ЦОДа возможны и «холодный» резерв с репликациями, и метрокластер с синхронной репликацией, если есть гарантированно низкие задержки интерконнекта; для полностью автоматического failover между двумя ЦОДами понадобится третья площадка под кворум DCS — классика для распределенных консенсусов.
Рекомендации ИТ-директору
Выбор топологии диктуют требования к RPO/RTO и доступность сетевой инфраструктуры между площадками. Один кластер в одном ЦОДе подходит для консолидированных контуров с простотой эксплуатации как приоритета. Метрокластер создавать имеет смысл, когда синхронные репликации достижимы по задержкам и надежности каналов. Геокластер — правильный выбор для холдингов и распределенных сетей с общим доменом, единой адресной книгой и потребностью переносить ящики между регионами без остановки бизнеса. В любом сценарии настройка хранилищ и репликаций — зона повышенного внимания: первичные копии и большие обновления следует строить как сервер-сервер или средствами SDS/СХД, а не через клиента NFS; для кворума DCS стоит заранее предусмотреть третью площадку и протестировать отказовые режимы Patroni.