Exchange Server 2019: Предпочитаемая архитектура.

Начиная с 2013 года для каждой "on-premises" версии Exchange Microsoft выпускает документ "Preferred Architecture", где делится советами о том как правильно "готовить" почтовую систему с точки зрения продуктовой команды. Документ сосредоточен на общих архитектурных моментах и с одной стороны основывается на здравом смысле, а с другой на корпоративных интересах компании Microsoft и продуктовой команды в частности. Советую воспринимать все, что там говорится через призму собственного опыта и собственных интересов. В рамках данной статьи мы разберем новый релиз предпочитаемой архитектуры.

Очень важный момент, который надо понимать - "Preferred Architecture" отталкивается от того, что у вас тысячи, а точнее десятки тысяч почтовых ящиков и несколько датацентров. Для ваших 200-500-1000 ящиков у них давно один ответ - "идите в Office 365". Поэтому если вы администрируете "Small Businesss" на 800 ящиков с одним сервером (а может и двумя-тремя), то все, что в "Preferred Architecture" безумно интересно, но в массе своей слабо применимо.

Часть 1. Пространство имен.

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

Для схемы с двумя датацентрами предлаются следующие варианты:

Bound namespace - в нем используются разные DNS имена для подключения к разным датацентрам. Т.е клиент подключается по DNS имени той площадки, где сейчас активна копия его базы данных. А копии как вы понимаете есть в каждом датацентре. Если активная копия переедет в другой датацентр, то все клиенты с ящиками в этой базе постепенно поменяют имя подключения на имя которое прописано для серверов в датацентре с активной в данный момент копией.
Unbound namespace - второй вариант с одним DNS именем и он же предпочитаемый. Общее имя для обоих датацентров, которое балансируется средствами DNS за счет нескольких записей и технологии DNS Round Robin. В таком случае клиент может подключиться к любой площадке и если подключение произошло туда, где нет активной копии, то клиентское подключение будет проксироваться в другую площадку. Это естественно рождает дополнительный трафик между площадками.

Вариант unbound хорош тем, что вы держите две площадки в режиме боеготовности Active - Active и всегда быстро поймете, когда что-то пойдет не так на одной из площадок. Но иногда нужен сценарий Bound namespace, т.к серверы могут быть разделены кабелем, лежащим на дне океана. В таком случае лишний проксирующий трафик не очень желателен, а высокая задержка при подключении в Москву через Сан Франциско может не понравиться пользователям.

Как и ранее рекомендуется DNS балансировка и разделение имен - отдельное имя для отдельного протокола:

• Для autodiscover service: autodiscover.contoso.com

• Для HTTP clients: mail.contoso.com

• Для IMAP clients: imap.contoso.com

• Для SMTP clients: smtp.contoso.com

В небольших инсталяциях такое дробление имен подключений делается крайне редко, поскольку смысла в этом особого нет, но "Preferred Architecture" ориентируется не на "небольшие инсталяции", отсюда и соответствующие рекомендации.

Пара слов про аппаратные балансировщики. Компании Kemp, Citrix, F5, Radware были и никуда не делись, их оборудование по прежнему покупают и используют вместе с Exchange. Делается это во многом из за желания получить дополнительный функционал. Что бы не рассказывать про банальный SSL-Offloading можно привести в пример функционал Permitted Groups, где вы можете ограничить доступ к сервису на основе членства в группах.

К чему я это говорю? К тому, что аппаратные балансировщики используются в 2019 году вне зависимости от того, прописаны они в "Preferred Architecture" или нет.

Часть 2. Растянутый сайт - Site resilient.

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

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

Каждый датацентр должен быть оформлен как отдельный сайт Active Directory. Причины такой рекомендации не только в управлении трафиком репликации AD DS. Конечно везде, где задержка более 10 ms между прощадками нужно ставить отдельный сайт AD. Это написано в "священном писании". Дело в том, что технологии отказоустойчивости транспорта Shadow redundancy и Safety Net отрабатывают "transport site resilience " только в том случае, если члены DAG находятся в разных сайтах Active Directory.

