Наблюдение за высоким уровнем доступности и устойчивости сайта

Применимо к: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Последнее изменение раздела: 2015-03-09

Обеспечение надежной работы серверов и исправности копий баз данных является основным условием постоянной работы системы обмена сообщениями. Для обеспечения доступности и надежности организации Microsoft Exchange Server 2010 необходимо вести активное наблюдение за работой аппаратуры, операционной системы Windows и служб Exchange 2010. Профилактическое наблюдение и обслуживание помогает выявлять потенциальные ошибки до того, как они приведут к серьезным неполадкам в работе организации Exchange.

Наблюдение за организацией Exchange включает регулярные проверки наличия проблем со службами или данными. Обычно наблюдение включает также систему уведомлений, которая отправляет сигналы в случае возникновения проблем. ВWindows Server 2008 и Exchange 2010 имеются определенные средства и службы, помогающие обеспечить нормальную работу организации Exchange. Основные преимущества ежедневного наблюдения:

• удовлетворение требованиям соглашений об условиях обслуживания;

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

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

Необходимо формализовать процедуры, роли и ответственности, связанные с процессом эксплуатации организации Exchange 2010. Важно понимать связь между разумными рекомендациями и процедурами и работоспособной инфраструктурой. Хорошо документированные, всесторонние эксплуатационные процессы и процедуры гарантируют эффективное управление всеми компонентами среды организации, необходимыми для работы Exchange.

В Exchange 2010 предусмотрен ряд встроенных инструментов, сценариев и функций, которые можно использовать в рамках профилактического наблюдения, когда в Exchange настроено обеспечение высокой доступности и устойчивости сайта. Основные командлеты для наблюдения за сохранением высокой доступности и устойчивости сайта – это Get-MailboxDatabaseCopyStatus и Test-ReplicationHealth. В дополнение к командлетам, которые могут выполнять функции наблюдения и составления отчетов о состоянии, в Exchange 2010 также имеется новый поток журнала событий, использующий возможности канала Crimson в Windows Server, а также встроенные сценарии, которые могут собирать и анализировать данные из этих каналов событий.

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

Содержание

Командлет Get-MailboxDatabaseCopyStatus

Командлет Test-ReplicationHealth

Ведение журнала событий канала Crimson

Скрипт CollectOverMetrics.ps1

Скрипт CollectReplicationMetrics.ps1

Сценарий CheckDatabaseRedundancy.ps1

Командлет Get-MailboxDatabaseCopyStatus

Командлет Get-MailboxDatabaseCopyStatus можно использовать для просмотра сведений о состоянии копий баз данных почтовых ящиков. Этот командлет позволяет просматривать сведения о всех копиях конкретной базы данных, об определенной копии базы данных на определенном сервере или о всех копиях баз данных на сервере. В следующей таблице приведены возможные значения состояния копий баз данных почтовых ящиков.

Состояние копии базы данных

В командлете Get-MailboxDatabaseCopyStatus также имеется параметр с именем ConnectionStatus, который возвращает подробные сведения об используемых сетях репликации. При использовании этого параметра в выходных данных задачи будут заполнены поля выходных данных IncomingLogCopyingNetwork и SeedingNetwork.

Примеры использования командлета Get-MailboxDatabaseCopyStatus

В следующих примерах показано использование командлета Get-MailboxDatabaseCopyStatus. В каждом примере результат выполнения этого командлета передается в командлет Format-List для отображения результатов в виде списка.

В этом примере возвращаются сведения о состоянии всех копий базы данных с именем DB2.

Get-MailboxDatabaseCopyStatus -Identity DB2 | Format-List

В этом примере возвращаются сведения о состоянии всех копий базы данных на сервере почтовых ящиков с именем MBX2.

Get-MailboxDatabaseCopyStatus -Server MBX2 | Format-List

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

Get-MailboxDatabaseCopyStatus -Local | Format-List

В этом примере возвращаются сведения о состоянии и доставке журналов, а также сведения о заполнении сети для базы данных с именем DB3 на сервере почтовых ящиков с именем MBX1.

Get-MailboxDatabaseCopyStatus -Identity DB3\MBX1 -ConnectionStatus | Format-List

Дополнительные сведения об использовании командлета Get-MailboxDatabaseCopyStatus см. в разделе Get-MailboxDatabaseCopyStatus.

