Establecer las líneas de base para la reorganización de índices de contenido de Exchange – Parte 1

Artículo original publicado el martes 26 de junio de 2012

Uno de los primeros pasos que toma la mayoría de los administradores de Exchange a la hora de solucionar problemas con la indización de contenido de Exchange es reorganizar los archivos de índice de contenido de la base de datos de buzones de correo en cuestión, de forma manual o con el script ResetSearchIndex.ps1 que se encuentra en el directorio \Exchange Server\Scripts). También colaboré durante mucho tiempo con administradores de Exchange que prefieren reorganizar los índices de búsqueda de forma proactiva en varios puntos durante el año natural o a medida que se vayan encontrando hitos a lo largo de un proyecto, como, por ejemplo, una migración.

Independientemente de las razones para reorganizar los índices, la mayoría de administradores, en caso de que se les pregunte, no son capaces de proporcionar estimaciones reales sobre cuánto tiempo tardará el proceso desde que empieza hasta que acaba. Las consecuencias no deseadas que puede acarrear el no haber calculado previamente esos tiempos variarán según la organización de que se trate. Algunos departamentos de TI aconsejarán que los usuarios puedan disponer de índices del lado servidor durante el horario de trabajo argumentando que se dan pérdidas en la productividad del usuario final y pequeños aumentos de problemas escalados que llegan al Help Desk. Des de un punto de vista operativo, el hecho de no saber de antemano los tiempos de reorganización también puede impedir que se avise a los administradores de Exchange de que hay problemas potenciales con el proceso de reorganización propiamente dicho. Sean cuales sean sus razones, saber con certitud el tiempo que va a tardar el proceso es de mucha utilidad.

Cierto es que hay muy poca información sobre el tiempo que se tarda actualmente –o, mejor aún, sobre el tiempo que se debería tardar– en reorganizar un índice de contenido de Exchange. Aparentemente esto se debe a que los tiempos de reorganización reales son siempre variables. Existen muchos factores que influyen en la velocidad de la reorganización y en el tiempo que tardan en finalizar esos procesos. Estos son los más importantes:

• Variabilidad en el número total de buzones de correo del usuario final conectados a una base de datos de Exchange
• Variabilidad en el tamaño de los buzones de correo de una base de datos de Exchange
• Variabilidad en los recuentos de elementos entre distintos buzones de correo usuarios de una base de datos de Exchange
• Variabilidad en los recuentos de elementos entre distintas bases de datos de buzones de correo de Exchange (durante reorganizaciones simultáneas)
• Variabilidad en el tamaño de los elementos de una base de datos de Exchange
• Variabilidad en el número y el tamaño de los datos adjuntos de correo electrónico de una base de datos de Exchange
• Los tipos y la cantidad de IFilters en un servidor de buzones de correo de Exchange (cuenta con la indización de varios formatos de archivo)
• El uso global de los recursos del sistema que hace un servidor de buzones de correo al realizar un rastreo (como la limitación)
• Y muchos otros…

En Microsoft (tanto en nuestra implementación corporativa como en varias creaciones de Office 365), usamos un marco de reorganización de búsquedas que desarrollamos entre mi colega Anatoly Girko y yo. Este marco se diseñó originalmente para proporcionar a nuestro personal de operaciones internas un conjunto de pasos de validación exhaustivo y unos indicadores de progreso de los que pudieran sacar provecho al realizar reorganizaciones de índices de contenido. Estas técnicas se usan en distintos hitos clave durante todo el proceso de reorganización para garantizar que se complete correctamente.

A medida que el marco fue evolucionando, decidimos agregar funciones adicionales que nos permitirían seguir y almacenar métricas de rendimiento del historial para cualquier tarea de reorganización. A medida que esas colecciones de datos fueron creciendo, y a medida que iban saliendo a la luz los datos de las tendencias subsiguientes, vimos que podíamos hacer estimaciones bastante más exactas y más fundamentadas sobre el tiempo que podría tardar una tarea de reorganización. Esto, a su vez, nos permitió, como equipo de operaciones, tomar mejores decisiones sobre cuándo debíamos programar las reorganizaciones para afectar lo menos posible la base de nuestro cliente final. Desde el principio, este marco se usó para supervisar las tareas de reorganización de miles de índices de contenido en varios de los entornos compatibles con Microsoft.

En una serie de artículos, hablaremos sobre nuestro "marco de reorganización” para que los usuarios interesados puedan aplicar una metodología similar a sus entornos en caso de necesitarlo. Cada etapa del marco se explicará al detalle, con debates sobre los distintos conjuntos de herramientas que pueden facilitar la tarea de la reorganización. Al final de esta serie se incluyen unos cuantos gráficos y tablas que muestran con claridad las estadísticas de reorganización de índices de contenido que observamos hasta la fecha. Para los clientes que no hayan seguido estadísticas en esta área anteriormente, esperamos que les sea útil y que la tomen como punto de referencia. En teoría, con esta documentación debería poder realizar estimaciones más fundamentadas sobre los tiempos de reorganización de índices de contenido de Exchange en sus entornos. Dicho esto, tenga en cuenta que, como todos los entornos de Exchange son exclusivos, las métricas de reorganización pueden diferir enormemente de las tasas observadas y presentadas aquí.

