Установление базовых показателей для перестроения индекса контента Exchange. Часть 2

Дата публикации исходной статьи: среда, 27 июня 2012 г.

В первой части этой серии статей я описывал скрипт E2K7_IndexRebuildAnalyzer.ps1. В данной статье я расскажу о платформе Search Rebuild Framework, разработанной моим коллегой Анатолием Гирко (Anatoly Girko) и мной. Изначально эта платформа предназначалась для обеспечения нашего внутреннего технического персонала полным набором проверок и индикаторов хода выполнения, которые бы применялись во время перестроения индексов контента.

Этап 1: сбор статистики перед перестроением

В нашей среде, когда принимается решение о перестроении файлов индексов контента базы данных почтовых ящиков Exchange, оператор вначале вычисляет статистику перед перестроением для соответствующего хранилища. Эта статистика всегда записывается в CSV-файл в целях документирования, а затем добавляется в наш набор исторических данных. Но, как было сказано ранее, использование параметра -CSVFile необязательно. В тех случаях, когда параметр -CSVFile не передается, выходные данные записываются окно консоли оболочки. Для лучшей читаемости данных необходимо настроить размер буфера экрана по ширине и размер окна по ширине консоли, чтобы поместились все выводимые заголовки и метрики. Это упростит чтение данных в окне консоли. А далее я обычно передаю выходные данные в команду Format-Table (ft) с параметром -AutoSize (-a) .

Примеры

Консольный пример :

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 | ft -a

Выходные данные :

Пример с CSV-файлом:

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -CSVFile c:\ericnor\NA-1ERICNOR-1_PreRebuild.csv

Выходные данные :

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

Этап 2: сброс индекса контента для соответствующих баз данных почтовых ящиков

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

В последующих примерах я буду сбрасывать файлы индекса контента для двух баз данных почтовых ящиков в своей среде. Эти два хранилища имеют самые большие значения числа почтовых ящиков, размера EDB-файлов и общего числа элементов в БД на кластерном сервере почтовых ящиков NA1-ERICNOR-1:

Сброс файлов индекса контента:

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

После удаления из файловой системы существующих файлов индекса контента и последующего перезапуска службы индексатора поиска Microsoft Exchange поток MonitorAndUpdateMDBList должен определить текущее состояние индексов контента для всех баз данных почтовых ящиков на сервере почтовых ящиков, для которых включено индексирование контента. После того как поток MonitorAndUpdateMDBList определяет состояние работоспособности индекса контента для каждой базы данных почтовых ящиков, он размещает значения состояния их работоспособности в памяти. Если значение состояния работоспособности индекса контента равно New (Новый), то служба индексатора поиска Майкрософт определила, что для перевода файлов индекса контента в работоспособное состояние требуется полный обход ("работоспособным" называется такое состояние, когда индекс поддерживается в актуальном состоянии с помощью уведомлений, связанных с обработкой хранения данных). В этот момент служба индексатора поиска Exchange инициирует полный обход соответствующих баз данных почтовых ящиков.

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

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

Пример

Как показано в предыдущем примере, файлы индекса контента для NA1-ERICNOR-1-DB1 и NA1-ERICNOR-1-DB18 были сброшены скриптом ResetSearchIndex. Чтобы проверить запуск службой индексатора поиска Microsoft Exchange операции полного обхода, необходимо найти код события 109 для каждой из баз данных почтовых ящиков на сервере почтовых ящиков. В данном случае нужные коды имеются:

Тип события: информация
Источник события: индексатор поиска MSExchange
Категория события: общая
Код события: 109
Дата: 10.5.2012
Время: 14:22:19
Компьютер: NA1-ERICNOR-1-A
Описание: индексатор поиска Exchange создал новый индекс поиска и выполнит полный обход базы данных почтовых ящиков NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).

Тип события: информация
Источник события: индексатор поиска MSExchange
Категория события: общая
Код события: 109
Дата: 10.5.2012
Время: 14:22:20
Компьютер: NA1-ERICNOR-1-A
Описание: индексатор поиска Exchange создал новый индекс поиска и выполнит полный обход базы данных почтовых ящиков NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).

