Share via

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

  • Article

Исходная статья опубликована в субботу, 22 сентября 2012 г.

Мониторинг является ключевым компонентом для любого успешного развертывания Exchange. В предыдущих выпусках мы приложили много усилий для разработки обработчика корреляций и тесно сотрудничали с группой разработчиков System Center Operations Manager (SCOM), чтобы представить комплексное решение предупреждения для сред Exchange.

Раньше понятие мониторинга обычно включало в себя сбор данных и, если это требовалось, выполнение действий на основании этих данных. Например, в контексте SCOM использовались разные механизмы для сбора данных посредством Exchange Management Pack:

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

Задачи мониторинга Exchange Server 2013

Когда мы приступили к разработке Exchange 2013, ключевым аспектом было улучшение сквозного мониторинга для всех развертываний Exchange — от самого маленького локального развертывания до самого крупного развертывания в мире, Office 365. Мы ставили перед собой три задачи:

  1. Предоставление наших знаний и опыта, связанных со службой Office 365, локальным клиентам  Почти 6 лет назад группа разработчиков Exchange запустила Exchange Online. Используемая нами операционная модель называется операционной моделью разработчиков (DevOps). В ней сведения о неполадках эскалируются непосредственно разработчику компонента, если этот компонент работает в службе неправильно или клиент сталкивается с неизвестной проблемой. Независимо от источника проблемы эскалация напрямую разработчику привносит элемент ответственности в процесс разработки программного обеспечения благодаря устранению неполадок ПО.

    Мы многому научились в результате использования данной модели. Например, в Exchange 2010 Management Pack присутствует почти 1100 предупреждений. Однако за прошедшие годы мы обнаружили, что в Office 365 полезными являются около 150 предупреждений (поэтому остальные мы убрали). Кроме того, мы обнаружили, что при получении эскалации разработчик с большей вероятностью проявит ответственность и начнет работу по устранению проблемы (с помощью исправления кода, новых рабочих процессов восстановления, настройки предупреждения и т. д.), так как он не хочет, чтобы его постоянно отрывали от работы для устранения одной и той же неполадки. В модели DevOps присутствует процесс, в котором дежурные каждую неделю проводят собрание для рассмотрения инцидентов за последнюю неделю; в результате осуществляется разработка собственных рабочих процессов восстановления, например сброс пулов приложений IIS и т. п. Перед Exchange 2013 у нас была своя собственная подсистема, которая обрабатывала такие рабочие процессы восстановления. Все эти знания так и не были перенесены в локальные продукты. В Exchange 2013 мы провели компонентизацию подсистемы рабочих процессов восстановления, чтобы иметь возможность поделиться накопленной информацией с локальными клиентами.

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

    Для прошлых выпусков каждой группе разработчиков компонентов требовалось создать модель работоспособности, соединяя все компоненты в своей системе. Например, транспорт состоит из SMTP-IN, SMTP-OUT, агентов транспорта, классификатора, модуля маршрутизации, драйвера хранилища и т. п. После этого группа разработчиков компонентов создавала предупреждения по каждому из таких компонентов. В результате в Management Pack имеются предупреждения, которые позволяют вам узнать о сбое драйвера хранилища. Однако это предупреждение не сообщает о сквозном взаимодействии с пользователем или о том, что может быть нарушено в таком взаимодействии. Поэтому в Exchange 2013 мы пытаемся перевернуть указанную модель "вверх дном". Мы не собираемся отказываться от мониторинга на уровне систем, так как он имеет важное значение. Но действительно важным при управлении службой является то, что именно видят ваши пользователи. Поэтому мы видоизменили модели и с нетерпением ждем возможности оценить и проанализировать взаимодействие с пользователем.

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

Мониторинг Exchange Server 2013 — управляемая доступность

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

Управляемая доступность ориентирована на пользователя. Мы хотим измерить три ключевых аспекта — доступность, взаимодействие с пользователем (которое для большинства протоколов измеряется по задержке) и наличие возникающих проблем. Чтобы лучше разобраться в этих трех аспектах, давайте рассмотрим в качестве примера пользователя, работающего с Outlook Web App (OWA).

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

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

Компоненты управляемой доступности

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

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

ma1
Рис. 1. Компоненты управляемой доступности

 

Зонды

