Отключение устаревшей аутентификации в Exchange Server 2019

Почему эта функция важна?

Не так давно появилось второе накопительное обновление (CU2) для Exchange 2019, в котором появилась возможность отключить устаревшую аутентификацию. Это важный шаг на пути удаления устаревших механизмов аутентификации из гибридных развертываний Exchange. Данная функция очень похожа на отключение базовой проверки подлинности в Office 365.

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

Каковы «традиционные» методы аутентификации?

Exchange Server существует уже 23 года, поэтому за это время многое претерпело изменения. За это время поддерживалось несколько методов аутентификации, чтобы синхронизировать их с клиентами и обеспечить простую миграцию. Следующие устаревшие методы аутентификации исторически использовались для доступа к серверам Exchange, и именно их удаление было интересно для целей этой функции и публикации:

• Базовая аутентификация
• Дайджест аутентификации
• Проверка подлинности Windows (NTLM и Kerberos)

Итак, что вам нужно сделать, чтобы настроить эту новую функцию?

Предварительные условия

Нужно убедиться, что гибридная современная аутентификация включена и успешно работает в гибридной среде Exchange.

Убедиться, что все почтовые клиенты и приложения поддерживают современную аутентификацию. Клиенты, которые в настоящее время поддерживают Hybrid Modern Auth, перечислены ниже. Также очень важно поддерживать клиентов в актуальном состоянии — это не только гарантирует, что они получат исправления для любых проблем, но и означает, что они также получают новейшие функции и возможности:

• Outlook 2013 или более поздняя версия (Outlook 2013 требуется изменение раздела реестра)
• Outlook 2016 для Mac или новее
• Outlook для iOS и Android
• Почта для iOS 11.3.1 или новее

Политики аутентификации

Устаревшая аутентификация в гибридных средах Exchange блокируется созданием политик аутентификации. Политики аутентификации определяют клиентские протоколы, где устаревшая аутентификация блокируется (все протоколы или определенные протоколы, хотя рекомендуется блокировать устаревшую аутентификацию для всех протоколов).

После создания политик аутентификации они назначаются пользователям. Назначение политики пользователям блокирует их устаревшие запросы аутентификации для указанных протоколов. Обратите внимание, что для того, чтобы политика вступила в силу, почтовые ящики должны быть на сервере Exchange 2019 CU2, и подключение к почтовому ящику не может осуществляться через более старую версию Exchange.

Все аспекты политик аутентификации управляются через командную консоль Exchange.

Поддерживаемые протоколы и сервисы

Протоколы и службы в Exchange, для которых можно заблокировать устаревшую аутентификацию, описаны в следующей таблице.

Протокол или сервис	Описание	Параметр
Exchange Active Sync (EAS)	Used by some email clients on mobile devices.	BlockLegacyAuthActiveSync
Autodiscover	Used by Outlook and EAS clients to find and connect to mailboxes in Exchange	BlockLegacyAuthAutodiscover
IMAP	Used by IMAP email clients.	BlockLegacyAuthImap
MAPI over HTTP (MAPI/HTTP)	Used by Outlook 2013 and later.	BlockLegacyAuthMapi
Offline Address Book (OAB)	A copy of address list collections that are downloaded and used by Outlook.	BlockLegacyAuthOfflineAddressBook
POP3	Used by POP email clients.	BlockLegacyAuthPop
Outlook Anywhere (RPC over HTTP)	Used by Outlook 2016 and earlier.	BlockLegacyAuthRpc
Exchange Web Services (EWS)	A programming interface that’s used by Outlook, Outlook for Mac, and third-party apps.	BlockLegacyAuthWebServices

Обычно, когда блокируется устаревшую аутентификацию для пользователя, рекомендуется блокировать устаревшую аутентификацию для всех протоколов. Однако можно использовать параметры (переключатели) BlockLegacyAuth* в командлетах New-AuthenticationPolicy и Set-AuthenticationPolicy, чтобы выборочно разрешать или блокировать устаревшую аутентификацию для определенных протоколов.

Шаг 1. Создание политики аутентификации

Чтобы создать политику, которая блокирует устаревшую аутентификацию для указанного клиентского протокола, используется командлет New-AuthenticationPolicy.

В этом примере создается политика аутентификации с именем «Block Legacy Auth» для блокировки устаревшей аутентификации для всех клиентских протоколов в Exchange 2019 (рекомендуемая конфигурация).

New-AuthenticationPolicy -Name «Block Legacy Auth» -BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover -BlockLegacyAuthImap -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthPop -BlockLegacyAuthRpc -BlockLegacyAuthWebServices

Шаг 2: Назначение политики аутентификации пользователям

Методы, которые можно использовать для назначения политик аутентификации пользователям:

Индивидуальные учетные записи пользователей:

В этом примере назначается политика с именем Block Legacy Auth для учетной записи пользователя laura@contoso.com.

Set-User -Identity laura@contoso.com -AuthenticationPolicy «Block Legacy Auth»

Фильтрация учетных записей пользователей по атрибутам. Этот метод требует, чтобы все учетные записи пользователей имели общий фильтруемый атрибут (например, название или отдел), который можно использовать для идентификации пользователей.

В этом примере назначается политика с именем Block Legacy Auth для всех учетных записей пользователей, атрибут Title которых содержит значение «Sales Associate».

$SalesUsers = Get-User -ResultSize unlimited -Filter {(RecipientType -eq ‘UserMailbox’) -and (Title -like ‘*Sales Associate*’)}$Sales = $SalesUsers.SamAccountName$Sales | foreach {Set-User -Identity $_ -AuthenticationPolicy «Block Legacy Auth»}

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

akol@contoso.com

tjohnston@contoso.com

kakers@contoso.com

Синтаксис использует две команды (одна для идентификации учетных записей пользователей, а другая для применения политики к этим пользователям).

В этом примере назначается политика с именем Block Legacy Auth для учетных записей пользователей, указанных в файле C:\My Documents\BlockLegacyAuth.txt.

$BLA = Get-Content «C:\My Documents\BlockLegacyAuth.txt»$BLA | foreach {Set-User -Identity $_ -AuthenticationPolicy «Block Legacy Auth»}

Настройка политики аутентификации по умолчанию

Политика проверки подлинности по умолчанию назначается всем пользователям, которым еще не назначена определенная политика (приоритет имеет непосредственно назначенная политика).

Можно настроить политику аутентификации по умолчанию для организации, используя командлет Set-OrganizationConfig.

В примере ниже настраивается политика аутентификации с именем «Block Legacy Auth» в качестве политики по умолчанию.

Set-OrganizationConfig -DefaultAuthenticationPolicy «Block Legacy Auth»

Как эта функция работает на практике?

На рисунках ниже показано, как работает эта функция после создания и назначения политики.

Hybrid Modern Auth Flow

Legacy Auth Flow

Как просмотреть политики аутентификации?

Чтобы просмотреть сводный список имен всех существующих политик аутентификации, выполните следующую команду:

Get-AuthenticationPolicy | Format-Table -Auto Name

Чтобы просмотреть подробную информацию о конкретной политике аутентификации, используйте этот синтаксис:

Get-AuthenticationPolicy -Identity «Block Legacy Auth»

Как удалить политики аутентификации?

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

Чтобы удалить политику для определенного пользователя, скажем, userA, используется команда:

Set-User userA -AuthenticationPolicy $null

Чтобы удалить политику для уровня организации, используется команда:

Set-OrganizationConfig -DefaultAuthenticationPolicy $null

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

Предпочтительная архитектура Exchange 2019

С каждым новым выпуском Exchange Server обновляется предпочтительная архитектура и появляются изменения, о которых интересно будет узнать. Первая предпочтительная архитектура (ПА) появилась вместе с Exchange Server 2013 в истории Exchange, затем последовало обновление для Exchange Server 2016, предоставив уточнения для изменений, появившихся в выпуске 2016 года. В этом обновлении для Exchange Server 2019  будет использоваться предыдущая версия ПА, чтобы воспользоваться преимуществами новых технологий и улучшений.

Предпочтительная архитектура

ПА является рекомендацией группы разработчиков Exchange Server, поскольку считается оптимальной архитектурой развертывания Exchange Server 2019 в локальной среде.

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

ПА разработана с учетом нескольких бизнес-требований:

• Обеспечение высокой доступности как в центре обработке данных, так и обеспечение устойчивости сайтов между центрами обработки данных
• Поддержка нескольких копий каждой базы данных, для быстрой их активации
• Уменьшение стоимости инфраструктуры обмена сообщениями
• Повышение доступности за счет оптимизации доменов отказов и снижения сложности

Конкретный предписывающий характер ПА означает, конечно, что не каждый клиент сможет развернуть его слово в слово. Например, не все клиенты имеют несколько центров обработки данных. У некоторых клиентов могут быть разные бизнес-требования или внутренние политики, которые они должны соблюдать, что требует другой архитектуры развертывания. Если они попадают в эти категории и хотят развернуть Exchange локально, все еще есть преимущества в том, чтобы как можно точнее придерживаться PA и отклоняться только там, где требования или политики вынуждают отклонятся. В качестве альтернативы всегда можете рассмотреть Office 365, где больше не нужно развертывать или управлять большим количеством серверов.

ПА устраняет сложность и избыточность, когда это необходимо, чтобы привести архитектуру к предсказуемой модели восстановления: при сбое активируется другая копия базы данных.

ПА охватывает следующие четыре области:

• Дизайн пространства имен
• Дизайн устойчивого сайта из пары центров обработки данных
• Дизайн сервера
• Дизайн группы доступности базы данных

Для Exchange Server 2019 нет изменений в трех из четырех категорий по сравнению с предпочтительной архитектурой Exchange Server 2016. Области дизайна пространства имен, дизайна центра обработки данных и дизайна DAG не претерпели существенных изменений.

Наиболее заметные изменения в ПА Exchange Server 2019 фокусируются на области проектирования серверов из-за некоторых новых и интересных технологий.

Дизайн пространства имен

Концепции, которые были доступны в 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, которая не использует сходство сеансов, в результате чего пятьдесят процентов трафика передается между центрами данных. Трафик равномерно распределяется между центрами обработки данных в паре отказоустойчивых сайтов с помощью циклического DNS, гео-DNS или других аналогичных решений. С точки зрения ПА, более простое решение является более простым в управлении, поэтому рекомендуется использовать циклический DNS.

Одним из предостережений  является обеспечение того, чтобы было назначено низкое значение TTL (время жизни) для любой записи DNS, связанной с  архитектурой Exchange. В случае полного отказа центра обработки данных при использовании циклического перебора DNS должна иметься возможность быстро обновить записи DNS, чтобы удалить IP-адреса из автономного центра обработки данных, чтобы они не возвращались для запросов DNS. Например, если записи DNS имеют более длительное значение TTL, равное 24 часам, может потребоваться до дня, чтобы кэши DNS должным образом обновлялись. Если не выполнить это условие, можно обнаружить, что некоторые клиенты не могут правильно перейти на все еще доступные IP-адреса в оставшемся центре обработки данных. Не забыть добавить IP-адреса обратно в записи DNS, когда ранее отключенный центр обработки данных будет восстановлен и снова готов к размещению служб.

Сходствосеансов требуется для ферм Office Online Server, поэтому для каждого центра обработки данных развертывается пространство имен с балансировщиком нагрузки, использующим уровень 7, и поддерживается сходство сеансов на основе файлов cookie.

В случае если в среде имеется несколько пар отказоустойчивых центров обработки данных, необходимо решить, требуется ли иметь одно всеобщее пространство имен или же необходимо управлять трафиком для каждого конкретного центра обработки данных, используя региональные пространства имен. Решение зависит от топологии сети и связанных с ней затрат при использовании несвязанной модели: например, если есть центры обработки данных, расположенные на значительном расстоянии, сетевое соединение между ними может быть не только дорогостоящим, но и иметь высокую задержку, что может создавать проблемы для пользователя и повлечь эксплуатационные проблемы. В этом случае имеет смысл развернуть связанную модель с отдельным пространством имен для каждого региона. Однако такие опции, как географический DNS, дают возможность развернуть единое пространство имен, Geo-DNS позволяет направлять пользователей в ближайший центр обработки данных на основе IP-адреса клиента.

Дизайн устойчивого сайта пары пары центров обработки данных

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

Хотя расширение сайта Active Directory по нескольким центрам обработки данных поддерживается для Exchange Server, для ПА рекомендуется, чтобы каждый центр обработки данных был отдельным сайтом Active Directory. И на то есть две причины:

1. Устойчивость службы транспорта через теневую избыточность (Shadow redundancy) в Exchange Server и Safety Net в Exchange Server может быть достигнута только в том случае, если в группе DAG есть участники, расположенные в нескольких сайтах Active Directory.
2. В руководстве Active Directory говорится, что подсети следует размещать на разных сайтах Active Directory, если задержка прохождения туда и обратно превышает 10 мс между подсетями.

Дизайн сервера

В ПА все серверы Exchange являются физическими серверами и используют локально подключенное дисковое хранилище. Развертывание физического оборудования обусловлено по двум причинам:

• Серверы масштабируются для использования 80% ресурсов в режиме наихудшего отказа
• Виртуализация даёт небольшое снижение производительности, а также добавляет дополнительный уровень управления и сложности, который вводит дополнительные режимы восстановления, которые не увеличивают ценность использования, особенно потому, что Exchange Server изначально предоставляет те же функциональные возможности.

Платформа сервера

Возможности платформы включают в себя:

• 2U, серверы с двумя сокетами и до 48 физических процессорных ядер (увеличение по сравнению с 24 ядрами в Exchange 2016)
• До 256 ГБ памяти (увеличение по сравнению с 192 ГБ в Exchange 2016)
• Контроллер кэширования записи с батарейным питанием
• 12 или более отсеков для дисков в корпусе сервера
• Возможность смешивать традиционное хранилище с вращающимися пластинами (HDD) и твердотельное хранилище (SSD) в одном шасси.

Теория Масштабирования

Важно отметить, что даже несмотря на то, что была увеличена разрешенная емкость процессора и памяти в Exchange Server 2019, основной рекомендацией для Exchange в случае роста, по-прежнему является масштабирование, а не наращивание мощности. Масштабирование по сравнению с увеличением мощности означает, что скорее станет видно, что развертывается большее количество серверов с чуть меньшим количеством ресурсов на сервер, чем меньшее количество очень плотных серверов, использующих максимальное количество ресурсов и заполненных большим количеством почтовых ящиков. При размещении достаточного количества почтовых ящиков на сервере, уменьшается влияние любого запланированного или незапланированного простоя, а также снижается риск обнаружения других узких мест в системе.

Увеличение системных ресурсов не должно приводить к предположению, что будет получен линейный прирост производительности в Exchange Server 2019 с использованием максимально разрешенных ресурсов при сравнении его с максимально разрешенными ресурсами Exchange 2016. Каждая новая версия Exchange приносит новые процессы и обновления, которые, в свою очередь, затрудняют сравнение текущей версии с предыдущей.

Дисковое хранилище

Дополнительные отсеки для дисков могут быть напрямую подключены к серверу в зависимости от количества почтовых ящиков, размера почтового ящика и масштабируемости ресурсов сервера.

Каждый сервер содержит одну пару дисков RAID1 для операционной системы, файлов Exchange, журналов протокола / клиента и транспортной базы данных.

Оставшееся хранилище настроено как JBOD (просто группа дисков). Необходимо помнить, что некоторые аппаратные контроллеры могут требовать, чтобы каждый диск был настроен как группа RAID0 с одним диском для использования кэширования записи.

Новым в ПА Exchange Server 2019 является рекомендация иметь два класса хранилища для всего, что еще не находится на ранее упомянутой паре дисков RAID1.

Традиционный класс хранения

Этот класс хранения содержит файлы базы данных Exchange Server и файлы журнала транзакций Exchange Server. Эти диски представляют собой диски SCSI (SAS) большой емкости с последовательным подключением и скоростью вращения 7200RPM.

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

По крайней мере один диск в традиционном пуле дисков хранения зарезервирован как оперативный резерв. Функция AutoReseed включена и быстро восстанавливает избыточность базы данных после сбоя диска, активируя горячее резервирование и инициируя повторное заполнение копии базы данных.

Твердотельный класс хранения

Этот класс хранения содержит новые файлы базы данных MetaCache (MCDB) Exchange 2019. Эти твердотельные накопители могут иметь различные форм-факторы, такие как традиционные 2,5 «/ 3,5» SAS-подключенные или M.2 PCIe-подключенные накопители.

Необходимо рассчитывать на развертывание примерно 5-10% дополнительного объёма в качестве твердотельного хранилища. Например, если ожидалось, что на одном сервере будет храниться 28 ТБ файлов базы данных почтовых ящиков в традиционном хранилище, в качестве дополнительного хранилища для того же сервера будет рекомендовано дополнительно 1,4-2,8 ТБ твердотельного хранилища.

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

В случае отказа твердотельного диска службы высокой доступности Exchange попытаются подключить уязвимые базы данных на разных узлах группы обеспечения доступности баз данных, где исправная MCDB для каждой уязвимой базы данных еще существует. Если по какой-либо причине не существует исправных MCDB для одной из затронутых баз данных, то службы высокой доступности Exchange оставят локальную уязвимую копию базы данных работающей без преимуществ для производительности MCDB.

Например, если требуется развернуть систему, способную вмещать 20 дисков, то эта система может иметь компоновку, как показано ниже:

• 2 жестких диска в RAID1 для ОС,  файлов Exchange и транспортной базы данных
• 12 жестких дисков для хранения баз данных Exchange
• 1 HDD в качестве запасного AutoReseed
• 4 твердотельных накопителя для Exchange MCDB, которые обеспечивают от 5 до 10% совокупной емкости хранилища баз данных

При желании можно добавить запасной SSD или второй накопитель AutoReseed.

Это может быть визуализировано следующим образом:

В приведенном выше примере мы имеем 120 ТБ хранилища базы данных Exchange и 7,68 ТБ хранилища MCDB, что составляет примерно 6,4% от традиционного пространства хранения базы данных. С таким объемом хранения MCBD мы идеально выровнены в пределах 5-10%. Каждый из дисков на 10 ТБ будет содержать четыре копии базы данных, а каждый диск MCDB будет содержать двенадцать MCDB.

Общие настройки хранения

Будь то традиционный или твердотельный, все диски, на которых размещены данные Exchange, отформатированы с использованием ReFS (с отключенной функцией целостности), а группа обеспечения доступности баз данных настроена так, что AutoReseed форматирует диски с помощью ReFS:

