Предпочтительная архитектура Exchange 2019
С каждым новым выпуском Exchange Server для наших локальных клиентов мы обновляем предпочитаемую архитектуру и обсуждаем, какие изменения мы хотели бы знать нашим клиентам. Exchange Server 2013 году принес нам первую из предпочитаемых архитектур в современной истории Exchange, а затем обновление для Exchange Server 2016 года, предоставив уточнение изменений, внесенных в выпуск 2016 года. В этом обновлении за Exchange Server 2019 г. мы рассмотрим предыдущий paererт, чтобы воспользоваться преимуществами новых технологий и улучшений.
Предпочтительная архитектура
Pa — это рекомендация команды инженеров Exchange Server, которая, по нашему мнению, является лучшей архитектурой развертывания для Exchange Server 2019 в локальной среде.
Хотя Exchange 2019 предлагает широкий выбор архитектуры для локальных развертываний, рассмотренная здесь архитектура является наиболее тщательной. Хотя существуют и другие поддерживаемые архитектуры развертывания, они не являются рекомендуемой практикой.
После этого клиент становится членом сообщества организаций со схожими Exchange Server развертываниями. Эта стратегия упрощает обмен знаниями и обеспечивает более быстрое реагирование на непредвиденные обстоятельства. Наша организация поддержки знает, как должно выглядеть развертывание Exchange Server PA, и не позволяет им тратить длительные циклы обучения и понимания строго настраиваемой среды клиента, прежде чем работать с ними над решением обращения в службу поддержки.
Pa разработан с учетом нескольких бизнес-требований, таких как требование, чтобы архитектура могла:
Включите как высокий уровень доступности в центре обработки данных, так и устойчивость сайта между центрами обработки данных.
Поддержка нескольких копий каждой базы данных, что обеспечивает быструю активацию
Снижение затрат на инфраструктуру обмена сообщениями
Повышение доступности за счет оптимизации доменов сбоя и снижения сложности
Конкретный предписывающий характер pa означает, что не каждый клиент сможет развернуть его слово в слово. Например, не у всех наших клиентов есть несколько центров обработки данных. Некоторые из наших клиентов могут иметь разные бизнес-требования или внутренние политики, которым они должны соответствовать, что требует другой архитектуры развертывания. Если вы относитесь к этим категориям и хотите развернуть локальную среду Exchange, вы по-прежнему имеете преимущества в том, чтобы как можно точнее придерживаться pa pa и отклоняться только в том случае, если требования или политики вынуждают вас отличаться. Кроме того, вы всегда можете использовать Microsoft 365 или Office 365, где больше не требуется развертывать большое количество серверов или управлять ими.
Pa устраняет сложность и избыточность, когда это необходимо, чтобы привести архитектуру к прогнозируемой модели восстановления: при сбое активируется другая копия затронутой базы данных.
Основное внимание уделяется следующим четырем областям:
Для Exchange Server 2019 г. у нас нет изменений в трех из четырех категорий из предпочтительной архитектуры Exchange Server 2016 года. Области проектирования пространства имен, проектирования центра обработки данных и структуры DAG не получают серьезных изменений. Мы были довольны развертываниями клиентов, которые внимательно следили за Exchange Server 2016 PA, и не видим необходимости отклоняться от рекомендаций в этих областях.
Наиболее заметные изменения в Exchange Server 2019 PA сосредоточены на области проектирования серверов из-за некоторых новых и интересных технологий.
Проектирование пространства имен
В статьях о планировании пространства имен и принципах балансировки нагрузки за Exchange Server 2016 г. Росс Смит IV рассказал о различных вариантах конфигурации, доступных в Exchange 2016, и эти понятия по-прежнему применяются для Exchange Server 2019 г. Для пространства имен можно развернуть привязанное пространство имен (с предпочтением для пользователей работать вне определенного центра обработки данных) или неограниченное пространство имен (пользователи подключаются к любому центру обработки данных без предпочтения).
Рекомендуемый подход — использовать модель без ограничений, развертывая одно пространство имен Exchange для каждого клиентского протокола для пары устойчивых к сайту центров обработки данных (где предполагается, что каждый центр обработки данных представляет свой собственный сайт Active Directory. Дополнительные сведения см. ниже). Например:
Для службы автообнаружения: autodiscover.contoso.com
Для HTTP-клиентов: mail.contoso.com
Для клиентов IMAP: imap.contoso.com
Для smtp-клиентов: smtp.contoso.com
Каждое пространство имен Exchange распределяется между обоими центрами обработки данных в конфигурации уровня 7, которая не использует сходство сеансов, что приводит к тому, что 50 процентов трафика перемещается между центрами обработки данных. Трафик равномерно распределяется между центрами обработки данных в паре устойчивых к сайту, через циклический перебор DNS, гео-DNS или другие аналогичные решения. С нашей точки зрения, более простое решение является наименее сложным и простым в управлении, поэтому мы рекомендуем использовать циклический перебор DNS.
Одно из предостережений, которое мы имеем для клиентов, заключается в том, чтобы вы назначали низкое значение срока жизни (время жизни) для любой записи DNS, связанной с вашей архитектурой Exchange. Если при использовании DNS с циклическим перебором происходит полный сбой центра обработки данных, необходимо поддерживать возможность быстрого обновления записей DNS. Вам потребуется удалить IP-адреса из автономного центра обработки данных, чтобы они не возвращались для ЗАПРОСОВ DNS. Например, если ваши записи DNS имеют более длинное значение TTL в 24 часа, для правильного обновления подчиненных кэшей DNS может потребоваться до дня. Если вы не выполните этот шаг, некоторые клиенты не могут правильно перейти на все еще доступные IP-адреса в оставшемся центре обработки данных. Не забудьте добавить IP-адреса обратно в записи DNS, когда ранее автономный центр обработки данных будет восстановлен и снова готов к размещению служб.
Сходство центров обработки данных требуется для ферм Office Online Server, поэтому пространство имен развертывается для каждого центра обработки данных с подсистемой балансировки нагрузки, использующим уровень 7, и поддерживает сходство сеансов с помощью сохраняемости на основе файлов cookie.
Если в вашей среде есть несколько пар центров обработки данных, устойчивых к сайту, необходимо решить, хотите ли вы иметь одно глобальное пространство имен или вы хотите управлять трафиком к каждому конкретному центру обработки данных с помощью региональных пространств имен. Ваше решение зависит от топологии сети и связанных с ней затрат на использование модели без ограничений. Например, если у вас есть центры обработки данных, расположенные в Северная Америка и Южной Африке, сетевой канал между этими регионами может быть не только дорогостоящим, но также может иметь высокую задержку, что может привести к возникновению проблем пользователей и операционных проблем. В этом случае имеет смысл развернуть привязанную модель с отдельным пространством имен для каждого региона. Однако такие параметры, как географическая DNS, позволяют развернуть единое единое пространство имен, даже если у вас есть дорогостоящие сетевые каналы. Geo-DNS позволяет направлять пользователей в ближайший центр обработки данных на основе IP-адреса клиента.
Проектирование пар центров обработки данных, устойчивых к сайту
Чтобы обеспечить высокодоступную и устойчивую к сайту архитектуру, необходимо иметь два или более хорошо подключенных центров обработки данных (в идеале требуется низкая задержка в сети кругового пути, в противном случае это негативно повлияет на репликацию и взаимодействие с клиентом). Кроме того, центры обработки данных должны быть подключены через избыточные сетевые пути, предоставляемые разными операционными операторами.
Хотя мы поддерживаем растягивание сайта Active Directory между несколькими центрами обработки данных, для pa рекомендуется, чтобы каждый центр обработки данных был собственным сайтом Active Directory. Существует две причины:
Обеспечение устойчивости сайта с помощью теневой избыточности в Exchange Server и Safety Net в Exchange Server может быть достигнуто только в том случае, если daG содержит члены, расположенные на нескольких сайтах Active Directory.
Active Directory опубликовала руководство , в котором говорится, что подсети должны размещаться на разных сайтах Active Directory, если задержка кругового пути между подсетями превышает 10 мс.
Проектирование сервера
В pa все серверы являются физическими серверами и используют локально подключенное хранилище. Физическое оборудование развертывается вместо виртуализированного оборудования по двум причинам:
Серверы масштабируются для использования 80 % ресурсов в режиме наихудшего сбоя.
Виртуализация обеспечивает небольшую снижение производительности и добавляет дополнительный уровень управления и сложности, что приводит к добавлению дополнительных режимов восстановления, которые не добавляют ценности, особенно с учетом того, что Exchange Server изначально предоставляет те же функции.
Серверы товаров
Платформы сервера товаров используются в pa. К текущим товарным платформам относятся:
2U, серверы с двумя сокетами до 48 физических ядер процессора (увеличение с 24 ядер в Exchange 2016)
До 256 ГБ памяти (увеличение с 192 ГБ в Exchange 2016)
Контроллер кэша записи с поддержкой батареи
12 или более дисковых отсеков в серверных корпусах
Возможность смешивать традиционное вращающееся дисковое хранилище (HDD) и твердотельные накопители (SSD) в одном корпусе.
Теория масштабирования
Важно отметить, что несмотря на то, что в Exchange Server 2019 году мы увеличили разрешенную емкость процессора и памяти, Exchange Server PG рекомендуется масштабировать, а не увеличивать. Горизонтальное и вертикальное масштабирование означает, что мы предпочли бы развернуть большее количество серверов с немного меньшим количеством ресурсов на сервер, а не меньшее количество серверов с высокой плотностью, использующих максимальное количество ресурсов и заполненных большим количеством почтовых ящиков. Размещая разумное количество почтовых ящиков на сервере, вы уменьшаете влияние любых запланированных или незапланированных простоев и снижаете риск обнаружения других узких мест системы.
Увеличение системных ресурсов не должно привести к предположению, что в Exchange Server 2019 г. вы увидите линейное повышение производительности с использованием максимально допустимых ресурсов при сравнении с максимально допустимыми ресурсами Exchange 2016. Каждая новая версия Exchange приносит новые процессы и обновления, которые, в свою очередь, затрудняют сравнение текущей версии с предыдущей версией. При определении структуры сервера следуйте всем рекомендациям корпорации Майкрософт по определению размера.
Хранилища
Дополнительные отсеки для дисков могут быть напрямую подключены к каждому серверу в зависимости от количества почтовых ящиков, размера почтовых ящиков и масштабируемости ресурсов сервера.
Каждый сервер содержит одну пару дисков RAID1 для операционной системы, двоичных файлов Exchange, журналов протокола/клиента и транспортной базы данных.
Остальное хранилище настроено как JBOD (всего несколько дисков). Обратите внимание, что некоторые аппаратные контроллеры хранилища могут потребовать, чтобы каждый диск был настроен в качестве группы RAID0 с одним диском для использования кэширования записи. Проконсультируйтесь с производителем оборудования, чтобы подтвердить правильную конфигурацию системы, гарантирующую использование кэша записи.
Впервые в Exchange Server 2019 PA рекомендуется использовать два класса хранилища для всего, что еще не находится в паре дисков RAID1, упомянутой ранее.
Традиционный класс хранения
Этот класс хранения содержит файлы Exchange Server базы данных и Exchange Server файлы журнала транзакций. Эти диски представляют собой диски SCSI большой емкости 7,2 КБ об/мин, последовательно подключенные к SCSI (SAS). Хотя диски SATA также доступны, мы наблюдаем улучшение операций ввода-вывода и более низкую годовую частоту сбоев с использованием эквивалента SAS.
Чтобы обеспечить максимально эффективное использование емкости и операций ввода-вывода каждого диска, на каждом диске развертывается до четырех копий баз данных. Обычный макет копирования во время выполнения гарантирует, что на диск будет не более одной активной копии базы данных.
По крайней мере один диск в традиционном пуле дисков хранилища зарезервирован в качестве горячего резерва. Функция AutoReseed включена и быстро восстанавливает избыточность базы данных после сбоя диска, активируя горячий резерв и инициируя повторное копирование базы данных.
Класс твердотельного хранилища
Этот класс хранения содержит новые файлы Базы данных MetaCache (MCDB) Exchange 2019. Эти твердотельные накопители могут поступать в различных форм-факторах, таких как, помимо прочего, традиционные подключенные sas 2.5"/3.5" или подключенные к M.2 PCIe диски.
Клиенты должны ожидать развертывания примерно 5–10 % дополнительного хранилища в качестве твердотельного хранилища. Например, если ожидается, что один сервер будет хранить 28 ТБ файлов базы данных почтовых ящиков в традиционном хранилище, то в качестве дополнительного хранилища для того же сервера также рекомендуется дополнительное хранилище объемом 1,4–2,8 ТБ.
Традиционные и твердотельные диски должны развертываться в соотношении 3:1, где это возможно. Для каждых трех традиционных дисков на сервере будет развернут один твердотельный диск. Эти твердотельные диски будут содержать mcDB для всех баз данных в трех связанных традиционных дисках. Эта рекомендация ограничивает домен сбоя, который может привести к сбою твердотельного диска в системе. При сбое SSD Exchange 2019 выполнит отработку отказа всех копий базы данных, использующих этот SSD для mcDB, на другой узел DAG с работоспособными ресурсами MCDB для затронутой базы данных. Ограничение числа операций отработки отказа базы данных снижает вероятность влияния на пользователей, если многие другие базы данных совместно использует меньшее число твердотельных дисков.
При сбое твердотельных дисков Служба высокой доступности Exchange попытается подключить затронутые базы данных на разных узлах DAG, где для каждой затронутой базы данных по-прежнему существует работоспособность MCDB. Если по какой-либо причине для одной из затронутых баз данных не существует работоспособных mcDB, службы высокого уровня доступности Exchange оставят локальную затронутую копию базы данных запущенной без преимуществ производительности MCDB.
Например, если клиент должен был развернуть систему, которая может содержать 20 дисков, она может иметь следующий макет.
2 жестких диска для зеркального отображения ОС, двоичных файлов Exchange и транспортной базы данных
12 жестких дисков для хранилища базы данных Exchange
1 жесткий диск в качестве запасного резерва AutoReseed
4 накопителя SSD для MCDB Exchange, которые обеспечивают от 5 до 10 % совокупной емкости хранилища базы данных.
При необходимости клиент может добавить запасной ssd или второй диск с автоматическим удалением.
Эту конфигурацию можно визуализировать на следующей схеме:
В приведенном выше примере мы имеем 120 ТБ хранилища базы данных Exchange и 7,68 ТБ хранилища MCDB, что составляет примерно 6,4 % традиционного хранилища базы данных. Благодаря такому объему хранилища MCBD мы полностью выровнены в соответствии с рекомендациями 5–10 %. Каждый из дисков емкостью 10 ТБ будет содержать четыре копии базы данных, а каждый диск MCDB будет содержать 12 MCDB.
Общие параметры хранилища
Как традиционные, так и твердотельные, все диски, на которых размещены данные Exchange, форматируются с помощью ReFS (с отключенной функцией целостности), а DAG настраивается таким образом, чтобы автоотбор дисков форматировался с помощью ReFS:
Set-DatabaseAvailabilityGroup -Identity <DAGIdentity> -FileSystem ReFS
BitLocker используется для шифрования каждого диска, обеспечивая тем самым шифрование неактивных данных и устранение проблем, связанных с кражей данных или заменой диска. Дополнительные сведения см. в разделе Включение BitLocker на серверах Exchange Server.
Проектирование группы доступности базы данных
В каждой паре устойчивых к сайту центров обработки данных у вас будет одна или несколько групп daG. Не рекомендуется растягивать DAG на более чем два центра обработки данных.
Конфигурация DAG
Как и в случае с моделью пространства имен, каждое daG в паре устойчивых к сайту центров обработки данных работает в модели без ограничений с активными копиями, распределенными поровну между всеми серверами в DAG. Эта модель:
Гарантирует, что во время обычных операций проверяется полный стек служб каждого члена DAG (подключение клиента, конвейер репликации, транспорт и т. д.).
Распределяет нагрузку между как можно большим количеством серверов во время сценария сбоя, тем самым только постепенно увеличивая использование ресурсов среди остальных членов в DAG.
Каждый центр обработки данных симметричный, с равным числом членов DAG в каждом центре обработки данных. Это означает, что каждое DAG имеет четное число серверов и использует сервер-свидетель для обслуживания кворума.
DaG является основным стандартным блоком в Exchange 2019. Что касается размера DAG, daG с большим количеством участвующих узлов-членов обеспечивает большую избыточность и ресурсы. В pa pa цель состоит в том, чтобы развернуть группы доступности базы данных с большим количеством узлов-членов, обычно начиная с восьми членов DAG и увеличивая количество серверов, необходимых для удовлетворения ваших требований. Создавать новые группы доступности баз данных следует только в том случае, если масштабируемость вызывает проблемы с существующим макетом копии базы данных.
Проектирование сети DAG
Pa использует единый, не объединяемый сетевой интерфейс как для подключения клиента, так и для репликации данных. Единый сетевой интерфейс — это все, что необходимо, так как в конечном итоге наша цель заключается в достижении стандартной модели восстановления независимо от того, происходит ли сбой сервера или происходит сбой сети. Результат тот же: копия базы данных активируется на другом сервере в daG. Это изменение архитектуры упрощает сетевой стек и устраняет необходимость вручную устранять перекрестное взаимодействие с пульсом.
Размещение следящего сервера
Размещение следящего сервера определяет, может ли архитектура предоставлять возможности автоматической отработки отказа центра обработки данных или потребуется активация вручную для включения службы в случае сбоя сайта.
Если в вашей организации есть третье расположение с сетевой инфраструктурой, изолированной от сбоев сети, влияющих на пару устойчивых к сайту центров обработки данных, в которой развернута daG, рекомендуется развернуть следящий сервер DAG в этом третьем расположении. Эта конфигурация дает daG возможность автоматической отработки отказа баз данных в другой центр обработки данных в ответ на событие сбоя на уровне центра обработки данных независимо от того, в каком центре обработки данных произошел сбой.
Если у вашей организации нет третьего расположения, рассмотрите возможность размещения сервера-свидетеля в Azure. Кроме того, поместите следящий сервер в один из центров обработки данных в паре устойчивых к сайту центров обработки данных. Если в паре устойчивых к сайту центров обработки данных имеется несколько групп доступности баз данных, поместите следящий сервер для всех daG в одном центре обработки данных (как правило, в центре обработки данных, где физически расположено большинство пользователей). Кроме того, убедитесь, что основной активный диспетчер (PAM) для каждой группы daG также находится в одном центре обработки данных.
Exchange Server 2019 г. и все более ранние версии не поддерживают использование функции Cloud-свидетеля, впервые представленной в Windows Server 2016 отказоустойчивом кластере.
Устойчивость данных
Устойчивость данных достигается путем развертывания нескольких копий базы данных. В pa копии базы данных распределяются по паре устойчивых к сайту центров обработки данных, обеспечивая тем самым защиту данных почтового ящика от сбоев программного обеспечения, оборудования и даже центра обработки данных.
Каждая база данных имеет четыре копии с двумя копиями в каждом центре обработки данных. Это означает, что для pa pa требуется как минимум четыре сервера. Из этих четырех копий три из них настроены как высокодоступные. Четвертая копия (копия с наибольшим номером предпочтения активации) настраивается как копия базы данных с отстаю. Благодаря структуре сервера каждая копия базы данных изолирована от других копий, тем самым уменьшая домены сбоев и повышая общую доступность решения, как описано в разделе DAG: за пределами "A".
Цель копии базы данных с отстающей базой данных заключается в том, чтобы обеспечить механизм восстановления редких случаев катастрофического логического повреждения в масштабах всей системы. Он не предназначен для восстановления отдельных почтовых ящиков или для восстановления элементов почтового ящика.
Для отстающей копии базы данных настраивается семь дней ReplayLagTime. Кроме того, диспетчер задержки воспроизведения также включается для динамического воспроизведения файлов журнала для отставание копий, когда доступность скомпрометирована из-за потери не отставанных копий.
Используя таким образом отстающую копию базы данных, важно понимать, что отстающая копия базы данных не является гарантированной резервной копией на определенный момент времени. Отстающая копия базы данных будет иметь порог доступности, как правило, около 90 %, из-за периодов, когда диск, содержащий отстающую копию, теряется из-за сбоя диска, отстающая копия становится копией высокого уровня доступности (из-за автоматического воспроизведения) и периодов, когда отстающая копия базы данных перестраивает очередь воспроизведения.
Для защиты от случайного (или вредоносного) удаления элементов используются технологии восстановления одного элемента или хранения на месте , а в окне Хранение удаленных элементов задается значение, соответствующее или превышающее любое определенное соглашение об уровне обслуживания для восстановления на уровне элемента.
При использовании всех этих технологий традиционные резервные копии не нужны; в результате pas использует собственную защиту данных Exchange.
Office Online Server проектирование
Как минимум, вам потребуется развернуть ферму Office Online Server (OOS) с по крайней мере двумя узлами OOS в каждом центре обработки данных, где размещаются серверы Exchange 2019. Каждая Office Online Server должна иметь по крайней мере 8 ядер процессора, 32 ГБ памяти и не менее 40 ГБ пространства, выделенного для файлов журналов. Серверы почтовых ящиков Exchange 2019 должны быть настроены так, чтобы использовать локальную ферму OOS в центре обработки данных, чтобы обеспечить минимальную задержку и максимальную пропускную способность между серверами для отображения содержимого файлов для пользователей.
Аннотация
Exchange Server 2019 году продолжает улучшать инвестиции, представленные в предыдущих версиях Exchange, и вводит дополнительные технологии, первоначально изобретенные для использования в Microsoft 365 и Office 365.
В соответствии с предпочтительной архитектурой вы воспользуетесь преимуществами этих изменений и обеспечите наилучший локальный пользовательский интерфейс. Вы будете продолжать традицию высоконадежного, предсказуемого и устойчивого развертывания Exchange.