Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Заказчик понял, что в связи с последними событиями можно ожидать внезапного окончания сервиса в облаке MS для всей компании. Если бы там крутилась только почта, то проблем бы не было: есть очень много опенсорсных или OS-based решений российской разработки. Но кроме самой почты ещё были календари, согласования, брони переговорок, общие ящики, сложные права доступа на отпуска и все прочие вещи. Нужно было сохранить не только почту, но и все процессы Exchange, с которыми работала компания, потому что они были глубоко в её бизнес-процессах.
И заказчик выбрал Exchange 2019 в частном облаке. Знаю, звучит странновато, но это реальность: лицензии уже были, стек знакомый, ресурсы выделены, а максимум, что сделает MS в такой ситуации — это лишит поддержки. Что заказчику не угрожало, потому что официальной поддержки его уже лишили. Мы поддерживали его вместо MS.
Вот эти согласования документов, интегрированные с почтой — одна из причин переезда с MS на MS
В общем, дальше надо было просто взять и переехать так, чтобы сотрудники компании это не почувствовали. И здесь было несколько подводных камней. Началось с того, что MS, видимо, не рассматривала в принципе это направление миграции: O365->On-prem просто не покрыт документацией, а в интерфейсе новой консоли серенький и неактивный в духе «under construction». Ну и сами ящики оказались не очень маленькими: при нормальной подписке ящик получает лимит до 100 Гб, и пользователи уверенно заполнили их примерно до 40-50 Гб каждый. После того как за неделю непрерывной синхронизации мы мигрировали три ящика, стало понятно, что с этим надо что-то делать.
Развернули четыре виртуальные машины на Windows Server 2019 Standard и установили следующие роли Exchange 2019: две штуки Exchange CAS/Mailbox и две штуки Exchange Edge Transport. CAS/Mailbox — это, собственно, штуки, которые несут основную почтовую функцию, а EDGE — это сервера, которые принимают обращения клиентов из DMZ и передают мейлбоксам. 2+2 — это рекомендованная схема, которая обеспечивает достаточную отказоустойчивость и балансировку. EDGE просто переключаются или передают друг другу сессии в случае проблем, а между мейлбоксами идёт репликация баз, и, если один ложится, можно переподключиться к другому инстансу, что и сделает один из EDGE с пользователем. Кроме всего прочего, это означает, что сервера можно обслуживать без выключения сервиса.
Соответственно, на серверах с ролью CAS/Mailbox настроен кластер DAG. Для миграции почты и одновременной работы пользователей в Exchange Online и On-Premise Exchange была настроена конфигурация Exchange Hybrid. DAG – это балансировщик между мейлбоксами, а Hybrid — решение, чтобы одновременно в своей инфраструктуре было видно и облако, и локальное решение. Это нужно, чтобы Active Directory не было разницы, где лежат объекты. То есть во время переезда учётки пользователей лежали в локальной AD, а почтовые ящики — половина в облаке, половина на локальном сервере.
Канал до облака MS у нас был 1 Гб/с. Но политика миграции у MS очень простая: любые подобные действия не должны замедлять работу системы для пользователей. То есть синхронизацию можно выполнять только с той скоростью, которую разрешает MS, а это не очень-то много. По факту у меня получалось около 30-40 Гб в день, что очень быстро стало проблемой из-за размеров пользовательских ящиков.
Достать пользовательские ящики чем-то другим без особых затрат тоже не представлялось возможным: наложенные средства бэкапа упрутся примерно в те же ограничения (или будут прерывать сервис пользователям), а собственные снапшоты MS делает в теневом виде, и снаружи к ним доступа просто нет.
При переносе ящика из облака в локальное хранилище, грубо говоря, создаётся его копия у нас на инсталляции, а затем Hybrid меняет адресацию на локальное хранилище. Пользователь ничего не замечает, перенастраивать на рабочих местах ничего не нужно, загрузки на поддержку внутри компании нет.
Проблема в медленном переносе. При таких объёмах почты он грозил затянуться на несколько месяцев. И если месяц фоновой синхронизации ещё как-то более-менее нормально смотрится, то полгода — это уже совсем перебор. Нужно было что-то делать с почтой, то есть как-то почистить ящики.
Пользователи ещё до миграции единогласно сказали, что в почтовых ящиках нет ни одного сообщения, которое можно было бы безболезненно удалить. Лукавили, конечно, но это легло в условия задачи. Соответственно, вариант «удалить старую почту» или «удалить сообщения по фильтру» сразу отпадал.
Второй предложенный вариант был в том, чтобы собрать по рабочим станциям локальные PST, положить их в общую файлопомойку в виде архива и не переносить то, что в них было. То есть мы бы получили некий медленный бэкап почты, но, чтобы получить доступ к какому-то старому письму, нужно было бы подключать PST к Outlook и ковыряться в нём. Этот вариант заказчику тоже не понравился. После некоторых размышлений пришли к тому, что можно сохранять в архив и сжимать всю почту, кроме как за последний год: то есть, например, если ящик жил шесть лет, то пять лет мы кладём в локальный архив, а последний год переносим вживую.
В итоге мы решили архивировать ящики таким образом, а также максимально их порезать в плане технических данных. Если что, MS хранит очень много удалённых писем, причём как тех, которые видны пользователю в корзине, так и просто всех удалённых за всю историю ящика на случай, если админу понадобится залезть в бэкап. Можно ограничить таймер, например, поставить хранение на 14 дней: после того, как из «распухшего» ящика будет что-то удалено, он будет «распухшим» ещё эти самые 14 дней.
Собственно, мы отключили «SingleItemRecoveryEnabled» и установили время хранения удалённых элементов «RetainDeletedItemsFor» до ноля (пока это не ноль, будет теневая копия ящика, по сути). Плюс включили сжатие. Это позволило уменьшить размер почтовых ящиков для переноса в десять и более раз.
Началось всё просто, с Read-Only контроллера на стороне заказчика. Домен-контроллеры почему-то были только в режиме Read-Only (RODC), видимо, так они достаются из коробки в каких-то инсталляциях (хотя я такое вижу первый раз). Один из контроллеров домена был конвертирован в RWDC, делов-то.
Вторая особенность: при базовой настройке Exchange Hybrid есть проблема с основными SMTP-адресами групп рассылок и части пользователей. Синхронизация делается с помощью Azure AD Connect. Это синхронизирует локальный AD с Office (облаком), чтобы все параметры передавались в обе стороны. Один из основных параметров для корректной синхронизации SMTP “proxyaddresses”. У части пользователей и групп рассылок данный параметр заполнен не был, и при первой синхронизации после настройки Exchange Hybrid для данных пользователей был изменен основной SMTP-адрес на адрес организации Azure AD по умолчанию (company.onmicrosoft.com). А он не соответствует реальному, то есть пока не поправили проблемным пользователям, из локальной инфраструктуры не доходила почта до облачных пользователей.
Теперь самая мякотка. Так как обратную миграцию пользователей из Office365 на On-Premise Exchange MS, по всей видимости, не предполагал (никакой документации на этот счёт нет), то возникла проблема, как связать уже существующих пользователей, групп рассылок, общие почтовые ящики и календари в Exchange Online c On-Premise Exchange.
Собственно, вот так это место выглядит в новой консоли:
Пункт серый: как бы формально он есть, но воспользоваться нельзя
Делалось этой повершеллом за один раз. При переходе из новой консоли в классическую консоль уже есть функция миграции.
Был выгружен полный список почтовых ящиков пользователей из Exchange Online и на их основе созданы объекты RemoteMailbox на On-Premise Exchange.
Часть групп рассылок уже была синхронизирована с локальным AD заказчика, для них также были созданы объекты на On-Premise Exchange. Были группы, которые существовали только в облаке. Для таких групп создали аналогичные группы в AD и накатили настройки идентичные облачным. После синхронизации группы из локального AD объединили с облачными. Аналогичным образом настроили календари для того, чтобы пользователи в облаке видели информацию календарей пользователей на локальном Exchange и наоборот. После приведения локального Exchange в соответствие c Exchange Online заказчика, смигрировали часть пользователей на локальный Exchange. Пользователи в облаке и локальном Exchange могут спокойно обмениваться почтой друг с другом, а также принимать и отправлять почту наружу прямо во время процесса.
Развернули инфраструктуру в частном облаке, которая даёт какие-то гарантии того, что сервис будет спокойно работать в наше сложное время. Потом начали миграцию: устаревшие данные перенесли в локальные PST с архивацией на стороне клиента.
В общей сложности у заказчика около 1500 ящиков, всего около 15 Тб данных после сжатия—архивирования—удаления удалённых. То есть проект не просто не маленький, а очень здоровенный, но при этом службе поддержки со стороны заказчика практически не пришлось взаимодействовать с пользователями. Опыт очень интересный, учитывая общую кровавость энтерпрайза. Если кому-то понадобится, полный инструментарий уже есть.
И заказчик выбрал Exchange 2019 в частном облаке. Знаю, звучит странновато, но это реальность: лицензии уже были, стек знакомый, ресурсы выделены, а максимум, что сделает MS в такой ситуации — это лишит поддержки. Что заказчику не угрожало, потому что официальной поддержки его уже лишили. Мы поддерживали его вместо MS.
Вот эти согласования документов, интегрированные с почтой — одна из причин переезда с MS на MS
В общем, дальше надо было просто взять и переехать так, чтобы сотрудники компании это не почувствовали. И здесь было несколько подводных камней. Началось с того, что MS, видимо, не рассматривала в принципе это направление миграции: O365->On-prem просто не покрыт документацией, а в интерфейсе новой консоли серенький и неактивный в духе «under construction». Ну и сами ящики оказались не очень маленькими: при нормальной подписке ящик получает лимит до 100 Гб, и пользователи уверенно заполнили их примерно до 40-50 Гб каждый. После того как за неделю непрерывной синхронизации мы мигрировали три ящика, стало понятно, что с этим надо что-то делать.
Как делали
Развернули четыре виртуальные машины на Windows Server 2019 Standard и установили следующие роли Exchange 2019: две штуки Exchange CAS/Mailbox и две штуки Exchange Edge Transport. CAS/Mailbox — это, собственно, штуки, которые несут основную почтовую функцию, а EDGE — это сервера, которые принимают обращения клиентов из DMZ и передают мейлбоксам. 2+2 — это рекомендованная схема, которая обеспечивает достаточную отказоустойчивость и балансировку. EDGE просто переключаются или передают друг другу сессии в случае проблем, а между мейлбоксами идёт репликация баз, и, если один ложится, можно переподключиться к другому инстансу, что и сделает один из EDGE с пользователем. Кроме всего прочего, это означает, что сервера можно обслуживать без выключения сервиса.
Соответственно, на серверах с ролью CAS/Mailbox настроен кластер DAG. Для миграции почты и одновременной работы пользователей в Exchange Online и On-Premise Exchange была настроена конфигурация Exchange Hybrid. DAG – это балансировщик между мейлбоксами, а Hybrid — решение, чтобы одновременно в своей инфраструктуре было видно и облако, и локальное решение. Это нужно, чтобы Active Directory не было разницы, где лежат объекты. То есть во время переезда учётки пользователей лежали в локальной AD, а почтовые ящики — половина в облаке, половина на локальном сервере.
Канал до облака MS у нас был 1 Гб/с. Но политика миграции у MS очень простая: любые подобные действия не должны замедлять работу системы для пользователей. То есть синхронизацию можно выполнять только с той скоростью, которую разрешает MS, а это не очень-то много. По факту у меня получалось около 30-40 Гб в день, что очень быстро стало проблемой из-за размеров пользовательских ящиков.
Достать пользовательские ящики чем-то другим без особых затрат тоже не представлялось возможным: наложенные средства бэкапа упрутся примерно в те же ограничения (или будут прерывать сервис пользователям), а собственные снапшоты MS делает в теневом виде, и снаружи к ним доступа просто нет.
Проблема с размером ящиков
При переносе ящика из облака в локальное хранилище, грубо говоря, создаётся его копия у нас на инсталляции, а затем Hybrid меняет адресацию на локальное хранилище. Пользователь ничего не замечает, перенастраивать на рабочих местах ничего не нужно, загрузки на поддержку внутри компании нет.
Проблема в медленном переносе. При таких объёмах почты он грозил затянуться на несколько месяцев. И если месяц фоновой синхронизации ещё как-то более-менее нормально смотрится, то полгода — это уже совсем перебор. Нужно было что-то делать с почтой, то есть как-то почистить ящики.
Пользователи ещё до миграции единогласно сказали, что в почтовых ящиках нет ни одного сообщения, которое можно было бы безболезненно удалить. Лукавили, конечно, но это легло в условия задачи. Соответственно, вариант «удалить старую почту» или «удалить сообщения по фильтру» сразу отпадал.
Второй предложенный вариант был в том, чтобы собрать по рабочим станциям локальные PST, положить их в общую файлопомойку в виде архива и не переносить то, что в них было. То есть мы бы получили некий медленный бэкап почты, но, чтобы получить доступ к какому-то старому письму, нужно было бы подключать PST к Outlook и ковыряться в нём. Этот вариант заказчику тоже не понравился. После некоторых размышлений пришли к тому, что можно сохранять в архив и сжимать всю почту, кроме как за последний год: то есть, например, если ящик жил шесть лет, то пять лет мы кладём в локальный архив, а последний год переносим вживую.
В итоге мы решили архивировать ящики таким образом, а также максимально их порезать в плане технических данных. Если что, MS хранит очень много удалённых писем, причём как тех, которые видны пользователю в корзине, так и просто всех удалённых за всю историю ящика на случай, если админу понадобится залезть в бэкап. Можно ограничить таймер, например, поставить хранение на 14 дней: после того, как из «распухшего» ящика будет что-то удалено, он будет «распухшим» ещё эти самые 14 дней.
Собственно, мы отключили «SingleItemRecoveryEnabled» и установили время хранения удалённых элементов «RetainDeletedItemsFor» до ноля (пока это не ноль, будет теневая копия ящика, по сути). Плюс включили сжатие. Это позволило уменьшить размер почтовых ящиков для переноса в десять и более раз.
Ещё подводные камни
Началось всё просто, с Read-Only контроллера на стороне заказчика. Домен-контроллеры почему-то были только в режиме Read-Only (RODC), видимо, так они достаются из коробки в каких-то инсталляциях (хотя я такое вижу первый раз). Один из контроллеров домена был конвертирован в RWDC, делов-то.
Вторая особенность: при базовой настройке Exchange Hybrid есть проблема с основными SMTP-адресами групп рассылок и части пользователей. Синхронизация делается с помощью Azure AD Connect. Это синхронизирует локальный AD с Office (облаком), чтобы все параметры передавались в обе стороны. Один из основных параметров для корректной синхронизации SMTP “proxyaddresses”. У части пользователей и групп рассылок данный параметр заполнен не был, и при первой синхронизации после настройки Exchange Hybrid для данных пользователей был изменен основной SMTP-адрес на адрес организации Azure AD по умолчанию (company.onmicrosoft.com). А он не соответствует реальному, то есть пока не поправили проблемным пользователям, из локальной инфраструктуры не доходила почта до облачных пользователей.
Теперь самая мякотка. Так как обратную миграцию пользователей из Office365 на On-Premise Exchange MS, по всей видимости, не предполагал (никакой документации на этот счёт нет), то возникла проблема, как связать уже существующих пользователей, групп рассылок, общие почтовые ящики и календари в Exchange Online c On-Premise Exchange.
Собственно, вот так это место выглядит в новой консоли:
Пункт серый: как бы формально он есть, но воспользоваться нельзя
Делалось этой повершеллом за один раз. При переходе из новой консоли в классическую консоль уже есть функция миграции.
Был выгружен полный список почтовых ящиков пользователей из Exchange Online и на их основе созданы объекты RemoteMailbox на On-Premise Exchange.
Часть групп рассылок уже была синхронизирована с локальным AD заказчика, для них также были созданы объекты на On-Premise Exchange. Были группы, которые существовали только в облаке. Для таких групп создали аналогичные группы в AD и накатили настройки идентичные облачным. После синхронизации группы из локального AD объединили с облачными. Аналогичным образом настроили календари для того, чтобы пользователи в облаке видели информацию календарей пользователей на локальном Exchange и наоборот. После приведения локального Exchange в соответствие c Exchange Online заказчика, смигрировали часть пользователей на локальный Exchange. Пользователи в облаке и локальном Exchange могут спокойно обмениваться почтой друг с другом, а также принимать и отправлять почту наружу прямо во время процесса.
Итого
Развернули инфраструктуру в частном облаке, которая даёт какие-то гарантии того, что сервис будет спокойно работать в наше сложное время. Потом начали миграцию: устаревшие данные перенесли в локальные PST с архивацией на стороне клиента.
В общей сложности у заказчика около 1500 ящиков, всего около 15 Тб данных после сжатия—архивирования—удаления удалённых. То есть проект не просто не маленький, а очень здоровенный, но при этом службе поддержки со стороны заказчика практически не пришлось взаимодействовать с пользователями. Опыт очень интересный, учитывая общую кровавость энтерпрайза. Если кому-то понадобится, полный инструментарий уже есть.