Командлет Get-MailboxDatabaseCopyStatus

Командлет Test-ReplicationHealth

Командлет Test-ReplicationHealth можно использовать для просмотра сведений о состоянии непрерывной репликации копий баз данных почтовых ящиков. Этот командлет можно использовать для проверки всех аспектов репликации и состояния преобразования, чтобы составить полный обзор конкретного сервера почтовых ящиков в группе обеспечения доступности баз данных.

Командлет Test-ReplicationHealth создан для профилактического наблюдения за непрерывной репликацией и конвейером непрерывной репликации, за доступностью службы Active Manager, а также за работоспособностью и состоянием внутренних служб кластеров, кворума и сетевых компонентов. Его можно выполнять локально или удаленно для любого сервера почтовых ящиков в группе обеспечения доступности баз данных. Командлет Test-ReplicationHealth выполняет тесты, приведенные в следующей таблице.

Тесты командлета Test-ReplicationHealth

Пример использования командлета Test-ReplicationHealth

В этом примере командлет Test-ReplicationHealth используется для тестирования исправности репликации сервера почтовых ящиков MBX1.

Test-ReplicationHealth -Identity MBX1

Командлет Get-MailboxDatabaseCopyStatus

Ведение журнала событий канала Crimson

В Windows Server 2008 имеется две категории журналов событий: журналы Windows и журналы приложений и служб. В категорию журналов Windows входят журналы событий, доступные в предыдущих версиях Windows: журналы событий приложений, безопасности и системы. Кроме того, в эту категорию включены два новых журнала: журнал установки (Setup) и журнал пересылаемых событий (ForwardedEvents). Журналы Windows предназначены для хранения событий из устаревших приложений и событий, относящихся ко всей системе.

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

В категорию журналов приложений и служб входят четыре подтипа: журналы администрирования, операционные, аналитические и отладки. События из журналов администрирования представляют особый интерес при использовании записей журналов событий для устранения проблем. События в журнале администрирования должны предоставлять рекомендации по реакции на эти события. События в операционном журнале также полезны, но для них может потребоваться дополнительная интерпретация. Журналы администрирования и отладки не понятны пользователям. Аналитические журналы (которые по умолчанию скрыты и отключены) хранят события, отслеживающие проблему, и в них часто записывается большой объем событий. Журналы отладки используются разработчиками при отладке приложений.

Exchange 2010 записывает события в каналы Crimson в области журналов приложений и служб. Эти каналы можно просмотреть, выполнив приведенные далее действия.

1. Откройте окно просмотра событий.

2. В дереве консоли выберите Журналы приложений и служб > Microsoft > Exchange.

3. В разделе Exchange выберите канал Crimson: HighAvailability или MailboxDatabaseFailureItems.

Канал HighAvailability содержит события, относящиеся к запуску и остановке службы репликации Microsoft Exchange и разным компонентам, работающим в службе репликации Microsoft Exchange, таким как диспетчер Active Manager, API синхронной репликации сторонних производителей, сервер Tasks RPC Server, прослушиватель TCP и модуль записи службы теневого копирования томов (VSS). Канал HighAvailability также используется диспетчером Active Manager для записи в журнал событий, относящихся к событиям отслеживания роли Active Manager и работы базы данных, таких как операция подключения базы данных и усечение журнала, а также для записи событий, относящихся к базовому кластеру группы обеспечения доступности баз данных.

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

Командлет Get-MailboxDatabaseCopyStatus

Скрипт CollectOverMetrics.ps1

В Exchange 2010 имеется скрипт с именем CollectOverMetrics.ps1, который можно найти в папке скриптов. Сценарий CollectOverMetrics.ps1 читает журналы событий членов группы обеспечения доступности баз данных, чтобы получить информацию об операциях над базой данных (подключениях, перемещениях и отработках отказов) за определенный период времени. Для каждой операции сценарий фиксирует следующую информацию.

• Идентификатор базы данных

• Время начала и окончания операции

• Серверы, к которым была подключена база данных в моменты начала и окончания операции

• Причина для выполнения операции

• Завершилась ли операция успешно, включая сведения об ошибках в случае сбоя операции

Сценарий записывает эти сведения в CSV-файлы (одна операция на каждой строке). Для каждой группы обеспечения доступности баз данных создается отдельный CSV-файл.

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