Set-DatabaseAvailabilityGroup -Identity <DAGIdentity> -FileSystem ReFS

Дизайн группы доступности базы данных

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

Конфигурация DAG

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

1. Гарантирует, что полный пакет услуг каждого участника группы обеспечения доступности баз данных (подключение клиента, конвейер репликации, транспорт и т.д.) проверяется во время обычных операций.
2. Распределяет нагрузку по максимально возможному количеству серверов во время сценария сбоя, тем самым лишь постепенно увеличивая использование ресурсов между оставшимися участниками группы обеспечения доступности баз данных.

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

DAG является фундаментальным строительным блоком в Exchange 2019. Что касается размера DAG, DAG с большим количеством участвующих узлов-участников обеспечивает большую избыточность и ресурсы. В ПА цель состоит в том, чтобы развернуть группы обеспечения доступности баз данных с большим числом узлов-участников, обычно начиная с группы обеспечения доступности баз данных из восьми участников и увеличивая количество серверов в соответствии с требованиями. Новые группы обеспечения доступности баз данных следует создавать только в том случае, если масштабируемость создает проблемы для существующего макета копии базы данных.

Дизайн сети DAG

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

Размещение сервера-свидетеля

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

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

Если у организации нет третьего расположения, можно рассмотреть возможность размещения сервера-свидетеля в Azure, а в качестве альтернативы, поместить следящий сервер в один из центров обработки данных в паре центров обработки данных сайта. Если развернуто несколько групп доступности базы данных в паре отказоустойчивых центров обработки данных сайта, поместить следящий сервер для всех групп обеспечения доступности баз данных в один и тот же центр обработки данных (обычно это центр обработки данных, где физически расположено большинство пользователей). Кроме того, следует убедиться, что служба Active Manager (PAM) для каждой группы доступности базы данных также находится в том же центре данных.

Exchange Server 2019 и все более ранние версии не поддерживают использование функции Cloud Witness, впервые представленной в отказоустойчивом кластере Windows Server 2016.

Устойчивость данных

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

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

Назначение отложенной копии базы данных — предоставить механизм восстановления для редкого события общесистемного катастрофического логического повреждения. Он не предназначен для восстановления отдельных почтовых ящиков или элементов почтовых ящиков.

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

При использовании отложенной копии базы данных важно понимать, что отложенная копия базы данных не является гарантированной резервной копией на определенный момент времени. Отложенная копия базы данных будет иметь порог доступности, обычно около 90%, из-за периодов, когда диск, содержащий отложенную копию, теряется из-за сбоя диска, отставшая копия становится копией высокой доступности (из-за автоматического воспроизведения), а также периоды, когда отстающая копия базы данных перестраивает очередь воспроизведения.

Для защиты от случайного (или злонамеренного) удаления элемента используются технологии восстановления одного элемента или удержания на месте, а для периода «Сохранение удаленного элемента» установлено значение, соответствующее или превышающее любой определенный SLA восстановления на уровне элемента.

При использовании всех этих технологий традиционные резервные копии не нужны. ПА использует собственную защиту данных Exchange.

Дизайн Office Online Server

Как минимум, нужно будет развернуть ферму Office Online Server (OOS), по крайней мере с двумя узлами OOS в каждом центре обработки данных, в котором размещаются серверы Exchange 2019. Каждый сервер Office Online должен иметь не менее 8 процессорных ядер, 32 ГБ памяти и не менее 40 ГБ пространства, выделенного для файлов журнала. Серверы почтовых ящиков Exchange 2019 должны быть настроены на использование локальной фермы OOS в их центре обработки данных, чтобы обеспечить минимально возможную задержку и максимально возможную пропускную способность между серверами для отображения содержимого файлов пользователям.

Резюме
Exchange Server 2019 продолжает улучшать функции, представленные в предыдущих версиях Exchange, а также вводит дополнительные технологии, изначально разработанные для использования в Office 365.

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

Процесс автообнаружения в гибридной среде Exchange. Часть 1.

Небольшое введение

На данную заметку меня воодушевил вопрос Заказчика «Как работает Autodiscover в Exchange Hybrid?» И чтобы продемонстрировать этот процесс наглядно я собрал гибридную среду Exchange из своей подписки Office 365 и пары виртуальных серверов в подписке Azure.В первой части основное внимание уделю представлению логики и связанных компонентов в процессе автообнаружения, реализованных в среде Exchange Hybrid.В следующих двух статьях я планирую рассмотреть процесс автообнаружения, реализованный в среде Exchange Hybrid, с помощью веб-инструмента Microsoft — анализатора Microsoft Remote Connectivity Analyzer (ExRCA).

Процесс автообнаружения в Exchange hybrid

Процесс автообнаружения в среде на основе Exchange Hybrid считается сложным процессом, поскольку автообнаружение реализовано в двух разных средах.Для пользователей, почтовый ящик которых перенесен в «облако» (Exchange Online), автообнаружение начнется с клиента автообнаружения при обращении к инфраструктуре Exchange on-Premises.«Процесс автообнаружения» основан на сценарии, в котором пользовательский почтовый ящик Exchange on-Premises мигрировал в «облако» (Exchange Online).Пользователь, при попытке создать новый профиль почты Outlook, по умолчанию обращается к инфраструктуре Exchange on-Premises, и поскольку почтовый ящик пользователя является «облачным» почтовым ящиком, сервер Exchange on-Premises отправит получателю информацию о его «облачном» e-mail адресе.Клиент Outlook запустит процесс автообнаружения, используя «облачный» адрес электронной почты.

Клиент автообнаружения

Термин «клиент автообнаружения» описывает элемент, который должен получить информацию автообнаружения из конечной точки автообнаружения (сервер Exchange).В среде Exchange Hybrid можно указать следующие типы клиентов Autodiscover:Outlook к ExchangeПроцесс автообнаружения, который выполняется клиентом Exchange, которому необходим доступ к своему почтовому ящику.Клиентом Autodiscover может быть любой почтовый клиент, например, Microsoft Outlook или ActiveSync (клиент для мобильных устройств) и т. д.Exchange к ExchangeДругим типом клиента автообнаружения может быть другой сервер Exchange.В гибридной среде инфраструктура Exchange on-Premise и инфраструктура Exchange Online работают как один логический объект.Когда речь идет о предмете веб-службы Exchange, информация делится между двумя различными инфраструктурами Exchange: Exchange on-Premises и Exchange Online (опирается на инфраструктуру автообнаружения).Когда инфраструктура Exchange Online должна получать информацию о конкретном получателе Exchange on-Premises, Exchange Online найдет сервер Exchange on-Premises, используя процесс автообнаружения.Например, когда «облачный пользователь» (пользователь, который имеет почтовый ящик Exchange Online) должен видеть статус «Свободно/занято» пользователя Exchange on-Premise (пользователь, почтовый ящик которого размещен на сервере Exchange on-Premise), запрос на информацию будет отправлен с сервера Exchange Online на сервер Exchange on-Premise.Exchange Online «находит» или «определяет» сервер Exchange on-Premise с помощью служб автообнаружения.

Exchange on-Premise и Exchange Online

Инфраструктура гибридной среды очень сложна и процесс автообнаружения является лишь частью этой инфраструктуры.Autodiscover служит инфраструктурой для многих других частей гибридной среды, таких как Free/Busy, Mail tips, out of office, перемещение почтового ящика (миграция почты) и т. д.

Прозрачность гибридной среды для пользователя

Основополагающая часть гибридной среды заключается в том, что, хотя гибридная среда соединяет две полностью разнесенные среды — среду Exchange on-Premise и Exchange Online и несмотря на то, что термин «гибридная среда» состоит из множества разных частей, с точки зрения клиента Exchange эта сложная инфраструктура «незаметна».Например, в гибридной среде Exchange если получатель с именем «CloudUser» задается вопросом, где размещен его почтовый ящик, в Exchange Online или Exchange on-Premise, для него не будет никакой возможности получить эту информацию.Администратор Exchange в гибридной среде должен быть знаком с внутренней инфраструктурой гибридной среды и процессом автообнаружения, но преимущество заключается в том, что с точки зрения пользователя эта инфраструктура (гибридная среда) прозрачна.

Гибридная среда и пространство имён SMTP-доменов

Гибридная среда Exchange создается для соединения различных инфраструктур в один логический объект.В среде Exchange Hybrid почтовые ящики организации распределяются между двумя разными средами — средой организации (Exchange on-Premises) и облачной средой (Exchange Online).Пользователи организации не знают о том, что эти две инфраструктуры различны, но на самом деле располагаются в двух совершенно разных средах.Логика, которая объединяет эти две различные инфраструктуры, реализуется на базе отношений организации Exchange между двумя различными инфраструктурами.Каждая из физических инфраструктур — Exchange on-Premises и Exchange Online должна относиться к другой инфраструктуре Exchange, используя другое доменное пространство имен (пространство имен доменов SMTP).среда Exchange Online относится к объектам, физически находящимся в среде Exchange on-Premises, используя общедоступное доменное имя;среда Exchange on-Premises, относится к объектам, физически расположенным в среде Exchange Online, с использованием пространства имен гибридных доменов.

Зависимость между адресом электронной почты и процессом автообнаружения

На первый взгляд может показаться, что нет четкой связи между субъектом адреса электронной почты и процессом автообнаружения, но на самом деле в гибридной среде Exchange процесс автообнаружения полностью зависит от адреса электронной почты пользователя.В Exchange Hybrid «фокусная точка автообнаружения» — это среда Exchange on-Premises.В сценарии, при котором пользовательский почтовый ящик находится в инфраструктуре Exchange Online, пользователь организации начнет процесс автообнаружения, обратившись к инфраструктуре Exchange on-Premises, а служба Exchange on-Premises уведомит его о том, что ему необходимо перезапустить автообнаружение путем адресации из другой инфраструктуры Exchange — инфраструктуры Exchange Online.

Пространство имен SMTP-доменов в гибридной среде Exchange

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

1. Public domain name (общедоступное доменное имя SMTP)

Это общедоступное доменное имя является формальным доменным именем организации, которое используется инфраструктурой Exchange on-Premise и в сценарии гибридной среды используется также как общедоступное доменное имя для представляющего облачного получателя.Получатель Exchange on-Premises и получатель Exchange Online будут продолжать использовать адрес электронной почты, который использует общедоступное доменное имя.Например, в сценарии, в котором общедоступным доменным именем является mctlabs.xyz, все получатели организации, почтовый ящик которых находится в Exchange on-Premises, и пользователи организации, почтовый ящик которых находится в Exchange Online, будут продолжать использовать конкретное доменное имя.Это общедоступное доменное имя, называется общим доменным именем, поскольку оно делится между двумя различными инфраструктурами Exchange (Exchange on-Premises и инфраструктура Exchange Online).

2. Пространства доменных имен Office 365

При создании новой подписки в Office 365 необходимо указать название организации.В данном сценарии доменное имя владельца Office 365 – kuznetsovdmitry.После того, как требуемое название организации предоставлено, Office 365 начнет автоматический процесс, в котором он создает два новых «доменных имени арендатора Office 365».На основе доменного имени арендатора Office 365 создаются два имени домена:

1. onmicrosoft.com
2. mail.onmicrosoft.com

Доменное имя onmicrosoft.com — доменное имя по умолчанию

Второе доменное имя может быть описано как доменное имя арендатора Office 365. Это пространство имен доменов не используется гибридной средой Exchange.Если имя организации, зарегистрированное в Office 365 — kuznetsovdmitry, то это имя будет прикреплено к имени домена Office 365 по умолчанию — onmicrosoft.com, а результатом будет доменное имя, которое представляет конкретного арендатора Office 365. В данном сценарии — kuznetsovdmitry.onmicrosoft.comПространство имен домена kuznetsovdmitry.onmicrosoft.com используется только средой Office 365 и Exchange Online.Необходимость использования выделенного пространства имен домена kuznetsovdmitry.onmicrosoft.com обусловлена по двум основным причинам:Причина 1. Каждый «объект» в Office 365 должен иметь имя UPN, которое включает суффикс имени домена, и каждый из узлов Exchange Online (например, получатель) должен иметь адрес электронной почты, который включает суффикс имени домена.При создании арендатора Office 365 гибрид Exchange еще не существует или еще не определен, а инфраструктура Office 365 нуждается в какой-то идентификации для объектов Office 365, таких как пользователи.В хронологическом порядке Office 365 не знает, будет ли внедряться среда Exchange Hybrid.Причина 2. Инфраструктура Office 365 может размещать локальный объект (профили пользователей, почтовые ящики и т. д.), который никак не связан с инфраструктурой Exchange Hybrid.В случае, если создается такой объект, например профиль облачного пользователя, который не синхронизирован с локальной Active Directory, этот объект должен иметь идентификатор.

Доменное имя mail.onmicrosoft.com — пространство имен гибридного домена

Третье доменное имя «Office 365», созданное по умолчанию, может быть описано как пространство имен доменов Exchange Hybrid.Это конкретное пространство имен доменов будет использоваться только в гибридных сценариях Exchange.Структура пространства имен гибридных доменов основана на следующей формуле:<Название организации Office 365> + <mail> + <onmicrosoft.com>В случае, если имя организации, зарегистрированное в Office 365, — kuznetsovdmitry, то это имя будет прикреплено к доменному имени mail + доменному домену по умолчанию Office 365 — onmicrosoft.com, и, в результате, получается гибридный домен Exchange — kuznetsovdmitry.mail.onmicrosoft.com.

Пространство имён гибридного домена используемое инфраструктурой Exchange on-Premise для целей маршрутизации

Маршрутизация связана с двумя различными инфраструктурами

1. Почтовый процесс

Каждый раз, когда получателю сервера Exchange on-Premise необходимо отправить сообщение электронной почты получателю Exchange Online, запрос будет принят службами Exchange on-Premise, которые понимают, что получатель находится в инфраструктуре Exchange Online.Exchange on-Premise будет использовать пространство имен гибридных доменов получателя. В Exchange Hybrid каждое почтовое сообщение, отправленное в пространство имен гибридных доменов Exchange, будет перенаправлено на сервер Exchange Online.

2. Процесс автообнаружения

Использование пространства имен гибридных доменов также связано с процессом автообнаружения в среде Exchange Hybrid.Когда пользователь, почтовый ящик которого находится в инфраструктуре Exchange Online, попытается получить информацию об автообнаружении, он обратится к серверу Exchange on-Premise.Когда сервер Exchange on-Premise уведомляет о том, что получатель рассматривается как получатель Exchange Online, Exchange on-Premise отправляет в качестве ответа адрес электронной почты, который включает в себя пространство имен гибридных доменов. В данном сценарии — kuznetsovdmitry.mail.onmicrosoft.comКогда клиент автообнаружения получает эту информацию, он понимает, что ему нужно создать новый процесс автообнаружения, но теперь уже обратившись к конечной точке автообнаружения, которая отвечает за доменное имя — kuznetsovdmitry.mail.onmicrosoft.com.

Гибридная среда — пользователи и их адреса электронной почты

Чтобы продемонстрировать концепцию множественных адресов электронной почты в гибридной среде, воспользуемся следующим сценарием:CloudUser является корпоративным сотрудником, почтовый ящик которого был перемещен в облако (Exchange Online).На сервере Exchange on-Premise у CloudUser настроен удаленный почтовый ящик.В Exchange on-Premise есть информация, что у CloudUser есть два адреса электронной почты: стандартный общедоступный адрес электронной почты — CloudUser@mctlabs.xyz и, кроме того, адрес электронной почты домена гибридной среды — CloudUser@kuznetsovdmitry.mail.onmicrosoft.com.В Office 365 и Exchange Online CloudUser будет иметь те же два адреса электронной почты и дополнительный адрес электронной почты — CloudUser@kuznetsovdmitry.onmicrosoft.com.Дополнительный адрес электронной почты, адрес электронной почты без поддомена, основан на доменном имени SMTP Office 365, который автоматически назначается каждому из пользователей Office 365, у которых есть почтовый ящик.Чтобы продемонстрировать разницу между средой Exchange on-Premise и средой Exchange Online, требуется обратить внимание на свойства почтового ящика CloudUser.На рисунке ниже представлен почтовый ящик CloudUser в Exchange on-Premise.Как можно увидеть, Exchange on-Premise знает о двух адресах электронной почты, которые имеет CloudUser.Адрес электронной почты — CloudUser@kuznetsovdmitry.mail.onmicrosoft.com основан на доменном имени SMTP, которое называется доменным именем службы в гибридной среде.Exchange on-Premises обращается к Exchange Online – на основе маршрутизации адресов электронной почты.Чтобы продемонстрировать разницу между средой Exchange On-Premise и средой Exchange Online, взглянем на свойства почтового ящика CloudUser.На следующем рисунке мы можем увидеть почтовые адреса пользователя CloudUser в Exchange On-Premise.Как видно, Exchange On-Premise «знает» о двух адресах электронной почты, которые имеет CloudUser.Адрес электронной почты — CloudUser@kuznetsovdmitry.mail.onmicrosoft.com основан на доменном имени SMTP, которое называется доменное имя службы в гибридной среде.Exchange on-Premise связывается с Exchange Online через почтовый адрес маршрутизации.На следующем рисункепоказаны адреса почтового ящика CloudUser в Exchange Online. Можно увидеть, что Exchange Online «знает» о трех адресах электронной почты, которые имеет CloudUser. Дополнительный адрес электронной почты, который есть у CloudUser, — CloudUser@kuznetsovdmitry.onmicrosoft.com.

Гибридная среда — пользователь Exchange on-Premise и пользователь Exchange Online. Процесс автообнаружения

В гибридной среде почтовый ящик пользователя организации может размещаться в инфраструктуре Exchange on-Premise или в инфраструктуре Exchange Online. Основное различие между процессом автообнаружения для пользователя Exchange on-Premise и пользователем Exchange Online — это то, что для пользователя Exchange on-Premise конечной точкой автообнаружения является Exchange on-Premise.Что касается пользователей, почтовый ящик которых размещен в Exchange Online, Exchange on-Premise для них будет являться элементом, который будет служить для маршрутизации запроса на автообнаружение клиента в инфраструктуру автообнаружения Office 365.Для пользователей, почтовый ящик которых находится в Exchange on-Premise, процесс автообнаружения реализуется следующим образом:

1. Автообнаружение будет доступно для локального Active Directory (с использованием запроса LDAP), при запросе списка серверов Exchange on-Premise, которые могут предоставить почтовому ящику необходимую информацию об автообнаружении.
2. Клиент автообнаружения подключится к локальному DNS-серверу для попытки разрешить имя хоста локального сервера Exchange on-Premise, который был возвращен Active Directory on-Premise.

