Последние года два мой отдел плотно занимается проектами миграции корпоративных почт с зарубежных сервисов в 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, поэтому важно было до них четко донести, какую из учетных записей использовать в новой системе.
На этом все. Задавайте вопросы в комментариях. И всем удачных переездов.
Комментарии (22)
BigD
13.06.2017 20:57Про ФЗ-242 интересно — кто-то реально переносит почту из-за этого? Странный кейс — почта обычно не является базой данных, не используется для сбора ПДн, поэтому по идее требование локализации не распространяется на почтовую систему.
kirillaristov
14.06.2017 03:51Мне тоже интересно, в каком случае корпоративная почта подпадает под ФЗ-242?
5000shazams
14.06.2017 10:35Информационной системой персональных данных может быть не только «база данных», а в обработку персональных данных входит не только «сбор». Часто в почтовой системе фигурируют данные сотрудников (имя, фамилия, мобильный телефон), сюда же присылают анкеты соискателей для HR, сканы документов, информацию для заказа пропусков и так далее. Поэтому, персональные данные в почтовой системе в 99% случаев есть.
Конечно, можно запретить сотрудникам делать подписи, имена ящиков сделать вида employee123@dtln.ru, удалять вложения к письмам, парсить текст письма на наличие ПДн..., но работать с такой почтовой системой будет не удобно. Лично я бы не смог :)
Кстати в том же office 365 при регистрации содержится предупреждение о том, что все будет храниться не в РФ. Наверное, не просто так.
navion
14.06.2017 00:37Из своего опыта скажу, что большие компании выбирают что-то типа Kaspersky Mail Security.
Это была ирония?VGusev2007
14.06.2017 10:11Почему ирония? Плохое решение?
navion
14.06.2017 14:02Очень неэффективное и, как любой продукт ЛК, страшно забагованное. Лучшие собаководы давно перешли на ESA/IronPort.
VGusev2007
14.06.2017 15:07Для реалий РФ, оно как? Годно?
navion
14.06.2017 15:14Про вирусы не скажу (все исполняемые файлы сразу летят в карантин), но получить смамерское письмо стало целым событием. На info что-то попадается, но там человеку не всегда понятно спам это, рассылка или письмо от реального человека.
DonAlPAtino
14.06.2017 10:52>High Availability. При отказе одного из серверов почтовые базы переедут на резервные. Конечный пользователь ничего не заметит. Эту схему можно реализовать и в рамках двух дата-центров.
Расскажите, пожалуйста, подробнее как вы в такой схеме переживаете не падение серверов (с этим-то все в порядке), а падение каналов между датацентрами, когда сервера в DAG кластерах перестают друг друга видеть. А вот клиенты, по странной стечению обстоятельств продолжают видеть все сервера.5000shazams
14.06.2017 12:41Вопрос решается кворумом: как только члены DAG перестают видеть друг друга, происходит анализ кворума. Если количество серверов DAG и свидетельских сущностей, участвующих при подсчете, набирает кворум, то площадка остается рабочей, иначе – гаснет.
PURISEG
15.06.2017 15:14Чтобы избежать Split-brain, можно расположить свидетельские сущности на третьей площадке.
DonAlPAtino
15.06.2017 21:33И при проблемах с связанностью получить размонтированные базы во всех датацентрах. При живых и рабочих серверах. Спасибо, плавали. Я вот все жду вдруг кто-нибудь что-то новое придумал. Чтобы эту конструкцию можно было без ручного присмотра оставить.
Schalker
15.06.2017 10:06Интересно. Спасибо за опыт.
Вот только вопрос «из-за бугра ».
Я понимаю почему и зачем пользователи из РФ мигрируют свои данные ( и почту ) на отечественные площадки. Правильно это.
С интересом слежу за " избавлением от Microsoft -зависимости " в России. У нас в Германии сложно с этим. Давит монополист.
Но мигрировать почтовые системы из-за бугра и загонять в российские MS — Exchange? Где логика?
LoadRunner
Интересно, насколько сложный в реализации такой кейс:
Почта для домена у mail\яндекса\gmail, у клиента — The Bat! (5 версии) на POP3, без сохранения писем на сервере. И надо всё перевести на MS Exchange.
Shtif
На самом деле на хабре уже есть статья о переносе почтовых ящиков при помощи ImapSync. Утилита умеет докачивать новые письма, так что проблем с синхронизацией быть не должно.
Некоторое время займёт создание почтовых ящиков, прописывание скрипта с паролями на синхронизацию, и в дальнейшем после подмены MX записей можно будет добрать письма, но потом обязательно убрать переносимые почтовые домены с обслуживания, так как например Яндекс использует свой DNS сервер, и после смены MX записей на хостинге он их игнорирует. Так можно потерять часть писем отправляемых с Яндекса (или настроить периодический запуск скрипта под imapsync).
Клиентская почтовая программа по большому счёту роли не играет, так как exchange умеет в POP3 и IMAP, главное чтобы сервер источник умел отдавать письма по IMAP.
LoadRunner
Вы, видимо, не до конца прочувствовали всю боль — писем на сервере нет, есть только локальная копия на компьютере, где устаревший клиент Bat, а формат его базы данных менялся. и протокол не IMAP, который допускает синхронизацию с сервером, а POP3.
Shtif
Если Bat позволяет выгружать письма в eml формат, и почтовый ящик 1, а не сотня, то это просто «выгрузить из Bat, загрузить в outlook». Для временного хранилища можно использовать общие папки, или в режиме Exchange сразу грузить всё в нужные папки. Вот если это у всех клиентов — надо уже изобретать скрипт автовыгрузки из бата, но и это в целом реализуемо с помощью 1 ПЯ с расширенными на всю базу правами.
LoadRunner
А Вы теоретизируете или в самом деле знаете, что Outlook открывает eml просто для чтения, и только через промежуточное звено в виде Express можно через IMAP пульнуть письмо на сервер?
Shtif
Попутал с .msg файлами, моя ошибка. Нашёл нечто подходящее на StackOverflow. Гугл тоже показал несколько eml2msg конвертеров разной степени доверенности.
Задачка интересная, даже обидно, что сейчас другой почтовый сервер поддерживаю, было бы интересно получить такой опыт.
dmx1024
Делал подобный перенос… Поначалу тоже думал, что ситуация тупиковая.
Решение (ручное):
1.Создаем в самом Bat-е еще один аккаунт, только IMAP, и настройками на новый сервер.
2.Создаем в новом аккаунте нужную структуру папок.
3.Вручную, небольшими частями (писем по 50-100) копируем письма между папками разных почтовых аккаунтов Bat-а.
Все!
LoadRunner
Не всё. После этого надо всем Outlook настроить. Иначе зачем Exchange.
Dobryak88
Действенный метод, переносил также.
Две потенциальные проблемы:
у пользователя POP3-аккаунт может иметь очень большой размер, а почтовый ящик на сервере — ограничения;
нагрузка на сеть и вычислительные ресурсы почтового сервера.
IMHO, первая наиболее критична для почты на хостинге; на второй проблеме споткнулся при «переезде» с POP3 на IMAP почтового ящика объёмом более 20 ГБ на внутреннем почтовом сервере, который не справился с таким объёмом.