Примечание . Вместо проверки журнала событий вручную удобно пользоваться командлетом Get-EventLog и записывать события запуска в CSV-файл. Пример:

Get-EventLog "Приложение" | Where-Object {$_.EventID -eq 109} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_StartEvents.csv

Этап 4: проверка выполнения и завершения индексатора поиска

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

• Индексатор поиска MSExchange — количество сканируемых баз данных.
• Индексатор поиска MSExchange — количество индексированных баз данных, обновляемых с помощью уведомлений.
• Индексы поиска MSExchange\<обходимый экземпляр БД> — состояние режима полного сканирования.
• Индексы поиска MSExchange\<обходимый экземпляр БД> — скорость индексации документов.
• Индексы поиска MSExchange\<обходимый экземпляр БД> — осталось просканировать почтовых ящиков.
• Индексы поиска MSExchange\<обходимый экземпляр БД> — количество недавно перемещенных сканируемых почтовых ящиков.
• Индексы поиска MSExchange\<обходимый экземпляр БД> — количество невыполненных пакетов.
• Индексы поиска MSExchange\<обходимый экземпляр БД> — значение задержки регулирования количества запросов.

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

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

После завершения полного обхода для отдельных баз данных почтовых ящиков можно заметить определенные изменения в различных счетчиках объектов в системном мониторе.

На уровне индексатора поиска MSExchange:

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

На уровне индексов баз данных почтовых ящиков:

• Значение Состояние режима полного сканирования конкретной базы данных уменьшается до 0 (что отражает новое значение состояния Работоспособность индекса контента , как определено в потоке монитора MonitorAndUpdateMDBList).
• Значение Осталось просканировать почтовых ящиков должно иметь значение 0.
• Не относясь непосредственно к операции перестроения с полным обходом , значение счетчика Количество недавно перемещенных сканируемых почтовых ящиков также должно быть равно 0 для каждого индекса. Когда почтовые ящики Exchange успешно перемещаются между базами данных почтовых ящиков Exchange (предполагая, что для конечной базы данных включен обход контента), уведомления поиска на конечной базе данных будут временно приостановлены. Служба индексатора поиска Exchange делает это для выполнения однократных обходов недавно перемещенных почтовых ящиков, чтобы главный индекс имел самые последние данные. Как только однократный обход завершен, уведомления, связанные с обработкой хранения данных, возобновляются. Обратить внимание здесь следует на то, что хотя полный обход технически выполнен, есть вероятность, что происходит однократный обход, если одновременно с перестроением индекса контента перемещались почтовые ящики. Если описываемый счетчик равен 0, все действия обхода, происходившие в базе данных почтовых ящиков, завершены. И это тоже следует проверить.

На сервере Exchange Server, где все индексы контента полностью обновлены, можно ожидать следующие значения счетчиков:

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

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

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

Тип события: информация
Источник события: индексатор поиска MSExchange
Категория события: общая
Код события: 110
Дата: 10.5.2012
Время: 17:39:47
Компьютер: NA1-ERICNOR-1-A
Описание: индексатор поиска Exchange завершил полный обход содержимого (индексацию) базы данных почтовых ящиков NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).

Тип события: информация
Источник события: индексатор поиска MSExchange
Категория события: общая
Код события: 110
Дата: 10.5.2012
Время: 17:11:47
Компьютер: NA1-ERICNOR-1-A
Описание: индексатор поиска Exchange завершил полный обход содержимого (индексацию) базы данных почтовых ящиков NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).

Примечание . Вместо проверки журнала событий вручную удобно пользоваться командлетом Get-EventLog и записывать события завершения в CSV-файл. Пример:

Get-EventLog "Приложение" | Where-Object {$_.EventID -eq 110} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_CompletionEvents.csv

Этап 5: сбор метрик после перестроения

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

Чтобы собрать эти метрики, используется скрипт E2K7_IndexRebuildAnalyzer с переключателем -PostRebuild.