Параметры скрипта CollectOverMetrics.ps1

Примеры использования скрипта CollectOverMetrics.ps1

В следующем примере выполняется сбор показателей для всех баз данных с именами, соответствующих шаблону «DB*» (с учетом подстановочного знака), в группе обеспечения доступности баз данных DAG1. После сбора показателей создается и отображается отчет в формате HTML.

CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport

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

CollectOverMetrics -SummariseCsvFiles (dir *.csv) -Database MailboxDatabase123,MailboxDatabase456
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { $_.DatabaseName -notlike "Mailbox Database*" }
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { ($_.ActiveOnStart -like "ServerXYZ*") -and ($_.ActiveOnEnd -notlike "ServerXYZ*") }

Командлет Get-MailboxDatabaseCopyStatus

Скрипт CollectReplicationMetrics.ps1

CollectReplicationMetrics.ps1 — это еще один сценарий сбора показателей работоспособности, включенный в Exchange 2010. Этот сценарий представляет собой активную форму наблюдения, поскольку он собирает показатели в режиме реального времени в ходе выполнения. Сценарий CollectReplicationMetrics.ps1 собирает данные, полученные от счетчиков производительности, которые относятся к репликации баз данных. Этот сценарий собирает данные счетчиков с нескольких серверов почтовых ящиков, записывает данные каждого сервера в CSV-файл и создает отчеты по различным статистическим показателям для всех этих данных (например, по таким показателям, как период, в течение которого каждая копия находилась в состоянии сбоя или приостановки, средняя длина очереди копирования или преобразования или период, в течение которого для копий не выполнялись критерии отработки отказа).

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

Данные, собранные с каждого сервера, записываются в файл с именем CounterData.<имя_сервера>.<отметка_времени>.csv. Сводный отчет записывается в файл с именем HaReplPerfReport.<имя_группы_обеспечения_доступности_баз_данных>.<отметка_времени>.csv или HaReplPerfReport.<отметка_времени>.csv, если сценарий не был запущен с параметром DagName.

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

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

Параметры скрипта CollectReplicationMetrics.ps1

Пример использования CollectReplicationMetrics.ps1

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

CollectReplicationMetrics.ps1 -DagName DAG1 -Duration "01:00:00" -Frequency "00:01:00" -ReportPath

В следующем примере показано чтение данных из всех файлов, отвечающих критерию «CounterData*», и затем создание сводного отчета.

CollectReplicationMetrics.ps1 -SummariseFiles (dir CounterData*) -Mode ProcessOnly -ReportPath

Командлет Get-MailboxDatabaseCopyStatus

Сценарий CheckDatabaseRedundancy.ps1

Как следует из названия, сценарий CheckDatabaseRedundancy.ps1 предназначен для контроля избыточности реплицированных баз данных почтовых ящиков. Для этого выполняется проверка наличия не менее двух настроенных и работоспособных текущих копий. Если существует только одна работоспособная копия реплицированной базы данных, то пользователю выдается оповещение. В этом случае при определении избыточности учитываются и активная, и пассивные копии.

Когда установлена роль сервера почтовых ящиков, сценарий CheckDatabaseRedundancy.ps1 автоматически настраивается продуктом Exchange на запуск запланированной задачи с именем Database One Copy Alert. По умолчанию запланированная задача Database One Copy Alert настроена на выполнение каждые 60 минут. Это поведение и параметры запланированной задачи можно изменить с помощью планировщика заданий Windows. Прежде всего этот сценарий проверяет членство в группе обеспечения доступности баз данных, поэтому если сервер почтовых ящиков не является членом такой группы, сценарий сразу же завершает работу.

Этот сценарий также можно запуска интерактивно из папки сценариев. При интерактивном запуске этого сценария необходимо указать либо имя базы данных, либо имя члена группы обеспечения доступности баз данных. Чтобы указать базу данных, используйте параметр MailboxDatabaseName, а для указания члена группы обеспечения доступности баз данных — параметр MailboxServerName. В случае интерактивного запуска в консоли сценарий выполняет проверку избыточности только один раз и выводит данные о текущем состоянии CurrentState (красный или зеленый индикатор) на экран.

