Последние года два мой отдел плотно занимается проектами миграции корпоративных почт с зарубежных сервисов в MS Exchange базе инфраструктуры наших дата-центров. Из облачных сервисов типа Office 365, Gmail в основном мигрируют из-за ФЗ-242, так как хотят, чтобы почта жила на российской инфраструктуре. Это не единственная причина: часть компаний после миграции целиком передает нам почтовую систему на администрирование под жесткий SLA, что не всегда можно получить в массовых сервисах. Те, у кого почта раньше жила на железе и кто хочет расширяться, не связываясь с покупкой нового оборудования, также обращаются к нам, скромному российскому облачному провайдеру.

На 27 проектах миграции и 50 тыс. перенесенных ящиков бывало всякое. Сегодня хочу рассказать, что нужно учесть и продумать, если собрались переезжать.

Что хотите получить на выходе

Перед стартом проекта согласовываем с провайдером следующие моменты:

• функциональность, которую ожидаете получить от новой почтовой системы: объем трафика, календари, UM, общие папки и пр.
• доступность на этапе миграции и после. Готовы ли вы на простои? Если да, то в каком объеме и когда? На какую доступность рассчитываете после миграции, когда ваши пользователи будут работать с новой системой?
• какие бизнес-процессы завязаны на почтовую организацию: работа службы поддержки, маркетинговые рассылки и пр.
• с какими решениями нужно интегрировать (1C, Sharepoint, Skype и пр.). Был случай, когда ИТ-менеджер стартовал миграцию почты из Lotus в Exchange, и на полдороге выяснилось, что у них есть еще и корпоративный портал, завязанный на Lotus. Переезжать на новый портал они не планировали, поэтому свернули миграцию, а непредусмотрительного менеджера уволили.
• примерные сроки миграции. Даже если все правильно посчитать с учетом объемов данных, которые нужно перенести на новую площадку, обязательно всплывут непредвиденные технические ограничения: канал связи окажется медленнее, чем ожидалось, или обнаружатся лимиты на экспорт данных из исходной почтовой системы.

С последним мы столкнулись, когда перевозили клиента из Gmail. В процессе выяснилось, что за сутки можно экспортировать не более 1,5 ГБ данных. Даже если ящик был всего на 2 ГБ, то его приходилось экспортировать два дня – 1,5 ГБ, потом сутки ждем и докачиваем оставшиеся 500 ГБ. Перенос ящиков на 20 ГБ занимал почти два недели.
Пока все экспортировалось небольшими порциями, жизнь в компании не останавливалась и приходила новая почта, которую тоже нужно синхронизировать с новой площадкой. Проблему удалось решить с помощью утилиты Cloudiway: она вытягивала все содержимое ящиков с учетом суточного лимита, т.е. нам не приходилось вручную раз в сутки выкачивать разрешенные 1,5 ГБ. Затем вытягивала дельту писем, которые падали за то время, пока она тянула основной объем. Со временем дельта все уменьшалась и уменьшалась, и после того как все данные из исходного ящика были перенесены, мы переключали пользователя на работу с целевой почтовой системой.

Еще одна “черная дыра”, куда уходит куча проектного времени, – взаимодействие между участниками проекта. Особенно если их больше двух.

Клиент мигрировал с зарубежного хостинга, и цепочка взаимодействия выглядела следующим образом: мы общались с проект-менеджером заказчика, он передавал наши сообщения ИТ-департаменту, который взаимодействовал с зарубежным хостинг-провайдером Exchange. Как-то нам нужно было включить MPC-proxy (служба, обеспечивающая перемещение почтовых ящиков во время миграции) на зарубежной площадке, и это заняло две недели.

На старте всегда озвучивают очень оптимистичные сроки. Будьте реалистами и смело умножайте первоначальную оценку на два.

Аудит существующей инфраструктуры

Здесь все просто: нужно проанализировать исходную почтовую систему и понять, что у нее со следующими параметрами:

• входящий и исходящий объем SMTP-трафика;
• количество и суммарный объем почтовых ящиков;
• количество конечных пользователей;
• расположение клиентов: они могут подключаться изнутри сети и снаружи сети, с доменных или недоменных машин;
• протоколы клиентских подключений и версии клиентов (MacOS-клиент, Outlook Anywhere, POP3, IMAP, ActiveSync);
• текущая конфигурация почтовой системы:
  — количество SMTP-доменов организации;
  — количество групп рассылок;
  — наличие ящиков большого размера (от 20 ГБ);
  — наличие сервисных ящиков (для 1С, сканеров, рассылок);
  — массовые рассылки.

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

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

