Миграция информационных систем — стандартная процедура для ИТ-специалистов. Тем не менее, при миграции инженеры сталкиваются со множеством проблем: в случае с корпоративной почтовой системой — от риска потери уже существующей корреспонденции до страха менять то, что работает.

МойОфис разрабатывает сразу два корпоративных почтовых решения: «МойОфис Почта 2», с поддержкой до 30 тыс. пользователей, а также Mailion — почту нового поколения на Cloud Native микросервисной архитектуре с одновременной поддержкой до 1 млн пользователей. Оба продукта можно развернуть на серверах организации (частное облако) или на базе инфраструктуры доверенного партнера.

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

Привет, Хабр! Меня зовут Андрей Колесников, в МойОфис я отвечаю за внедрение продуктов компании в инфраструктуру клиентов. Более 10 лет я занимаюсь сопровождением критических бизнес-систем, 5 из них — в компании МойОфис.

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

• реализация проектов цифровой трансформации или, проще говоря, импортозамещение;
  оптимизация систем и ресурсов;
• расширение функциональных возможностей;
• экономия средств (на лицензиях, аппаратных мощностях, затратах на эксплуатацию).

Ниже я рассмотрю основные этапы миграции и подробно опишу три сценария миграции на примере почтовых систем.

Основные этапы миграции

1. Обследование и анализ. На этом этапе мы проводим функциональное тестирование новой системы. Разбираемся в её инфраструктурных особенностях, интеграционных возможностях, инструментах администрирования, утилитах миграции данных.
2. Внедрение новой системы. Подготавливаем ландшафт, выделяем ресурсы и занимаемся инсталляцией нового сервиса в целевой конфигурации.
3. Следующий этап опционален. Это обеспечение сосуществования двух информационных систем, в нашем случае — почтовых серверов. Для этого необходимо (при наличии технической возможности) настроить системы так, чтобы пилотная группа пользователей могла работать в новой системе или иметь возможность параллельной работы в двух системах.
4. Миграция данных. Решение о необходимости переноса накопленной информации принимается индивидуально. Этот этап сопряжен с дополнительными рисками, как и любые операции по переносу данных. Если мы приняли решение о переносе информации, то разрабатываются собственные или используются проприетарные инструменты миграции. Как правило, они существуют в симбиозе.
5. Переключение на новую информационную систему. Счастье! Мы перевели всех пользователей на новую платформу и начинаем использовать новые возможности.

Сценарии миграции

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

Сценарий №1: «Всё, что было в Вегасе — остается в Вегасе»

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



Мы настраиваем новый почтовый сервис на домене my.ru, на отдельной машине с уникальным IP-адресом. Добавляем MX-запись для второго сервиса в DNS.

Теперь системы работают параллельно на разных доменах:





Таким образом, без дополнительных усилий мы обеспечиваем параллельное функционирование двух почтовых систем.



В установленный день происходит отключение сервера на домене hi.ru.



Это наименее трудоемкий вариант. Такой подход, как правило, используется в организациях с небольшой численностью сотрудников. Перенос корреспонденции можно выполнить массово или делегировать сотрудникам персонально. Это делается с помощью локальных архивов, копирования данных в почтовом клиенте, плагинов и других вариантов. Здесь бывает удобно использовать в качестве нового домена — домен третьего уровня. Например, @hоlding.hi.ru.

Сценарий №2: Вариации

На начальном этапе мы поступаем по аналогии с первым сценарием. Рядом устанавливаем почтовый сервер для нового домена (mail.my.ru).



Как правило, доступ пользователей к серверу, который выводится из эксплуатации (mail.hi.ru), закрывается административно, на нем настраивается пересылка всей почты на аналогичные ящики на новом сервере (andrey.kolesnikov@hi.ru --> andrey.kolesnikov@my.ru). Могут быть и другие варианты. Можно настроить автоответ пользователям, которые продолжат писать на более не используемый домен (@hi.ru). В письме может содержаться актуальный почтовый адрес. Сервер, который более не используется, может функционировать в течение долгосрочного периода, а впоследствии быть остановленным.

Сценарий №3: «Сообщающиеся сосуды»

Наиболее востребованный вариант миграции — это миграция с сохранением почтового домена (в нашем примере: hi.ru). Можно, конечно, сообщить в один день, что теперь компания использует новую систему, и переключиться на нее. Но нужно учитывать, что все новое вызывает вопросы, а чем больше людей — тем больше вопросов. Последствия могут быть плачевными и даже привести к остановке работы компании.

В целях митигации этого риска используется технология миграции на новую систему постепенно, пилотными группами с параллельным сосуществованием двух почтовых систем. То есть когда часть людей продолжает использовать прежний почтовый сервер, а часть переводится на новый сервис. Пользовательские возможности при этом не ограничиваются. Внутренняя и внешняя переписка происходят в рамках одного домена (@hi.ru). Назовем такой сценарий «сообщающиеся сосуды».