Подход Site Resilient с двумя датацентрами совсем не новый, первые его упоминания можно найти в документации к Exchange 2010. Просто раньше это было экзотикой, а сейчас обычное дело.

Часть 3. Дизайн сервера Exchange.

Со времен Exchange Server 2016 рекомендации по серверам изменились не сильно. Попрежнему рекомендуется строить Exchange на основе физических серверов. Мол виртуализации это дополнительная технология, которой надо управлять, плюс она всё равно медленней чем "физика". А схема рекомендуемой архитектуры подразумевает 80% утилизацию железа. Опять же, никто не рассматривает серверы на 300 ящиков, которые и близко не утилизируют 2 CPU и типовые 256 GB памяти. В реальности Exchange виртуализировали и будут виртуализировать. Хотя приходится сталкиваться с вольным переводом предложения "Physical hardware is deployed rather than virtualized hardware" как "Microsoft не рекомендует виртуализировать Exchange".

Типовой сервер Exchange в понимании Microsoft:

2U с 2-мя CPU до 48 ядер на борту.
До 256 GB памяти.
12 и более дисков.
Микс из HDD и SSD.
Батарейка на контроллере.

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

При аппаратном выходе из строя одного из серверов замена упавшего сервера так же осуществляется через тот же "шкаф".

Очень много шума навели системные требования Exchange Server 2019. А конкретно строка 128 GB minimum recommended. За последние пол года я получил не один десяток вопросов в стиле "Зачем столько памяти" или "Мы не можем поставить 2019 версию, у нас нет столько памяти".

По порядку:

Exchange Server 2019 не требует минимально 128 GB.
Exchange Server 2019 прекрасно работает с теми же требованиями по памяти как и Exchange Server 2016 (ну или близко к ним).
Да, Microsoft использует все механизмы, чтобы продать вам Exchange Online.
Да, у поддержки Microsoft появился еще один повод вас динамить.
На момент написания статьи Microsoft до сих пор не опубликовала данные по рассчету системных требований.

Exchange 2019 Sizing Calculator должен выйти в самом ближайшем будущем.

В нем должны обновить данные по рассчетам CPU потребностей. (SPECint)
В нем появится MetaCache. (новая тема, о ней ниже)
2TB жесткое ограничение на размер баз данных.

Но это все в будущем, а пока вернемся к рекомендуемому серверу. Все базы сервера должны храниться на локальных дисках, т.е никаких СХД не подразумевается. Два диска уходят под систему, они объединяются в RAID1. Остальное диски идут под базы и собираются в JBOD (Just a Bunch of Disks). Под базы и логи массив собирается из обычных 7200 SAS. SAS выбирается по причине того, что он живет дольше SATA (по данным MS).

Принципиально новым в архитектуре является появление SSD и файлов MetaCache Database (MCDB). Технология MCDB пришла из Office 365, суть ее в хранении мета информации (т.е не самих писем, а вспомогательных данных) отдельно на SSD. Вроде как это позволяет ускорить на 50% вход и даже поиск. Кстати, поиск теперь хранится внутри базы. Я уже не помню в какой раз Microsoft меняет движок поисковой системы. На этот раз опять новый стек с именем BigFunnel, но про него пока известно только то, что он есть.

Для хранения MCDB подойдут любые SSD - 2.5"/3.5"/ M.2 PCIe. Понадобится набрать SSD на 5-10% от общего объема с данными. Т.е если под почту вы планируете 30 TB на сервере в JBOD , то до 3 TB нужно иметь в SSD на том же сервере.

Количественное соотношение дисков рекомендуется 3 к 1. Т.е на три обычных диска добавляется один SSD для хранения MCDB. Если SSD диск выйдет из строя, Exchange перекинет все активные базы, которые использовали этот SSD на другой сервер в DAG, где с дисками под MCDB проблем нет. Отсюда и растут рекомендации 3 к 1. Если уменьшить кол-во SSD дисков, то кол-во баз данных, которые используют один SSD станет выше и вероятность проблем при падении SSD возрастет. Но даже если все SSD откажут, базы данных продолжат свою работу, просто без дополнительных преимуществ по скорости.

