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

Область действия: 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 используются для хранения параметров конфигурации для некоторых элементов пробы и мониторинга рабочих элементов.
  • Active Directory используется для хранения глобальных переопределений.
  • Реестр Windows используется для хранения данных времени выполнения, например закладок, и локальных переопределений (для определенного сервера).
  • Инфраструктура журнала событий красного канала Windows используется для хранения результатов рабочих элементов.
  • Почтовые ящики работоспособности используются для операций зондов. Для каждой базы данных почтовых ящиков на сервере создается несколько почтовых ящиков работоспособности.

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

  • Перезапуск отвечающего устройства: завершает и перезапускает службу
  • Reset AppPool Responder: Stops and restarts an application pool in Internet Information Services (IIS)
  • Отработка отказа: инициирует отработку отказа базы данных или сервера
  • Отвечающее устройство для проверки ошибок: инициирует проверку ошибки сервера, что приводит к перезагрузке сервера
  • Автономная служба реагирования: принимает протокол на сервере из-под обслуживания (отклоняет клиентские запросы)
  • Online Responder: перевод протокола на сервер обратно в рабочую среду (принимает клиентские запросы)
  • Escalate 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 командлетов для управляемой доступности, которые описаны в следующей таблице.

Командлет Описание
Get-ServerHealth Используется для получения необработанной информации о работоспособности сервера, например настройки работоспособности и их текущее состояние (исправно или нет), мониторы настроек работоспособности, серверные компоненты, целевые ресурсы для зондов и временные метки, связанные с временем запуска или остановки зонда или монитора, а также время перехода в то или иное состояние.
Get-HealthReport Используется для получения сводного представления работоспособности, которое включает в себя настройки работоспособности и их текущее состояние.
Get-MonitoringItemIdentity Используется для просмотра зондов, мониторов и ответчиков, связанных с определенными настройками работоспособности.
Get-MonitoringItemHelp Используется для просмотра описания некоторых свойств зондов, мониторов и ответчиков.
Add-ServerMonitoringOverride Используется для создания локального, предназначенного для конкретного сервера переопределения зонда, монитора или ответчика.
Get-ServerMonitoringOverride Используется для просмотра списка локальных переопределений на указанном сервере.
Remove-ServerMonitoringOverride Используется для удаления локального переопределения на указанном сервере.
Add-GlobalMonitoringOverride Используется для создания глобального переопределения для группы серверов.
Get-GlobalMonitoringOverride Используется для просмотра списка глобальных переопределяет, настроенных в организации.
Remove-GlobalMonitoringOverride Используется для удаления глобального переопределения.
Set-ServerComponentState Используется для настройки состояния одного или нескольких серверных компонентов.
Get-ServerComponentState Используется для просмотра состояния одного или нескольких серверных компонентов.