Архитектура почтовой системы

Выбор архитектуры MS Exchange будет зависеть от требований к доступности. Вариантов два:

Stand alone. Все почтовые ящики располагаются на одном сервере. Этот вариант – не про высокую доступность, зато про низкую стоимость. На уровне приложения резервирования нет. Если на других уровнях (например, виртуализация) резервирования тоже нет, то при сбое Exchange будет недоступен.
Такая архитектура подойдет, если у вас немного ящиков и вас устроит восстановление из бэкапа.

High Availability. Все роли почтовой системы дублируются. Серверы MailBox (на схеме – MBX) добавляются в группу высокой доступности (Database Availability Group, DAG). При отказе одного из серверов почтовые базы переедут на резервные. Конечный пользователь ничего не заметит. Эту схему можно реализовать и в рамках двух дата-центров. Тогда почтовой системе не будет страшен выход из строя целого ЦОДа.
Эта архитектура – для тех компаний, для которых неприемлем простой. Чаще всего это большие компании.

Схема HA.

Выбор антиспам/антивирус-решения

Из своего опыта скажу, что большие компании выбирают что-то типа Kaspersky Mail Security. Небольшие проекты обычно пользуются встроенными антивирус- и антиспам-решениями. Они могут быть не такими удобными или функциональными, как сторонние решения, но свою задачу они тоже хорошо выполняют. Никто особо не жаловался еще).

Сайзинг почтовой системы

Вопрос не стоит, если новая система – полный клон старой и мы ничего не планируем в ней менять. Для остальных случаев придется посчитать ресурсы. У MS есть инструмент (на самом деле просто excel-табличка с кучей параметров:)), с помощью которого можно просчитать объем ресурсов для инсталляции Exchange – Microsoft Exchange Sizing Calculator. Сразу скажу, что инструмент не интуитивный и потребует времени, чтобы разобраться, но это неплохой вариант, если за плечами нет опыта сайзинга подобных проектов.
При расчете не забываем делать поправку на то, что почтовая система будет бэкапиться, а значит скорость бэкапа будет в том числе зависеть от типа используемых дисков. Если планируете использовать антивирус, который будет проверять базу онлайн, то логичнее выбрать SAS-диски, но, конечно, выбор типа дисков должен базироваться на анализе реальной нагрузки на систему.
Так как миграция происходит не одномоментно, особенно для больших компаний, нужно предусмотреть возможность масштабирования инфраструктуры под почту (в одном проекте за время миграции численность пользователей успела вырасти в 2 раза – было 1000, стало 2000). Если под систему используются виртуальные ресурсы, то это сделать проще.

Способ миграции

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

При сutover-миграции вся почтовая система переносится на новую площадку целиком за одну итерацию. Этот вариант можно рассматривать, если у вас небольшая почтовая система (до 500 ГБ) и вы согласны на простой от нескольких часов. Сама миграция будет быстрой: если удачно запланировать техокно, то можно переехать за выходные или даже быстрее, с минимальными неудобствами для бизнеса.

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

План миграции, инструкции, регламенты

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

• архитектура исходной и конечной систем;
• техокна и длительность простоя;
• собственно порядок действий по миграции.

Если участников в проекте много, то прописываем процедуры административного взаимодействия и зоны ответственности. Не обязательно, чтобы это была официальная бумага с подписью и печатью на каждой странице. Можно просто в письме договориться о том, кто и за что отвечает, как строится взаимодействие с третьими сторонами (DNS-хостер, облачный провайдер) и пр.

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

В одном из проектов миграции из Office 365 в Exchange была следующая ситуация. На исходной системе у пользователей была две учетки – для входа на компьютер (AD-учетка) и для входа в почту, в Office 365. После миграции должна была остаться одна учетная запись. Пользователей было около 600, поэтому важно было до них четко донести, какую из учетных записей использовать в новой системе.

На этом все. Задавайте вопросы в комментариях. И всем удачных переездов.

https://habrahabr.ru/post/330756/