DAG и MCDB. Если вы вдруг решили, что у вас получится разогнать свой единственный сервер Exchange через MCDB, то мне придется вас разочаровать. MCDB работает только с DAG!

Microsoft дает пример разделения дисков на сервере с 20 дисками:

2 HDDs в зеркале для системы
12 HDDs для баз
1 HDD для AutoReseed
4 SSDs for Exchange MCDBs

На примере 120 TB данных и 7.68 TB для MCDB, что около 6.4%

Уже давно рекомендуемая файловая система для всех дисков с базами данных это ReFS. (с отключенной проверкой целостности) Почему не NTFS? Сложный вопрос, Microsoft детального ответа на него не дает, все в стиле старой шутки:

- Армяне лучше, чем грузины! - Чем? Ну чем они лучше?! - Чем грузины.

Четыре года назад одним специалистом были сделаны тесты скорости работы. На тот момент ReFS проигрывала по всем пунктам, кроме загрузки CPU

Ниже итоговая таблица с результатами замеров. (Оригинал)

Кроме ReFS, частью рекомендуемой архитектуры является функция AutoReseed. Мое личное мнение AutoReseed это неуловимый Джо. Со времен его появления я ни разу им не пользовался и не видел никого, кто бы им пользовался.

AutoReseed позволяет вам, используя функцию Windows по монтированию дисков к папке и запасной диск реализовать автоматическое ресидирование базы, когда у вас упала копия. (без ручного вмешательства администратора) Логика в том, что если у вас база 2TB и упала копия, то пока вы заметите, а потом замените диск и запустите сидирование по WAN каналу пройдет столько времени, что не исключен выход из строя и дисков с оставшейся копией. (ну BLOB же)

Для спортивного интереса в тестовой среде я проводил настройку. Очень много привязок к именам путей и баз, которые должны быть или так или никак. Поэтому не удобно. Но при желании работает. Ниже общая схема, как должны выглядеть пути. Через 30 минут начинает сидировать сама. AutoReseed - часть рекомендуемой архитектуры.

Ну и конечно все диски шифруются BitLocker, что официально поддерживается и рекомендуется. Даже есть статья четырехлетней давности "Enabling BitLocker on Exchange Servers".

Часть 4. Дизайн DAG.

Основным строительным блоком Exchange является DAG. Более того DAG растянутый на два датацентра. Самое интересное, что тянуть DAG на три датацентра не рекомендуемый сценарий. Так же как и для пространства имен, здесь рекомендуется распределение активных копий по всем датацентрам.

Это позволяет убедиться, что каждый сервер жив, что у него работает весь стек технологий (client connectivity, replication pipeline, transport) и при этом почтовая система равномерно распределяет нагрузку.

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

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

Когда то давно Microsoft рекомендовала использовать для сервера DAG несколько сетевых адаптеров дабы разделять трафик клиентов и трафик репликации. Эти времена прошли и актуальная информация - каждый сервер должен иметь один non-teamed сетевой интерфейс.

Есть еще одна мысль, которую Microsoft продвигает уже не первый год. Эта мысль - "бэкапы не нужны". Для всего есть "Exchange Native Data Protection". Стек технологий, которые минимизируют определенные риски потери данных.

Идеология подхода Exchange Native Data Protection:

Минимум 4 копии каждой базы данных.
Наличие копии, которая обновляется с задержкой. (ReplayLagTime)
Технологии Single Item Recover (корзина 3 уровня) и In-Place Hold.

Подразумевается, что если человек вдруг все удалил, то вы можете достать письма из корзины. Если произошёл логический сбой, то вы можете через переключение на базу с задержкой в обновлении и предотвратить проблему. Все это безумно интересно, но для человека, который восстанавливал базы и через Veeam и через ReplayLagTime реакция может быть только одна. Exchange Native Data Protection это полная ерунда, которая применима разве, что для Office 365, где есть правила игры и в случае каких то проблем ответственное лицо это 100 тысячная компания с которой любые взятки будут гладки.

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

Илья Рудь.

P.S Понравилась статья - поделись в "чатике или фейсбуке". Это больше, чем спасибо.