Настраиваем оба почтовых сервера на работу с адресами @hi.ru. MX-запись в DNS не меняем, она остается прежней:



То есть внешняя почта будет приходить на текущий сервер («Сервер 1» на схеме ниже). На нем же письма будут обрабатываться в соответствии с правилами и пересылаться на новый сервер («Сервер 2»). Основная настройка производится посредством транспортных правил, smtp-коннекторов, списков пересылки и списков доступа. Настройка «сообщающихся сосудов» для разных почтовых систем — тема для отдельной статьи, возможно, в будущем мы напишем об этом подробнее. Вот одна из Хабр-статей о переезде с Microsoft Exchange.



Обобщая, «Сервер 1» имеет список пользователей, которые переведены на «Сервер 2». После получения письма «Сервер 1» обрабатывает его и оставляет для локального использования или пересылает на «Сервер 2». На «Сервере 2» также есть список пользователей, которые обслуживаются локально. Если пользователя нет в этом списке, то письмо отправляется на «Сервер 1».



Администратор переводит пользователей с «Сервера 1» на «Сервер 2» по группам. Когда все пользователи будут переведены, «Сервер 1» более не используется, его выключают. В этот момент меняется А-запись в DNS для mail.hi.ru на IP-адрес «Сервера 2».

Миграция данных

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

Учетные записи

Большинство современных информационных систем поддерживает интеграцию со службами каталогов. Мы рассматриваем миграцию на продукт «МойОфис Почта 2». Наша система имеет возможность интеграции с Active Directory, сторонними службами каталогов, поэтому при использовании сторонних служб достаточно произвести настройку интеграции. При этом данные об аккаунтах продолжат храниться в корпоративном каталоге. Если необходимо завести новых пользователей по списку, то это реализуется посредством API продукта. Есть и другие варианты, например, частный случай: RedHat sync utility Directory Server with Active Directory, ПО для синхронизации данных Red Hat Directory Server с Active Directory. Также никто не отменял старый добрый импорт/экспорт в LDIF.

Электронные сообщения

Основной объем работ по миграции данных приходится на письма. Существует несколько подходов к переносу информации. Первый — на файловом уровне. Мы можем скопировать данные из файловой системы любым доступным способом. Например, посредством rsync. Второй — при помощи MDA. В случае c Dovecot используется встроенный механизм dsync. Есть ряд кастомизированных утилит для переноса данных с различных почтовых решений:

• GMail Migration Feature
• Courier
• Cyrus

Если форматы хранения писем в системах различаются (maildir, mbox, dbox, другие), то используются конвертеры. Несколько примеров доступны по ссылке.

Мы используем ряд собственных утилит, например, при конвертации из PST-файлов. Третий подход к миграции данных широко распространен и является наиболее универсальным. Это миграция по протоколу IMAP. Самый популярный инструмент — imapsync . Есть и аналоги — например, imapcopy.

Адресная книга и календари

В веб-интерфейсе продукта «МойОфис Почта 2» есть возможность импорта календарей из Exchange. В иных случаях прорабатывается индивидуальный план миграции. Сервис функционирует по протоколу CalDAV. Адресная книга — это отдельный каталог LDAP. Здесь применимы вышеописанные варианты с учетными записями: встроенный функционал продукта, сторонние утилиты, импорт/экспорт LDIF.

Проблемы миграции

Практически у каждой задачи есть решение, иногда несколько. Одни решения требуют продолжительного исследования, другие дополнительного времени. В процессе работы мы сталкиваемся со стеком проблем. Одна из них — миграция большого объёма данных. В данном случае процесс упирается в производительность и ограничение полосы пропускания сети инфраструктуры. Это увеличивает время работ. Тут же встает вопрос об инкрементальной синхронизации. Ее время играет особую роль на этапе переключения на новую систему, так как это время напрямую связано с простоем сервиса. Ряд нюансов кроется в поддержке непрерывности работы двух почтовых сервисов.

Не для всех почтовых решений существуют готовые сценарии, что требует выделения ресурсов на разработку и отладку инструментов. Каждый проект уникален, имеет свои инфраструктурные особенности. Нередко смена одной информационной системы тянет за собой ряд интеграционных проблем с другой системой. В данном случае обновление почтового сервера будет одной из частей более крупного проекта по цифровизации. Это говорит о выделении большего объема ресурсов. Еще одна распространенная причина неприятия изменений — это страх менять то, что работает. Но тут у каждого свои рецепты преодоления: обучение, открытость к инновациям, умение найти компромисс. Как говорится, семь раз plan, один apply :)

Заключение

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

Миграция почтовых систем — вполне понятный, а в нашей компании еще и максимально безопасный процесс. Если у вас есть интерес к внедрению приложений различных классов, если сложная задача для вас — вызов, и вы хотите сделать свой вклад в развитие цифровых технологий, то приходите работать в МойОфис. Мы открыли набор и расширяем профессиональный штат инженеров внедрения.