Клиент автообнаружения попытается подключиться к серверу Exchange on-Premise.В гибридной среде Exchange для пользователей, почтовый ящик которых расположен в Exchange Online, Процесс автообнаружения сложнее и включает дополнительные шаги.Процесс автообнаружения реализуется следующим образом:

1. Автообнаружение будет доступно для локального Active Directory на рабочем месте (с использованием запроса LDAP) при запросе списка серверов Exchange
   on-Premise, которые могут предоставить необходимую информацию об автообнаружении.
2. Клиент автообнаружения подключится к локальному DNS-серверу, попросив разрешить имя хоста локального сервера Exchange on-Premise, который был возвращен Active Directory on-Premise.
3. Клиент автообнаружения попытается подключиться к серверу Exchange on-Premise.
4. Будет возвращен ответ от Exchange on-Premise с сообщением о перенаправлении, информирующим пользователя о том, что для получения необходимых услуг автообнаружения ему потребуется использовать другой адрес электронной почты, его электронную почту Office 365.

Клиент Exchange начнет процесс автообнаружения, обратившись к инфраструктуре Exchange Online.Чтобы продемонстрировать процесс Процесса автообнаружения в гибридной среде для пользователя, почтовый ящик которого размещен в облаке (Exchange Online), используется следующий сценарий:

• Почтовый ящик CloudUser размещен в Exchange Online (инфраструктура Exchange основана на гибридной среде)
• CloudUser необходимо создать новый профиль почтового клиента Outlook, чтобы он мог подключиться к своему почтовому ящику (почтовый ящик Exchange Online)
• Exchange on-Premise относится к почтовому ящику CloudUser как к удаленному почтовому ящику.

Шаг 1 — Определение конечной точки автообнаружения в среде Active Directory.В сценарии удаленного почтового ящика (облачный почтовый ящик) первая часть процесса автообнаружения идентична процессу автообнаружения, который реализован пользователем, который имеет стандартный почтовый ящик на сервере Exchange on-Premise.Когда CloudUser пытается создать новый профиль Outlook, Outlook будет запрашивать локальную службу Active Directory для разрешения имени серверов Exchange on-Premise, которые предоставляют необходимые службы автообнаружения.Шаг 2 — Обращение к серверу Exchange on-PremisesС технической точки зрения сервер Exchange on-Premise не знает, кто такой CloudUser. Чтобы иметь возможность получить подробную информацию об CloudUser, Exchange on-Premise связывается с локальной Active Directory, запрашивая информацию об CloudUser.Ответ из Active Directory включает информацию о том, что почтовый ящик CloudUser является удаленным почтовым ящиком, а у CloudUser есть следующий адрес электронной почты для маршрутизации — CloudUser@kuznetsovdmitry.onmicrosoft.com.Шаг 3 — Клиент автообнаружения запускает Процесс автообнаружения, обращаясь к инфраструктуре Exchange Online.Клиент автообнаружения запустит новый DNS-запрос, ищущий хост с именем — kuznetsovdmitry.onmicrosoft.com.Шаг 4 – производится проверка, может ли конечная точка автообнаружения взаимодействовать с использованием HTTPS.Клиент автообнаружения попытается создать сеанс HTTPS для конечной точки автообнаружения конечного пользователя (Exchange Online) с запросом необходимых служб автообнаружения.

Exchange 2016: новые функции в сравнении с Exchange 2010

Большинство организаций, которые хотели бы перейти на Exchange 2016, в настоящее время используют Exchange 2010. Поэтому важно знать изменения, происходящие в Exchange 2016. Это важно для пользователей Exchange 2010, потому что Exchange 2016 имеет множество архитектурных изменений. Многие функции были добавлены и многие удалены.

Это первый шаг миграции Exchange 2010 до Exchange 2016.

Больше, чем миграция, необходимо знать, какими будут изменения, с которыми предстоит столкнуться. Это поможет подготовиться к тому, чтобы подготовиться к новым изменениям и избегать любых сбоев.

Новые возможности по сравнению с Exchange 2010

     Консоль управления Exchange (EMC):

EMC представлял собой ограниченный инструмент в Exchange 2010. Microsoft заметила задержанное обновление в EMC и решила создать более удобную консоль администратора, которая будет использоваться в Exchange 2016 для управления из графического интерфейса.

Центр Администрирования Exchange (EAC):

Центр управления Exchange  2010 запускался от имени панели управления Exchange, а в Exchange 2013 мы получили все конфигурации для EAC. То же самое происходит в Exchange 2016. Мы можем подключиться из любого места в EAC с помощью веб-браузера. Это одна консоль для всего. Public Folders — это почтовые ящики, поэтому отдельной консоли не требуется. Многие функции графического интерфейса перешли в оболочку управления Exchange, например очереди сообщений. Обновление EAC происходит намного быстрее, чем в консоли управления Exchange 2010.

Архитектура Exchange 2016:

Exchange 2016 сокращен до двух ролей, которые невозможно установить вместе. Как можно догадаться, что это роль почтового ящика и роль пограничного транспорта.

Роль транспортного сервера-концентратора, единой системы обмена сообщениями и роли клиентского доступа были объединены с ролью почтового ящика. Итак, время попрощаться с Hub Transport, Unified Messaging и ролью клиентского доступа.

Роль сервера почтовых ящиков использует протоколы HTTP, POP, IMAP и SMTP-клиента. Это означает, что можно забыть про RPC и RPC CAS Array.

Архитектура Exchange 2016 обеспечит следующие преимущества:

• Гибкость обновления. В отличие от Exchange 2010 у нас есть только одна роль, поэтому нам не нужно беспокоиться о том, какая роль сервера должна быть обновлена в первую очередь.
• Сходство сеансов: в Exchange 2010 мы использовали схожую сессию для многих протоколов, что не требуется, потому что роль CAS и почтового ящика объединена в одном сервере.
• Простота. Меньшее количество требований к пространству имен по сравнению с Exchange 2010. Для протоколов и для автообнаружения требуется одно.
• Outlook может подключаться только к Outlook Anywhere с MAPI через HTTP или RPC через HTTP.
• Высокая доступность почтового ящика по-прежнему предоставляется группой доступности баз данных, которая сократила время перехода на другой ресурс.
• Служба Exchange Store была переписана в управляемом коде.
• Каждая база данных работает под собственным процессом, что позволяет изолировать проблему хранилища с одной базой данных.

Managed Store

В Exchange 2016 Information Store есть 2 процесса: Microsoft.Exchange.Store.Service.exe и Microsoft.Exchange.Store.Worker.exe, который называется Managed Store.

Managed Store написан на C # и интегрирован с службой репликации Microsoft Exchange. Это обеспечивает повышенную отказоустойчивость.

Managed Store также позволяет более лучше гранулировать управление потреблением ресурсов и ускорить анализ основных причин за счет улучшения диагностики

Managed Store управляет базами данных почтовых ящиков через службу репликации Microsoft Exchange и продолжает использовать старый механизм базы данных Extensible Storage Engine (ESE). Служба репликации Microsoft Exchange отвечает за доступность службы серверов почтовых ящиков.

Managed Store также обеспечивает более быстрое восстановление базы данных и улучшенную работу с отказом физического диска.

Managed Store интегрирован с поисковой системой поиска Search, которая обеспечивает более надежную индексацию и поиск.

Управление сертификатами

В Exchange 2010 нам требовалось установить сертификат на сервер из консоли управления Exchange. В Exchange 2016 мы можем установить сертификат на несколько серверов за один раз, используя Exchange Admin Center. Мы также увидим уведомление об окончании срока действия сертификата в EAC.

Установка

Улучшенные проверки готовности:

Проверка готовности выполняется быстрее, чем предыдущие установки Exchange, и позволяет устанавливать необходимые функции Windows.

Упрощенный и современный мастер:

В мастере настройки остались только необходимые шаги.

Гибридное развертывание с Офис 365

HCW: Мастер гибридной конфигурации, который был включен в Exchange 2013, стал облачным приложением. В Exchange 2016 мы можем загрузить Мастер гибридной конфигурации. Мастер будет функционировать так же, как и Exchange 2013, но добавляет немного новых преимуществ:

• Hybrid Configuration Master можно быстро обновить для поддержки изменений в службе Office 365.
• Мастер может быть обновлен для учета проблем, обнаруженных при попытке настроить гибридное развертывание.
• Улучшена диагностика и устранение неполадок для устранения проблем, возникающих при запуске мастера.
• Тот же самый мастер будет использоваться всеми, кто настроит гибридное развертывание, если мы используем Exchange 2013 или Exchange 2016.

Улучшение AADConnect: мульти-лесные гибридные развертывания стали простыми, когда мы используем Azure Active Directory Connect (AADConnect). AADConnect представляет агентов управления, которые значительно упрощают синхронизацию нескольких локальных лесов Active Directory с одним тенантом Office 365.

Новая аутентификация:

Гибридное развертывание теперь будет поддерживать новую современную модель аутентификации в Outlook.

ActiveSync:

Клиенты Exchange ActiveSync будут плавно перенаправляться в Office 365, когда почтовый ящик пользователя перемещается из локального Exchange в Exchange Online. Клиенты Exchange ActiveSync должны поддерживать перенаправление HTTP 451.

Outlook on the Web (старое название OWA):

Веб-приложение Outlook — это новый Outlook в Интернете.

Он поддерживает Microsoft Edge, Internet Explorer 11 и самую последнюю версию Mozilla Firefox, браузеров Google Chrome и Safari.

Добавлены следующие новые функции:

• Возможности работы с платформой для телефонов для Android и IOS.
• Премиальные возможности Android для Chrome на Android версии 4.2 или более поздних версиях.
• Улучшения электронной почты: новое однострочное представление папки «Входящие» с оптимизированной областью чтения, эмодзи, архивирование и возможность отменить действия почтового ящика, такие как перемещение сообщения или удаление сообщения.
• Слияние контактов: пользователи могут добавлять контакты из своих учетных записей LinkedIn.
• Календарь: новый внешний вид и новые функции, в том числе напоминания по электронной почте о событиях Календаря, возможность предлагать новое время в приглашениях на встречи, календари дней рождений и улучшенный поиск.
• Поисковые предложения и уточнения для более быстрого поиска. Предложения по поиску. Поисковые фильтры помогут пользователю более легко найти информацию, которую они ищут, предоставляя контекстно-зависимые фильтры. Фильтры могут включать диапазоны дат, связанные отправители и т. д.
• Новые темы: 13 новых тем с графическим дизайном.
• Обновлены опции для отдельных почтовых ящиков.
• Штифты и Флаги: позволяет пользователям хранить основные электронные письма в верхней части своего почтового ящика (контакты) и отмечать другие для последующих действий (флаги). Штифты являются папками, отлично подходят для использования папок для организации электронной почты. Быстрое обнаружение и управление помеченными элементами с помощью фильтров входящих сообщений или нового модуля Задачи.
• Улучшения производительности в ряде областей Outlook в Интернете, включая создание событий календаря, составление, загрузку сообщений в области чтения, поиск, запуск, всплывающие окна и переключение папок.
• Приложения для Outlook: приложения Outlook позволяют пользователям и администраторам расширять возможности Outlook в Интернете
• Предварительный просмотр ссылки: это позволяет пользователям вставлять ссылку в сообщения, а Outlook в Интернете автоматически генерирует богатый предварительный просмотр, чтобы дать получателям заглянуть в содержимое адресата. Это также работает с видео-ссылками. Поэтому каждая ссылка будет генерировать предварительный просмотр, и у вас есть возможность удалить предварительный просмотр. Предварительный просмотр всегда хорош, потому что он дает введение ссылки.
• Режим офлайн: в Exchange 2016 мы можем использовать OWA, переименованный в OOTW, в автономном режиме без Интернета. Это означает, что нам не нужна лицензия на Outlook, и мы можем продолжать читать и писать электронные письма без Интернета в OOTW.

Посмотрим, как это работает. Приложения Internet Explorer 11 и Windows Store с использованием JavaScript поддерживают AppCache, как определено в спецификации HTML5. Это позволяет создавать автономные веб-приложения. AppCache позволяет веб-страницам кэшировать ресурсы локально, включая изображения, библиотеки сценариев, таблицы стилей и т. д. Кроме того, AppCache позволяет отправлять URL-адреса из кэшированного контента с использованием стандартного унифицированного идентификатора ресурса (URI).

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

• Microsoft Edge
• Internet Explorer 11 и более поздние версии
• Google Chrome 44 и более поздние версии
• Firefox 39 и более поздние версии
• Safari 8 и более поздние версии (только для OS X/iOS)

Поддержка современной аутентификации для Outlook:

Exchange 2016 поддерживает модель аутентификации библиотеки подлинности Active Directory в Outlook клиентах в Windows и других ОС. ADAL позволит использовать двухфакторную аутентификацию, которая помогает в обеспечении безопасности данных для многих организаций.

MAPI через HTTP

MAPI через HTTP — это протокол по умолчанию в Exchange 2016, который Outlook использует для подключения и связи с сервером Exchange. Это более надежный и стабильный протокол на транспортном уровне модели OSI, который может обнаруживать ошибки транспортного уровня более высокого уровня и улучшать восстановление. Одна из лучших особенностей этого протокола заключается в том, что он может приостановить и возобновить соединение с Outlook, которое позволяет прогнозировать изменение сетей и возобновление из спящего режима. Если клиент Outlook не поддерживает этот протокол, он будет продолжать подключаться с помощью Outlook Anywhere.

Если мы устанавливаем Exchange 2016 в смешанном режиме, тогда при запуске Exchange 2016 мы увидим предупреждение, как показано ниже.

Для его включения необходимо выполнить следующую команду.

Set-OrganizationConfig –MapihttpEnable $true

Сотрудничество с документами

Outlook в Интернете позволит пользователям получать линки на документы, хранящимися в OneDrive for Business, и размещать их на локальном сервере SharePoint вместо прикрепления файла к сообщению. Это похоже на Office 365.

Если файл Word, Excel или PowerPoint, хранящийся в локальных SharePoint или OneDrive для бизнеса включен в сообщение электронной почты, полученное пользователем на Exchange 2016, то теперь у пользователя будет возможность просматривать и редактировать этот файл в Outlook в Интернете наряду с сообщением (чтобы получить эту функцию в организации должен быть развернут Office Online Server). Для редактирования вложения у пользователя должна быть лицензия клиента Office.

Еще немного улучшений:

• Сохранить файл в OneDrive
• Загрузите файл в OneDrive
• Недавно используемые списки, заполненные как локальными, так и сетевыми файлами.

Поток почты:
В Exchange 2016 полностью изменена архитектура транспорта. Ниже краткий обзор изменений:

Транспортный поток: В Exchange 2016 транспортный поток имеет несколько различных услуг: транспортная служба Front End Transport, транспортная служба и служба транспорта почтовых ящиков. То же самое, что и в Exchange 2013.

Маршрутизация: Маршрутизация почты в Exchange 2016 распознает границы DAG, а также границы сайта Active Directory. Кроме того, улучшена маршрутизация почты, чтобы отправлять сообщения в очередь непосредственно для внутренних получателей.

SafetyNet: транспортная корзина Exchange 2016 была улучшена и переименована в Safety Net.

Safety Net представляет собой концепцию первичной сети безопасности и теневую сеть безопасности. Если первичная сеть безопасности недоступна в течение более 12 часов, запросы на повторную отправку становятся теневыми запросами на повторную отправку, а сообщения повторно отправляются из Shadow Safety Net.

Safety Net берет на себя определенную ответственность за теневое резервирование в среде DAG. Теневая избыточность дублирует электронную почту на сервер почтовых ящиков на втором сайте AD и подтверждает доставку.

Теневая избыточность не требует сохранения другой копии доставленного сообщения в теневой очереди, пока ожидается, что доставленное сообщение будет реплицироваться в пассивные копии базы данных почтовых ящиков на других серверах почтовых ящиков в группе доступности баз данных. Копия доставленного сообщения уже хранится в Safety Net, поэтому сообщение может быть повторно отправлено в Safety Network, если это необходимо.

Коннекторы: Максимальный размер сообщения по умолчанию для коннектора отправки или коннектора приема, как указано параметром MaxMessageSize, увеличен с 10 МБ до 25 МБ. Как и в Exchange 2010, у нас есть коннекторы отправки и коннекторы приема.
Мы можем установить коннектор отправки в службе транспорта сервера почтовых ящиков для маршрутизации исходящей почты через транспортный сервер Front End на локальном сайте Active Directory с помощью параметра FrontEndProxyEnabled командлета Set-SendConnector, тем самым объединив путь маршрутизации электронной почты от Транспортной службы.

Коннектор приема: мы можем настроить FrontEnd Transport или Hub Transport. FrontEnd подключается через порт 25, а транспортный блок-концентратор подключается через порт 2525. Если хотим обойти FrontEnd, то нужно обеспечить отправку трафика на порт 2525 для защиты от спама.

Мы можем использовать Exchange Edge Transport server. Exchange 2016 поставляется с пограничным транспортным сервером.

Архитектура транспорта

Предотвращение потери данных

Известно, что DLP является частью истории успеха Exchange 2013, которая сейчас является требованием бизнес-стандарта для многих финансовых организаций. DLP было улучшено и добавилось больше шаблонов для других стран. Улучшенная DLP в Exchange 2016 теперь может идентифицировать, контролировать и защищать 80 различных типов конфиденциальной информации. Здесь можно проверить инвентаризацию конфиденциальных данных.

Правила транспорта
Все мы знакомы с правилами транспорта, которые работают и на уровне сервера, и настраивается для всей организации.
Exchange 2016 добавляет следующие новые функции в правила транспорта:

В правилах транспорта Exchange теперь можно определить 80 различных типов конфигурации DLP.
Появилось новое условие: «Вложение добавлено с этими свойствами, включая любое из этих слов», добавлена проверка свойства вложения для определенных слов. Это условие легко интегрирует правила транспорта Exchange и политики DLP с SharePoint Server, инфраструктурой классификации файлов Windows Server 2012 R2 (FCI) или сторонней классификационной системой.
Добавлено новое действие «Информирование получателя сообщения». Правило транспорта может быть настроено на отправку уведомления получателю с указанным текстом, который может уведомить получателя, что сообщение содержит некоторые проблемы и необходимы действия.
Добавлено еще одно новое действие «Создать отчет об инциденте и отправить его на обновление», чтобы члены списков рассылки могли получать отчет об инциденте.
Предикаты и действия содержат дополнения.