Инфраструктура зондов состоит из трех отдельных платформ:

  1. Зонды — это искусственные транзакции, которые создаются каждой группой разработчиков компонентов. Они аналогичны тестовым командлетам в предыдущих выпусках. Зонды измеряют восприятие службы, выполняя пользовательские сквозные искусственные транзакции.
  2. Проверки представляют собой пассивный механизм мониторинга. Они измеряют фактический трафик клиента.
  3. Платформа уведомлений позволяет нам предпринимать немедленные действия, не ожидая выполнения зонда. То есть в случае обнаружения сбоя мы сразу же можем предпринять меры. Платформа уведомлений основана на уведомлениях. Например, когда истекает срок действия сертификата, активируется событие уведомления, которое оповещает операции о необходимости продления срока действия этого сертификата.

Мониторы

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

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

ma2
Рис. 2. Мониторинг на разных уровнях для проверки взаимодействия с пользователем

 

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

Мы осуществляем мониторинг на разных уровнях, чтобы выявить зависимости. Поскольку в Exchange 2013 нет обработчика корреляций, мы стараемся разграничить зависимости с помощью уникальных кодов ошибки, соответствующих разным зондам, и зондов, которые не связаны с зависимостями. Например, если вы видите, что произошел одновременный сбой зондов самопроверки почтового ящика и самопроверки протокола, какой вывод вы сделаете? Что перестало работать хранилище? Необязательно; этот вывод заключается в том, что не работает экземпляр локального протокола на сервере почтовых ящиков. Если вы видите, что зонд самопроверки протокола работает, а зонд самопроверки почтового ящика нет, какой вывод вы сделаете? Эта ситуация указывает на наличие проблемы на уровне "хранилища", которая может заключаться в отключении хранилища или базы данных.

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

Ответчики

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

Доступно несколько типов ответчиков:

  • Ответчик перезапуска — завершает работу службы и перезапускает ее.
  • Ответчик сброса пула приложений — выполняет отключение и повторное включение пула приложений IIS.
  • Ответчик отработки отказа — выводит сервер почтовых ящиков Exchange 2013 из эксплуатации.
  • Ответчик проверки на ошибки — запускает проверку сервера на наличие ошибок.
  • Автономный ответчик — выводит протокол на компьютере из эксплуатации.
  • Ответчик эскалации — осуществляет эскалацию проблемы.
  • Специализированные ответчики компонентов 

Автономный ответчик используется для прекращения использования протокола на серверах клиентского доступа. Этот ответчик разрабатывался как инвариантный к подсистеме балансировки нагрузки. При вызове этого ответчика протокол не подтверждает проверку работоспособности подсистемы балансировки нагрузки, таким образом позволяя этой подсистеме балансировки нагрузки удалить сервер или протокол из пула балансировки нагрузки. Также существует ответчик подключения к сети, который автоматически инициализируется, когда соответствующий монитор снова становится работоспособным (предполагается, что другие сопоставленные мониторы в неработоспособном состоянии отсутствуют); ответчик подключения к сети просто разрешает протоколу отвечать на проверку работоспособности подсистемы балансировки нагрузки, что позволяет этой подсистеме добавить сервер или протокол обратно в пул балансировки нагрузки. Автономный ответчик можно также вызвать вручную с помощью командлета Set-ServerComponentState. Это позволяет администраторам вручную перевести серверы клиентского доступа в режим обслуживания.

При вызове ответчик эскалации создает событие Windows, распознаваемое Exchange 2013 Management Pack. Это не обычное событие Exchange. Это не событие, которое сообщает, что OWA не работает или возникла ошибка ввода-вывода. Это событие Exchange, которое указывает, является ли набор работоспособности работоспособным или нет. Мы используем такие события отдельного экземпляра для управления мониторами внутри SCOM. И при этом мы берем за основу событие, создаваемое в ответчике эскалации, которое противопоставляется событиям, используемым в продукте. Другим походом к данной концепции является степень косвенности. Управляемая доступность решает, когда нам следует обратить монитор внутри SCOM. Управляемая доступность принимает решение о том, когда должна осуществляться эскалация, или, другими словами, когда в процесс следует вовлечь человека.

Ответчики также можно регулировать, чтобы не подвергнуть риску всю службу. Такое регулирование зависит от ответчика:

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

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

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

