Microsoft Exchange Server 2013 г. включает компонент Active Manager, который управляет платформой высокого уровня доступности, которая включает в себя группу доступности базы данных (DAG) и копии баз данных почтовых ящиков. Active Manager выполняется внутри службы репликации Microsoft (MSExchangeRepl.exe) на всех серверах почтовых ящиков. На серверах почтовых ящиков, которые не входят в DAG, существует единая роль Active Manager: Standalone Active Manager. На серверах, которые являются участниками группы обеспечения доступности баз данных, существуют две роли Active Manager: Primary Active Manager (PAM) и Standby Active Manager (SAM). Роль PAM — это экземпляр Active Manager в группе обеспечения доступности баз данных, принимающий решения о том, какие копии будут пассивными, а какие — активными. PAM отвечает за получение уведомлений об изменении топологии и реакцию на сбои серверов. Член группы обеспечения доступности баз данных, которому принадлежит роль PAM, всегда является текущим владельцем ресурса кворума кластера (кластерной группы по умолчанию). Если на сервере-владельце ресурса кворума кластера происходит сбой, роль PAM автоматически перемещается на оставшийся сервер, который становится новым владельцем ресурса кворума кластера. Кроме того, если сервер, на котором размещен ресурс кворума кластера, необходимо перевести в автономный режим для обслуживания или обновления, сначала следует перенести роль PAM на другой сервер группы обеспечения доступности баз данных. Роль PAM контролирует все передвижения активных назначений между копиями баз данных. (Только одна копия в любой момент времени может быть активной, и она может быть подключенной или отключенной.) Роль PAM также выполняет функции роли SAM на локальном компьютере (обнаружение сбоев локальных баз данных и банка данных).
Роль SAM предоставляет сведения о том, на каком сервере размещается активная копия базы данных почтовых ящиков, другим компонентам Exchange, использующим клиентский компонент Active Manager (например, службе клиентского доступа или транспортной службе). Роль SAM обнаруживает сбои локальных баз данных и локального банка данных. Она реагирует на сбои, запрашивая у роли PAM отработку отказа (если база данных реплицирована). Роль SAM не определяет целевой сервер отработки отказа и не обновляет состояние расположения базы данных в роли PAM. Она обращается к состоянию расположения активной копии базы данных для ответа на получаемые запросы активной копии базы данных.
Примечание
Exchange 2013 не является кластеризованным приложением. Вместо этого функции библиотеки кластеризации clusapi.dll используются для реализации функциональности кластера, групп, сети кластера (пульса), управления узлами, реестра кластера и ряда задач управления. Кроме этого, служба Active Manager хранит сведения о текущем состоянии базы данных почтовых ящиков (данные об активных и пассивных копиях, а также о подключении) в базе данных кластера (также называется реестром кластера). Хотя эти сведения хранятся непосредственно в базе данных кластера, к ним не обращаются напрямую никакие другие компоненты.
В Exchange 2013 служба репликации Microsoft Exchange периодически отслеживает работоспособность всех подключенных баз данных. Кроме этого, она также отслеживает ошибки и сбои ввода-вывода подсистемы ESE. Если служба обнаруживает сбой, она уведомляет о нем службу Active Manager. Затем Active Manager определяет, какую копию базы данных следует подключить, и что для этого необходимо. Кроме того, он отслеживает активную копию базы данных почтового ящика (на основе последней подключенной копии базы данных) и предоставляет сведения о результатах отслеживания серверу клиентского доступа, к которому подключен клиент.
Лучший выбор копирования
Если происходит сбой, который препятствует доступу к активной копии реплицированной базы данных почтовых ящиков, Active Manager выполняет несколько действий для восстановления после сбоя, выбрав наилучшую пассивную копию затронутой базы данных для активации. В Exchange 2010 этот процесс был известен как выбор лучшей копии (BCS), а в Exchange 2013 он теперь называется лучшим копированием и выбором сервера (BCSS). Общий процесс выглядит следующим образом:
Компонент «Управляемая доступность» или Active Manager определяет сбой или администратор инициирует переключение без цели.
PAM запускает внутренний алгоритм BCSS.
Выполняется процесс, называемый попыткой копирования последних журналов (ACLL), в ходе которого предпринимается попытка скопировать с сервера все отсутствующие файлы журналов, находившиеся в активной копии базы данных до отказа или переключения.
После завершения процесса ACLL значение AutoDatabaseMountDial для серверов почтовых ящиков, на которых хранятся копии базы данных, сравнивается с длиной очереди копирования базы данных, которая активируется. На этом этапе выполняется одно из следующих действий:
количество отсутствующих файлов журнала равно или меньше значения AutoDatabaseMountDial, в таком случае выполняется шаг 5; или
количество отсутствующих файлов журнала превышает значение AutoDatabaseMountDial, в таком случае Active Manager попытается активировать следующую наиболее доступную копию, если такая существует.
PAM создает запрос на установку в банк данных Microsoft Exchange через удаленный вызов процедур (RPC). На этом этапе выполняется одно из следующих действий:
база данных подключается и становится доступной для клиентов; или
база данных не подключается, и РАМ выполняет действия 3 и 4 для следующей оптимальной копии (если она доступна).
В Exchange 2010 процесс BCS оценивал ряд свойств всех копий баз данных, чтобы определить "оптимальную" для активации копию. К ним относятся:
длина очереди копирования;
длина очереди воспроизведения;
состояние базы данных;
состояние индекса содержимого.
В Exchange 2013 Active Manager выполняет все те же проверки и этапы BCS, но теперь также включает в себя использование ограничения убывающей последовательности состояний работоспособности. В частности, BCSS включает несколько новых проверок работоспособности, которые входят в состав встроенных компонентов мониторинга управляемой доступности в Exchange 2013. Есть четыре новых дополнительных проверки, выполняемых Active Manager (перечислены в порядке их выполнения):
Все работоспособные. Проверяет наличие сервера, на котором размещена копия затронутой базы данных, которая содержит все компоненты мониторинга в работоспособном состоянии.
До нормальной работоспособности. Проверяет наличие сервера, на котором размещена копия затронутой базы данных, которая содержит все компоненты мониторинга с приоритетом "Обычный" в работоспособном состоянии.
Все лучше, чем источник. Проверяет наличие сервера, на котором размещена копия затронутой базы данных с компонентами мониторинга в состоянии, которое лучше, чем текущий сервер, на котором размещена затронутая копия.
То же самое, что источник: проверяет наличие сервера, на котором размещена копия затронутой базы данных, в состоянии которого находятся компоненты мониторинга, в том же состоянии, что и на текущем сервере, на котором размещена затронутая копия.
Если BCSS будет вызвано в результате отработки отказа, активированного компонентом наблюдения (т. е. через отвечающее устройство отработки отказов), вводится в действие дополнительное обязательное ограничение, устанавливающее, что работоспособность компонента целевого сервера должна быть выше, чем у сервера, на котором произошел сбой. Например, если при сбое Outlook Web App запускается отработка отказа через средство реагирования на отказ, СЛУЖБА BCSS должна выбрать сервер, на котором размещена копия затронутой базы данных, на которой Outlook Web App работоспособна.
Процесс выбора оптимальной копии
Что касается сбоев базы данных (не ошибок протокола), Active Manager в Exchange 2013 выполняет те же проверки, что и в Exchange 2010. Active Manager начинает процесс выбора оптимального копирования с создания списка копий базы данных, которые являются потенциальными кандидатами для активации. Все недоступные или административно заблокированные для активации копии базы данных игнорируются и не используются во время процесса выбора. Порядок расположения копий в списке зависит от значения AutoDatabaseMountDial:
Если параметр AutoDatabaseMountDial настроен с любым значением, отличным Lossless от всех серверов, на которых размещена копия базы данных, Active Manager сортирует результирующий список, используя длину очереди копирования в качестве первичного ключа. Вычисление выполняется на основании LastLogInspected (с точки зрения копии), поэтому список потенциальных копий сортируется по наибольшему значению LastLogInspected (копия с наименьшей длиной очереди копирования). Если необходимо, Active Manager сортирует список второй раз, используя значение предпочтения активации в качестве вторичного ключа, чтобы разорвать все условия связывания, при которых две или больше пассивных копии имеют одинаковую длину очереди копирования. Копия с наименьшим значением предпочтения активации имеет наибольший приоритет в списке.
Если параметр AutoDatabaseMountDial настроен со значением Lossless на любом сервере, на котором размещена копия базы данных, Active Manager сортирует результирующий список в порядке возрастания, используя значение параметра активации в качестве первичного ключа. Кроме того, когда администратор выполняет переключение базы данных или сервера без потерь, не указывая цель, Active Manager также сортирует список результатов по возрастанию, используя значение предпочтения активации в качестве первичного ключа.
Далее 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, DisconnectedAndResynchronizing или SeedingSource (десятый набор условий). Если копии, отвечающие десятому набору условий, не удается найти, автоматическая активация копии базы данных невозможна.
После обнаружения одной или нескольких копий, соответствующих одному или нескольким наборам условий, запускается процесс ACLL для копирования всех файлов журнала из исходного источника в потенциальную новую активную копию. После завершения процесса ACLL PAM отправляет запрос на подключение и либо база данных подключается и становится доступной для клиентов, либо база данных не подключается, и PAM ищет следующую лучшую копию (если она доступна).
В этом модуле рассмотрена поддержка высокой доступности и аварийного восстановления в Azure для рабочих нагрузок SAP, таких как серверы приложений SAP, экземпляры SAP ASCS-SCS, экземпляры СУБД и SAP HANA. Подготовка к экзамену AZ-120 "Планирование и администрирование рабочих нагрузок Microsoft Azure для SAP".
Администрирование инфраструктуры базы данных SQL Server для облачных, локальных и гибридных реляционных баз данных с помощью предложений реляционной базы данных Microsoft PaaS.