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

Artículo original publicado el miércoles 27 de junio de 2012

En la Parte 1 de esta serie, se explicó el script E2K7_IndexRebuildAnalyzer.ps1. En este artículo se tratará el Marco de recompilación de búsqueda que desarrollamos 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.

Fase 1: Reunión de estadísticas previa a la reorganización

En nuestro entorno, cuando se decide reorganizar archivos del Índice de contenido de la base de datos de buzones de correo de Exchange el Operador comienza calculando las estadísticas previas a la reorganización relativas al almacén afectado. Estas estadísticas se escriben siempre en formato CSV por motivos de documentación y terminan insertándose en nuestro conjunto de recopilación de datos histórico. De todos modos, como ya se ha dicho, el uso del parámetro -CSVFile es opcional. En situaciones en las que el parámetro - CSVFile no se transfiere, el resultado correspondiente se escribe en la ventana de la consola del shell. Para obtener una lectura óptima puede ajustar tanto el Ancho del búfer de la pantalla como el Ancho de la ventana de la consola para que se ajuste a los distintos encabezados y métricas que se mostrarán. Esto le permitirá leer los valores más fácilmente en la sesión de la consola. Llegados a este punto, yo suelo "canalizar" el resultado a Format-Table (ft) con el parámetro -AutoSize (-a) .

Ejemplos

Ejemplo de consola:

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

Resultado :

Ejemplo de CSV:

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

Resultado :

La métrica previa se contrasta entonces con la recopilación de datos históricos y de ahí se deriva una duración media para completar el presupuesto de reorganización. Se tiene en cuenta la ubicación regional de la base de datos de buzones de correo y de los buzones de usuario final correspondientes. Basándonos en la ubicación del almacén y en la duración estimada, se programa el trabajo de reorganización para una fecha y una hora en la que la actividad del usuario en ese almacén sea mínima.

Fase 2: Restablecimiento del índice de contenido de las bases de datos de buzones de correo afectado

Los operadores de nuestro entorno proceden entonces a restablecer el Índice de contenido de la base de datos de buzones de correo con cualquiera de las técnicas documentadas en la sección Reorganizar el catálogo de texto del índice.

En los ejemplos siguientes se restablecerán los archivos del Índice de contenido de dos bases de datos de buzones de correo de mi entorno. Estos dos almacenes tienen, además, los mayores recuentos de buzón, tamaños de archivos EDB y totales de elementos de base datos del Servidor de buzones de correo en clúster NA1-ERICNOR-1:

Restablecimiento de archivos de índice de contenido:

Fase 3: El indizador de búsqueda de validación detectó un rastreo completo necesario

Después de haber quitado del sistema de archivos los archivos de Índice de contenido y de que el servicio Indizador de búsqueda de Microsoft Exchange se haya reiniciado como consecuencia de esto, es responsabilidad del subproceso MonitorAndUpdateMDBList determinar el estado actual de los Índices de contenido de todas las Bases de datos de buzones de correo del Buzón del servidor habilitadas para la Indización de contenido. Una vez el subproceso MonitorAndUpdateMDBList haya determinado el Estado de mantenimiento del índice de contenido de cada Base de datos de buzones de correo, coloca los valores de Estado de mantenimiento de la base de datos de buzones de correo en la memoria. Si el valor del Estado de mantenimiento del índice de contenido es igual a "Nuevo ", el Servicio de Indizador de búsqueda de Microsoft ha determinado que se necesita un Rastreo completo para dotar a los archivos de Índice de contenido de un buen mantenimiento (siendo "Buen mantenimiento" el lugar donde se tiene al día el índice a través de la Notificación de almacén). Es entonces cuando el servicio Indizador de búsqueda de Exchange inicia una tarea de Rastreo completo con la Base de datos de buzones de correo afectado.

La hora a la que comienza realmente la tarea de Rastreo completo está señalada en el registro de Eventos de aplicaciones como Id. de evento 109.

Para asegurarse de que todas las tareas de Rastreo completo han empezado en un sistema, el operador que realiza el trabajo validará la presencia de la Id. del evento 109 para cada Base de datos de buzones de correo cuyo Índice de contenido se restableció previamente en el Paso 2.

Ejemplo