Архивирование на месте, удержание и eDiscovery

В Exchange 2016 добавились следующие улучшения для архивирования на месте, удержания и eDiscovery:

• Поддержка общих папок для e-Discovery и внутреннего удержания на месте

В Exchange 2016 общие папки интегрированы в рабочий процесс e-Discovery и удержания на месте. В Exchange 2016 eDiscovery может искать общедоступные папки, и мы можем помещать In-Place Hold в общие папки. Доступны настройки на основе запросов и времени на основе общих папок.

• Поиск соответствия

В Exchange 2016 представлен новый инструмент поиска eDiscovery под названием Поиск соответствия. Этот инструмент способен выполнить один запрос для очень большого количества почтовых ящиков. Количество почтовых ящиков не ограничено, поэтому поиск по всем почтовым ящикам можно осуществить в одном запросе. Количество поисковых запросов, которые могут работать одновременно, не ограничено.

Поиск соответствия можно запускать из командной консоли Exchange.

Администратору или диспетчеру eDiscovery должна быть назначена роль управления поиском почтового ящика или быть членом группы ролей управления обнаружением для запуска команд поиска соответствия.

• Удержание на месте In-Place Hold — это единая модель удержания, которая позволяет нам удовлетворять требованиям законного удержания в приведенных ниже сценариях:

-Преобразить результаты запроса, который также называется проведением запроса. Это позволяет использовать неизменяемость в почтовых ящиках.

-Установите временное удержание для удовлетворения требований хранения.

-Установить удержание почтового ящика на неопределенное время. Похоже на судебный процесс удержания в Exchange 2010.

-Установить пользователя на несколько вариантов удержания.

• In-Place eDiscovery позволяет авторизованным пользователям искать данные почтовых ящиков во всех почтовых ящиках и копировать сообщения в почтовый ящик обнаружения для обзора, который похож на Exchange 2010, но в Exchange 2016 мы можем запускать один запрос для всех почтовых ящиков, в Exchange 2010 необходимо запустить один запрос на один почтовый ящик. В Exchange 2016 In-place eDiscovery позволяет администраторам обнаружения проводить более эффективный поиск и удержание.

— Federated search — Этот поиск позволяет искать и сохранять данные в нескольких хранилищах данных. В Exchange 2016 можно выполнять поиск In Place eDiscovery Exchange, SharePoint 2013 и Skype for Business. Можно использовать центр eDiscovery в SharePoint 2013 для выполнения поиска и хранения In-place eDiscovery.

— Query-based Hold In-Place — этот поиск позволяет сохранять результаты запроса, который позволяет сохранять неизменность во всех почтовых ящиках.

-Export search results Члены группы Discovery могут экспортировать содержимое почтового ящика в PST-файл из консоли eDiscovery для SharePoint 2013. В то же время командлет запроса на экспорт почтовых ящиков больше не требуется для экспорта почтового ящика в PST-файл.

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

-KQL-синтаксис Язык запросов ключевого слова (KQL) является новым. Менеджеры обнаружения также могут использовать синтаксис языка запросов ключевых слов (KQL) в поисковых запросах. KQL аналогичен расширенному синтаксису запросов поиска Exchange 2010 (AQS).

— In-Place eDiscovery and Hold wizard Члены группы Discovery могут использовать мастер In-place eDiscovery & Hold для выполнения операций eDiscovery и удержания.

Если SharePoint не существует, то в Центре администрирования Exchange будет подмножество eDiscovery.

• Поиск в первичных и архивных почтовых ящиках в Outlook в Интернете. Нет необходимости запускать два отдельных запроса, «Outlook в Интернете» может искать первичные и архивные почтовые ящики в одном запросе.
• Архив контента Skype for Business Теперь в Exchange 2016 можно архивировать содержимое Skype for Business из почтового ящика. Также можно разместить контент Skype for Business в режиме ожидания, используя In-Place Hold и In-place eDiscovery для поиска содержимого Skype for Business, заархивированного в Exchange.

Microsoft Rights Management connector:

В Exchange 2016 мы получаем дополнительное приложение, называемое соединителем Microsoft Rights Management (RMS-коннектор), которое помогает нам повысить защиту данных, подключившись к облачным службам управления правами Microsoft.

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

Аудит:

• Отчеты аудита: в EAC Exchange 2016 присутствуют функции аудита, которые позволяют нам запускать отчеты или экспортировать записи из журнала аудита почтового ящика и журнала аудита администратора. Журнал аудита почтовых ящиков регистрируется всякий раз, когда к почтовому ящику обращается кто-то, кроме владельца почтового ящика. Это помогает определить, кто обратился к почтовому ящику и что было сделано. Журнал аудита администратора регистрирует любое действие на основе командлета Exchange Management Shell, выполняемое администратором. Это помогает во время расследования и устранения неполадок конфигурации и причины проблем, которые могут быть связаны с безопасностью.
• Просмотр журнала аудита администратора Мы можем просматривать записи журнала аудита администратора в EAC вместо экспорта журнала аудита администратора, поскольку это может занять до 24 часов. Мы можем просмотреть его, если перейти в «Управление соблюдением» > «Аудит» и нажать «Просмотреть журнал аудита администратора». Это отобразит до 1000 записей на нескольких страницах.

Защита от вредоносных программ:

Exchange 2016 имеет очень сильные встроенные возможности фильтрации вредоносных программ, которые помогают защитить нашу сеть от вредоносного программного обеспечения, передаваемого по электронной почте. Все электронные письма, отправленные или полученные Exchange 2016, проверяются на наличие вредоносных программ (вирусов и программ-шпионов). Если обнаружено вредоносное ПО, сообщение удаляется. Уведомления могут отправляться отправителям или администраторам, когда зараженное сообщение удаляется и не доставляется. Мы можем заменить зараженные вложения на стандартные или настраиваемые сообщения, которые уведомляют получателей об обнаружении вредоносных программ.

Получатели:

Управление получателями Exchange 2016:

• Политика именования групп: теперь мы можем создать политику именования групп, которая позволит нам установить имена групп рассылки в соответствии с политикой компании. Это позволяет нам блокировать некоторые слова. Мы можем указать префикс и суффикс для группы. В EAC выберите «Группы» далее … затем нажать «Настроить политику именования групп».

Можно выполнить следующую команду, чтобы проверить политику

Get-OrganizationConfig | FL DistributionGroupNamingPolicy

Совместное использование и совместная работа:

Улучшения в Exchange 2016.

• Общие папки: общедоступные папки являются почтовыми ящиками общих папок в Exchange 2016, которые находятся в базе данных почтовых ящиков. Таким образом, они могут воспользоваться существующими технологиями высокой доступности и хранения почтовых ящиков. Архитектура общих папок использует специально разработанные почтовые ящики для хранения как иерархии, так и содержимого общих папок. Нет базы данных PF и нет репликации PF. Теперь Exchange 2016 использует модель репликации с одним мастером.
• Общие почтовые ящики: создание и администрирование общих почтовых ящиков улучшилось в Exchange 2016. Теперь мы можем создать общий почтовый ящик за один шаг в центре администрирования Exchange. Для создания общего почтового ящика в EAC перейти к получателям > Общие почтовые ящики.
• Почтовые ящики сайта. В Exchange 2016 мы можем использовать почтовый ящик сайта, чтобы сохранить документ и электронные письма, где электронные письма остаются в базе данных почтовых ящиков, а документы идут в SharePoint. Почтовые ящики сайта улучшают совместную работу и производительность пользователей, позволяя получить доступ к документам Microsoft SharePoint 2013 и электронной почте Exchange с использованием одного и того же клиентского интерфейса. Почтовый ящик сайта функционально состоит из членства на сайте SharePoint 2013 (владельцы и члены), общего хранилища через почтовый ящик Exchange 2013 для почтовых сообщений и сайта SharePoint 2013 для документов и интерфейса управления, который отвечает требованиям к обеспечению и жизненному циклу.

Интеграция с SharePoint и Skype for Business

Exchange 2016 предлагает расширенную интеграцию со Skype for Business и SharePoint 2016. Преимущества этой расширенной интеграции:

• Exchange 2016 может архивировать контент Skype для Business Server 2015 и использует Exchange 2016 как хранилище контактов.
• Менеджер обнаружения может запускать поиск и обнаружение в режиме «Поиск на месте» в Exchange 2016, SharePoint 2013 и Skype for Business.

Пакетное перемещение почтовых ящиков:

Ещё в Exchange 2013 появилось пакетное перемещение почтовых ящиков и общих папок. Работает на основе службы репликации почтовых ящиков с расширенными возможностями управления. Также можно указать путь к файлу csv, чтобы выполнить перемещение.

В пакетное перемещение входят следующие усовершенствования:

• Возможность перемещения нескольких почтовых ящиков большими партиями.
• Уведомление по электронной почте.
• Автоматическое перемещение и автоматическая приоритизация.
• Первичные и личные архивные почтовые ящики могут перемещаться вместе или по отдельности.
• Опция для ручной подачи запроса. Это позволяет нам пересмотреть ход процесса, прежде чем мы его завершим.
• Периодическая инкрементная синхронизация для переноса изменений.

Высокая доступность и устойчивость сайта:

Exchange 2016 также использует копии баз данных DAG и почтовых ящиков для обеспечения высокой доступности с помощью восстановления отдельных элементов, политик хранения, запаздывающих копий базы данных и собственной защиты данных Exchange. Платформа высокой доступности, хранилище информации и расширяемый модуль хранения данных (ESE) были расширены для обеспечения большей доступности, упрощения управления и сокращения затрат.

В то же время в Exchange 2016 есть много улучшений:

• Управляемая доступность. Это одна из лучших новых функций, которая обеспечивает внутреннее отслеживание и функции, ориентированные на восстановление, тесно интегрированы, чтобы помочь предотвратить сбои, активно восстанавливать службы и автоматически инициировать отказы серверов или предупреждать администраторов о принятии мер.
• Управляемое хранилище: новое усовершенствование, обеспечивающее более высокую доступность благодаря повышенной отказоустойчивости.
• Поддержка нескольких баз данных на диске. Как и в Exchange 2013 поддерживается несколько баз данных (1 активную и другие пассивные копии) на одном диске. Это позволяет максимально эффективно использовать более крупные диски с пропускной способностью и IOPS.
• Автоматическое повторное заполнение: AutoReseed — это повторное заполнение, которое автоматически сохраняет данные, если имеется запасной диск того же размера. Поэтому, если диск не работает, Exchange 2016 автоматически перегрузит вашу копию базы данных. Автозаполнение впервые появилось в Exchange 2013  и продолжило свое развитие в Exchange 2016.
• Автоматическое восстановление после сбоев в хранилище: эта функция продолжает инновации с Exchange 2010, чтобы система могла восстанавливаться после сбоев, которые влияют на отказоустойчивость или избыточность. В дополнение к поведению с ошибкой Exchange 2010 Exchange 2016 также включает в себя поведение восстановления для длительных периодов ввода-вывода, чрезмерное потребление памяти с помощью MSExchangeRepl.exe и серьезные случаи, когда система находится в таком плохом состоянии, что потоки не могут быть запланированы.
• Улучшения в отложенной копии: В Exchange 2016 запаздывающие копии могут позаботиться о себе в определенной степени, используя автоматическое воспроизведение журнала. Теперь запаздывающие копии будут воспроизводить файлы журналов во многих ситуациях, например, при восстановлении одной страницы или небольшом диске. Если Exchange Server обнаруживает, что для запаздывающей копии требуется исправление страницы, файлы журнала автоматически заполняются в копию для выполнения исправления страницы. Отложенные копии будут ссылаться на функцию автоматического воспроизведения, когда достигнут порога минимального дискового пространства и когда запаздывающая копия будет обнаружена как единственная доступная копия за определенный период времени. Отложенные копии также могут использовать систему безопасности, что значительно облегчает восстановление или активацию.
• Оповещение об единственной копии: оповещение о единственной копии, появившееся в Exchange 2010, больше не является отдельным запланированным сценарием. Теперь оно интегрировано в компоненты управляемой доступности в системе и является встроенной функцией в Exchange.
• Автоматическая настройка сети DAG: в Exchange 2016 сети групп доступности базы данных могут автоматически настраиваться системой на основе настроек конфигурации. DAG могут различать сети MAPI и репликации, а затем автоматически настраивать сети DAG.
• Нет необходимости в административной точке доступа кластера: с Exchange 2013 с пакетом обновления 1 (SP1) мы имеем возможность создавать DAG без IP-адреса и кластерной точки доступа. В Exchange 2016 Создание DAG по умолчанию не будет иметь точки доступа к IP и кластеру, поэтому рекомендуется устанавливать Exchange 2016 на Windows 2012 R2 или выше.

Управление рабочей нагрузкой Exchange:

Рабочая нагрузка Exchange — это функция, протокол или служба Exchange, которые были явно определены для управления ресурсами системы Exchange. Каждая рабочая нагрузка Exchange потребляет системные ресурсы, такие как CPU, операции с базой данных почтовых ящиков или запросы Active Directory для выполнения пользовательских запросов или выполнения фоновой работы. Примерами рабочих нагрузок Exchange являются Outlook в Интернете, Exchange ActiveSync, миграция почтовых ящиков и помощники почтовых ящиков.

Exchange 2016 имеет два способа управления рабочими нагрузками Exchange:

• Мониторинг работоспособности системных ресурсов: управление рабочими нагрузками на основе состояния системных ресурсов.
• Контроль за потреблением ресурсов отдельными пользователями: контроль использования ресурсов отдельными пользователями был возможен в Exchange 2010, который назывался пользовательским дросселированием, и эта возможность была улучшена в Exchange 2016.

Функции Exchange 2010, которых не стало в Exchange 2016

Архитектура:

Роль транспортного сервера-концентратора:

Эта роль была объединена как транспортные службы в роли почтового ящика Exchange 2016. Роль сервера клиентского доступа: эта роль была объединена как службы клиентского доступа в роли почтового ящика Exchange 2016.

В Exchange 2016 удалили роль сервера клиентского доступа и добавили службы сервера клиентского доступа. Роль почтового ящика остается единственной ролью, и она выполняет все действия.

Exchange больше не сможет использовать балансировку нагрузки сети Windows и DAG в той же инфраструктуре, которая была вариантом для небольшой организации, вместо инвестирования в аппаратные балансировщики.

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

Роль сервера единой системы обмена сообщениями:

Упразднена. Эта роль была объединена как служба унифицированного обмена сообщениями в роли почтового ящика Exchange 2016.

Библиотека MAPI/CDO:

Библиотека MAPI/CDO более не поддерживаются. В Exchange 2016 Exchange Web Services (EWS), API Exchange ActiveSync (EAS) и репрезентативного переноса состояния (REST) заменили библиотеку MAPI/CDO. Если приложение использует библиотеку MAPI/CDO, в Exchange 2016 ему необходимо перейти на EWS, EAS или REST API.

 EMC and ECP:

Все элементы управления входят в Центр администрирования Exchange. EAC использует тот же самый виртуальный каталог ECP.

Клиентский доступ:

Outlook RPC/MAPI:

Outlook Anywhere — единственный способ подключения Outlook к Exchange 2016. MAPI через HTTP является протоколом по умолчанию, а альтернативой является RPC через HTTP. Outlook 2013 SP1 или выше поддерживают MAPI через HTTP.

Outlook 2003 and 2007:

Outlook 2003 и 2007 не поддерживаются в Exchange 2016. Outlook 2003 не поддерживался в Exchange 2013, а в Exchange 2016 Outlook 2007.

OWA(OOTW) and Outlook:

Проверка орфографии: Упразднена встроенная программа проверки орфографии. Теперь OOTW будет использовать проверку орфографии веб-браузера.

Настраиваемые фильтры:

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

Флаги сообщений: Пользовательские данные могут устанавливаться только из Outlook. OOTW не поддерживает его.

Список контактов чата: упразднен список контактов чата, который появился в списке папок в Exchange 2010 OWA.

Поток почты:

Связанные соединители:

В Exchange 2016 мы не можем связать соединитель отправки с соединителем получения. Параметр LinkedReceiveConnector был удален из New-SendConnector и Set-SendConnector.

Анти-спам и защита от вредоносных программ:

Управление антиспамовым агентом в EMC:

Больше нет GUI-управления Анти-спамом и антивирусными программами. Мы можем настроить его только из оболочки управления Exchange.

Агент фильтрации соединений на транспортных серверах-концентраторах:

В Exchange 2016 агент фильтра вложений и агент фильтрации подключений недоступны.

Единственный способ установить агент фильтрации подключений — настроить его на пограничном транспортном сервере.

Управление политиками и соответствие требованиям:

Управляемые папки:

В Exchange 2010 мы использовали управляемые папки для управления хранением сообщений. В Exchange 2016 они заменены политиками хранения и тэгами для MRM.

Мастер управляемых папок:
В Exchange 2010 мы использовали мастер Port Managed Folder для создания тегов хранения на основе настроек управляемой папки и управляемого контента. Эта функциональность упразднена. В Exchange 2016 административный центр Exchange не включает эту функцию. Мы должны использовать команду New-RetentionPolicyTag с параметром ManagedFolderToUpgrade для создания тега хранения на основе управляемой папки. Можно использовать для переноса управляемых папок на тег хранения.

Единая система обмена сообщениями и голосовой почты:

         Поиск по каталогам с использованием автоматического распознавания речи (ASR):

В Exchange 2010 пользователи голосового доступа Outlook использовали речевые входы с использованием функции автоматического распознавания речи (ASR) для поиска пользователей, перечисленных в каталоге. Речевые входы также использовались в Outlook Voice Access для навигации по меню, сообщениям и другим параметрам. Однако мы все еще должны использовать клавиатуру телефона, чтобы ввести свой ПИН-код, и перейти по личным параметрам.

Теперь в Exchange 2016 аутентифицированные и неидентифицированные пользователи голосового доступа Outlook не могут искать пользователей в каталоге с использованием речевых входов или ASR на любом языке.

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

 

Функция Auto Reseed в Exchange 2013

Это одна из интересных функций в Exchange 2013, потому что прежде чем мы узнаем, что у нас есть проблема, она уже исправлена.

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

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

Преимущество использования Auto Reseed заключается не в том, чтобы иметь автоматическое заполнение, но означает, что мы можем планировать сокращение количества копий базы данных. Например, в группе DAG из 48 баз данных с 6 копиями, 4 в производственном центре обработки данных и 2 в центре обработки данных DR, если уменьшить на 1 экземпляр из производственного центра обработки данных с учетом автоматического повтора, тогда он даст 48 дисков, и позволит сэкономить 8- 16 дисков в Spare, поэтому общая экономия составляет минимум 32 диска.

Давайте рассмотрим преимущества Auto Reseed:

1. Автоматическое заполнение сразу после аварии.
2. Уменьшенное количество копий баз данных означает снижение пропускной способности сети.
3. Уменьшенное количество дисков означает снижение стоимости хранения
4. В некоторых случаях уменьшено количество серверов.
5. Системному администратору просто нужно исправить неисправное оборудование.
6. Сокращение ручного вмешательства.
7. Больше не нужно просыпаться ночью.
8. Нет необходимости в мониторинге SCOM.

Auto Reseed использует следующий рабочий процесс:

Служба репликации Microsoft Exchange периодически проверяет копии на наличие статуса FailedAndSuspended.

После того, как служба репликации Microsoft Exchange находит копию с статусом FailedAndSuspended, служба репликации Microsoft Exchange выполняет некоторые предварительные проверки:

Это едининичная ситуация с копией?

Доступны ли запасные диски?

Возможна ли какая-либо проблема при автоматическом повторении?

Когда все проверки успешно пройдены, служба репликации Microsoft Exchange распределяет и переназначает запасной диск.

Затем будет проведено заполнение.

После завершения заполнения служба репликации Microsoft Exchange проверяет, что недавно загруженная копия работоспособна.

Вот все и готово.

Да, служба репликации Microsoft Exchange выделяет и переназначает запасной диск.

На приведенной ниже диаграмме vol1 и vol2 и каждый содержит БД, vol3 является запасным, поэтому, если с vol1 или vol2 случится авария, vol3 будет автоматически заполнен.

Функция Auto Reseed использует три атрибута DAG для обработки. Два атрибута относятся к двум используемым точкам монтирования. Ниже приведен снимок экрана, где эти значения автоматически настраиваются. Таким образом, DAG поставляется с AutoReseed, готовым в Exchange 2013. Следующие три атрибута, которые он использует:

1. Атрибут AutoDagVolumesRootFolderPath относится к точке монтирования, содержащей все доступные тома. Сюда входят тома, на которых размещаются базы данных и запасные тома.

     2. Атрибут AutoDagDatabasesRootFolderPath относится к точке монтирования, содержащей базы данных.

    3. Атрибут AutoDagDatabaseCopiesPerVolume используется для настройки количества копий базы данных на один том.

Рабочий процесс AutoReseed:

1. Обнаружение копии в состоянии Failed and Suspended в течение 15 минут
2. Exchange пытается возобновить копирование 3 раза с промежутком в 5 минут. Когда все 3 попытки потерпят неудачу, переходит к шагу 3
3. Exchange пытается назначить запасной диск 5 раз с промежутком в 1 час.
4. Exchange пытается запустить процесс заполнения на месте с безопасным удалением существующих файлов 5 раз с промежутком в 1 час.
5. Как только все повторные попытки завершены без успеха, рабочий процесс останавливается или в случае успеха завершает заполнение.
6. В случае отсутствия успеха Exchange будет ждать 3 дня и проверять, не исчезла ли копия в состоянии Failed and Suspended, а затем запускает рабочий процесс с шага 1.

Шаги конфигурации:

1. Необходимо настроить корневые пути для баз данных и томов

Set-DatabaseAvailabilityGroup DAG01 -AutoDagDatabasesRootFolderPath “C:\EDBs”   

Set-DatabaseAvailabilityGroup DAG01 -AutoDagVolumesRootFolderPath “C:\EVols”

2. Настраиваем количество баз данных на один том

Set-DatabaseAvailabilityGroup DAG01 -AutoDagDatabaseCopiesPerVolume 1

3. Создаём корневые каталоги для баз данных и томов

Необходимо запустить следующие команды на всех серверах DAG

md C:\EDBs

md C:\EVols

4. Монитруем папки томов

На всех серверах DAG монтируем диски.

а) Открыть Diskmgmt.msc

б) Перевести диски в онлайн

в) Инициализировать диск

г) Затем выбираем каждый диск по одному и щелкаем правой кнопкой мыши.

д) Выбираем новый простой том

е) Выбираем размер раздела (все размеры тома должны быть одинаковыми), затем, нажав на букве диска, в окне пути указываем путь монтирования в соответствии с экраном

ж) Далее — далее — готово

В примере используются 2 тома с базами данных и 1 запасной том, который будет установлен в следующие папки:

• C:\EVols\Vol1
  
• C:\EVols\Vol2
  
• C:\EVols\Vol3

Имена прикрепленных папок могут быть именем любой папки, если папки установлены под корневым томом.

5. Создаём папки базы данных

В примере создаются 2 базы данных, поэтому будем настраивать 2 папки базы данных на всех серверах, как указано ниже:

     md c:\EDBsdb001

     md c:\EDBsdb002

6. Создаём точки монтирования для баз данных

Чтобы проверить guid тома из командной строки запускаем mountvol

Это самый важный шаг, на котором монтируется том для размещения базы данных.

Используется следующий синтаксис:

Mountvol dB path Volume guid

Следующие команды выполняются на всех серверах:

Работает только в командной строке, а не в EMS.

    Mountvol.exe c:\EDBs\db001 ?Volume{GUID}

    Mountvol.exe c:\EDBs\db002 ?Volume{GUID}

Чтобы проверить, выполняем следующую команду.

Mountvol

Мы видим путь базы данных, добавленный к следующему пути тома.

7. Создаём структуру каталога базы данных

В примере используются 2 базы данных для 2 томов, поэтому запускаем следующие команды только на первичном сервере:

    md c:\EDBs\DB001\db001.db

    md c:\EDBs\DB001\db001.log

    md c:\EDBs\DB002\db002.db

    md c:\EDBs\DB002\db002.log

Предыдущие команды повторяем для баз данных на каждом томе.

8. Создание баз данных
Создаём базы данных с путями журналов и баз данных, настроенными с соответствующими папками в соответствии с командлетом ниже на основном сервере.

New-MailboxDatabase -Name db001 -Server servername -LogFolderPath C:\EDBs\db001\db001.log -EdbFilePath C:\EDBs\db001\db001.db\db001.edb

New-MailboxDatabase -Name db002 -Server servername -LogFolderPath C:\EDBs\db002\db002.log -EdbFilePath C:\EDBs\db002\db002.db\db002.edb

9. Монтируем базы данных

Mount-database db001

Mount-database db002

10. Создаём копию баз данных на другом сервере DAG

Add-Mailboxdatabasecopy DBname –MailboxServer servername

Подождём, пока копии базы данных примут состояние healthy.

11. Тестирование автоматического повторного заполнения:
Перейдём в управление дисками и переведём диск с пассивной копией в состояние offline. Vol3 должен стать диском для пассивной копии, и автозаполнение должно начаться с «отказавшего» vol2.

Внимание: в данном примере, если удалить раздел, операция восстановления работать не будет.

Теперь переводим в offline vol2, на котором DB002.

В течение 5 минут статус изменится с Failed and Suspended на статус Seeding. Время заполнения зависит от размера базы данных.

12. Обзор журнала событий.
Теперь проверим событие, чтобы узнать, что произошло. Можно увидеть какие события указывают в какой стадии находится автоматическое заполнение.

EventID 1109: начата операция обработки процедуры автоматического восстановления

Event id 825: начато заполнение копии базы данных

Event id 1110: успешное завершение автоматического восстановления

Event id 826: заполнение копии базы данных завершено

Event id 827 : начинается заполнение каталога

Event id 828: заполнение каталога завершено

Event id 1109: процесс восстановления начался после заполнения, чтобы проверить работоспособность до объявления состояния работоспособности

Event id 1110: процесс заполнения завершен и база данных работоспособна

Всё. Автозаполнение выполнено.

 

Немного траблшутинга

Проблема с обновлением адресной книги.
В клиенте Outlook есть адресная книга, и не одна.
Помимо личного списка контактов, хранящегося в почтовом ящике, Exchange отдает клиентам адресную книгу всей организации. В online режиме Outlook подключается к серверу для того, чтобы получить списки получателей. В крупных инсталляциях число почтовых пользователей измеряется десятками тысяч, и нагрузка на серверы может оказаться довольно значительной. Поэтому в связки Outlook + Exchange Server по умолчанию используется схема синхронизации.

Клиент синхронизирует данные почтовых папок и загружает с сервера offline-адресную книгу (OAB). Сначала клиент качает полную адресную книгу, размер которой может составлять десятки и сотни мегабайт, а потом, на ежедневной основе, небольшие бинарные патчи с изменениями. Но иногда может случиться так, что почтовый клиент перестаёт получать обновления адресной книги на регулярной основе. При попытках обновить вручную ничего не происходит.

Проверяем на стороне Exchange. Адресная книга находится в точке распространения и регулярно обновляется.

Симптомы
Для подключения к почтовому ящику Exchange Server используется Microsoft Outlook. Когда инициируется ручная загрузка адресной книги (автономной) из местоположения HTTP (S), индикатор, который появляется в диалоговом окне Outlook (Ход отправки и получения) останавливается и ничего не происходит. Скачивание не заканчивается, и локальные файлы автономной адресной книги не обновляются.

Причина
Существует несколько известных причин этой проблемы.

• Беспроводные устройства на компьютере устаревшие драйверы.

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

• Политики для фоновой интеллектуальной службы передачи (BITS) настроены на локальной рабочей станции.

Настройки этой политики позволяют контролировать скорость загрузки обновлений. Если значения политики настроены неправильно, то они могут мешать, а то и запрещать загрузки обновлений.

• Фоновая интеллектуальная служба передачи службы не запущена.

Если фоновая интеллектуальная служба передачи служба не запущена, то Outlook не будет загружать автономную адресную книгу. Решение Для решения этой проблемы, можно использовать несколько способов.

• Обновить драйверы для беспроводных устройств.
• Проверить реестр. Если используется HTTP (s) местоположение, из которого следует загрузить автономную адресную книгу, процесс скачивания обрабатывается соответствующим битом. В этом случае необходимо определить, настроены ли биты политики.

БИТЫ политики находятся в следующем ключе реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\BITS
И могут быть настроены следующим DWORD:
EnableBitsMaxBandwidth
MaxBandwidthValidFrom
MaxBandwidthValidTo
MaxTransferRateOnSchedule
MaxTransferRateOffSchedule
Если указано значение EnableBitsMaxBandwith = 1, то это означает, что данный бит регулирует загрузки, а другие биты используются для управлений загрузок. Необходимо отключить бит регулирования, чтобы разрешить скачивание обновлений автономной адресной книги.
Вернёмся к первой причине.
Обновление драйверов беспроводных устройств. Казалось бы, причем они тут? Ответ прост — MAPI idle tasks. Разработчики MAPI (Mail API, с его помощью Outlook общается с Exchange) сделали так, что некоторые вещи происходят только тогда, когда компьютер простаивает. Скачивание Offline Address Book (в том числе и принудительным нажатием кнопки) — одно из них. Что значит «простаивает» для разработчиков Outlook? Простаивает — значит пользователь не двигает мышью, а драйвер не присылает ОС новых координат курсора.
Не менее продвинутые разработчики драйверов для мышей решили, что надо посылать ОС статусное сообщение даже в том случае, если мышь не двигается.
Событие IDLE не наступает никогда. Регулярное обновление драйверов решает данную проблему.

Outlook 2010 и Outlook 2007

Можно использовать следующие шаги, чтобы определить, используется ли HTTP-адрес для загрузки OAB.
1. Запустить Outlook, если он не запущен.
2.Удерживая клавишу CTRL, щелкнуть правой кнопкой мыши значок «Outlook» в области уведомлений в правой части панели задач и выбрать «Проверить автосоединение электронной почты».
3.Щелкнуть, чтобы снять флажок Использовать Guessmart, а затем сниять флажок Secure Guessmart Authentication.
4.Щелкнуть, чтобы установить флажок Использовать автообнаружение.
5. Ввести адрес электронной почты и пароль, если отсутствует, а затем нажать «Тестировать».
6. На вкладке Результаты будет отображен путь к URL-адресу автономной адресной книги.

Если значение URL-адреса автономной адресной книги начинается с HTTP, используется местоположение HTTP (S) для загрузки автономной адресной книги. Если значение URL-адреса автономной адресной книги — это общедоступные папки, то местоположение HTTP (S) для загрузки автономной адресной книги не используется.

Примечание.
Outlook 2016 и Outlook 2013 используют только HTTP-адрес для загрузки автономной адресной книги.

 

Проблема 550 5.7.1 Client does not have permissions to send as this sender.

Симптомы

Клиент пытается совершить отправку сообщения из-под другого пользователя. Казалось бы, что тут сложного, даём права Send As и всё хорошо. Да, в большинстве случаев прав Send As более чем достаточно, но по факту мы получаем ошибку: SEND — Письмо не отправлено. Сервер сообщает: 5.7.1 Client does not have permissions to send as this sender.

Решение
Решение кроется в недрах Active Directory.
Необходимо поправить разрешения на соединителе получения «HubTransport» клиентского прокси-сервера.
ADSI Edit, Configuration -> Services -> Microsoft Exchange -> DOMAINNAME -> Administrative Groups -> Exchange Administrative Group -> Servers -> SERVERNAME -> Protocols -> SMTP Receive Connectors.
Затем открыть свойства для «Client» Proxy SERVERNAME. На вкладке безопасности перейти к «Authenticated Users» и добавить разрешения для «Accept any Sender» and «Accept Authoritative Domain Sender». И всё начинает работать.

Расчеты инфраструктуры Exchange 2013

Введение

«Определение размеров как наука и вид искусства», так говорит Jeff Mealiffe в его потрясающем блоге Ask the Perf Guy: Sizing Exchange 2013 Deployments. Рекомендации для определения размеров инфраструктуры Exchange в настоящее время получили развитие с момента ранних дней появления Exchange. Нельзя сказать, проще или сложнее стало разрабатывать инфраструктуру Exchange, но одно можно сказать наверняка, теперь у нас есть такой продвинутый инструмент, как Exchange Server Role Requirements Calculator, который за нас делает всю работу, но понимание некоторых основных принципов архитектуры и компонентов сервера Exchange по-прежнему фундаментально.

Исторически сложилось, что предоставляемые Microsoft продукты приходят к нам из тестовых лабораторий и промышленных развертываний. В последнее время в Microsoft начали уделять больше внимания производственной среде (имеется в виду, что многие данные поступают из Office 365). Можно предположить, что этот сдвиг может представлять лучшие рекомендации, но нужно помнить, что расчет инфраструктуры Exchange является искусством, а также развивающейся наукой и иногда то, что казалось хорошей рекомендаций сегодня не может так выглядеть в будущем, особенно потому, что пользователи постоянно меняют свое потребление объёмов почтового ящика.

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

Рисунок 1 Роли Exchange Server 2013

Процесс определения размеров

Упрощенный процесс проектирования Exchange будет иметь, по крайней мере, 3 основных этапа:

1. Оценка / Сбор / Определение требований. Если вы эволюционируете существующую инфраструктуру или разрабатываете новую с нуля, необходимо определить исходные условия и допущения для новой архитектуры Exchange. Это включает:

• Профили пользователей: собрать все имеющиеся данные о существующих требованиях профилей пользователей развернутой системы обмена сообщениями или оценить, если это совершенно новое решение. НЕ НУЖНО УГАДЫВАТЬ ПРОФИЛЬ ПОЛЬЗОВАТЕЛЯ!
• Требования к организации, такие как требуемый размер почтового ящика, цели уровня обслуживания, количество сайтов, количество копий базы данных почтовых ящиков, архитектуры хранения, планы роста, развертывание сторонних продуктов и т.д.

2. Расчет необходимой инфраструктуры Exchange. Самый простой и рекомендуемый способ сделать это с помощью инструмента калькулятор. Сделайте несколько итераций с помощью калькулятора, проверьте некоторые возможные аппаратные требования и сценарии высокой доступности для того, чтобы достичь одного конечного результата, что будет иметь смысл для вас не только с технической, но и с финансовой точки зрения.
3. Проверка решения. Используйте инструменты, такие как Jetstress для проверки конструкции хранения, а также выполните другие необходимые лабораторные испытания до начала производства, чтобы гарантировать, что производство и реализация не доставит проблем.

Минимальные требования Exchange Server 2013

В качестве отправной точки, мы можем рассмотреть аппаратные минимумы для Exchange Server 2013:

• 64Bit CPU
• 8 ГБ оперативной памяти для сервера с ролью почтовых ящиков, 4 ГБ для сервера с ролью клиентского доступа, или 8 Гб для мультиролевых серверов
• Файл подкачки = RAM + 10MB
• 30GB свободного места на диске установки плюс 500 МБ для каждого языкового пакета
• 200MB свободно на системном диске
• 500MB свободно на диске очереди
• Диски отформатированы в файловой системе NTFS

Рабочий пример

Для того, чтобы лучше проиллюстрировать процесс расчета, давайте рассмотрим следующую конфигурацию для нашей будущей инфраструктуры Exchange.

• 5000 почтовых ящиков
• 200 сообщений/день, со средним размером сообщения 75KB
• 10GB квота почтового ящика
• Единый сайт
• 3 копии базы данных почтовых ящиков, отсроченных копии нет
• 2U платформа для сервера с 12 внутренними отсеками для дисков
• 2х дисковый массив RAID под диск для операционной системы и двоичных файлов Exchange
• 1 запасной диск
• 9 дисков для хранения баз данных почтовых ящиков
• Используются 7200 RPM 4 Тб диски SAS среднего ценового диапазона
• Базы данных почтовых ящиков хранятся на JBOD с прямым подключением, не используя RAID
• 8 узлов DAG, поддержка отказа 2 узлов

Роль почтовых ящиков

Профиль пользователя обычно определяет потребности в ресурсах, но вы должны учитывать некоторые факторы, которые влияют на расчет, такие как:

• Количество почтовых ящиков
• Механизмы безопасности / аудит
• Использование мобильных устройств
• Режим Outlook (онлайн / кэширование)
• Управление записью сообщений / Архивирование
• Высокая доступность (DAG)

Диск

Требования к диску для роли Почтовый ящик состоят из:

• Емкость (ГБ)
• Производительность (IOPS)

