Follow us on Twitter
Follow us on YouTube
Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.
Artículo original publicado el miércoles 27 de junio de 2012
En la Parte 1 de esta serie se presentó el script E2K7_IndexRebuildAnalyzer.ps1 . En este artículo se discutirá el Marco de reorganización de búsqueda que desarrollamos Anatoly Girko y yo. Este marco se diseñó originalmente para facilitar a nuestro personal de tareas 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.
En nuestro entorno, cuando se decide reorganizar archivos del Índice de contenido de la base de datos de buzones de correo de Exchangeel 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).
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
La métrica previase 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.
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:
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.
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
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:
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:
En el nivel del Índice/Índices de la base de datos de buzones de correo:
En un servidor Exchange Server en el que todos los Índices de contenido estén totalmente al día se vería lo siguiente:
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
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.
.\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 “NoEventsFound” 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 “NoEventsFound” 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 “NoEventFound” 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:
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.
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 propiedadesResultFound 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.
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.
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