Tal y como se ha ilustrado en el ejemplo anterior, los archivos de Índice de contenido para NA1-ERICNOR-1-DB1 y NA1-ERICNOR-1-DB18 se restablecieron con el script ResetSearchIndex. Para validar que el servicio Indizador de búsqueda de Microsoft Exchange ha empezado las tareas de Rastreo completo, le recomendamos que tenga un Id. del evento 109 único en cada Base de datos de buzones de correo en el Servidor del buzón. Este parece ser el caso:

Tipo de evento: Información
Origen del evento: Indizador de búsqueda de MSExchange
Categoría del evento: General
Id. del evento: 109
Fecha: 5/10/2012
Hora: 2:22:19 PM
PC: NA1-ERICNOR-1-A
Descripción: El Indizador de búsqueda de Exchange creó un nuevo índice de búsqueda y realizará un rastreo completo en la Base de datos de buzones de correo NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).

Tipo de evento: Información
Origen del evento: Indizador de búsqueda de MSExchange
Categoría del evento: General
Id. del evento: 109
Fecha: 5/10/2012
Hora: 2:22:19 PM
PC: NA1-ERICNOR-1-A
Descripción: El Indizador de búsqueda de Exchange creó un nuevo índice de búsqueda y realizará un rastreo completo en la Base de datos de buzones de correo NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).

Nota: Una técnica viable alternativa a inspeccionar el Registro de eventos visualmente sería sencillamente sacar provecho del cmdlet Get-EventLog y escribir los eventos de Inicio en formato CSV. Ejemplo:

Get-EventLog "Application" | Where-Object {$_.EventID -eq 109} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_StartEvents.csv

Fase 4: Progreso y finalización del indizador de búsqueda de validación

Una vez se ha validado que las tareas de Rastreo completo han empezado (con la Id. de evento 109 presente), el Operador supervisa el progreso de reorganización al completo con el Monitor de sistema. Se supervisarán especialmente los siguientes Objetos y Contadores:

• Indizador de búsqueda de MSExchange\Número de bases de datos en rastreo
• Indizador de búsqueda de MSExchange\Número de bases de datos indizadas actualizadas por notificaciones
• Índices de búsqueda de MSExchange\<Instancia BD en rastreo>\Estado modo rastreo completo
• Índices de búsqueda de MSExchange\<Instancia BD en rastreo>\Velocidad de indización de documentos
• Índices de búsqueda de MSExchange\<Instancia BD en rastreo>\Número de buzones por rastrear
• Índices de búsqueda de MSExchange\<Instancia BD en rastreo>\Número de buzones movidos recientemente en rastreo
• Índices de búsqueda de MSExchange\<Instancia BD en rastreo>\Número de lotes pendientes
• Índices de búsqueda de MSExchange\<Instancia BD en rastreo>\Valor de retraso límite

Al revisar el objeto MSExchangeSearchIndexer, un Operador puede determinar fácilmente cuántos Índices de contenido del Servidor están al día y cuántos están en rastreo en ese momento. Cuando un Servidor de buzón está totalmente al día, el valor del contador "Número de bases de datos en rastreo " siempre será igual a 0 y el valor de contador "Número de bases de datos indizadas actualizadas por notificaciones" será igual al número de Bases de datos de buzones de correo habilitadas para Indización de contenido en el servidor.

En mi ejemplo tengo un total de dieciocho Bases de datos de buzones de correo en mi servidor de correo. Dos de ellas están actualmente en proceso de Rastreo completo, por lo tanto, asegúrese de que el valor para el "Número de bases de datos en rastreo" sea igual a 2 y el valor del "Número de bases de datos indizadas actualizadas por notificaciones" sea igual a 16, lo cual se cumple:

A medida que las Bases de datos de buzones de correo individuales completan el Rastreo completo, verá que se producen cambios específicos en los diversos contadores de objetos del Monitor del sistema.

En el nivel del Indizador de búsqueda de MSExchange:

• El contador del "Número de bases de datos en rastreo" disminuye en 1
• El "Número de bases de datos indizadas actualizadas por notificaciones" aumenta en 1.

En el nivel del Índice/Índices de la base de datos de buzones de correo:

• El valor del "Estado modo rastreo completo" de la base de datos específica disminuyó a 0(lo que refleja un nuevo valor para el Estado de mantenimiento del índice de contenido, tal como se determina en el subproceso del monitor MonitorAndUpdateMDBList).
• Asegúrese de que el "Número de buzones por rastrear" refleje un valor de 0.
• Aunque no esté especialmente relacionado con la tarea de reorganización Rastreo completo per se, el valor del contador "Número de buzones movidos recientemente en rastreo " también podría ser 0 para cada índice. Como los Buzones de Exchange se mueven correctamente entre Bases de datos de Exchange (siempre que el destino esté habilitado para la Indización de contenido), las Notificaciones de búsqueda de la base de datos de destino se suspenderán temporalmente. El Servicio Indizador de búsqueda de Exchange hace esto para poder realizar rastreos puntuales de los buzones movidos recientemente para actualizar totalmente el Índice maestro. Una vez completado el rastreo puntual, se reanudan las Notificaciones de almacén. La clave de esto es que, a pesar de que el Rastreo completo se haya completado técnicamente, aún es posible que haya más rastreos puntuales si el buzón se moviese al mismo tiempo que la reorganización de Índices de contenido. Si el contador es igual a 0, toda actividad de rastreo que se dé en la Base de datos de buzones de correo estará definitivamente completa y por lo tanto es recomendable que se valide como tal.

En un servidor Exchange Server en el que todos los Índices de contenido estén totalmente al día se vería lo siguiente:

• El "Indizador de búsqueda de MSExchange\Número de bases de datos en rastreo " es igual a 0.
• El "Indizador de búsqueda de MSExchange\Número de bases de datos indizadas actualizadas por notificaciones" es igual al número de Bases de datos de buzones de correo habilitadas para la indización en el Servidor del buzón.
• El "Estado modo rastreo completo" para cada instancia de base de datos de buzones de correo de Exchange del Servidor del buzón es igual a 0.
• El "Número de buzones por rastrear" para cada instancia de base de datos de buzones de correo de Exchange del Servidor del buzón es igual a 0.
• El "Número de buzones movidos recientemente en rastreo" para cada instancia de base de datos de buzones de correo de Exchange del Servidor del buzón es igual a 0.

En mi ejemplo, todos estos valores son Verdaderos, por lo que puedo asumir razonablemente que los índices se han reorganizado correctamente y que, desde una perspectiva del Índice de contenido, el servidor tiene un mantenimiento Bueno:

Cuando todos los Índices de contenido parezcan estar actualizados por el Monitor del sistema, el operador que realice el trabajo procedería a revisar el Registro de eventos de aplicaciones y a validar la presencia del Id. de evento 110, el evento de finalización del Indizador de búsqueda de Microsoft Exchange para el Rastreo completo. Del mismo modo que con la Id. de evento 109, habrá una entrada de evento para cada Base de datos de buzones de correo que haya completado el Rastreo completo:

Tipo de evento: Información
Origen del evento: Indizador de búsqueda de MSExchange
Categoría del evento: General
Id. del evento: 110
Fecha: 5/10/2012
Hora: 5:39:47 PM
PC: NA1-ERICNOR-1-A
Descripción: El Indizador de búsqueda de Exchange completó un rastreo completo (indización) en la Base de datos de buzones de correo NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).

Tipo de evento: Información
Origen del evento: Indizador de búsqueda de MSExchange
Categoría del evento: General
Id. del evento: 110
Fecha: 5/10/2012
Hora: 5:39:47 PM
PC: NA1-ERICNOR-1-A
Descripción: El Indizador de búsqueda de Exchange completó un rastreo completo (indización) en la Base de datos de buzones de correo NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16)).

Nota : Una técnica viable alternativa a inspeccionar el Registro de eventos visualmente sería sencillamente sacar provecho del cmdlet Get-EventLog y escribir los eventos de Finalización en formato CSV. Ejemplo:

Get-EventLog "Application" | Where-Object {$_.EventID -eq 110} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_CompletionEvents.csv

Fase 5: Recopilar métrica posterior a la reorganización

En la Fase-5 se da por hecho que el operador ha validado la finalización del Rastreo completo para cada Base de datos de buzones de correo. Es en este punto que recopilaría la métrica Posterior a la reorganización para determinar el rendimiento de las características para cada Base de datos de buzones de correo que se rastrearon.

Para recopilar esta métrica, se usa el script E2K7_IndexRebuildAnalyzer sacando provecho del conmutador -PostRebuild .

Tal como se ha mencionado anteriormente -PostRebuild analiza los registros de Eventos de aplicaciones para comprobar la presencia de la Id. de evento 109 y la Id. de evento 110 . En el caso de la Replicación continua de clúster , se evalúa el Registro de eventos de aplicación de cada nodo del Clúster CCR. Si el script puede ubicar estas Id. de evento, calculará la duración total (en varios incrementos de tiempo) necesaria para completar el Rastreo completo con cada Base de datos de buzones de correo y devolverá al operador las características de rendimiento de cada tarea de reorganización única.

