Управляемая доступность

Область применения: Exchange Server 2013 с пакетом обновления 1 (SP1)

Удобство работы пользователей с электронной почтой всегда было основной целью администраторов систем обмена сообщениями. Чтобы обеспечить доступность и надежность организации Microsoft Exchange Server 2013, необходимо активно отслеживать все аспекты системы и быстро устранять все обнаруженные проблемы. В предыдущих версиях Exchange мониторинг критически важных системных компонентов обычно включался с помощью внешнего приложения, например Microsoft System Center 2012 Operations Manager, для сбора данных, а также для обеспечения действий по восстановлению проблем, обнаруженных в результате анализа собранных данных. Exchange 2010 и предыдущие версии включали манифесты работоспособности и подсистемы корреляции в виде пакетов управления. Эти компоненты позволили Operations Manager определить, является ли конкретный компонент работоспособным или неработоспособным. Кроме того, Operations Manager также использовал инфраструктуру командлетов диагностики, встроенную в Exchange 2010, для выполнения искусственных транзакций с различными аспектами системы.

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

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

• Доступность. Могут ли пользователи получить доступ к службе?
• Задержка. Как это происходит для пользователей?
• Ошибки. Могут ли пользователи выполнить то, что они хотят?

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

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

Управляемая доступность реализована в виде двух служб:

• Служба диспетчера работоспособности Exchange (MSExchangeHMHost.exe): эта служба является процессом контроллера, используемым для управления рабочими процессами. Он используется для создания, выполнения, запуска и остановки рабочих процессов по мере необходимости. Он также используется для восстановления рабочих процессов при сбоях, чтобы рабочие процессы не становились едиными точками отказа.

• Рабочий процесс Диспетчера работоспособности Exchange (MSExchangeHMWorker.exe):эта служба является рабочим процессом, ответственным за выполнение задач во время выполнения в управляемой платформе доступности.

Управляемая доступность использует постоянное хранилище для выполнения своих функций:

• XML-файлы в папке \bin\Monitoring\config используются для хранения параметров конфигурации некоторых рабочих элементов зондов и мониторов.
• Active Directory используется для хранения глобальных переопределений.
• Реестр Windows используется для хранения данных времени выполнения, например закладок, и локальных переопределений (для определенного сервера).
• Инфраструктура журнала событий красного канала Windows используется для хранения результатов рабочих элементов.
• Почтовые ящики работоспособности используются для операций зондов. Для каждой базы данных почтовых ящиков на сервере создается несколько почтовых ящиков работоспособности.

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

г.

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

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

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

Все зонды определяются при запуске службы диспетчера работоспособности в красном канале Microsoft.Exchange.ActiveMonitoring\ProbeDefinition. Каждое определение пробы имеет множество свойств, но наиболее релевантные свойства:

• Имя: имя пробы, начинающееся с sampleMask монитора пробы.
• TypeName: тип объекта кода пробы, который содержит логику пробы.
• ServiceName: имя набора работоспособности, содержащего эту пробу.
• TargetResource: объект, проверяемый пробой. Это имя свойства добавляется к имени пробы при его выполнении, чтобы стать результатом проверки ResultName.
• RecurrenceIntervalSeconds: частота выполнения пробы.
• TimeoutSeconds: время ожидания пробы перед сбоем.

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

В основе повторяющихся зондов лежит запуск через равные промежутки времени (RecurrenceIntervalSeconds) и проверка (или зондирование) некоторых аспектов работоспособности. Если компонент работоспособен, зонд записывает информационное событие в канал Microsoft.Exchange.ActiveMonitoring\ProbeResult с параметром ResultType, имеющим значение 3. Если происходит ошибка проверки или истекает время ожидания, зонд выдает ошибку и записывает сообщение об ошибке в тот же канал. Тип результата 4 означает, что проверка завершилась сбоем, а resultType 1 означает, что истекло время ожидания. Если истекает время ожидания, многие пробы будут выполняться повторно до значения свойства MaxRetryAttempts.