Аналогично другим сценариям и командлетам, CheckDatabaseRedundancy.ps1 может быть запущен в режиме наблюдения и создавать события, если добавить параметр MonitoringContext. Созданная Exchange запланированная задача запускает сценарий в режиме наблюдения. В этом случае режиме сценарий также может вызываться решением для отслеживания, таким как Microsoft System Center Operations Manager (SCOM). В режиме наблюдения сценарий создает события красного и зеленого цвета в журнале событий приложений на локальном сервере. Событие красного цвета (код события 4113) создается, только если база данных находилась в «красном» состоянии в течение 20 минут и более (в общей сложности, не подряд) из часового периода работы сценария, а событие зеленого цвета (код события 4114) — когда база данных находилась в «зеленом» состоянии в течение 10 минут подряд. По умолчанию оповещение о событии красного цвета повторяется каждые 15 минут после своего появления.

Кроме того, данный сценарий имеет ряд других полезных параметров. Например, можно добавить параметр ShowDetailedErrors, чтобы получить более подробные сведения обо всех возникших ошибках, или параметр Verbose — для получение информации по устранению неполадок. Сценарий также включает параметр SendSummaryMailTos, который позволяет отправить сводный отчет по электронной почте на указанные адреса по завершении работы сценария. Так администраторы могут быстро просматривать часовые отчеты и обнаруживать проблемы избыточности. Чтобы использовать функцию отправки отчета по электронной почте, необходимо включать параметр SummaryMailFrom в каждом случае использования параметра SendSummaryMailTos.

Корпорация Майкрософт рекомендует регулярно запускать этот сценарий в ходе обычных операций мониторинга, используя автоматизированную запланированную задачу или систему наблюдения, такую как SCOM. Чтобы избежать возникновения длительных периодов, когда избыточность базы данных находится под угрозой, запускайте этот сценарий каждые 60 минут. Сценарий включает параметр TerminateAfterDurationSecs. Если для него во время выполнения сценария заданы значения -1 или 0, то этот параметр позволяет запускать сценарий на бесконечный период времени.

Если вы не используете решение для отслеживания, такое как SCOM, рекомендуем разрешить автоматически созданной запланированной задаче автоматизировать и запланировать выполнение сценария.

В планировщике заданий Windows Server 2008 SP2 есть известные проблемы, которые могут привести к сбою планировщика в случае планирования продолжительной задачи. В Windows Server 2008 R2 эти проблемы отсутствуют, поэтому по возможности запускайте сценарий из Windows Server 2008 R2. Если вы не можете запустить сценарий из Windows Server 2008 R2 и вам приходится запускать его из Windows Server 2008 с пакетом обновления 2 (SP2), рекомендуется внести два изменения. Во-первых, вместо запуска сценария со встроенным промежуточным подавлением 60 минут, запускайте сценарий каждые 5 минут. Для этого укажите следующие параметры:

CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors

Во-вторых, если возможно, используйте SCOM для задания поведения промежуточного подавления (например, если в течение 20 минут регистрируются 3 события красного цвета, создается оповещение, а если регистрируется событие зеленого цвета, то цвет CurrentState меняется на зеленый).

Если запланированная задача Database One Copy Alert изменена или удалена, вы можете удалить и повторно запланировать ее с помощью следующей команды:

schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY

Замените параметры в приведенном выше сценарии нужными параметрами. Дополнительные параметры также описаны в сценарии.

При использовании средства командной строки schtasks для создания запланированной задачи длина параметра /TR ограничена 261 символом. В приведенном выше примере этот предел превышен. Если используются параметры и пути, при которых длина параметра /TR превышает 261 символ, необходимо вручную создать запланированную задачу при помощи планировщика заданий в меню «Администрирование». Либо можно скопировать и вставить следующий XML-код в Блокнот, отредактировать его нужным образом, сохранить как XML-файл и импортировать с помощью планировщика заданий:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="https://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2010-05-11T15:55:47</Date>
    <Author>administrator</Author>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT1H</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2010-05-11T15:55:00</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>SYSTEM</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <IdleSettings>
      <Duration>PT10M</Duration>
      <WaitTimeout>PT1H</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>Powershell.exe</Command>
      <Arguments>-NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue</Arguments>
    </Exec>
  </Actions>
</Task>

Командлет Get-MailboxDatabaseCopyStatus

 © Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены.