Применимо к: Exchange Server 2010 SP1
Последнее изменение раздела: 2011-04-21
Обеспечение надежной работы серверов и исправности копий баз данных является основным условием постоянной работы системы обмена сообщениями. Для обеспечения доступности и надежности организации 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
Скрипт CollectReplicationMetrics.ps1
Сценарий CheckDatabaseRedundancy.ps1
Командлет
Get-MailboxDatabaseCopyStatus
Командлет Get-MailboxDatabaseCopyStatus можно использовать для просмотра сведений о состоянии копий баз данных почтовых ящиков. Этот командлет позволяет просматривать сведения о всех копиях конкретной базы данных, об определенной копии базы данных на определенном сервере или о всех копиях баз данных на сервере. В следующей таблице приведены возможные значения состояния копий баз данных почтовых ящиков.
Состояния копий баз данных
| Состояние копии базы данных | Описание |
|---|---|
|
Failed (сбой) |
Копия базы данных почтовых ящиков находится в состоянии Failed (сбой), поскольку она не приостановлена, но не может копировать или преобразовывать файлы журналов. Пока копия базы данных не приостановлена и находится в состоянии сбоя, система будет периодически проверять, устранена ли проблема, которая привела к состоянию сбоя. После того как система обнаружит, что эта проблема устранена, и никакие другие проблемы не мешают, состояние копии автоматически изменяется на Healthy (исправно). |
|
Seeding (заполнение) |
Выполняется заполнение или копии базы данных почтовых ящиков, или индекса контента или и того, и другого. После успешного завершения заполнения состояние копии должно измениться на Initializing (инициализация). |
|
SeedingSource (источник заполнения) |
Копия базы данных почтовых ящиков используется как источник для заполнения копии базы данных. |
|
Suspended (приостановлено) |
Копия базы данных почтовых ящиков находится в состоянии Suspended (приостановлено) в результате того, что администратор вручную приостановил эту копию базы данных, выполнив командлет Suspend-MailboxDatabaseCopy. |
|
Healthy (исправно) |
Копия базы данных почтовых ящиков успешно копирует и преобразует файлы журналов, или она уже успешно скопировала и преобразовала все доступные файлы журналов. |
|
ServiceDown (служба не работает) |
Служба репликации Microsoft Exchange недоступна или не работает на сервере, на котором находится эта копия базы данных. |
|
Initializing (инициализация) |
Копия базы данных почтовых ящиков будет находиться в состоянии инициализации, когда создана копия базы данных, когда служба репликации Microsoft Exchange запускается или только что запущена, а также во время перехода из состояния Suspended (приостановлено), ServiceDown (служба не работает), Failed (сбой), Seeding (заполнение), SinglePageRestore (восстановление одной страницы), LostWrite (потеря записи) или Disconnected (отключено) в другое состояние. В этом состоянии система проверяет, находятся ли база данных и поток журнала в согласованном состоянии. В большинстве случаев копия находится в состоянии инициализации около 15 секунд, и во всех случаях она не должна находиться в этом состоянии долее 30 секунд. |
|
Resynchronizing (повторная синхронизация) |
Копия базы данных почтовых ящиков и ее файлы журналов сравниваются с действующей копией базы данных для поиска какого-либо отклонения этой копии. Копия остается в этом состоянии до тех пор, пока отклонение не будет обнаружено и устранено. |
|
Mounted (подключено) |
Активная копия находится в оперативном режиме и принимает клиентские подключения. Только активная копия базы данных почтовых ящиков может находиться в состоянии «подключено». |
|
Dismounted (отключено) |
Активная копия находится в автономном режиме и не принимает клиентские подключения. Только активная копия базы данных почтовых ящиков может находиться в состоянии «отключено». |
|
Mounting (подключение) |
Активная копия переходит в оперативный режим и еще не принимает клиентские подключения. Только активная копия базы данных почтовых ящиков может находиться в состоянии «подключение». |
|
Dismounting (отключение) |
Активная копия переходит в автономный режим и завершает клиентские подключения. Только активная копия базы данных почтовых ящиков может находиться в состоянии «отключение». |
|
DisconnectedAndHealthy (отключено и исправно) |
Копия базы данных почтовых ящиков больше не подключена к активной копии базы данных, но во время потери подключения она находилась в исправном состоянии. Это состояние представляет копию базы данных по отношению к ее исходной копии базы данных. Такое состояние может быть получено при сбоях сети группы обеспечения доступности баз денных между исходной и целевой копиями базы данных. |
|
DisconnectedAndResynchronizing (отключение и повторная синхронизация) |
Копия базы данных почтовых ящиков больше не подключена к активной копии базы данных, но во время потери подключения она находилась в состоянии повторной синхронизации. Это состояние представляет копию базы данных по отношению к ее исходной копии базы данных. Такое состояние может быть получено при сбоях сети группы обеспечения доступности баз денных между исходной и целевой копиями базы данных. |
|
FailedAndSuspended (сбой и приостановка) |
Состояния сбоя и приостановки установлены системой одновременно, поскольку был обнаружен сбой, и для устранения этого сбоя явно требуется вмешательство администратора. В качестве примера можно привести ситуацию, когда система обнаружила неустранимое отклонение активной базы данных почтовых ящиков от ее копии. В отличие от состояния сбоя, в данном состоянии система не будет периодически проверять, устранена ли проблема, и выполнять автоматическое восстановление. Здесь необходимо вмешательство администратора, который должен устранить причину сбоя, прежде чем копия база данных может быть переведена в исправное состояние. |
|
SinglePageRestore (восстановление одной страницы) |
Это состояние указывает, что в копии базы данных почтовых ящиков происходит операция восстановления одной страницы. |
В командлете 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.
Командлет
Test-ReplicationHealth
Командлет Test-ReplicationHealth можно использовать для просмотра сведений о состоянии непрерывной репликации копий баз данных почтовых ящиков. Этот командлет можно использовать для проверки всех аспектов репликации и состояния преобразования, чтобы составить полный обзор конкретного сервера почтовых ящиков в группе обеспечения доступности баз данных.
Командлет Test-ReplicationHealth создан для профилактического наблюдения за непрерывной репликацией и конвейером непрерывной репликации, за доступностью службы Active Manager, а также за работоспособностью и состоянием внутренних служб кластеров, кворума и сетевых компонентов. Его можно выполнять локально или удаленно для любого сервера почтовых ящиков в группе обеспечения доступности баз данных. Командлет Test-ReplicationHealth выполняет тесты, приведенные в следующей таблице.
Тесты командлета Test-ReplicationHealth
| Имя теста | Описание |
|---|---|
|
ClusterService |
Проверяет, работает ли служба кластеров и достижима ли она в указанном члене группы обеспечения доступности баз данных, а если член этой группы не указан, то достижима ли она на локальном сервере. |
|
ReplayService |
Проверяет, работает ли служба репликации Microsoft Exchange и достижима ли она в указанном члене группы обеспечения доступности баз данных, а если член этой группы не указан, то достижима ли она на локальном сервере. |
|
ActiveManager |
Проверяет, имеет ли экземпляр диспетчера Active Manager, работающий в указанном члене группы обеспечения доступности баз данных (или если этот член группы не указан, то на локальном сервере), допустимую роль (основной, дополнительный или отдельный). |
|
TasksRpcListener |
Проверяет, работает ли сервер Tasks RPC Server и достижим ли он в указанном члене группы обеспечения доступности баз данных, а если член этой группы не указан, то достижим ли он на локальном сервере. |
|
TcpListener |
Проверяет, работает ли прослушиватель копий журналов TCP и достижим ли он в указанном члене группы обеспечения доступности баз данных, а если член этой группы не указан, то достижим ли он на локальном сервере. |
|
DagMembersUp |
Проверяет, работают ли все члены группы обеспечения доступности баз данных, а также их доступность и достижимость. |
|
ClusterNetwork |
Проверяет, доступны ли все управляемые кластером сети в указанном члене группы обеспечения доступности баз данных (или на локальном сервере, если член этой группы не указан). |
|
QuorumGroup |
Проверяет, находится ли кластерная группа по умолчанию (группа кворума) в исправном и оперативном состоянии. |
|
FileShareQuorum |
Проверяет, настроен ли следящий сервер и файловый ресурс-свидетель таким образом, чтобы была достижима группа обеспечения доступности баз данных. |
|
DBCopySuspended |
Проверяет, находятся ли какие-либо копии баз данных почтовых ящиков в приостановленном состоянии в указанном члене группы обеспечения доступности баз данных, а если член этой группы не указан, то на локальном сервере. |
|
DBCopyFailed |
Проверяет, находятся ли какие-либо копии баз данных почтовых ящиков в состоянии сбоя в указанном члене группы обеспечения доступности баз данных, а если член этой группы не указан, то на локальном сервере. |
|
DBInitializing |
Проверяет, находятся ли какие-либо копии баз данных почтовых ящиков в состоянии инициализации в указанном члене группы обеспечения доступности баз данных, а если член этой группы не указан, то на локальном сервере. |
|
DBDisconnected |
Проверяет, находятся ли какие-либо копии баз данных почтовых ящиков в отключенном состоянии в указанном члене группы обеспечения доступности баз данных, а если член этой группы не указан, то на локальном сервере. |
|
DBLogCopyKeepingUp |
Проверяет, выполняется ли копирование и проверка журнала пассивными копиями баз данных в указанном члене группы обеспечения доступности баз данных (или на локальном сервере, если этот член не указан) согласованно с действиями по созданию журнала в активной копии. |
|
DBLogReplayKeepingUp |
Проверяет, выполняются ли действия по преобразованию пассивных копий баз данных в указанном члене группы обеспечения доступности баз данных (или на локальном сервере, если этот член не указан) согласованно с действиями по копированию и проверке журнала. |
Пример использования командлета Test-ReplicationHealth
В этом примере командлет Test-ReplicationHealth используется для тестирования исправности репликации сервера почтовых ящиков MBX1.
| Скопировать код |
|
|---|---|
Test-ReplicationHealth -Identity MBX1 |
|
Ведение журнала событий канала
Crimson
В Windows Server 2008 имеется две категории журналов событий: журналы Windows и журналы приложений и служб. В категорию журналов Windows входят журналы событий, доступные в предыдущих версиях Windows: журналы событий приложений, безопасности и системы. Кроме того, в эту категорию включены два новых журнала: журнал установки (Setup) и журнал пересылаемых событий (ForwardedEvents). Журналы Windows предназначены для хранения событий из устаревших приложений и событий, относящихся ко всей системе.
Журналы приложений и служб представляют собой новую категорию журналов событий. Эти журналы хранят события из одного приложения или компонента, а не события, которые имеют значение на уровне системы. Эта новая категория журналов событий называется каналом Crimson приложения.
В категорию журналов приложений и служб входят четыре подтипа: журналы администрирования, операционные, аналитические и отладки. События из журналов администрирования представляют особый интерес при использовании записей журналов событий для устранения проблем. События в журнале администрирования должны предоставлять рекомендации по реакции на эти события. События в операционном журнале также полезны, но для них может потребоваться дополнительная интерпретация. Журналы администрирования и отладки не понятны пользователям. Аналитические журналы (которые по умолчанию скрыты и отключены) хранят события, отслеживающие проблему, и в них часто записывается большой объем событий. Журналы отладки используются разработчиками при отладке приложений.
Exchange 2010 записывает события в каналы Crimson в области журналов приложений и служб. Эти каналы можно просмотреть, выполнив приведенные далее действия.
- Откройте окно просмотра событий.
- В дереве консоли выберите Журналы приложений и служб
> Microsoft > Exchange.
- В разделе Exchange выберите канал Crimson:
HighAvailability или MailboxDatabaseFailureItems.
Канал HighAvailability содержит события, относящиеся к запуску и остановке службы репликации Microsoft Exchange и разным компонентам, работающим в службе репликации Microsoft Exchange, таким как диспетчер Active Manager, API синхронной репликации сторонних производителей, сервер Tasks RPC Server, прослушиватель TCP и модуль записи службы теневого копирования томов (VSS). Канал HighAvailability также используется диспетчером Active Manager для записи в журнал событий, относящихся к событиям отслеживания роли Active Manager и работы базы данных, таких как операция подключения базы данных и усечение журнала, а также для записи событий, относящихся к базовому кластеру группы обеспечения доступности баз данных.
Канал MailboxDatabaseFailureItems используется для ведения журнала событий, связанных с любыми сбоями, влияющими на реплицированную базу данных почтовых ящиков.
Скрипт
CollectOverMetrics.ps1
В Exchange 2010 имеется скрипт с именем CollectOverMetrics.ps1, который можно найти в папке скриптов. Сценарий CollectOverMetrics.ps1 читает журналы событий членов группы обеспечения доступности баз данных, чтобы получить информацию об операциях над базой данных (подключениях, перемещениях и отработках отказов) за определенный период времени. Для каждой операции сценарий фиксирует следующую информацию.
- Идентификатор базы данных
- Время начала и окончания операции
- Серверы, к которым была подключена база данных в моменты начала
и окончания операции
- Причина для выполнения операции
- Завершилась ли операция успешно, включая сведения об ошибках в
случае сбоя операции
Сценарий записывает эти сведения в CSV-файлы (одна операция на каждой строке). Для каждой группы обеспечения доступности баз данных создается отдельный CSV-файл.
Данный сценарий поддерживает параметры, позволяющие настроить его поведение и выходные данные. Например, результаты можно ограничить определенным подмножеством при помощи параметров Database или ReportFilter. В сводный отчет в формате HTML будут включены только операции, которые соответствуют критериям этих фильтров. Доступные параметры перечислены в следующей таблице.
Параметры скрипта CollectOverMetrics.ps1
| Параметр | Описание |
|---|---|
|
DatabaseAvailabilityGroup |
Задает имя группы обеспечения доступности баз данных, из которой планируется собирать показатели. Если этот параметр не указан, то будет использоваться группа обеспечения доступности баз данных, членом которой является локальный сервер. Для сбора информации и создания отчетов по нескольким группам обеспечения доступности баз данных можно использовать подстановочные символы. |
|
Database |
Предоставляет список баз данных, для которых необходимо создать
отчет. Поддерживаются подстановочные знаки, например
|
|
StartTime |
Задает продолжительность периода, за который создается отчет. Сценарий собирает только сведения о событиях, зарегистрированных в течение этого периода. В результате сценарий может фиксировать неполные записи об операциях (например, только конец операции в начале периода или наоборот). Если ни StartTime, ни EndTime не указаны, то для сценария устанавливается период по умолчанию — последние 24 часа. Если указан только один параметр, то будет задан период, равный 24 часам, который начинается или заканчивается в указанное время. |
|
EndTime |
Задает продолжительность периода, за который создается отчет. Сценарий собирает только сведения о событиях, зарегистрированных в течение этого периода. В результате сценарий может фиксировать неполные записи об операциях (например, только конец операции в начале периода или наоборот). Если ни StartTime, ни EndTime не указаны, то для сценария устанавливается период по умолчанию — последние 24 часа. Если указан только один параметр, то будет задан период 24 часа, который начинается или заканчивается в указанное время. |
|
ReportPath |
Задает папку, используемую для хранения результатов обработки событий. Если этот параметр не указан, то будет использоваться папка скриптов. Если этот параметр указан, то сценарий использует список созданных им CSV-файлов в качестве исходных данных для сводного отчета в формате HTML. Этот отчет аналогичен отчету, который создается при помощи параметра -GenerateHtmlReport. Файлы могут создаваться для нескольких групп обеспечения доступности баз данных в разные моменты времени или даже в перекрывающиеся периоды; тогда сценарий объединяет все эти данные. |
|
GenerateHtmlReport |
Указывает, что сценарий собирает все записанные сведения, группирует данные по типу операции и создает файл в формате HTML, содержащий статистику для каждой группы. Отчет включает общее число операций в каждой группе, число операций, завершившихся сбоем, и статистику по продолжительности операций для каждой группы. Отчет также содержит разбивку по типам ошибок, которые привели к сбою операций. |
|
ShowHtmlReport |
Указывает, что созданный отчет в формате HTML следует сразу же отобразить в веб-браузере. |
|
SummariseCSVFiles |
Указывает, что сценарий считывает данные из существующих CSV-файлов, которые были ранее созданы сценарием. Затем эти данные используются для создания сводного отчета, аналогичного тому, что создается при помощи параметра GenerateHtmlReport. |
|
ActionType |
Указывает тип операций, сведения о которых должен собирать
сценарий. Допустимы следующие значения этого параметра:
|
|
ActionTrigger |
Указывает, сведения о каких административных операциях должен
собирать сценарий. Этот параметр может принимать значения
|
|
RawOutput |
Указывает, что сценарий передает результаты, которые были бы записаны в CSV-файлы, непосредственно в выходной поток, как в случае использования параметра Write-Output. Эти сведения впоследствии могут передаваться по конвейеру в другие команды. |
|
IncludedExtendedEvents |
Указывает, что сценарий собирает сведения о событиях, которые предоставляют диагностическую информацию по времени подключения баз данных. Этот этап может занимать много времени, если журнал событий приложений на серверах очень большой. |
|
MergeCSVFiles |
Указывает, что сценарий объединяет все CSV-файлы, содержащие данные по каждой операции, в один CSV-файл. |
|
ReportFilter |
Указывает, что к операциям необходимо применить фильтр с
использованием полей в том виде, в котором они представлены в
CSV-файлах. Этот параметр использует тот же формат, что и операция
|
Примеры использования скрипта 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*") }
|
|
Скрипт
CollectReplicationMetrics.ps1
CollectReplicationMetrics.ps1 — это еще один сценарий сбора показателей работоспособности, включенный в Exchange 2010. Этот сценарий представляет собой активную форму наблюдения, поскольку он собирает показатели в режиме реального времени в ходе выполнения. Сценарий CollectReplicationMetrics.ps1 собирает данные, полученные от счетчиков производительности, которые относятся к репликации баз данных. Этот сценарий собирает данные счетчиков с нескольких серверов почтовых ящиков, записывает данные каждого сервера в CSV-файл и создает отчеты по различным статистическим показателям для всех этих данных (например, по таким показателям, как период, в течение которого каждая копия находилась в состоянии сбоя или приостановки, средняя длина очереди копирования или преобразования или период, в течение которого для копий не выполнялись критерии отработки отказа).
Можно указать либо каждый сервер по отдельности, либо всю группу обеспечения доступности баз данных. Можно либо запустить сценарий, чтобы сначала собрать данные и затем создать отчет, либо запустить его только для сбора данных или только для создания отчета по уже собранным данным. Можно указать частоту и общую продолжительность сбора данных.
Данные, собранные с каждого сервера, записываются в файл с именем CounterData.<имя_сервера>.<отметка_времени>.csv. Сводный отчет записывается в файл с именем HaReplPerfReport.<имя_группы_обеспечения_доступности_баз_данных>.<отметка_времени>.csv или HaReplPerfReport.<отметка_времени>.csv, если сценарий не был запущен с параметром DagName.
Сценарий запускает задачи PowerShell для сбора данных с каждого сервера. Эти задачи выполняются в течение всего периода сбора данных. Если пользователь указывает много серверов, этот процесс может занять значительный объем памяти. Заключительный этап процесса — обработка данных для сводного отчета — может также занять много времени в случае большого объема данных. Можно выполнить этап сбора информации на одном компьютере, а затем скопировать данные на другой компьютер для обработки.
Сценарий CollectReplicationMetrics.ps1 поддерживает параметры, позволяющие настроить его поведение и выходные данные. Доступные параметры перечислены в следующей таблице.
Параметры скрипта CollectReplicationMetrics.ps1
| Параметр | Описание |
|---|---|
|
DagName |
Задает имя группы обеспечения доступности баз данных, из которой планируется собирать показатели. Если этот параметр не указан, будет использоваться группа обеспечения доступности баз данных, членом которой является локальный сервер. |
|
DatabaseNames |
Предоставляет список баз данных, для которых необходимо создать
отчет. Поддерживаются подстановочные знаки, например
|
|
ReportPath |
Задает папку, используемую для хранения результатов обработки событий. Если этот параметр не указан, то будет использоваться папка Scripts. |
|
Duration |
Задает время, которое должен работать процесс сбора. Обычными значениями являются 1–3 часа. Большую продолжительность следует указывать только при длительных интервалах между выборками или в виде серии коротких операций, выполняемых в рамках запланированных задач. |
|
Frequency |
Указывает частоту, с которой должны собираться показатели данных. Обычными значениями являются 30 секунд, 1 минута или 5 минут. При нормальных условиях более короткие интервалы не покажут значительных отличий между выборками. |
|
Servers |
Указывает идентификатор серверов, с которых собирается статистика. Можно указать любое значение, включая подстановочные символы или идентификаторы GUID. |
|
SummariseFiles |
Указывает список CSV-файлов для создания сводного отчета. Формат имени этих файлов: CounterData.<CounterData>*; они создаются сценарием CollectReplicationMetrics.ps1. |
|
Mode |
Указывает этапы обработки, которые выполняет сценарий. Можно использовать следующие значения:
|
|
MoveFilestoArchive |
Указывает, что сценарий должен переместить файлы в сжатую папку после обработки. |
|
LoadExchangeSnapin |
Указывает, что сценарий должен загружать команды из командной консоли Exchange. Этот параметр целесообразно использовать, когда нужно запускать сценарий вне командной консоли Exchange, например в рамках запланированной задачи. |
Пример использования 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 |
|
Сценарий
CheckDatabaseRedundancy.ps1
Как следует из названия, сценарий CheckDatabaseRedundancy.ps1 предназначен для контроля избыточности реплицированных баз данных почтовых ящиков. Для этого выполняется проверка наличия не менее двух настроенных и работоспособных текущих копий. Если существует только одна работоспособная копия реплицированной базы данных, то пользователю выдается оповещение. В этом случае при определении избыточности учитываются и активная, и пассивные копии.
При запуске этого сценария необходимо указать либо имя базы данных, либо имя члена группы обеспечения доступности баз данных. Чтобы указать базу данных, используйте параметр MailboxDatabaseName, а для указания члена группы обеспечения доступности баз данных — параметр MailboxServerName. В случае интерактивного запуска в консоли сценарий выполняет проверку избыточности только один раз и выводит данные о текущем состоянии CurrentState (красный или зеленый индикатор) на экран.
Аналогично другим сценариям и командлетам, CheckDatabaseRedundancy.ps1 может быть запущен в режиме наблюдения и создавать события, если добавить параметр MonitoringContext. В этом случае сценарий может вызываться решением для отслеживания, таким как Microsoft System Center Operations Manager (SCOM). В режиме наблюдения сценарий создает события красного и зеленого цвета в журнале событий приложений на локальном сервере. Событие красного цвета (код события 4113) создается, только если база данных находилась в «красном» состоянии в течение 20 минут и более (в общей сложности, не подряд) из часового периода работы сценария, а событие зеленого цвета (код события 4114) — когда база данных находилась в «зеленом» состоянии в течение 10 минут подряд. По умолчанию оповещение о событии красного цвета повторяется каждые 15 минут после своего появления.
Кроме того, данный сценарий имеет ряд других полезных параметров. Например, можно добавить параметр ShowDetailedErrors, чтобы получить более подробные сведения обо всех возникших ошибках, или параметр Verbose — для получение информации по устранению неполадок. Сценарий также включает параметр SendSummaryMailTos, который позволяет отправить сводный отчет по электронной почте на указанные адреса по завершении работы сценария. Так администраторы могут быстро просматривать часовые отчеты и обнаруживать проблемы избыточности. Чтобы использовать функцию отправки отчета по электронной почте, необходимо включать параметр SummaryMailFrom в каждом случае использования параметра SendSummaryMailTos.
Майкрософт рекомендует регулярно запускать этот сценарий в ходе обычных операций мониторинга. Чтобы избежать возникновения длительных периодов, когда избыточность базы данных находится под угрозой, запускайте этот сценарий каждые 60 минут. Сценарий включает параметр TerminateAfterDurationSecs. Если для него во время выполнения сценария заданы значения -1 или 0, то этот параметр позволяет запускать сценарий на бесконечный период времени. Если решение для отслеживания, такое как SCOM, не используется, можно создать запланированную задачу Windows для автоматизации и планирования выполнения сценария.
В планировщике заданий Windows Server 2008 SP2 есть известные проблемы, которые могут привести к сбою планировщика в случае планирования продолжительной задачи. Эти проблемы отсутствуют в Windows Server 2008 R2; поэтому по возможности запускайте сценарий из Windows Server 2008 R2. Если запустить сценарий из Windows Server 2008 R2 не удается и приходится запускать его из Windows Server 2008 SP2, рекомендуется внести два изменения. Во-первых, вместо запуска сценария со встроенным промежуточным подавлением 60 минут, запускайте сценарий каждые 5 минут. Для этого укажите следующие параметры:
| Скопировать код |
|
|---|---|
CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors |
|
Во-вторых, если возможно, используйте SCOM для задания поведения промежуточного подавления (например, если в течение 20 минут регистрируются 3 события красного цвета, создается оповещение, а если регистрируется событие зеленого цвета, то цвет CurrentState меняется на зеленый).
Чтобы запланировать запуск сценария в Windows Server 2008 R2, настройте запланированную задачу в планировщике заданий Windows при помощи следующей команды:
| Скопировать код |
|
|---|---|
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="http://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>
|
|