Как уже было сказано ранее, при указании -PostRebuild происходит анализ журналов событий приложений на присутствие как кода события 109, так и кода события 110. В случае непрерывной репликации кластера журнал событий приложений проверяется для каждого узла в кластере с непрерывной репликацией. Если скрипт может найти указанные коды событий, он вычисляет общее время (в различных единицах измерения времени), которое потребовалось на выполнение полного обхода для каждой из баз данных почтовых ящиков. Затем скрипт возвращает оператору характеристики пропускной способности каждой уникальной операции перестроения.

Еще раз повторим, что будут проверены все базы данных почтовых ящиков на сервере почтовых ящиков вне зависимости от того, производилось ли перестроение индексов поиска на всех базах данных почтовых ящиков. Кроме того, если запустить скрипт без параметра -CSVFile, результаты будут выведены в окно консоли. Когда вычисляется статистика после перестроения, я бы настоятельно рекомендовал использовать параметр -CSVFile, так как это существенно упрощает составление отчетов, сортировку, фильтрацию и обобщение с помощью Excel.

Пример

.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -PostRebuild -CSVFile c:\ericnor\NA1-ERICNOR-1_PostRebuild.csv

После завершения работы скрипта E2K7_IndexRebuildAnalyzer можно изучить CSV-файл. Просмотр CSV-файла показывает, что были обработаны все базы данных почтовых ящиков Exchange на сервере почтовых ящиков. Строка NoEventsFound возвращена для многих баз данных почтовых ящиков Exchange, так как не была найдена пара кодов событий индексатора поиска. В примере имеется 16 баз данных почтовых ящиков, для которых выдана строка NoEventsFound, и две базы данных, имеющих действительные метрики после перестроения:

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

В результате применения фильтра к набору результатов примера отображаются только базы данных NA1-ERICNOR-1-DB1 и NA1-ERICNOR-1-DB18 (т. е. те базы данных почтовых ящиков, для которых сбрасывался индекс контента). Также понятно, что метрики после перестроения были успешно установлены, так как имеются действительные значения для различных заголовков, вычисляемых после перестроения:

Применение фильтра:

Этап 6: проверка с использованием Test-ExchangeSearch

На этапе 6 в платформе Rebuild Framework проверяется, возвращает ли действительные результаты поиска каждый из почтовых ящиков, размещенных в базах данных почтовых ящиков, для которых сбрасывались индексы контента. Эта цель может быть достигнута использованием базовой функциональности, содержащейся в командлете Test-ExchangeSearch. Конечная проверка будет выполнена только тогда, когда все почтовые ящики возвратят командлету значение True.

Пример:

Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG1\ NA1-ERICNOR-1-DB1 | Test-ExchangeSearch | ft -a

Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG18\ NA1-ERICNOR-1-DB18 | Test-ExchangeSearch | ft -a

Этот процесс занимает значительное время в зависимости от числа почтовых ящиков, содержащихся в базе данных. Следует отметить, что во время пакетного выполнения командлета Test-ExchangeSearch свойства ResultFound и SearchTime будут видны в окне консоли только после обработки всех почтовых ящиков (вне зависимости от результата, True или False). В некоторых случаях может иметь смысл сохранение всех результатов в CSV-файл для документирования.

Все почтовые ящики, возвратившие False в тесте с использованием Test-ExchangeSearch, рассматриваются как имеющие проблему однократного обхода и исправляются соответствующим образом.

Этап 7: анализ метрик после перестроения

Для удобства чтения данных я представлю различные метрики в виде таблицы, а не в виде столбцов Excel, как они были исходно. Как было сказано ранее, на кластерном сервере почтовых ящиков NA1-ERICNOR-1 было две базы данных почтовых ящиков Exchange, для которых перестраивались индексы контента: NA1-ERICNOR-1-DB1 и NA1-ERICNOR-1-DB18.

Метрики почтовых ящиков после перестроения:

Метрики перестроения базы данных почтовых ящиков:

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

Заключение

Во второй статье серии я описал этапы работы платформы Search Rebuild Framework. В моей следующей и последней статье будут описаны средние значения, которые были получены в наших развертываниях в Майкрософт.

Эрик Норберг (Eric Norberg)
Инженер по эксплуатации,
специализирующийся на Office 365

Это локализованная запись блога. Исходная статья находится по адресу Establishing Exchange Content Index Rebuild Baselines – Part 2