Применимо к: Exchange Server 2010 SP1
Последнее изменение раздела: 2010-12-01
Microsoft Exchange Server 2010 содержит новый компонент Active Manager, функциональность которого заменяет модель ресурсов и компоненты управления отработкой отказов, доступные благодаря интеграции со службой кластеров в предыдущих версиях Exchange. В Exchange модель ресурсов кластера более не используется для обеспечения высокой доступности. Все ресурсы кластера Exchange, предоставляемые библиотекой exres.dll, больше не существуют, включая так называемые кластерные серверы почтовых ящиков. В Exchange используется отказоустойчивый кластер Windows, но кластерных групп для Exchange нет, как нет и ресурсов хранения в кластере. Это значит, что при просмотре кластера с помощью средств управления кластером будут доступны только базовые ресурсы кластера (IP-адрес, сетевое имя и, при необходимости, ресурс кворума). Узлы кластера и сети также будут присутствовать, но они управляются Exchange, а не средствами управления кластером или самим кластером.
Active Manager работает в качестве роли на всех серверах почтовых ящиков. На серверах почтовых ящиках, на которых не настроено обеспечение высокой доступности, существует одна роль Active Manager: автономная служба Active Manager. На серверах, которые являются участниками группы обеспечения доступности баз данных, существуют две роли Active Manager: основная служба Active Manager (PAM) и резервная служба Active Manager (SAM). Роль PAM — это экземпляр Active Manager в группе обеспечения доступности баз данных, принимающий решения о том, какие копии будут пассивными, а какие — активными. PAM отвечает за получение уведомлений об изменении топологии и реакцию на сбои серверов. Член группы обеспечения доступности баз данных, которому принадлежит роль PAM, всегда является текущим владельцем ресурса кворума кластера (кластерной группы по умолчанию). Если на сервере-владельце ресурса кворума кластера происходит сбой, роль PAM автоматически перемещается на оставшийся сервер, который становится новым владельцем ресурса кворума кластера. Кроме того, если сервер, на котором размещен ресурс кворума кластера, необходимо перевести в автономный режим для обслуживания или обновления, сначала следует перенести роль PAM на другой сервер группы обеспечения доступности баз данных. Роль PAM контролирует все передвижения активных назначений между копиями баз данных (в любой момент времени активной может быть только одна копия, которая может быть подключенной или отключенной). Роль PAM также выполняет функции роли SAM на локальном компьютере (обнаружение сбоев локальных баз данных и банка данных).
Роль SAM предоставляет сведения о том, на каком сервере размещается активная копия базы данных почтовых ящиков, другим компонентам Exchange, использующим клиентский компонент Active Manager (например, службе клиентского доступа RPC или транспортному серверу-концентратору). Роль SAM обнаруживает сбои локальных баз данных и локального банка данных. Она реагирует на сбои, запрашивая у роли PAM отработку отказа (если база данных реплицирована). Роль SAM не определяет целевой сервер отработки отказа и не обновляет состояние расположения базы данных в роли PAM. Она обращается к состоянию расположения активной копии базы данных для ответа на получаемые запросы активной копии базы данных.
 Примечание. |