Antes de entrar en materia, cabe decir que esta serie no pretende ser una guía de solución de problemas. Se supone que después de tratar de solucionar algún problema, decidió realizar una reorganización, ya sea para solucionar un problema o como medida proactiva. Todos los ejemplos que se presentan en esta serie se centran en Exchange 2007. Decidí basarme en la versión de 2007 en esta entrada porque las probabilidades de realizar una reorganización de índices en esta versión son bastante más altas que en la versión de 2010; en el sentido que esta última tiene la habilidad de reinicializar índices de contenido desde recursos redundantes en buen estado y, por lo tanto, la necesidad de realizar reorganizaciones completas de índices es mucho menos frecuente en arquitecturas de copia múltiple. En las próximas semanas Anatoly y yo publicaremos una entrada suplementaria que proporcionará la referencia del script de la versión Exchange 2010 del script Analizador de reorganizaciones de índices de contenido mientras vamos recopilando los ejemplos correspondientes para su uso.

Script Analizador de reorganización de índices

Dentro de Microsoft , el primer conjunto de herramientas que usamos para reorganizar índices de contenido es el script IndexRebuildAnalyzer. Lo creamos entre Anatoly y yo con el objetivo específico de establecer unas líneas de base para la reorganización de índices de contenido. Como ya se mencionó antes, existen dos versiones de este script: una versión para Exchange 2007 y otra para Exchange 2010. Para calcular sus estadísticas correctamente use siempre el script que corresponde a la versión de la base de datos del buzón de Exchange cuyo índice va a reorganizarse. El script IndexRebuildAnalyzer genera dos tipos de métricas distintos según el modo de la tarea que pasó el operador. Dentro de la organización, nos referimos a estos dos modos como “métrica de pre-reorganización” y “métrica de post-reorganización”. (Todas las propiedades se exponen en la sección siguiente Referencia de los scripts).

Aunque este script está pensado principalmente para reorganizaciones de índices de contenido, los administradores de Exchange podrían usar el script en “modo previo” para obtener las estadísticas a un momento dado para varios objetivos céntricos de buzones de correo, como “Número de buzones de correo”, “Número de elementos de una base de datos”, “Tamaño medio de los mensajes” de toda la organización, etc. Esto puede, por ejemplo, ofrecerle funciones y puntos de vista adicionales sobre las tendencias de un usuario, en caso de que la herramienta deba usarse a menudo, dependiendo de las necesidades y los requisitos de su empresa.

Los parámetros del script E2K7_IndexRebuildAnalyzer.ps1, así como los ejemplos de uso, pueden obtenerse pasando el parámetro -Help en la sesión de PowerShell antes de ejecutar el script.

En la tabla siguiente se explica resumidamente cada parámetro:

Encabezados de las métricas de la base de datos

Pre-reorganización

Como ya se comentó, el "modo de la tarea" del script viene determinado por la presencia o ausencia del modificador -PostRebuild. Para obterner la métrica pre-reorganización no se usa el modificador -PostRebuild. Cuando se crea una instancia al script en modo previo, aparecen los siguientes encabezados con las métricas correspondientes:

Post-reorganización (con el parámetro -PostRebuild)

Cuando se usa el modificador -PostRebuild, IndexRebuildAnalyzer trata de calcular las métricas de rendimiento de las tareas de reorganización de índices de contenido. Para ello, analiza el Registro de eventos de aplicaciones para obtener la hora de inicio (indicada por el ID de evento 109) y la de finalización de la reorganización (indicada por el ID de evento 110) de cada base de datos de buzones de correo en el servidor de buzones de correo. Para calcular la métrica post-reorganización correctamente, los dos ID de evento deben aparecer en el Visor de eventos para cada base de datos de buzones de correo cuyo índice de contenido se restableció. Si los dos ID de evento no están disponibles, el script no podrá calcular las estadísticas. En esos casos, se devuelve la cadena “NoEventsFound”. Los motivos más comunes por los que se devuelve esta cadena son los siguientes:

• La tarea de reorganización de índices de contenido de un conjunto de bases de datos no se completó.
• El Registro de eventos de aplicacionesse encapsuló o se desactivó; en cuyo caso el procedimiento recomendado es establecer el Tamaño máximo del registro al valor más alto posible.
• Últimamente no se restablecieron los índices de contenido de las bases de datos de buzones de correo que informan de que "NoEventsFound”; de aquí la ausencia de los dos ID de evento en el Registro de eventos. Si se usa la opción -CSVFile, con Excel se pueden filtrar estas cadenas fácilmente del conjunto de resultados. En el paso 5 del marco trataré el tema del filtrado y daré ejemplos al respecto.

Todos los encabezados y métricas de "pre-reorganización" también se calculan cuando se pasa el modificador -PostRebuild para ejecutar el script. Si se usa el modificador -PostRebuild se incluirán los siguientes encabezados y métricas:

Conclusión

Puede descargar el script Analizador de reorganizaciones de índices de Exchange 2007 aquí.

La parte 2 de esta serie está centrada en el marco de reorganización de búsquedas y la parte 3 trata de los casos que nos llegaron a Microsoft hasta a fecha.

Eric Norberg
Ingeniero de servicios
de Office 365

Esta entrada de blog es una traducción. Encontrará el artículo original en Establishing Exchange Content Index Rebuild Baselines – Part 1