Для определения фактического размера почтового ящика на диске, мы должны учитывать 3 фактора: квота хранения, чистый объём базы данных и объём восстанавливаемых элементов. Расчет пробела базы данных на каждый ящик = количество сообщений/день х средний размер сообщения = 200 х 75 = 14.65MB (в нашем примере). Размер папки восстанавливаемых элементов (количество сообщений/день х средний размер сообщения х время хранения удаленных элементов) + (размер квоты почтового ящика х 0,012) + (размер квоты почтового ящика х 0,03) = (200 х 75 х 14) + (10GB х 0,012) + (10GB х 0,03) = 635.16MB (в нашем примере). Фактический размер почтового ящика на диске = квота почтового ящика + пробел базы данных + папка восстанавливаемых элементов. В нашем примере, фактический размер почтового ящика будет 10GB + 14.65MB + 635.16MB = 10.63GB. Для того, чтобы рассчитать общее необходимое пространство для хранения, мы должны использовать следующую формулу:

Общий объём = Пространство почтового ящика + Пространство индексируемого содержимого + пространство логов.

Пространство индексируемого содержимого

Пространство индексированного содержимого базы = размер базы х 0,20. Пространство индексируемого содержимого на диске = (средний размер базы данных х (количество баз данных на диске + 1) х 0,20).

ПРОСТРАНСТВО ДЛЯ ПОЧТОВОГО ЯЩИКА

1. Рассматривается 5% свободного места на диске

Доступное пространство (за исключением требуемого свободного пространства) = Форматированная емкость диска х (1 — свободное пространство)

2. Регулирование размера диска к отформатированному размеру. В нашем примере, 4ТБ диски будут иметь 3725 ГБ
3. Подсчет максимального количества баз данных на диск, предполагая, что максимальный размер каждой <1 ТБ. В этом примере давайте предположим, 4 базы на диск.
4. Подсчет необходимого пространства индексированного содержимого. Пространство, необходимое для индексирования контента будет составлять 20% от размера базы данных, с дополнительным 20% от одной базы данных контента для задач обслуживания индексации.
5. Теперь мы можем удалить пространство для индексирования содержимого из нашего свободного места на томе:
6. Получить наш максимальный размер базы данных, разделить последний результат на желаемое количество баз данных на одном диске.
7. Приняв это значение, мы можем затем рассчитать наше максимальное количество пользователей в базе данных (с точки зрения мощности):

С 9 томами баз данных и 4 копий базы данных каждого тома, мы можем иметь всего до 36 копий баз данных на одном сервере.

С 96 активных копий и 66 пользователей в базе данных, мы можем обслуживать максимум 66 х 96 = 6336 пользователей. Так как нам нужно только 5000 пользователей, мы можем продолжать с этой конфигурацией. Если максимальное количество пользователей уступало требуемому, у нас было бы 2 варианта:

1. Увеличить число узлов DAG
2. Увеличить количество дисковых томов на одном сервере. Имейте в виду, что каждый сервер Exchange ограничен до 100 баз данных.

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

Оценочный размер базы данных = 66 пользователей х 10.63GB = 701.58GB

Потребление базы данных/том = 701.58GB х 4 базы данных = 2806.32GB

Используя формулу, которая упоминалось ранее, мы можем вычислить нашу оценку потребления индекса контента:

701.58GB размер базы данных х (4 базы данных + 1) х 0,20 = 701.58GB

ПРОСТРАНСТВО ЖУРНАЛОВ

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

Профиль сообщения (средний размер сообщения 75 KB)	Количество журналов транзакций генерируемых в день
50	10
100	20
150	30
200	40
250	50
300	60
350	70
400	80
450	90
500	100

Таблица 1

Потенциальный размер журнала для поддержки 3-х дней усечения в случае отказа = (66 почтовых ящиков/база х 40 журналов/день х размер журнала 1MB) х 3 дня = 7.62GB

Потенциальный размер журнала для поддержки перемещения 1% почтовых ящиков в неделю = 66 почтовых ящиков/база данных х 0,01 х 10.63GB размер почтового ящика = 7.02GB

Итоговое требуемое пространство для каждой базы данных = 7.62GB + 7.02GB = 14.64GB

Требуется пространство/том = 14.64GB х 4 базы данных = 58.56GB

ИТОГОВОЕ ДИСКОВОЕ ПРОСТРАНСТВО

Итоговое пространство = Пространство под почтовый ящик + Пространство под индексированное содержимое + Пространство под журналы = 2806.32GB + 701.58GB + 58.56GB = 3566.46GB

Так как у нас в общей сложности 5000 пользователей, и каждая база данных имеет 66 пользователей, нам понадобится 76 баз данных почтовых ящиков. Так как у нас базы в 3-х экземплярах, общее количество баз данных в DAG будет 76 х 3 = 228. Так как мы на каждом диске размещаем 4 базы данных, нам нужно в общей сложности 228/4 = 57 дисков.

Общий используемый для хранения будет 57 х 3566.46GB = 198.52TB.

IOPS

Количество отправленных/полученных сообщений на ящик в день	Оцениваемый   IOPS на ящик (Активная или Пассивная копия базы данных)
50	0.034
100	0.067
150	0.101
200	0.134
250	0.168
300	0.201
350	0.235
400	0.268
450	0.302
500	0.335

Таблица 2

Используя наш пример:

66 почтовых ящиков x 4 базы данных на диске х 0.134 IOPS / 200 сообщений на почтовый ящик/день = 35,38 IOPS на диск

CPU

Оценочное потребление CPU для почтовых ящиков:

Количество отправленных/полученных сообщений на ящик в день	Mcycles   на пользователя, Активная копия базы данных или отдельностоящий сервер почтовых ящиков	Mcycles на пользователя, Пассивная копия базы данных
50	2.13	0.69
100	4.25	1.37
150	6.38	2.06
200	8.50	2.74
250	10.63	3.43
300	12.75	4.11
350	14.88	4.80
400	17.00	5.48
450	19.13	6.17
500	21.25	6.85

Таблица 3

Продолжая наш пример. Требования высокой доступности для проектирования на примере 5000 пользователей привело к общей сложности 76 активных баз данных, разделенных на 6 узлов (2 узла на случай отказа). То есть мы будем иметь максимум 13 активных баз данных в любой момент времени из 29 копий базы данных на сервере (228/8) и мы знаем, что существует 66 пользователей в базе данных. Таким образом, мы можем определить требования к процессору для каждого сервера нашего развертывания.

(13 баз данных x 66 ящиков x 8.5 mcycles на ящик в активной копии) + (16 баз данных x 66 ящиков x 2.74 mcycles на ящик в пассивной копии) = 7293 + 2893.44 = 10,186.44 mcycles на сервер.

1. Ищем на SPECint_rate2006 оценку для процессора, который вы собираетесь использовать для решения Exchange.

На сайте Standard Performance Evaluation Corporation, выбираем Results, далее CPU2006, и выбираем Search all SPECint_rate2006 results.

Под Simple Request, введите критерии поиска для вашего целевого процессора, например, Processor Matches E5-2630.

Найдите конфигурацию сервера и процессор, в использовании которого вы заинтересованы (или, если точная комбинация не доступна, найти что-то как можно ближе) и запишите значение в столбце Result и значение в столбце # Cores.

2. Получение SPECint_rate2006 счет на одно ядро путем деления значения в столбце Result на значение в # Cores.
3. Для определения ожидаемого количества мегациклов рабочей нагрузки Exchange на целевой платформе, используйте следующую формулу:
4. Убедитесь, что максимальная загрузка процессора не поднимается выше 80%.

Память

• Минимальный объем памяти должен быть всегда 8GB
• Используйте следующие значения для расчета общей памяти на один сервер

Количество полученных/отправленных сообщений в день на ящик	Роль сервера почтовых ящиков   (MB)
50	12
100	24
150	36
200	48
250	60
300	72
350	84
400	96
450	108
500	120

Таблица 4

Память почтовых ящиков на сервере-= (наихудшие активные копии баз данных на сервере-пользователей х за базу данных х памяти за активный почтовый ящик)

Количество копий баз данных на сервер	Минимум памяти (GB)
1-10	8
11-20	10
21-30	12
31-40	14
41-50	16

Таблица 5

В нашем примере, так как у нас есть максимум 13 активных копий баз данных на одном сервере, необходимая память будет 13 х 66 х 48MB = 40,2GB (округляем до 48GB).

Сеть

• 1 х Gbit минимум
• DAG — каждый сервер должен иметь по крайней мере две сети: одну сеть MAPI и сеть репликации.

Как посчитать размер других ролей Exchange Server 2013 и проверить окончательный дизайн.

Роль клиентского доступа

Роль CAS снова изменилась с этой версией Exchange, теперь это в основном прокси без сохранения состояния. CAS также имеет минимальные требования к аппаратным средствам, что делает развертывание серверов с мультиролью более привлекательным.

CPU

• 2013 CAS требует 25% от mcycles активного пользователя сервера почтовых ящиков (соотношение 1: 4)

Память

4GB минимум

Память на сервер CAS = 2 Гб + 2 Гб на каждое ядро физического процессора

диск

нет особых потребностей относительно дисковой подсистемы

сеть

Gbit рекомендуется

Мультироль

На самом деле существует рекомендация использовать мультирольный подход при проектировании инфраструктуры Exchange 2013. При сборе ролей CAS и почтовых ящиков на сервере, количество памяти и мощность процессора должны быть скорректированы.

Память

1. Использовать расчеты для роли почтового ящика
2. Посчитать дополнительную память, используя следующую формулу:

CPU

Используйте эту таблицу вместо той, которая предусмотрена в разделе роли почтового ящика:

Количество полученных/отправленных сообщений в день на ящик	Mcycles на пользователя, Активная копия базы данных или мультироль
50	2.66
100	5.31
150	7.97
200	10.63
250	13.28
300	15.94
350	18.59
400	21.25
450	23.91
500	26.56

Таблица 6

Роль Edge

Роль Edge была введена с пакетом обновления 1 для Exchange 2013 и это в основном безопасный транспортный сервер для размещения в сети периметра.

CPU

	Антивирус и Антиспам установлены	Антивирус и Антиспам не установлены
Рекомендуемые ядра процессора / сервер	8	4
Ядра Edge: соотношение к ядрам сервера почтовых ящиков	1:5	1:7

Таблица 7

 

Память

• 4GB минимум
• 1 Гб / ядро

диск

• Емкость для хранения размер требуемой очереди
• Используйте следующие расчеты по размеру общего размера транспортной базы данных:

Общий трафик ежедневных сообщений = число пользователей х сообщений профиля

Общий размер базы данных транспорта = средний размер сообщения х общий дневной трафик сообщений х (1 + (процент сообщений в очереди х максимум дней очереди) + дней удержания) х 2-х экземпляра для обеспечения высокой доступности

В нашем примере:

Общий размер базы данных транспорта = 75KB х (5000 пользователей х 200 сообщений / день) х (1 + (50% х 2 дня максимум очереди) + 2 дня удержания) х 2 копии = 429GB

сеть

• Gbit рекомендуется

Виртуализация

Поскольку виртуализация популярна в развертывании Exchange, вот несколько советов и рекомендаций:

• Размер для физических ресурсов, добавить ~ 12% нагрузку на процессор при гипервизоре
• Не превышать намеченную сумму ресурсов

Не использовать динамическую память

• Хост-отказоустойчивые кластеризации и миграционные технологии поддерживаются, но они должны приводить к холодной загрузке или использования технологии, аналогичной технологии Hyper-V Live Migration для онлайн миграции
• Моментальные снимки не поддерживаются
• Максимум 2: 1 виртуальное соотношение физического процессора, 1: 1 рекомендуется
• Необходимо использовать хранилище на уровне блоков
• VHDs должен быть фиксированного размера
• Данные Exchange должны быть размещены на отдельном от гостевых виртуальных машин хранилище
• Важная техническая документация:

Exchange 2013 virtualization

Best Practices for Virtualizing & Managing Exchange 2013

Проверки решения

Перед тем как запустить ваши недавно подсчитанные серверы в производстве, может быть, вы хотите, чтобы провести некоторые проверки развернутой конфигурации. Есть некоторые инструменты от Microsoft, которые могут помочь вам с этой задачей:

1.Microsoft Exchange Server Jetstress 2013 — Jetstress имитирует базы данных Exchange и загружает файл журнала, произведенные определенным количеством пользователей, таким образом, что позволяет проверить производительность и стабильность дисковой подсистемы, прежде чем запустить серверы в производственной среде.

2.Exchange Load Generator 2013 — Использование Microsoft Exchange Load Generator 2013 (LoadGen) в качестве инструмента моделирования для измерения воздействия MAPI, OWA, ActiveSync, IMAP, POP и SMTP клиентов на серверах Exchange 2013. LoadGen позволяет проверить, как сервер под управлением сервера Exchange 2013 отвечает на электронную почту под нагрузкой. Чтобы смоделировать доставку этих запросов обмена сообщениями, вы запускаете LoadGen тесты на клиентских компьютерах. Эти тесты отправляют несколько запросов сообщений на сервер Exchange, тем самым вызывая нагрузки. LoadGen является полезным инструментом для администраторов, которые занимаются расчетами размеров серверов и проверками плана развертывания. В частности, LoadGen поможет вам определить, сможет ли каждый из серверов справиться с нагрузкой.

3.Performance Monitor — часть операционной системы, PerfMon использует объекты производительности Exchange для получения информации счетчика, содержит информацию, которая позволяет оценить состояние здоровья вашего решения обмена сообщениями.

4.Managed Availability — Проверка на события, связанные с производительностью проверки производительности, сделанных зондами.

 

Предпочтительная архитектура Exchange 2016

Предпочтительная Архитектура (ПА) является практической рекомендацией инженерной команды Exchange. Лучшее из того, что является оптимальной архитектурой развертывания для Exchange 2016 и очень похоже на развертывания Office 365.

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

ПА разработан с учетом нескольких бизнес-требований, например, требование о том, что архитектура сможет:

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

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

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

ПА состоит из четырех приоритетных областей:

• Дизайн пространства имен
• Дизайн центра обработки данных
• Дизайн сервера
• Дизайн группы доступности баз данных

Дизайн пространства имен

В планировании пространства имен и принципах балансировки нагрузки изложены различные варианты конфигурации, которые доступны в Exchange 2016. Для пространства имен можно выбрать либо развертывание связанного пространства имен (подключение пользователей к определенному центру обработки данных) или несвязанное пространство имен (подключение пользователей к любому центру обработки данных без предпочтения).

Рекомендуемый подход заключается в использовании неограниченной модели развертывания единого пространства имен Exchange, в соответствии с протоколом клиента для пары сайта с устойчивыми ЦОД (где предполагается, что каждый центр обработки данных представляет свой сайт Active Directory). Например:

autodiscover.contoso.com

Для HTTP-клиентов: mail.contoso.com

Для IMAP клиентов: imap.contoso.com

Для SMTP клиентов: smtp.contoso.com

Каждое пространство имен Exchange используется с балансировкой нагрузки для обоих центров обработки данных в конфигурации L7 без привязки сеансов, в результате чего пятьдесят процентов трафика проксируется между центрами обработки данных. Трафик распределяется равномерно по всем центрам обработки данных для устойчивой пары сайтов с помощью round robbin DNS, geo-DNS или других аналогичных решений. С точки зрения упрощения, данное решение является наименее сложным и легче управляемым, поэтому рекомендация заключается в использовании round robbin DNS.

Для фермы серверов Office Online, пространство имен центров обработки данных развернуты с использованием балансировки нагрузки L7, сохраняя привязку сеансов с  использованием сходства на основе файлов cookie.

В случае, если есть несколько сайтов устойчивой пары ЦОД, нужно будет решить, использовать единое пространство имен, или если нужно контролировать трафик для каждого конкретного центра обработки данных, с помощью региональных пространств имен. В конечном счете, решение зависит от топологии сети и связанные с этим расходы при использовании несвязанной модели. Например, если есть датацентры, расположенные в Северной Америке и Европе, сетевое соединение между этими регионами может быть не только дорого, но это также может иметь высокую латентность. В этом случае, имеет смысл развернуть связанную модель с отдельным пространством имен для каждого региона. Тем не менее, варианты, как географических DNS предлагают возможность развертывания единого унифицированного пространства имен, даже если используются дорогостоящие сетевые связи; geo-DNS позволяет направлять пользователей к ближайшему центру обработки данных на основе IP-адреса своих клиентов.

Дизайн устойчивого сайта пары центров обработки данных

Для достижения высокой доступности архитектуры устойчивого сайта, необходимо иметь два или более центров обработки данных, которые хорошо связаны (в идеале, имеют более низкую латентность сети туда-обратно, в противном случае всё отрицательно сказывается на репликации и подключении клиента). Кроме того, центры обработки данных должны быть подключены через избыточных сетевых каналов , поставляемых различными провайдерами.

В то время как сайт Active Directory поддерживает растягивание между несколькими центрами обработки данных, для ПА существует рекомендация, чтобы каждый центр обработки данных имел свой собственный сайт Active Directory. Есть две причины:

Устойчивость транспорта сайта с помощью теневой избыточности и безопасности сети можно достичь только тогда, когда группа доступности баз данных расположена в более чем одном сайте Active Directory.

Подсети должны быть размещены на различных сайтах Active Directory, когда между подсетями задержки больше 10 мс. 

Дизайн сервера

В ПА, все серверы физические. Развертывание на физических серверах рекомендуется по двум причинам:

Серверы маштабируются с использованием 80% ресурсов.

Виртуализация добавляет дополнительный слой управления и сложности, который вводит дополнительные режимы восстановления, которые сказываются на функциональности Exchange.

Серверные платформы, используемые в ПА. Платформы включают в себя:

2U, два процессора (20-24 ядер)

до 96 ГБ памяти

контроллер кэш записи с питанием от батареи

12 или более дисковых отсеков внутри корпуса сервера

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

Каждый сервер содержит одну пару дисков RAID1 для операционной системы, двоичных файлов Exchange, журналов протокол / клиент и транспортной базы данных. Остальная часть хранения сконфигурирована как JBOD, используя диски большой емкости 7.2K RPM Serial Attached SCSI (SAS) (в то время как SATA диски также доступны, эквивалент SAS обеспечивает лучшую IO и ниже годовую статистику отказов).

Каждый диск, который содержит базы данных почтовых ящиков Exchange отформатирован ReFS (с отключенной функцией целостности) и группа доступности баз данных  имеет такую ​​конфигурацию, что AutoReseed форматирует диски в ReFS:

Set-DatabaseAvailabilityGroup <DAG> -FileSystem ReFS

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

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

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

Дизайн группы доступности баз данных