Уведомления — это зонды, которые выполняет не инфраструктура диспетчера работоспособности, а некоторые другие службы на сервере. Эти службы проводят собственный мониторинг, а затем передают их данные в инфраструктуру управляемой доступности, напрямую записывая результаты зондов. Эти зонды не отображаются в канале ProbeDefinition, поскольку в нем описываются только зонды, выполняемые инфраструктурой управляемой доступности. Например, монитор ServerOneCopyMonitor активируют результаты зонда, записанные службой MSExchangeDAGMgmt. Эта служба выполняет собственный мониторинг, определяет наличие проблемы и записывает в журнал результаты зонда. Большинство зондов-уведомлений могут записывать в журнал как красные события (указывают на неработоспособный монитор), так и зеленые (возобновление работоспособности монитора).

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

С помощью монитора для этой проверки можно определить счетчик и пороговое значение, которые считаются неработоспособными. Мониторы типа Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor или Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor означают, что зонд, который они отслеживают, является пробой проверки.

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

• Работоспособность: монитор работает должным образом, и все собранные метрики находятся в пределах нормальных рабочих параметров
• Неработоспособно. Монитор не работоспособен и инициировал восстановление через ответчика или уведомил администратора путем эскалации.

С точки зрения администрирования мониторы имеют гораздо больше состояний, которые отображаются в оболочке:

• Пониженная производительность. Если монитор находится в неработоспособном состоянии от 0 до 60 секунд, он считается неработоспособным. Если монитор пребывает в неработоспособном состоянии дольше 60 секунд, он считается неработоспособным.
• Отключено: монитор был явно отключен администратором.
• Недоступно: служба работоспособности Microsoft Exchange периодически запрашивает состояние каждого монитора. Если служба не получает ответ на запрос, состояние монитора изменяется на "Недоступный".
• Исправление. Администратор задает состояние восстановления, чтобы указать системе, что корректирующее действие выполняется человеком, что позволяет системе и людям различать другие сбои, которые могут произойти в то же время, когда выполняется корректирующее действие (например, операция повторного копирования базы данных).

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

Стоит отметить, что один сбой пробы не обязательно указывает на то, что с сервером что-то не так. Это конструкция мониторов, которая позволяет правильно определить, когда возникает реальная проблема, которую необходимо устранить. Таким образом, многие мониторы имеют пороговые значения нескольких сбоев пробы, прежде чем стать неработоспособными. Даже в этом случае многие из этих проблем могут быть автоматически устранены ответчиками, поэтому лучше всего искать проблемы, требующие вмешательства вручную, — в канале Microsoft.Exchange.ManagedAvailability\Monitoring crimson. Этот канал содержит последнюю ошибку пробы.

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

• Перезапуск ответчика: завершает и перезапускает службу.
• Сброс ответчика AppPool: останавливает и перезапускает пул приложений в службах IIS.
• Ответчик отработки отказа: инициирует отработку отказа базы данных или сервера
• Ответчик ошибок: инициирует проверку ошибок сервера, тем самым вызывая перезагрузку сервера.
• Автономный ответчик: выводит протокол на сервере из строя (отклоняет клиентские запросы)
• Online Responder: размещает протокол на сервере обратно в рабочую среду (принимает клиентские запросы)
• Ответ на эскалацию: передает сведения о проблеме администратору с помощью ведения журнала событий.

Помимо указанных ответчиков у некоторых компонентов также есть специализированные уникальные ответчики.

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

Настройки работоспособности