Важно понимать, что мониторы определяют типы выполняемых ответчиков и график их выполнения, мы называем это последовательностью восстановления для монитора. Например, предположим, что данные зонда протокола OWA (самопроверка протокола) активирует для монитора неработоспособное состояние. При этом сохраняется текущее время (назовем его T). Монитор запускает конвейер восстановления, который основан на текущем времени. Монитор может определять действия по восстановлению с заданными интервалами в конвейере восстановления. В случае с монитором протокола OWA на сервере почтовых ящиков последовательность восстановления имеет следующий вид:

  1. При T=0 выполняется ответчик сброса пула приложений IIS.
  2. Если при T=5 минут монитор не возвратился в работоспособное состояние, запускается ответчик отработки отказа и базы данных перемещаются с сервера.
  3. Если при T=8 минут монитор не возвратился в работоспособное состояние, запускается ответчик проверки на ошибки и выполняется принудительная перезагрузка сервера.
  4. Если при T=15 минут монитор все еще не возвратился в работоспособное состояние, активируется ответчик эскалации.

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

Systems Center Operations Manager (SCOM)

Systems Center Operations Manager (SCOM) используется в качестве портала для просмотра информации о работоспособности, связанной со средой Exchange. Неработоспособные состояния на портале SCOM активируются событиями, записанными в журнал приложений через ответчик эскалации. Панель мониторинга SCOM была обновлена и теперь содержит три ключевые области:

  • Активные предупреждения
  • Работоспособность организации
  • Работоспособность сервера

Exchange Server 2013 SCOM Management Pack будет поддерживаться в SCOM 2007 R2 и SCOM 2012.

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

Для любой среды значения по умолчанию могут не всегда соответствовать оптимальному состоянию, либо могут возникать условия, требующие выполнения экстренного действия. Управляемая доступность предоставляет возможность включить переопределения для всей среды или для отдельного сервера. Каждое переопределение можно задать на определенный период или применить к определенной версии сервера. Командлеты *-ServerMonitoringOverride и *-GlobalMonitoringOverride позволяют администраторам задавать, удалять и просматривать переопределения.

Определение работоспособности

Мониторы, которые похожи друг на друга или привязаны к архитектуре определенного компонента группируются в наборы работоспособности. Работоспособность набора работоспособности всегда определяется "худшим" из мониторов в этом наборе, то есть при наличии в наборе работоспособности 9 мониторов, 1 из которых неработоспособен, весь этот набор работоспособности считается неработоспособным. Вы можете определить коллекцию мониторов (а также соответствующих зондов и ответчиков) в заданном наборе работоспособности, используя командлет Get-MonitoringItemIdentity.

Для просмотра работоспособности вы используете командлеты Get-ServerHealth и Get-HealthReport. Get-ServerHealth используется для извлечения необработанных данных о работоспособности, а Get-HealthReport обрабатывает эти данные и предоставляет актуальный моментальный снимок работоспособности. Эти командлеты могут работать на нескольких уровнях:

  • Они могут показывать работоспособность для заданного сервера, анализируя ее по набору работоспособности.
  • Они могут использоваться для подробного рассмотрения отдельного набора работоспособности и просмотра состояния каждого из мониторов.
  • Они могут использоваться для создания сводки по работоспособности заданного набора серверов (членов группы обеспечения доступности баз данных или сбалансированного по нагрузке массива CAS).

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

  1. Точки контакта с клиентами — компоненты, которые напрямую взаимодействуют с клиентами в режиме реального времени (например, OWA).
  2. Компоненты-службы — компоненты, которые не взаимодействуют с клиентами напрямую в режиме реального времени (например, формирование автономной адресной книги).
  3. Серверные компоненты — физические ресурсы сервера (например, диск, память).
  4. Доступность зависимостей — способность сервера обращаться к зависимостям (например, Active Directory).

Заключение

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

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

Росс Смит IV (Ross Smith IV) Старший руководитель программы Группа улучшения качества программного обеспечения Exchange

  

"Вершитель высокой доступности Exchange" Грег Силь (Greg Thiel) старший руководитель-архитектор группы Exchange Server

Это локализованная запись блога. Оригинал статьи находится на странице Lessons from the Datacenter: Managed Availability