На каждой площадке устойчивой пары ЦОД имеется одна или несколько групп DAG.

Конфигурация DAG

Как и в модели пространства имен, каждый DAG в пределах участка устойчивой пары ЦОД работает в несвязанной модели с активными копиями, распределенных в равной степени на всех серверах в группе DAG.

Эта модель:

1. Гарантирует, что каждый член DAG обеспечивает доступность сервисов (подключение клиента, репликации, транспорт и т.д.) во время обычных операций.
2. Распределяет нагрузку по всем доступным серверам во время сценария отказа, тем самым увеличивая постепенно использование ресурсов между оставшимися членами в пределах DAG.

Каждый центр обработки данных является симметричным, с равным числом членов DAG в каждом центре обработки данных. Это означает, что каждый DAG содержит четное количество серверов и использует следящий сервер для кворума обслуживания.

DAG является фундаментальным блоком в Exchange 2016. В отношении размера DAG, большая DAG обеспечивает более высокую степень избыточности и ресурсов. В ПА, цель заключается в развертывании крупных группы DAG (обычно начиная с восьми членов DAG и увеличения количества серверов в соответствии с требованиями, чтобы удовлетворить бизнес-требования). При необходимости масштабирования в случае недостаточности ресурсов необходимо создавать новые группы DAG.

Дизайн сети DAG

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

Размещение сервера свидетеля

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

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

Если третьего расположения нет в наличии, можно рассмотреть вопрос о размещении свидетеля в Azure. Как альтернатива, разместить следящий сервер в одном из центров обработки данных в пределах устойчивого сайта пары центров обработки данных. Если есть несколько групп DAG в пределах участка устойчивого сайта пары ЦОД, поместить следящий сервер для всех групп DAG в одном центре данных (как правило, центре обработки данных, где большинство пользователей находятся физически). Кроме того, необходимо убедиться, что Primary Active Manager (PAM) для каждого DAG также находится в одном центре данных.

Отказоустойчивость данных

Устойчивость данных достигается путем развертывания нескольких копий баз данных. В ПА копии баз данных распределяются по площадке устойчивой пары ЦОД, тем самым гарантируя, что данные сообщения защищены от сбоев программного обеспечения, аппаратных средств и даже ЦОД.

Каждая база данных имеет четыре копии, с двумя экземплярами в каждом центре обработки данных, что означает, как минимум, что ПА требует четыре сервера. Из этих четырех копий, три из них настроены как копии высокой доступности. Четвертая копия (копия с самым высоким предпочтением активации) выполнена в виде отсроченной копии базы данных. Благодаря конструкции сервера, каждый экземпляр базы изолирован от других его копий, тем самым снижая домены отказов и увеличения общей доступности решения.

Цель отсроченной копии базы данных, чтобы обеспечить механизм восстановления для редких случаев общесистемного, катастрофического или логического сбоя. Она не предназначена для индивидуального восстановления почтового ящика или восстановления объектов почтового ящика.

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

При использовании отсроченной копии базы данных в этом виде, важно понимать, что данная копия базы данных не является гарантией резервного копирования точка-в-время. Отсроченная копия базы данных будет иметь порог доступности, как правило, около 90%, из-за периода, когда диск, содержащий отсроченную копию выходит из строя, отсроченная копия становится копией высокой доступности (за счет автоматического воспроизведения вниз), а также периоды, когда отсроченная копия базы данных вновь перестраивает очередь воспроизведения.

С учетом всех этих технологий, традиционные резервные копии не нужны; в результате, ПА использует Exchange Native Data Protection.

Дизайн серверов Office Online

Как минимум необходимо будет развернуть два сервера  Office Online в каждом центре обработки данных, где размещены серверы Exchange 2016. Каждый сервер Office Online должен иметь 8 процессорных ядер, 32GB памяти и по меньшей мере 40 ГБ пространства, предназначенном для лог-файлов.

Серверы Exchange в определенном центре обработки данных настроены на использование местной фермы серверов Office Online с помощью следующей команды:

Set-MailboxServer <East MBX Server> –WACDiscoveryEndPoint https://oos-east.contoso.com/hosting/discovery

Резюме

Эти изменения упрощают развертывание Exchange, не уменьшая доступность или отказоустойчивость развертывания. А в некоторых случаях, по сравнению с предыдущими поколениями, ПА повышает доступность и отказоустойчивость развертывания.

Клонирование соединителей приема Exchange 2013

Best Practic Microsoft рекомендует запустить все роли сервера Exchange по крайней мере на 2 серверах. Итак, когда развернут новый HubTransport или HubTransport + сервер почтовых ящиков — мы сталкиваемся с задачей дублировать SMTP-соединители получения для принтеров, устройств и других сервисов и приложений, таких как MSSQL, мониторинга и отчетности и т.д. Средние и крупные организации могут использовать несколько таких соединителей с десятками адресов и диапазонов, поэтому копирование вручную с сервера на сервер неблагодарное занятие.
Вот один из способов клонировать соединители со всеми конфигурациями массово.

1. Давайте определим сервер источник — «old server», где мы получаем соединители и сервер назначения — «new server»:

$OldServer = «YourSourseExchangeFQDN»
$NewServer = «YourTargetExchangeFQDN»

2. Таким образом, мы получаем список из SMTP-соединителей получения по умолчанию для соединителей Exchange, которые являются уникальными в каждом сервере и автоматически создаются во время установки сервера, за рядом исключений. Эти соеденители обычно «Client Frontend имя_сервера«, «Client Proxy имя_сервера«, «Default имя_сервера«, «Default Frontend имя_сервера«, и «Outbound Proxy Frontend имя_сервера» и так далее.

[array]$ReceiveConnectors = Get-ReceiveConnector -Server $OldServer | Where {$_.Name -notlike «*Default*» -and $_.Name -notlike «*Client*» -and $_.Name -notlike «*Proxy*»}

3. Затем проверяем создание новых соединителей на новом сервере:

$ReceiveConnectors | foreach {New-ReceiveConnector -Name $_.Name -AuthMechanism $_.AuthMechanism -BinaryMimeEnabled $_.BinaryMimeEnabled -Bindings $_.Bindings -ChunkingEnabled $_.ChunkingEnabled -DeliveryStatusNotificationEnabled $_.DeliveryStatusNotificationEnabled -EightBitMimeEnabled $_.EightBitMimeEnabled -DomainSecureEnabled $_.DomainSecureEnabled -EnhancedStatusCodesEnabled $_.EnhancedStatusCodesEnabled -LongAddressesEnabled $_.LongAddressesEnabled -OrarEnabled $_.OrarEnabled -SuppressXAnonymousTls $_.SuppressXAnonymousTls -AdvertiseClientSettings $_.AdvertiseClientSettings -ServiceDiscoveryFqdn $_.ServiceDiscoveryFqdn -TlsCertificateName $_.TlsCertificateName -Comment $_.Comment -Enabled $_.Enabled -ConnectionTimeout $_.ConnectionTimeout -ConnectionInactivityTimeout $_.ConnectionInactivityTimeout -MessageRateLimit $_.MessageRateLimit -MessageRateSource $_.MessageRateSource -MaxInboundConnection $_.MaxInboundConnection -MaxInboundConnectionPerSource $_.MaxInboundConnectionPerSource -MaxInboundConnectionPercentagePerSource $_.MaxInboundConnectionPercentagePerSource -MaxHeaderSize $_.MaxHeaderSize -MaxHopCount $_.MaxHopCount -MaxLocalHopCount $_.MaxLocalHopCount -MaxLogonFailures $_.MaxLogonFailures -MaxMessageSize $_.MaxMessageSize -MaxProtocolErrors $_.MaxProtocolErrors -MaxRecipientsPerMessage $_.MaxRecipientsPerMessage -PermissionGroups AnonymousUsers -PipeliningEnabled $_.PipeliningEnabled -ProtocolLoggingLevel $_.ProtocolLoggingLevel -RemoteIPRanges $_.RemoteIPRanges -RequireEHLODomain $_.RequireEHLODomain -RequireTLS $_.RequireTLS -EnableAuthGSSAPI $_.EnableAuthGSSAPI -ExtendedProtectionPolicy $_.ExtendedProtectionPolicy -TlsDomainCapabilities $_.TlsDomainCapabilities -TransportRole $_.TransportRole -SizeEnabled $_.SizeEnabled -TarpitInterval $_.TarpitInterval -MaxAcknowledgementDelay $_.MaxAcknowledgementDelay -Server $NewServer -WhatIf}

4. Если результат совпадает с ожиданиями, то ключ -WhatIf опускается:

$ReceiveConnectors | foreach {New-ReceiveConnector -Name $_.Name -AuthMechanism $_.AuthMechanism -BinaryMimeEnabled $_.BinaryMimeEnabled -Bindings $_.Bindings -ChunkingEnabled $_.ChunkingEnabled -DeliveryStatusNotificationEnabled $_.DeliveryStatusNotificationEnabled -EightBitMimeEnabled $_.EightBitMimeEnabled -DomainSecureEnabled $_.DomainSecureEnabled -EnhancedStatusCodesEnabled $_.EnhancedStatusCodesEnabled -LongAddressesEnabled $_.LongAddressesEnabled -OrarEnabled $_.OrarEnabled -SuppressXAnonymousTls $_.SuppressXAnonymousTls -AdvertiseClientSettings $_.AdvertiseClientSettings -ServiceDiscoveryFqdn $_.ServiceDiscoveryFqdn -TlsCertificateName $_.TlsCertificateName -Comment $_.Comment -Enabled $_.Enabled -ConnectionTimeout $_.ConnectionTimeout -ConnectionInactivityTimeout $_.ConnectionInactivityTimeout -MessageRateLimit $_.MessageRateLimit -MessageRateSource $_.MessageRateSource -MaxInboundConnection $_.MaxInboundConnection -MaxInboundConnectionPerSource $_.MaxInboundConnectionPerSource -MaxInboundConnectionPercentagePerSource $_.MaxInboundConnectionPercentagePerSource -MaxHeaderSize $_.MaxHeaderSize -MaxHopCount $_.MaxHopCount -MaxLocalHopCount $_.MaxLocalHopCount -MaxLogonFailures $_.MaxLogonFailures -MaxMessageSize $_.MaxMessageSize -MaxProtocolErrors $_.MaxProtocolErrors -MaxRecipientsPerMessage $_.MaxRecipientsPerMessage -PermissionGroups AnonymousUsers -PipeliningEnabled $_.PipeliningEnabled -ProtocolLoggingLevel $_.ProtocolLoggingLevel -RemoteIPRanges $_.RemoteIPRanges -RequireEHLODomain $_.RequireEHLODomain -RequireTLS $_.RequireTLS -EnableAuthGSSAPI $_.EnableAuthGSSAPI -ExtendedProtectionPolicy $_.ExtendedProtectionPolicy -TlsDomainCapabilities $_.TlsDomainCapabilities -TransportRole $_.TransportRole -SizeEnabled $_.SizeEnabled -TarpitInterval $_.TarpitInterval -MaxAcknowledgementDelay $_.MaxAcknowledgementDelay -Server $NewServer}

Теперь можно сравнить скопированные соединители на предмет совпадения настроек.

Заблуждения о высокой доступности в Exchange 2010

Терминология высокой доступности и отказоустойчивости сайтов в Exchange 2010

Для начала немного терминологии для понимания компонентов, настроек и концепций, которые будут описаны ниже.

Термин	Описание	Как настраивается
Activation Активация	Процесс переключения пассивной копии почтовой базы в активную копию.	Командлет Move-ActiveMailboxDatabase.
Activation Suspended or Blocked Приостановка или блокировка активации	Процесс приостановки или блокировки отдельной почтовой базы или целого сервер от автоматической активации.	Командлеты Suspend-MailboxDatabaseCopy или Set-MailboxServer.
Active Manager	Внутренний компонент Exchange, который работает внутри сервиса Microsoft Exchange Replication Service и который отвечает за отслеживание отказов и выполнение корректирующих их действия в DAG.	Никак.
Alternate Witness Directory Альтернативный следящий каталог	Дополнительное свойство DAG, которое задает имя общего файлового ресурса на альтернативном следящем сервере для определения кворума.	Командлет Set-DatabaseAvailabilityGroup или консоль управления Exchange (EMC).
Alternate Witness Server Альтернативный следящий сервер	Дополнительное свойство DAG, которое задает следящий сервер, который будет использоваться DAG после того, как вы выполните переключение центров обработки данных.	Командлет Set-DatabaseAvailabilityGroup или EMC.
Attempt Copy Last Logs (ACLL) Попытка копирования последних журналов	Процесс, выполняемый во время выбора оптимальной копии и в ходе которого система пытается копировать из исходной активной почтовой базы все файлы журналов, которые отсутствуют в пассивной копии, выбранной для активации.	Никак.
AutoDatabaseMountDial	Параметр сервера почтовых баз, который на основе количества пропущенных при копировании файлов журналов определяет, будет ли пассивная копия почтовой базы автоматически монтироваться как активная копия.	Командлет Set-MailboxServer.
Best Copy Selection (BCS) Выбор оптимальной копии	Процесс, выполняемый диспетчером активации для того, чтобы определить наилучшую копию почтовой базы в ответ на отказ активной копии или в ответ на действия администратора по переключению копий.	Никак.
Continuous Replication Block Mode Непрерывная репликация в блочном режиме	Вид непрерывной репликации, которая реплицирует журналы транзакций ESE между буферами журналов на активной почтовой базе и буферами журналов на одной или нескольких пассивных копиях.	Никак (не конфигурируется). Система автоматически переключается между файловым и блочным режимами в зависимости от возможности пассивной копии продолжать непрерывную репликацию.
Continuous Replication File Mode Непрерывная репликация в файловом режиме	Форма непрерывной репликации, которая реплицирует последние файлы транзакционных журналов в одну или несколько пассивных копий почтовых баз.	Никак (не конфигурируется).
Datacenter Центр обработки данных	В Exchange под этим обычно подразумевается сайт Active Directory, однако это может относиться и к физическому сайту. В рамках этой статьи центр обработки данных – это сайт Active Directory.	Никак.
Datacenter Activation Coordination (DAC) Mode Режим координации активации центра обработки данных	Это настройка DAG, которая после ее включения вынуждает членов DAG требовать право на монтирование почтовых баз.	Командлет Set-DatabaseAvailabilityGroup.
Datacenter Activation Coordination Protocol (DACP) Протокол координации активации центров обработки данных	Бит в памяти (0 или 1), который используется членами DAG в режиме DAC. Значение 0 говорит о том, что член DAG не может монтировать базы; значение 1 говорит о том, что член DAG может монтировать активные базы, которые на нем расположены.	Никак. Используется автоматически, когда DAG настроена в режиме DAC.
Datacenter Switchover Переключение центров обработки данных	Ручной процесс активации компонентов Exchange в резервном центре обработки данных и восстановления работы Exchange после сбоя основного центра.	Процесс описан в Переключениях центра обработки данных.
Failover Переключение при сбое	Автоматический процесс, выполняемый системой в результате отказа одной или нескольких активных копий почтовых баз.	Никак. Выполняется автоматически,хотя вы можете заблокировать или приостановить активацию отдельных баз или всего члена DAG.
File Share Witness Файловый ресурс-свидетель	Ресурс кластера, используемый для определения кворума в модели с большинством узлов и общих файловых ресурсов.	Никак. Exchange автоматически создает и удаляет их в зависимости от количества членов DAG.
Incremental Resync Добавочная повторная синхронизация	Встроенный процесс, который устраняет некоторые виды расхождений между копиями почтовых баз в DAG (обычно между активной копией и предыдущей активной копией).	Никак. Выполняется системой автоматически.
Lossy Failover Потеря данных во время переключения при сбое	Ситуация переключения на резервную базу, при которой активируемая пассивная копия монтируется без одного или нескольких файлов журналов.	Частично контролируется через AutoDatabaseMountDial.
Primary Active Manager (PAM) Основная служба Active Manager	Роль службы Active Manager на единственном (в данный момент времени) члене DAG, который отвечает за переключение на резервную базу или резервный сервер.	Никак. Роль PAM автоматически располагается на члене DAG, который владеет ресурсной группой кластера.
Quorum Кворум	Имеет двойное назначение: Ссылается на модель принятия решения, используемую членами кластера для обеспечения целостности кластера. Exchange использует две модели кворума из четырех: Большинство узлов (для DAG с нечетным количеством членов) Большинство узлов и общих файловых ресурсов (для DAG с нечетным количеством членов) Ссылается на общую для членов кластера информацию (т.е. данные кворума), которая используется для поддержки кворума	Никак. Автоматически настраивается Exchange в зависимости от количества членов DAG.
RPCClientAccessServer	Свойство почтовой базы, которое задает сервер или массив серверов клиентского доступа, через которые клиенты MAPI/RPC (Outlook 2003, Outlook 2007, Outlook 2010) получают доступ к почтовым ящикам.	Командлет Set-MailboxDatabase.
Site Сайт	Сайт Active Directory, который определяется как одна или больше быстрых, надежных и хорошо связанных сетей (задержка < 10 мс).	Никак. Настраивается вне Exchange с помощью Active Directory Sites and Services.
Split Brain	Ситуация, при которой несколько членов кластера полагают, что они являются ответственными за один или более общих ресурсов.	Никак.
Standby Active Manager (SAM) Резервная служба Active Manager	Роль службы Active Manager на тех членах DAG, которые не несут роли PAM. Это роль отвечает за мониторинг локальных отказов и ответы на запросы серверов клиентского доступа и транспортных серверов-маршрутизаторов о расположении почтовой базы пользователей.	Никак. Роль SAM автоматически настраивается на членах DAG, которые не владеют группой ресурсов кластера.
StartedMailboxServers	Список членов DAG, которые работают и исправны.	Серверы автоматически добавляются в список во время нормального функционирования. Добавляются вручную как часть реактивации основного центра обработки данных с помощью командлета Start-DatabaseAvailabilityGroup.
StoppedMailboxServers	Список членов DAG, которые отмечены как неработоспособные или неисправные.	Серверы автоматически добавляются в список во время работы системы. Добавляются вручную как часть процесса активации резервного центра обработки данных с помощью командлета Stop-DatabaseAvailabilityGroup.
Switchover Переключение	В контексте одной почтовой базы – это ручной процесс перемещения активной базы на другой сервер. В контексте целого сервера – это ручной процесс перемещения всех активных копий баз с одного сервера на один или несколько других серверов.	Командлет Move-ActiveMailboxDatabase.
Targetless Switchover Переключение без указания целевой базы	Процесс переключения, при котором администратор не указал, какая пассивная копия должна стать активной, а вместо этого позволил алгоритму выбора оптимальной копии службы Active Manager выбрать лучшую копию для активации.	Командлет Move-ActiveMailboxDatabase (без использования параметра TargetServer).
Transport Dumpster Транспортна корзина	Функция роли транспортного сервера-маршрутизатора, которая оставляет копии сообщений, отправленных в реплицируемые почтовые базы в DAG, так что эти сообщения могут быть восстановлены системой в случае отказа почтовой базы.	Командлет Set-TransportConfig или EMC.
Witness Directory Следящий каталог	Обязательное свойство каждой DAG, задающее название каталога, который является общим файловым ресурсом на следящем сервере и предназначен для определения кворума.	Командлет Set-DatabaseAvailabilityGroup или EMC.
Witness Server Следящий сервер	Обязательное свойство каждой DAG, которое задает внешний по отношению к этой DAG сервер, использующийся как участник кворума, если DAG содержит четное число членов.	Командлет Set-DatabaseAvailabilityGroup или EMC.