Una vez más, vale la pena señalar que todas las Bases de datos de buzones de correo del Servidor del buzón se evaluarán independientemente de si se han reorganizado o no todas las Bases de datos de buzones de correo de sus Índices de búsqueda. Además, si se ha creado una instancia sin la opción -CSVFile , el conjunto de resultados se exportará a la ventana de la consola. Al calcular las estadísticas posteriores a la reorganización, recomendaría encarecidamente sacar provecho al -CSVFile , ya que el uso de Excel facilita las notificaciones, la ordenación, el filtrado y la dinamización.

Ejemplo

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

Después de que el E2K7_IndexRebuildAnalyzer haya completado la ejecución, puede examinarse el archivo CSV. Esta revisión muestra que todas las Bases de datos de buzones de correo de Exchange del Servidor del buzón se han procesado. La cadena \ldblquote NoEventsFound \rdblquote se devuelve para muchas de las Bases de datos de buzones de correo de Exchange porque la combinación de pares de la Id. de evento del indizador de búsqueda no puede ubicarse. En el caso del ejemplo, hay 16 Bases de datos de buzones de correo con el mensaje \ldblquote NoEventsFound\rdblquote y dos Bases de datos de buzones de correo con una métrica posterior a la reorganización válida:

Este conjunto de resultados puede perfeccionarse aún más si se aplica un sencillo filtro basado en texto en Excel . Si se aplican filtros a cualquiera de los encabezados de columna del proceso posterior a la reorganización y se desactiva la cadena \ldblquote NoEventFound \rdblquote solo se mostrarán las bases de datos con una métrica posterior a la reorganización válida:

Al haber aplicado este filtro al conjunto de resultados del ejemplo, ahora solo se muestran NA1-ERICNOR-1-DB1 y NA1-ERICNOR-1-DB18 (p.ej., las Bases de datos de buzones de correo cuyos Índices de contenido se restablecieron). Asimismo, también queda claro que la métrica posterior a la reorganización se determinó correctamente porque hay valores válidos para los distintos encabezados del proceso posterior a la reorganización:

Aplicación del filtro Post String:

Fase 6: Validación Test-ExchangeSearch

La Fase 6 del Marco de reorganización valida que todos los buzones alojados en las Bases de datos de buzones de correo cuyos Índices de contenido se restablecieron pueden ahora devolver respuestas de búsqueda válidas. Este objetivo puede alcanzarse sacando provecho de la función principal del cmdlet Test-ExchangeSearch . La validación final se completa solo cuando todos los buzones devuelven la respuesta Verdadero al cmdlet.

Ejemplo:

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

Este proceso tardará más o menos dependiendo del número de buzones que existan en la base de datos. También se ha de señalar que al realizar tareas masivas con Test-ExchangeSearch , las propiedades ResultFound y SearchTime solo estarán visibles en la ventana de la consola una vez procesados todos los buzones (sin tener en cuenta si el resultado es Verdadero o Falso ). En algunos casos también podría ser útil almacenar todos los resultados en CSV por motivos de documentación.

Todos los buzones de usuario final que devuelven Falso tras la prueba Test-ExchangeSearch , se tratan como problemas puntuales y se resuelven como tales.

Fase 7: Análisis de la métrica posterior a la reorganización

Para facilitar la lectura voy a mostrar las distintas métricas en formato de tabla en lugar de en forma nativa en columnas de Excel . Tal como se ha señalado anteriormente, hay dos Bases de datos de buzones de correo de Exchange del Servidor del buzón en clúster NA1-ERICNOR-1 cuyos Índices de contenido se han reorganizado: NA1-ERICNOR-1-DB1 y NA1-ERICNOR-1-DB18

Reorganizaciones posteriores de la métrica del buzón:

 

Métrica de reorganización de la base de datos de buzones de correo:

Las distintas métricas de reorganización y previas a la reorganización se agregan entonces al conjunto de recopilación de datos históricos para poder contribuir a las medias históricas en los próximos ejercicios de reorganización.

Conclusión

La segunda entrada de esta serie trata sobre las fases del Marco de reorganización de búsqueda.  La próxima entrada, que también será la última, hablará de las medias estimadas que se han observado en nuestras implementaciones en Microsoft.

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 2