|---|
| Exchange 2010 не является кластерным приложением. Вместо этого функции библиотеки кластеризации clusapi.dll используются для реализации функциональности кластера, групп, сети кластера (пульса), управления узлами, реестра кластера и ряда задач управления. Кроме этого, служба Active Manager хранит сведения о текущем состоянии базы данных почтовых ящиков (данные об активных и пассивных копиях, а также о подключении) в базе данных кластера. Хотя эти сведения хранятся непосредственно в базе данных кластера, к ним не обращаются напрямую никакие другие компоненты. |
В Exchange 2010 служба репликации Microsoft Exchange периодически отслеживает работоспособность всех подключенных баз данных. Кроме этого, она также отслеживает ошибки и сбои ввода-вывода подсистемы ESE. Если служба обнаруживает сбой, она уведомляет о нем службу Active Manager. Затем Active Manager определяет, какую копию базы данных следует подключить, и что для этого необходимо. Кроме того, она отслеживает активную копию базы данных почтовых ящиков (на основании сведений о копии базы данных, подключенной последней) и предоставляет сведения о результатах отслеживания компоненту клиентского доступа RPC на сервере клиентского доступа, к которому подключен клиент.
Выбор оптимальной копии в Active
Manager
При возникновении сбоя, затрагивающего реплицированную базу данных почтовых ящиков, Active Manager выполняет ряд действий по восстановлению путем выбора оптимальной копии сбойной базы, которая будет активирована. Общий процесс выглядит следующим образом.
- Active Manager обнаруживает сбой.
- PAM запускает внутренний алгоритм, который называется выбором
оптимальной копии (BCS).
- Выполняется процесс, называемый попыткой копирования
последних журналов (ACLL), в ходе которого предпринимается
попытка скопировать с сервера все отсутствующие файлы журналов,
находившиеся в активной копии базы данных до отработки отказа.
- По завершении этого процесса PAM выдает банку данных Microsoft
Exchange запрос на подключение через удаленный вызов процедур
(RPC). На этом этапе выполняется одно из следующих действий:
- база данных подключается и становится доступной для клиентов;
или
- база данных не подключается, и РАМ выполняет действия 3 и 4 для
следующей оптимальной копии (если она доступна).
- база данных подключается и становится доступной для клиентов;
или
В процессе поиска оптимальной копии, которую нужно активировать, РАМ использует до десяти отдельных наборов условий. После того, как будет найдена оптимальная копия, выполняется попытка копирования последних журналов. Если после завершения процесса из предыдущей активной копии были скопированы все недостающие файлы журнала, база данных подключается без потери данных. Эта ситуация называется отработкой отказа без потерь. Если процесс завершается неудачно, проверяется настроенное значение параметра AutoDatabaseMountDial. Дополнительные сведения о параметре AutoDatabaseMountDial см. в разделе Set-MailboxServer. Если число утерянных журналов не превышает настроенного значения AutoDatabaseMountDial, выполняется подключение базы данных. Если число утерянных журналов превышает настроенное значение параметра AutoDatabaseMountDial, база данных не будет подключена, пока не будут восстановлены недостающие файлы журнала или администратор не подключит базу данных вручную, проигнорировав потерю большого объема данных. Если база данных не подключается автоматически, РАМ выбирает следующую оптимальную копию (если она доступна). Существует по крайней мере три причины того, что изначально выбранная копия базы данных не подключается автоматически:
- число потерянных файлов журналов превышает значение, заданное
для параметра AutoDatabaseMountDial;
- для сервера, на котором выполнялась попытка подключения,
настроено нестрогое максимальное значение числа активных баз
данных, и на этом сервере было достигнуто максимальное число
активных копий базы данных;
- копия базы данных приостановлена для активации.
Процесс выбора оптимальной копии
Active Manager начинает процесс выбора оптимальной копии с создании списка копий базы данных, которые являются потенциальными кандидатами для активации. Любые недоступные или заблокированные администратором для активации (при помощи свойства DatabaseCopyAutoActivationPolicy командлета Set-MailboxServer) копии базы данных пропускаются и не включаются в процесс выбора. Порядок расположения копий в списке зависит от версии Exchange 2010.
- В окончательной первоначальной версии (RTM) Exchange 2010
Active Manager сортирует итоговый список, используя в качестве
первичного ключа длину очереди копирования. Расчет выполняется на
основе параметра LastLogInspected (с позиции копии), поэтому список
потенциальных копий сортируется по максимальному значению
LastLogInspected (которое соответствует копии с наименьшей длиной
очереди копирования). Затем Active Manager сортирует список
второй раз, используя значение параметра
ActivationPreference в качестве вторичного ключа. Копия с
минимальным значением ActivationPreference имеет наивысший
приоритет в списке.
- В Exchange 2010 с пакетом обновления 1 (SP1) алгоритм
аналогичен RTM-версии, за исключением серверов, для параметра
автоподключения базы данных которых задано значение
Lossless. При использовании значения Lossless Active Manager
сортирует итоговый список в порядке возрастания, используя в
качестве первичного ключа значение параметра ActivationPreference.
Такое поведение не является ошибкой: оно сводит к минимуму
несогласованность базы данных за счет операций перемещения (таких
как переключения или запуск сценария
StartDagServerMaintenance.ps1).
Далее Active Manager пытается найти в списке копию базы данных почтовых ящиков в состоянии Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing или SeedingSource и оценивает потенциал активации каждой копии в списке на основе упорядоченного набора из десяти условий. Active Manager определяет, отвечает ли какой-либо кандидат для активации первому набору условий:
- Индекс содержимого имеет состояние Healthy (исправен).
- Длина очереди копирования файлов журнала меньше 10.
- Длина очереди преобразования файлов журнала меньше 50.
Если ни одна копия базы данных не отвечает первому набору условий, Active Manager пытается найти копию базы данных, отвечающую второму набору условий:
- Индекс содержимого имеет состояние Crawling (сканирование).
- Длина очереди копирования файлов журнала меньше 10.
- Длина очереди преобразования файлов журнала меньше 50.
Если ни одна копия базы данных не отвечает второму набору условий, Active Manager пытается найти копию базы данных, отвечающую третьему набору условий:
- Индекс содержимого имеет состояние Healthy (исправен).
- Длина очереди преобразования файлов журнала меньше 50.
Если ни одна копия базы данных не отвечает третьему набору условий, Active Manager пытается найти копию базы данных, отвечающую четвертому набору условий:
- Индекс содержимого имеет состояние Crawling (сканирование).
- Длина очереди преобразования файлов журнала меньше 50.
Если ни одна копия базы данных не отвечает четвертому набору условий, Active Manager пытается найти копию базы данных, отвечающую пятому набору условий:
- Длина очереди преобразования файлов журнала меньше 50.
Если ни одна копия базы данных не отвечает пятому набору условий, Active Manager пытается найти копию базы данных, отвечающую шестому набору условий:
- Индекс содержимого имеет состояние Healthy (исправен).
- Длина очереди копирования файлов журнала меньше 10.
Если ни одна копия базы данных не отвечает шестому набору условий, Active Manager пытается найти копию базы данных, отвечающую седьмому набору условий:
- Индекс содержимого имеет состояние Crawling (сканирование).
- Длина очереди копирования файлов журнала меньше 10.
Если ни одна копия базы данных не отвечает седьмому набору условий, Active Manager пытается найти копию базы данных, отвечающую восьмому набору условий:
- Индекс содержимого имеет состояние Healthy (исправен).
Если ни одна копия базы данных не отвечает восьмому набору условий, Active Manager пытается найти копию базы данных, отвечающую девятому набору условий:
- Индекс содержимого имеет состояние Crawling (сканирование).
Если ни одна копия базы данных не отвечает девятому набору условий, Active Manager пытается активировать любую копию базы данных в состоянии Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing или SeedingSource (десятый набор условий). Если копии, отвечающие десятому набору условий, не удается найти, автоматическая активация копии базы данных невозможна.
Как только будут найдены одна или несколько копий, отвечающих хотя бы одному набору условий, процесс ACLL копирует все файлы журналов из источника в потенциальную новую активную копию. По завершении этого процесса PAM выдает запрос на подключение, и либо база данных подключается и становится доступной для клиентов, либо база данных не подключается и РАМ ищет следующую оптимальную копию (если она доступна).
Примеры выбора оптимальной копии
В следующем разделе приведено несколько примеров процесса выбора и активации оптимальной копии в Active Manager.
Пример 1. Основной сценарий
В этом примере существует четыре копии базы данных почтовых ящиков DB1. База данных DB1 в данный момент активна на сервере Server1, на котором происходит аппаратный сбой. В следующей таблице приведено текущее состояние копий базы данных DB1 на серверах Server2, Server3 и Server4.
| Копия базы данных | Приоритет активации | Длина очереди копирования | Длина очереди преобразования | Состояние индекса содержимого | Состояние базы данных | Блокировка активации |
|---|---|---|---|---|---|---|
|
Server2\DB1 |
2 |
4 |
0 |
Healthy (исправно) |
Healthy (исправно) |
Нет |
|
Server3\DB1 |
3 |
2 |
2 |
Healthy (исправно) |
DisconnectedAndHealthy (отключено и исправно) |
Нет |
|
Server4\DB1 |
4 |
10 |
0 |
Crawling (сканирование) |
Healthy (исправно) |
Нет |
В результате сортировки доступных копий на основе длины их очереди копирования (при необходимости с использованием приоритета активации) получается следующий упорядоченный список:
- Server3\DB1
- Server2\DB1
- Server4\DB1
Из этого списка только две копии базы данных отвечают первому набору условий для активации:
- копия на сервере Server3, которая находится в состоянии
Disconnectedandhealthy, с длиной очереди копирования менее 10,
длиной очереди преобразования менее 50 и состоянием индекса
содержимого Healthy;
- копия на сервере Server2, которая находится в состоянии
Healthy, с длиной очереди копирования менее 10, длиной очереди
преобразования менее 50 и состоянием индекса содержимого
Healthy.
Из этих двух копия на сервере Server3 имеет наименьшую длину очереди копирования; поэтому для попытки активации выбирается копия на сервере Server3, поскольку она содержит наименьший объем недостающих данных.
После активации копии на сервере Server3 служба репликации Microsoft Exchange на сервере Server3 выполняет процесс ACLL и пытается скопировать все отсутствующие файлы журналов с предыдущего активного сервера (в данном случае сервера Server1). По завершении процесса ACLL PAM получает уведомление о его результатах. Если все журналы успешно скопированы, то база данных помечается как активная копия и подключается без потерь данных. Если один или несколько журналов отсутствуют, то анализируется значение параметра AutoDatabaseMountDial. Если объем потерянных данных не превышает заданное значение, то база данных помечается как активная копия и подключается с потерями данных. Затем большая часть недостающих данных будет восстановлена из транспортной корзины.
Если Active Manager не отправляет запрос на подключение банку данных и операция подключения завершается неудачно, Active Manager возвращается к отсортированному списку и пытается активировать следующую оптимальную копию (в данном случае на сервере Server2).
Пример 2. Две копии с одинаковой длиной очереди копирования
В этом примере существует четыре копии базы данных почтовых ящиков DB2. База данных DB2 в данный момент активна на сервере Server1, на котором происходит аппаратный сбой. В следующей таблице приведено текущее состояние копий базы данных DB2 на серверах Server2, Server3 и Server4.
| Копия базы данных | Приоритет активации | Длина очереди копирования | Длина очереди преобразования | Состояние индекса содержимого | Состояние базы данных | Блокировка активации |
|---|---|---|---|---|---|---|
|
Server2\DB2 |
2 |
2 |
0 |
Healthy (исправно) |
Healthy (исправно) |
Нет |
|
Server3\DB2 |
3 |
2 |
2 |
Healthy (исправно) |
DisconnectedAndHealthy (отключено и исправно) |
Нет |
|
Server4\DB2 |
4 |
10 |
0 |
Crawling (сканирование) |
Healthy (исправно) |
Нет |
В результате сортировки доступных копий на основе длины их очереди копирования (при необходимости с использованием приоритета активации) получается следующий упорядоченный список:
- Server2\DB2
- Server3\DB2
- Server4\DB2
Из этого списка только две копии базы данных отвечают первому набору условий для активации:
- копия на сервере Server2, которая находится в состоянии
Healthy, с длиной очереди копирования менее 10, длиной очереди
преобразования менее 50 и состоянием индекса содержимого
Healthy;
- копия на сервере Server3, которая находится в состоянии
Disconnectedandhealthy, с длиной очереди копирования менее 10,
длиной очереди преобразования менее 50 и состоянием индекса
содержимого Healthy.
Копия на сервере Server2 имеет такую же длину очереди копирования, что и копия на сервере Server3, но у нее также более низкий приоритет активации; поэтому копия на сервере Server2 занимает первое место в списке и выбирается для попытки активации, поскольку имеет наименьший объем недостающих данных и наименьший приоритет активации.
Пример 3. Копии с одинаковыми состояниями базы данных и разными состояниями индексов содержимого
В этом примере существует четыре копии базы данных почтовых ящиков DB3. База данных DB3 в данный момент активна на сервере Server1, на котором происходит аппаратный сбой. В следующей таблице приведено текущее состояние копий базы данных DB3 на серверах Server2, Server3 и Server4.
| Копия базы данных | Приоритет активации | Длина очереди копирования | Длина очереди преобразования | Состояние индекса содержимого | Состояние базы данных | Блокировка активации |
|---|---|---|---|---|---|---|
|
Server2\DB3 |
2 |
0 |
3 |
Crawling (сканирование) |
Healthy (исправно) |
Нет |
|
Server3\DB3 |
3 |
0 |
3 |
Healthy (исправно) |
DisconnectedAndHealthy (отключено и исправно) |
Нет |
|
Server4\DB3 |
4 |
0 |
0 |
Healthy (исправно) |
Healthy (исправно) |
Нет |
В результате сортировки доступных копий на основе длины их очереди копирования (при необходимости с использованием приоритета активации) получается следующий упорядоченный список:
- Server2\DB3
- Server3\DB3
- Server4\DB3
Все три копии базы данных, размещенные на указанных выше серверах, отвечают условиям для активации. Хотя копия на сервере Server2 имеет более низкий приоритет активации, состояние ее индекса содержимого — Crawling; поэтому, когда Active Manager анализирует список на соответствие первому набору условий (который включает состояние индекса содержимого Healthy), то копия базы данных на сервере Server3 будет предпочтительной, поскольку состояние ее индекса содержимого — Healthy.
Пример 4. Влияние параметра AutoDatabaseMountDial на выбор оптимальной копии
В этом примере существует четыре копии базы данных почтовых ящиков DB4. База данных DB4 в данный момент активна на сервере Server1, на котором происходит сбой, вызывающий перезагрузку. В следующей таблице приведено текущее состояние копий базы данных DB4 на серверах Server2, Server3 и Server4. Для параметра AutoDatabaseMountDial на всех серверах почтовых ящиков в группе обеспечения доступности баз данных задано значение Lossless (длина очереди копирования равна 0).
| Копия базы данных | Приоритет активации | Длина очереди копирования | Длина очереди преобразования | Состояние индекса содержимого | Состояние базы данных | Блокировка активации |
|---|---|---|---|---|---|---|
|
Server2\DB4 |
2 |
0 |
4523 |
Healthy (исправно) |
Healthy (исправно) |
Нет |
|
Server3\DB4 |
3 |
100 |
25 |
Crawling (сканирование) |
Healthy (исправно) |
Нет |
|
Server4\DB4 |
4 |
6 |
62 |
Healthy (исправно) |
Healthy (исправно) |
Нет |
Поскольку для параметра автоподключения базы данных задано значение Lossless, Active Manager использует в качестве первичного ключа для сортировки приоритет активации вместо длины очереди копирования. В результате сортировки доступных копий на основе их приоритета активации получается следующий упорядоченный список:
- Server2\DB4
- Server3\DB4
- Server4\DB4
Ни одна из баз данных не отвечает первому, второму или третьему набору условий, но копия базы данных на сервере Server3 отвечает четвертому набору условий (состояние ее индекса содержимого — Crawling, и длина очереди преобразования меньше 50). Для копии базы данных на сервере Server3 длина очереди копирования равна 100, но, поскольку сервер Server1 не завершил перезагрузку, процесс ACLL не может скопировать отсутствующие файлы журналов на сервер Server3. Процесс ACLL сообщает PAM, что объем недостающих данных выходит за пределы заданного значения параметра AutoDatabaseMountDial, поэтому PAM выбирает следующую доступную оптимальную копию.
В приведенном выше сценарии копии базы данных на серверах Server2 и Server4 отвечают шестому набору условий (состояние базы данных и индекса содержимого — Healthy, а длина очереди копирования меньше 10). Следующей выбирается копия базы данных на сервере Server2, поскольку она стоит выше в отсортированном списке доступных копий. Процесс ACLL выполняется на сервере Server2, но связь сервера Server1 с сетью по-прежнему отсутствует, и процесс ACLL не может скопировать журналы. Однако, поскольку длина очереди копирования не превышает заданное значение параметра AutoDatabaseMountDial, процесс ACLL отправляет PAM сообщение об успешном завершении операции и PAM выдает запрос на подключение базы данных через RPC.