С точки зрения отчетности управляемая доступность реализует два представления работоспособности: внутреннее и внешнее. Во внутреннем представлении используются наборы работоспособности. Каждый компонент в Exchange 2013 (например, Outlook Web App, Exchange ActiveSync, служба хранилища сведений, индексирование содержимого, транспортные службы и т. д.) отслеживается с помощью управляемой доступности с помощью проб, мониторов и ответчиков. Группа проб, мониторов и ответчиков для данного компонента называется набором работоспособности. Набор работоспособности — это группа проб, мониторов и средств реагирования, которые определяют работоспособность этого компонента. Текущее состояние набора работоспособности (например, является ли он работоспособным или неработоспособным) определяется с помощью мониторов набора работоспособности. Если все мониторы набора работоспособности работоспособны, то набор работоспособности находится в работоспособном состоянии. Если какой-либо монитор не находится в работоспособном состоянии, состояние набора работоспособности будет определяться его наименее работоспособным монитором.

Подробные инструкции для просмотра работоспособности сервера или состояния набора оценки работоспособности см. в статье Manage health sets and server health.

Группы работоспособности

Внешнее представление управляемой доступности состоит из групп работоспособности. Группы работоспособности предоставляются в System Center Operations Manager 2007 R2 и System Center Operations Manager 2012.

Существует четыре основных группы работоспособности:

• Точки касания клиентов: компоненты, влияющие на взаимодействие с пользователем в режиме реального времени, например протоколы или хранилище сведений.
• Компоненты службы: компоненты без прямого взаимодействия с пользователем в режиме реального времени, например служба репликации почтовых ящиков Microsoft Exchange или процесс создания автономной адресной книги (OABGen)
• Компоненты сервера: физические ресурсы сервера, такие как дисковое пространство, память и сеть.
• Доступность зависимостей. Возможность доступа сервера к необходимым зависимостям, таким как Active Directory, DNS и т. д.

Если установлен пакет управления Exchange, System Center Operations Manager (SCOM) служит порталом работоспособности для просмотра сведений, связанных со средой Exchange. Панель мониторинга SCOM содержит три представления работоспособности сервера Exchange:

• Активные оповещения. Ответчики эскалации записывают события в журнал событий Windows, которые используются монитором в SCOM. Эти события отображаются в виде оповещений в представлении Активные оповещения.
• Работоспособность организации. В этом представлении отображается сводная сводка по общей работоспособности организации Exchange. Эти накопительные пакеты включают отображение работоспособности для отдельных групп доступности баз данных и работоспособности на определенных сайтах Active Directory.
• Работоспособность сервера. Связанные наборы работоспособности объединяются в группы работоспособности и суммируются в этом представлении.

Переопределения

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

Переопределения можно создавать и применять к одному серверу (этот процесс называется переопределением сервера) или к группе серверов (этот процесс называется глобальным переопределением). Данные конфигурации переопределения сервера хранятся в реестре Windows на сервере, к которому применяется переопределение. Данные конфигурации глобального переопределения хранятся в Active Directory.

Переопределения можно настраивать без срока действия или с заданным сроком действия. Кроме того, глобальные переопределения можно настроить для всех серверов или только серверов с определенной версией Exchange.

При настройке переопределения оно вступит в силу не сразу. Служба диспетчера работоспособности Microsoft Exchange проверяет наличие обновленных данных конфигурации каждые 10 минут. Кроме того, глобальные переопределения зависят от задержки репликации Active Directory.

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

Задачи управления и командлеты

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

• извлечение или просмотр состояния системы;
• просмотр настроек работоспособности и сведений о зондах, мониторах и ответчиках;
• управление переопределениями.

Два основных средства для работы с управляемой доступностью — это журнал событий Windows и командная консоль. Компонент управляемой доступности записывает много информации в красные каналы ActiveMonitoring и ManagedAvailability журналов событий Exchange, например:

• определения зондов, мониторов и ответчиков, которые записываются в соответствующие журналы событий *Definition;
• результаты зондов, мониторов и ответчиков, которые записываются в соответствующие журналы событий *Results;
• сведения о действиях восстановления ответчика, в том числе время начала и завершения действия (при успешном или неудачном выполнении), которые записываются в журнал событий RecoveryActionResults.

Существует 12 командлетов для управляемой доступности, которые описаны в следующей таблице.