Установление базовых показателей для перестроения индекса контента Exchange. Часть 1
Дата публикации исходной статьи: вторник, 26 июня 2012 г.
Одним из первых действий большинства администраторов Exchange при устранении возможных проблем с индексированием контента Exchange обычно является перестроение файлов индекса контента соответствующей базы данных почтовых ящиков (вручную или скриптом ResetSearchIndex.ps1 из каталога \Exchange Server\Scripts). За годы своей работы я также познакомился и работал с немалым количеством администраторов Exchange, которые предпочитали заранее перестраивать индексы поиска по календарному плану в течение года или на определенных этапах выполнения проекта (один из примеров — проект миграции).
Вне зависимости от причины сброса индексов, большинство администраторов, если их спросить, не смогут дать реалистичные оценки длительности всего процесса от начала до завершения. Нежелательные последствия того, что нет точной оценки, будут разными в разных организациях. В некоторых отделах ИТ будут не слишком рады, если серверные индексы будут недоступны пользователям в течение рабочего дня, поскольку из-за этого снижается продуктивность пользователей и увеличивается количество обращений в службу поддержки. С эксплуатационной точки зрения отсутствие информации о предполагаемом времени перестроения может препятствовать получению администраторами Exchange оповещений о потенциальных проблемах в течение самого периода перестроения. Вне зависимости от причин, стоит иметь ясное представление о предполагаемой длительности процесса.
Надо сказать, что сегодня имеется очень мало сведений о том, сколько времени занимает процесс перестроения индекса контента Exchange (точнее, сколько он должен занимать). Вероятно, это связано с тем, что фактическое время перестроения всегда меняется. Есть много факторов, влияющих на время перестроения. Самые явные из них:
- Число почтовых ящиков конечных пользователей, размещенных в базе данных почтовых ящиков Exchange.
- Размеры почтовых ящиков, содержащихся в базе данных почтовых ящиков Exchange.
- Число элементов в почтовых ящиках, размещенных в базе данных почтовых ящиков Exchange.
- Число элементов в базах данных почтовых ящиков Exchange (если выполняется параллельное перестроение).
- Размеры элементов, находящихся в базе данных почтовых ящиков Exchange.
- Число и размеры почтовых вложений, находящихся в базе данных Exchange.
- Типы и число включенных фильтров IFilter на сервере почтовых ящиков Exchange (позволяют индексировать различные форматы файлов).
- Общее использование системных ресурсов сервером почтовых ящиков, который выполняет обход (регулирование ресурсов).
- И множество других…
В Майкрософт (в нашей корпоративной реализации и в различных предложениях Office 365) мы используем платформу Search Rebuild Framework, разработанную моим коллегой Анатолием Гирко (Anatoly Girko) и мной. Изначально эта платформа предназначалась для обеспечения нашего внутреннего технического персонала полным набором проверок и индикаторов хода выполнения, которые бы применялись во время перестроения индексов контента. Они используются на различных этапах процесса перестроения, чтобы обеспечить успешное его выполнение.
По мере развития платформы мы решили добавить другие функции, которые позволили бы отслеживать и сохранять исторические метрики пропускной способности для всех операций перестроения. Когда количество данных возросло, и стали проявляться закономерности, мы заметили, что можем делать существенно более обоснованные и точные оценки длительности операций перестроения. В свою очередь, это позволило нам как эксплуатационному отделу принимать более качественные решения о планируемом времени перестроений, направленные на минимизацию перерывов в работе конечных пользователей наших клиентов. Со времени своего появления платформа использовалась для наблюдения за операциями перестроения нескольких тысяч индексов контента в различных средах, которые мы обслуживали.
В этой серии статей мы опишем нашу платформу Rebuild Framework, чтобы в случае необходимости заинтересованные стороны могли применить похожую методику к своим средам. Мы подробно рассмотрим каждый из этапов платформы, включая различные наборы инструментов, созданные нами для упрощения процесса. В завершение будет дан ряд графиков и таблиц, содержащих собранную на данный момент статистику и выводы по перестроениям индексов контента. Мы надеемся, что для тех клиентов, которые ранее не отслеживали статистику в этой области, статьи станут хорошим ориентиром. Они позволят делать более обоснованные оценки времени перестроения индексов контента Exchange в ваших собственных средах. Важно отметить, что, так как все среды Exchange уникальны, ваши метрики перестроения могут очень сильно отличаться от тех значений, которые мы получили и приводим здесь.
Прежде чем погрузиться в технические глубины, стоит заметить, что эта серия статей не планировалась как руководство по устранению неполадок. Мы предполагаем, что ваша собственная практика выявления неисправностей привела вас к решению о проведении перестроений либо в ответ на возникшую проблему, либо в качестве превентивной меры. Все примеры, приведенные здесь, будут ориентированы на Exchange 2007. Я решил сосредоточиться на версии 2007 из-за того, что вероятность перестроения индексов в версии 2007 существенно выше, чем в 2010 (в отличие от 2007, версия 2010 может повторно заполнять индексы контента из работоспособных избыточных источников, что в архитектуре с несколькими копиями делает необходимость выполнения полного перестроения индексов контента значительно менее частой). В ближайшие недели Анатолий и я опубликуем дополнительную статью о скрипте Content Index Rebuild Analyzer для Exchange 2010, когда накопятся необходимые примеры его использования.
Скрипт Index Rebuild Analyzer
В Майкрософт основным набором инструментов, который мы используем во время перестроения индексов контента, является скрипт IndexRebuildAnalyzer. Этот скрипт был написан Анатолием и мной специально для установления базовых показателей перестроения индексов контента. Как было сказано ранее, есть две версии этого скрипта: для Exchange 2007 и для Exchange 2010. Чтобы правильно вычислять статистику, всегда используйте тот скрипт, который подходит к версии базы данных почтовых ящиков Exchange, чей индекс перестраивается. Скрипт IndexRebuildAnalyzer создает два типа метрик в зависимости от режима работы, включенного оператором. Между собой мы их называем метрики перед перестроением и метрики после перестроения (все свойства задокументированы в разделе описания скрипта ниже).
Хотя этот скрипт и используется в основном для отслеживания операций перестроения индекса контента, администраторы Exchange несомненно могут применять его в предварительном режиме , чтобы получить статистику на момент времени для решения различных задач, связанных с почтовыми ящиками (например, "число почтовых ящиков", "число элементов в базе данных", "средний размер сообщения" для всей организации и т. д.). Это может, например, дать дополнительные данные о пользовательских тенденциях, если инструмент будет использоваться регулярно и сообразно потребностям бизнеса.
Параметры скрипта E2K7_IndexRebuildAnalyzer.ps1 и примеры использования можно получить, передав параметр -Help в сеансе PowerShell перед выполнением скрипта.
В следующей таблице описаны все параметры:
| Параметр | Обязательный? | Описание |
| -CMS </кластер1,кластер2> | Обязательный | Когда используется параметр -CMS, будет вычисляться статистика для всех баз данных на сервере почтовых ящиков Exchange или кластерном сервере почтовых ящиков Exchange. Статистику по базам данных на нескольких отдельных серверах почтовых ящиков или кластерных серверах почтовых ящиков можно получить, указав имена серверов, разделенные запятой. |
| -Database <имя_базы_данных,имя_базы_данных> | Обязательный | Когда используется параметр -Database, можно вычислить статистику по определенной базе данных почтовых ящиков. Подразумевается, что при использовании этого параметра имя базы данных будет передаваться в следующем формате:
"Имя_сервера_почтовых_ящиков\Имя_группы_хранения\Имя_базы_данных" Статистику по нескольким базам данных можно получить, указав имена баз данных, разделенные запятой. Базы данных, которые не содержат активные почтовые ящики пользователей, не будут обрабатываться. |
| -All | Необязательный | При использовании переключателя -All будет вычислена вся статистика для всех баз данных почтовых ящиков Exchange в организации Exchange. |
| -CSVFile | Необязательный | При использовании параметра -CSVFile все метрики будут выведены в CSV-файл. |
| -PostRebuild | Необязательный | Переключатель -PostRebuild используется для указания скрипту режима выполнения. В частности, когда вызывается -PostRebuild, скрипт будет анализировать журналы событий приложений и пытаться вычислить метрики производительности для операций перестроения индекса. |
| -Help | Необязательный | Отображает справку по скрипту. |
Заголовки метрик для баз данных
Режим перед перестроением
Как было сказано выше, "режим работы" скрипта определяется присутствием или отсутствием переключателя -PostRebuild. Чтобы получить метрики перед перестроением, переключатель -PostRebuild использовать не следует. Когда скрипт запущен в режиме перед перестроением, будут создаваться следующие заголовки с соответствующими метриками:
| Заголовок | Описание |
| Server (Сервер) | Идентификатор сервера почтовых ящиков, связанного с обработанной базой данных. |
| Database (База данных) | Отображаемое имя обработанной базы данных почтовых ящиков Exchange. |
| EDB Size (GB) (Размер EDB-файла в ГБ) | Размер соответствующего файла базы данных на диске в гигабайтах. |
| EDB Size (MB) (Размер EDB-файла в МБ) | Размер соответствующего файла базы данных на диске в мегабайтах. |
| Mailbox Count (Число почтовых ящиков) | Число активных почтовых ящиков Exchange в обработанной базе данных. Отключенные почтовые ящики не обрабатываются. |
| Database: Total Items (Общее число элементов в БД) | Полное число почтовых элементов, присутствующих в базе данных почтовых ящиков Exchange. |
| Database: Total Item Size (MB) (Общий размер элементов в БД в МБ) | Общий размер всех почтовых элементов, хранимых в обработанной базе данных почтовых ящиков, в мегабайтах. |
| Database: Average Message Size (MB) (Средний размер сообщения в БД в МБ) | Средний размер сообщения для всех почтовых элементов, находящихся в обработанной базе данных. |
| Per User: Average Mailbox Size (MB) (Средний размер почтового ящика на пользователя в МБ) | Средний размер активных почтовых ящиков, находящихся в обработанной базе данных. |
| Per User: Average Item Count (Среднее число элементов на пользователя) | Среднее число почтовых элементов для активных почтовых ящиков, находящихся в обработанной базе данных. |
Режим после перестроения (с использованием параметра -PostRebuild)
Когда используется переключатель -PostRebuild, скрипт IndexRebuildAnalyzer будет пытаться вычислить метрики пропускной способности для операций перестроения индекса контента. Он делает это путем анализа журнала событий приложений , чтобы получить время начала (отмечено кодом события 109) и завершения перестроения (отмечено кодом события 110) для каждой базы данных почтовых ящиков на сервере почтовых ящиков. Чтобы вычислить метрики после перестроения, в компоненте Просмотр событий должна присутствовать полная пара кодов событий для каждой базы данных почтовых ящиков, чьи индексы контента были сброшены. Если пара кодов событий недоступна, скрипт не сможет вычислить статистику. В этих случаях будет возвращена строка NoEventsFound (События не найдены). Наиболее частая причина возврата такой строки:
- Операция перестроения индекса контента для конкретной базы данных или набора баз данных не была выполнена.
- Журнал событий приложений сокращен или очищен (рекомендуется присвоить наибольшее возможное значение параметру максимального размера журнала).
- База данных почтовых ящиков, сообщающая NoEventsFound, не подвергалась недавно сбросу индексов контента (так как в журнале событий отсутствует пара кодов событий). Используя параметр -CSVFile и Excel, такие строки можно легко отфильтровать в результатах. Я буду рассматривать примеры фильтрации на этапе 5 платформы.
Все заголовки и метрики "перед перестроением" вычисляются также и в случае применения переключателя -PostRebuild во время выполнения скрипта. При использовании переключателя -PostRebuild добавляются следующие заголовки и метрики:
Заголовок |
Описание |
Content Index Rebuild Start Time (Время запуска перестроения индекса контента) |
Время запуска, когда служба индексатора поиска начинает полный обход базы данных почтовых ящиков. |
Content Index Rebuild End Time (Время завершения перестроения индекса контента) |
Время завершения, когда служба индексатора поиска заканчивает полный обход базы данных почтовых ящиков. |
Total Rebuild Time: H:Min:Sec (Полное время перестроения, Ч:Мин:Сек) |
Полное время в формате Часы:Минуты:Секунды , которое потребовалось службе индексатора поиска на выполнение полного обхода базы данных почтовых ящиков. |
Total Rebuild Time: Min Total (Полное время перестроения, мин.) |
Полное время перестроения в минутах , которое потребовалось службе индексатора поиска на выполнение полного обхода . |
Total Rebuild Time: Sec Total (Полное время перестроения, сек.) |
Полное время перестроения в секундах , которое потребовалось службе индексатора поиска на выполнение полного обхода. |
Rebuild: Per Mailbox Average: Sec (Среднее время перестроения на почтовый ящик, сек.) |
Среднее время в секундах на выполнение полного обхода одного почтового ящика. |
Rebuild: MB per/sec (Скорость перестроения, МБ/с) |
Средняя пропускная способность полного обхода в мегабайтах в секунду . |
Rebuild: Items per/sec (Скорость перестроения, элементов в сек.) |
Пропускная способность индексатора поиска во время полного обхода в почтовых элементах в секунду . |
Заключение
Скрипт Index Rebuild Analyzer для Exchange 2007 можно загрузить на этой странице.
Во второй части я расскажу о платформе Search Rebuild Framework, а в третьей части — представлю результаты, собранные на текущий момент в корпорации Майкрософт.
Эрик Норберг (Eric Norberg)
Инженер по эксплуатации,
специализирующийся на Office 365
Это локализованная публикация в блоге. Оригинал — Establishing Exchange Content Index Rebuild Baselines – Part 1.