Заблуждения о высокой доступности и отказоустойчивости сайтов в Exchange 2010

Попробуем развеять эти заблуждения в произвольном порядке.

Заблуждение номер 1: альтернативный следящий сервер (Alternate Witness Server, AWS) дублирует следящий сервер (Witness Server, WS)

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

Хотя вы можете настроить альтернативный следящий сервер (и соответствующую альтернативный следящий каталог) для DAG в любое время, альтернативный следящий сервер не будет использоваться этой DAG до тех пор, пока не произойдет переключение между центрами, особенно когда используется командлет Restore-DatabaseAvailabilityGroup.

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

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

Заблуждение номер 2: Microsoft рекомендует размещать следящий сервер в третьем центре обработки данных в случае, если состоящая из двух членов группа DAG распределена между двумя центрами обработки данных

В этом сценарии у нас один член группы доступности баз данных размещен в основном центре обработки данных (Портленд), другой в резервном (Редмонд). Так как это группа доступности из двух членов, то нам придется использовать следящий сервер. Рекомендация есть и была в том, чтобы размещать следящий сервер в главном центре, как показано ниже.

Рисунок 1: Когда группа доступности баз данных распределяется между двумя центрами обработки данных, размещайте следящий сервер в основном

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

Рисунок 2: В случае отключения WAN член DAG в основном центре обработки данных будет поддерживать кворум и обслуживать локальных пользователей

Причина такого поведения кроется в сути того, что есть кворум и группы DAG, в частности:

• Все группы DAG и их члены требуют кворум для своей работы. Если у вас нет кворума, то у вас не будет работоспособной группы доступности. Если кворум потерян, то базы размонтируются, связность невозможна и репликация останавливается.
• Кворум требует большинства голосов, чтобы достигнуть консенсуса. Таким образом, если у вас в DAG четное количество членов, вам необходим внешний компонент, чтобы предоставить решающий голос для одного из участников голосования, чтобы избежать равенства голосов.
  • В Windows Failover Cluster только члены кластера имеют голос. Когда кластер теряет одного голосующего члена, то для поддержания кворума нужен следящий сервер, тогда один из членов DAG, который может связаться со следящим сервером, размещает блокировку Server Message Block (SMB) на файле witness.log, который расположен в следящем каталоге. Член DAG, который размещает блокировку SMB, называется блокирующим узлом. Как только блокировка SMB установлена, ни один другой член DAG не может ее установить.
  • Блокирующий узел при этом обретает право решающего голоса, т.е. он голосует не один раз, а два (за себя и за следящий сервер).
  • Если те члены кластера, которые могут общаться с блокирующим узлом, составляют большинство, то они вместе с блокирующим узлом будут поддерживать кворум и продолжать обслуживать клиентов. Члены DAG, которые не могут общаться с блокирующим узлом, оказываются в меньшинстве, теряют кворум и прекращают работу с DAG.
• Формула большинства для поддержания кворума выглядит как V/2 + 1, результат который всегда есть целое число. Формула равна число голосующих (V) деленное на 2, плюс 1 (для устранения равенства голосов).

Вернемся обратно к нашему примеру и рассмотрим размещение следящего сервера в третьем центре обработки данных, как показано ниже:

Рисунок 3: Размещение следящего сервера в третьем центре обработки данных никак не меняет алгоритм переключения

Эта конфигурация никак не меняет алгоритм переключения. В случае потери связи по WAN между Портлендом и Редмондом один член DAG сохранит кворум, а другой потеряет его, как показано ниже:

Рисунок 4: В случае потери связи по WAN между двумя центрами обработки данных один член DAG сохранит кворум

Здесь у нас два члена DAG и, следовательно, два голосующих. Согласно формуле V/2 + 1 нам необходимы по крайней мере 2 голоса, чтобы поддерживать кворум.Если соединение по WAN между Портлендом и Редмондом потеряно, это заставит кластер, лежащий в основе DAG, проверить, сохранился ли кворум.

В этом примере член DAG в Портленде разместил блокировку SMB на файле witness.log, расположенном на сервере слежения в Олимпии. Т.к. член DAG в Портленде является блокирующим узлом, он получает решающий голос, и поэтому теперь обладает двумя голосами, необходимыми, чтобы удержать кворум и сохранить свой кластер и свою группу доступности в рабочем состоянии.

Хотя член DAG в Редмонде может связаться со следящим сервером в Олимпии, он не может разместить блокировку SMB на файле witness.log, т.к. она уже существует. И т.к. он не может взаимодействовать с блокирующим узлом, то он оказывается в меньшинстве, теряет кворум и прекращает работу с кластером и DAG. Помните, что не важно, могут ли другие члены DAG взаимодействовать со следящим сервером: им нужно только взаимодействовать с блокирующим узлом для того, чтобы участвовать в кворуме и оставаться в рабочем состоянии.

Как сказано в статье Управление группами доступности базы данных на TechNet, если у вас группа доступности,распределенная между двумя сайтами, мы рекомендуем вам разместить следящий сервер в центре обработки данных, который вы рассматриваете как основной (тот, где больше пользователей). Еслиу вас несколько центров обработки данных с большим числом пользователей, то мы рекомендуем вам две группы доступности (это также задокументировано на TechNet в статье Примеры проектов группы доступности базы данных.

Заблуждение номер 2a: если у нас DAG с четным количеством членов, распределенных между двумя центрами обработки данных, то размещение следящего сервера в третьем центре повышает надежность

В дополнение к Заблуждению номер 2 существует похожее на него заблуждение в том, что размещение четного количества членов DAG в двух центрах обработки данных и использование следящего сервера в третьем дает большую надежность, т.к. позволяет настроить систему так, чтобы она выполняла аварийное переключение центров обработки данных (datacenter failover). Вы могли заметить, что термина «аварийное переключение датацентров» (datacenter failover) в приведенном выше списке терминов нет. С точки зрения Exchange такого понятия нет. В результате нет такой конфигурации, которая бы выполняля аварийное переключение центров обработки данных для Exchange.

Помните, что аварийное переключение – это корректирующее действие, автоматически выполняемое системой. Для Exchange 2010 нет механизма для аварийного переключения центров обработик данных. В то время как вышеприведенная конфигурация может обеспечить аварийное переключение серверов и почтовых баз, она не может выполнять аварийное переключение центров обработки данных. Напротив, процесс восстановления при отказе центра является ручным процессом, называемым переключением центра обработки данных (datacenter switchover), и этот процесс всегда начинается с человека, принимающего решение активировать резервный центр.

Активация резервного центра обработки данных – нетривиальная задача, так как она включает в себя гораздо больше, чем какие-то действия внутри DAG. Она также включает перемещение адресного пространства из основного в резервный центр. Более того, она подразумевает, что основной центр больше не может поддерживать уровень сервиса, необходимый организации. Это условие система не может определить сама. Она не имеет представления о природе и длительности подобного отказа. Таким образом, аварийное переключение центра – это всегда ручной процесс, который начинается с процесса принятия решения.

Как только решение об аварийном переключении центров принято, само переключение – это прямолинейный процесс, хорошо описанный в статье Переключения центра обработки данных.

Заблуждение номер 3: Включение режима DAC предотвращает автоматическое переключение между центрами обработки данных, поэтому для создания конфигурации с автоматическим переключением центров обработки данных при отказе не нужно включать режим DAC в DAG

Режим координации активации центра обработки данных (Datacenter Activation Coordination, DAC) никак не связан с аварийным переключением. Режим DAC – это свойство DAG, которое, будучи включенным, заставляет членов DAG в момент запуска перехватывать права других членов DAG и монтировать почтовые базы. Режим DAC был создан для следующего сценария:

• У вас группа доступности, распределенная  между двумя центрами обработки данных;
• Потеряно питание в основном центре, что также привело к потере канала WAN между основным и резервным центрами;
• Т.к. питание отсутствует достаточно долго, вы решаете активировать резервный центр и выполняете процедуру переключения центров;
• Неожиданно питание в основном центре восстанавливается, но канал WAN между центрами еще не работает;
• Члены DAG, которые запускаются в основном центре, не могут связаться с членами DAG в резервном.

В этом сценарии запускающиеся в основном центре члены DAG не знают, то было выполнено переключение центров. Они все еще полагают, что они отвечают за активные копии почтовых баз, и без режима DAC, если они имеют достаточное число голосов для кворума, они попытаются смонтировать активные почтовые базы. Это может привести к состоянию, называемому split brain, которое происходит на уровне баз. При этой ситуации несколько членов DAG, которые не могут взаимодействовать друг с другом, будут держать активные копии одной и той же почтовой базы. Это очень нежелательное состояние, которое может привести к потере информации и сделать ее восстановление сложным и долгим (хотя и возможным, но определенно мы бы не хотели, чтобы наш заказчик оказался в такой ситуации).

Способ монтирования почтовых баз в Exchange 2010 был изменен. Да, Information Store все еще выполняет монтирование, но делает он это только по просьбе  Active Manager. Даже когда администратор выбирает в EMC команду Mount Database, он обращается к Active Manager, который предоставляет административный интерфейс для этой задачи и выполняет запрос RPC в Information Store для того, чтобы выполнить монтирование (даже для серверов почтовых ящиков, которые не входят в DAG).

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

Режим DAC использует бит памяти в Active Manager, называемый Datacenter Activation Coordination Protocol (DACP). Это замысловатое название просто обозначает бит памяти, который принимает значение 0 или 1. Значение 1 означает, что Active Manager может отправлять запросы на монтирование, а значение 0, что не может.

Начальное значение бита всегда 0, и т.к. это бит памяти, то всякий раз, когда служба Microsoft Exchange Replication (MSExchangeRepl.exe) останавливается или перезапускается, этот бит сбрасывается в 0. Чтобы установить бит DACP в 1 и получить возможность монтировать базы, стартующий член DAG должен:

• Или иметь возможность взаимодействовать с любым другим членом DAG, у которого бит DACP равен 1;
• Или иметь возможность взаимодействовать со всеми членами  DAG, которые перечислены в свойстве StartedMailboxServers.

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

Возвращаясь к вышеописанному сценарию с DAC, когда восстанавливается питание в основном центре без одновременного восстановления канала WAN, члены DAG, стартующие в этом центре могут взаимодействовать только друг с другом. И т.к. они стартуют после потери питания, их бит DACP равен 0. В результате ни один из членов DAG в основном центре не соответствует вышеприведенным условиям, и поэтому не может изменить их DACP в 1 и отправить запросы на монтирование.

Вот каким образом режим DAC предотвращает split brain на уровне базы. Это никак не связано с аварийным переключением, и поэтому запрет режима DAC не будет разрешать автоматическое переключение центров.

Кстати, как описано в документации на TechNet в статье Общие сведения о режиме координации активации центра обработки данных, еще одно полезное свойство режима DAC заключается в том, что он дает вам возможность использовать встроенные в Exchange средства обеспечения устойчивости сайтов.

Заблуждение номер 4: параметр AutoDatabaseMountDial контролирует, сколько файлов журналов отбрасываются системой при монтировании базы

Это случай, когда две независимые функции объединились в форме одного заблуждения: параметр AutoDatabaseMountDial и функция, известная как добавочная повторная синхронизация (Incremental Resync, также известная как Incremental Reseed v2). Эти функции действительно не связаны, хотя кажутся такими, т.к. они связаны с примерно одним и тем же количеством файлов журналов на различных копиях одной и той же базы.

Когда в DAG происходит отказ, который влияет на активную копию почтовой базы, пассивная копия активируется одним из двух способов: или автоматически системой, или вручную администратором. Автоматическое восстановление основано на параметре AutoDatabaseMountDial.

Как описано в статье Общие сведения о режиме координации активации центра обработки данных, этот параметр – способ для администратора указать члену DAG максимальное количество потерянных файлов журналов, при котором еще возможно монтирование копий баз. Значение по умолчанию равно BestAvailability, которое разрешает потерять до 12 файлов журналов. Это означает, что если из активной копии в пассивную не передалось 12 или менее файлов журналов, то сервер все еще сможет смонтировать эту копию как новую активную базу. Этот сценарий известен как потеря данных во время переключения при сбое (lossy failover),  и Exchange делает это так, как он спроектирован.

После активации пассивной копии с потерями она будет создавать файлы журналов, продолжая последовательность генерации, основываясь на последнем файле журнала, полученном из активной копии (или через нормальную репликацию, или как результат успешного копирования во время процесса ACLL). Чтобы это продемонстрировать, давайте рассмотрим этот сценарий подробнее с момента наступления отказа.

У нас две копии DB1; активная копия на EX1 и пассивная копия на EX2. Текущие настройки и статус почтовой базы следующий:

• AutoDatabaseMountDial: BestAvailability
• Copy Queue Length: 4
• Replay Queue Length: 0
• Last log generated by DB1\EX1: E0000000010
• Last Log Received by DB1\EX2: E0000000006

Теперь кто-то случайно выключает EX1, и у нас происходит потеря данных во время переключения, при этом DB1\EX2 монтируется как новая активная копия базы. Т.к. E0000000006 – это последний файл журнала, который есть на DB1\EX2, сервер продолжает генерировать файлы журналов E0000000007, E0000000008, E0000000009, E0000000010 и так далее.

Администратор узнает, что EX1 выключен и перезапускает его. EX1 загружается и запускает процесс Microsoft Exchange Replication. Служба Active Manager, которая запускается в этом сервисе, обнаруживает, что:

• DB1\EX2 была активирована с потерями
• DB1\EX2 – это активная копия
• DB1\EX1 – это теперь несинхронизированная пассивная копия

При любой потере данных во время переключения, когда есть пригодные для использования исходные активные копии, всегда существует различие в потоках файлов журналов, которые система должна учитывать. Это состояние заставляет DB1\EX1 автоматически запустить процесс, называемый повторной синхронизацией (resync), который создан на случай обнаружения различий в потоках файлов журналов. Его назначение – пересинхронизировать копии базы так, чтобы при определенных условиях отказа вам не пришлось бы выполнять полную повторную синхронизацию копии базы.

В нашем примере различие наступает при генерации файла E0000000007:

Рисунок 5: Различие в потоке файлов журналов наступает с файла журнала E0000000007

DB1\EX2 получала журналы с 1 по 6 с базы DB1\EX1, когда та была активной копией. Но после аварии журналы с 7 по 10 не были скопированы с EX1 на EX2. Таким образом, когда DB1\EX2 становится активной копией, она продолжает генерацию журналов с последнего файла, который она имела – то есть с файла 6. В результате DB1\EX2 генерирует свои собственные файлы 7-10, которые теперь содержат данные, которые отличаются от данных, содержащихся в файлах 7-10 базы DB1\EX1.

Чтобы обнаружить (и исправить) это различие, функция добавочной повторной синхронизации запускается с последнего файла (в нашем примере это файл 10) и сравнивает два файла копий баз, затем предыдущую пару и т.д. пока не найдет совпадающие копии. В нашем
примере это файл 6. Т.к. DB1\EX1 теперь является пассивной копей, и т.к. ее журналы с 7 по10 отличаются от журналов с 7 по 10 на DB1\EX2, которая теперь является активной копией, эти файлы журналов исключаются системой. Конечно, это не восстановит потерянных сообщений, т.к. они восстанавливаются через механизм Transport Dumpster.

Затем файлы журналов с 7 по 10 на DB1\EX2 реплицируются на DB1\EX1, и DB1\EX1 становится здоровой актуальной копией базы DB1\EX2, как показано ниже:

Рисунок 6: Добавочная повторная синхронизация исправляет различие в потоке журналов

Нужно отметить, что описание процесса добавочной повторной синхронизации сильно упрощено, и что на самом деле он гораздо сложнее, но для целей этого обсуждения достаточно базового понимания.

Как мы увидели в этом примере, хотя DB1\EX2 потерял четыре файла журналов, он все еще может смонтировать новую активную копию почтовой базы, т.к. число потерянных файлов журналов было в пределах значения AutoDatabaseMountDial, сконфигурированного на EX2. Также мы увидели, что для того, чтобы устранить различие в потоке файлов журналов после потери данных во время переключения, функция добавочной повторной синхронизации отбросила четыре файла журналов.

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

Чтобы понять, почему эти функции действительно не связаны, и почему AutoDatabaseMountDial не отбрасывает файлы журналов, рассмотрим сам процесс сбоя. AutoDatabaseMountDial просто определяет, будет ли копия базы монтироваться во время активации, основываясь на количестве потерянных файлов журналов. Ключ здесь в слове «потерянных». Мы говорим о файлах журналов, которые не были реплицированы на эту активную копию. Если они не реплицированы, то они и не существуют на этой копии, и поэтому они не могут быть выброшены. Вы не можете выбросить то, чего у вас нет.

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

Но предположим, что на самом деле произошел отказ хранилища, и что мы вообще потеряли DB1\EX1. Без жизнеспособной базы добавочная повторная синхронизация тут не поможет, и все, что вы можете сделать – это выполнить операцию повторного заполнения (reseed).

Таким образом, как мы видим:

• AutoDatabaseMountDial не контролирует, сколько файлов журналов файлов отбрасывает система
• AutoDatabaseMountDial – это совершенно отдельный процесс, который не требует возможности или успеха добавочной повторной синхронизации
• Добавочная повторная синхронизация отбрасывает файлы журналов в ходе устранения различий, но не теряет сообщений из-за этого

Источник: http://blogs.technet.com/b/exchange/archive/2011/05/31/exchange-2010-high-availability-misconceptions-addressed.aspx