Établissement de lignes de base pour la reconstruction d’index de contenu Exchange – Partie 2

Article d’origine publié le mercredi 27 juin 2012

Dans la Partie 1 de cette série, j’ai abordé le script E2K7_IndexRebuildAnalyzer.ps1. Dans cet article, je parlerai de l’infrastructure de reconstruction de recherche qu’Anatoly Girko et moi-même avons développée. Cette infrastructure a été conçue à l’origine pour offrir à nos équipes opérationnelles en interne un ensemble de procédures de validation exhaustives et d’indicateurs de progression dont elles pouvaient se servir au moment de recréer des index de contenu.

Étape 1 : Collecte des statistiques de préreconstruction

Dans notre environnement, lorsque nous prenons la décision de reconstruire les fichiers d’index de contenu d’une base de données de boîtes aux lettres Exchange, les opérateurs commencent d’abord par calculer les statistiques de préreconstruction de la banque affectée. Ces statistiques sont toujours rédigées au format CSV à des fins de documentation pour être au final insérées dans notre collection de données historiques. Cependant, comme nous l’avons vu, l’utilisation du paramètre -CSVFile est facultative. Dans des cas où le paramètre -CSVFile n’est pas transmis, la sortie correspondante sera écrite dans la fenêtre de la console de l’environnement de ligne de commande. Pour une meilleure lisibilité, vous devez régler à la fois la largeur de la mémoire tampon écran et la largeur de la fenêtre de la console pour correctement adapter les divers en-têtes et mesures à générer. Vous pourrez ainsi lire les valeurs plus facilement dans la session de la console. De là, je fais généralement en sorte de « canaliser » la sortie vers la cmdlet Format-Table (ft) à l’aide du paramètre -AutoSize (-a) .

Exemples

Exemple de la console :

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

Sortie  :

Exemple CSV :

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

Sortie  :

Des mesures préalables sont ensuite comparées à la collection de données historiques et un temps moyen de reconstruction est estimé. Nous tenons compte de l’emplacement régional de la base de données de boîtes aux lettres et des boîtes aux lettres utilisateur correspondantes. En fonction du lieu géographique de la banque et du temps estimé, nous planifions le travail de reconstruction à une date et une heure où l’activité des utilisateurs dans cette banque est minime.

Étape 2 : Réinitialisation de l’index de contenu pour la ou les bases de données de boîtes aux lettres affectées

Dans notre environnement, les opérateurs procèdent ensuite à la redéfinition de l’index de contenu de la base de données de boîtes aux lettres. Pour cela, ils utilisent l’un des techniques documentées dans la rubrique Procédure de recréation du catalogue d’indexation de texte intégral.

Dans les exemples qui suivent, je vais redéfinir les fichiers d’index de contenu de deux bases de données de boîtes aux lettres dans mon environnement. Il s’avère aussi que ces deux banques sont les plus importantes en termes de nombre de boîtes aux lettres, de taille de fichiers EDB et de nombre d’éléments de base de données collective sur le serveur de boîtes aux lettres en cluster NA1-ERICNOR-1 :

Redéfinition des fichiers d’index de contenu :

Étape 3 : Validation de la détection de l’analyse complète requise via le service Microsoft Exchange Search Indexer

Après avoir successivement supprimé les fichiers d’index de contenu existants dans le système de fichiers, puis redémarré le service Microsoft Exchange Search Indexer, nous confions le soin au thread MonitorAndUpdateMDBList de déterminer l’état actuel des index de contenu pour l’ensemble des bases de données de boîtes aux lettres activées à des fins d’indexation de contenu sur le serveur de boîtes aux lettres. Après avoir déterminé l’ état d’intégrité des index de contenu pour chaque base de données de boîtes aux lettres, le thread MonitorAndUpdateMDBList stocke en mémoire chaque valeur relative à l’état d’intégrité. Si la valeur de l’état d’intégrité des index de contenu est égal à « Nouveau », c’est que le service Microsoft Exchange Search Indexer a déterminé qu’une analyse complète est nécessaire pour ramener les fichiers d’index de contenu à un état Intègre (« Intègre » correspondant au moment où l’index est maintenu à jour via des notifications de la banque d’informations). C’est à cet instant précis que le service Exchange Search Indexer lance une analyse complète dans la base de données de boîtes aux lettres.

L’heure à laquelle l’analyse complète débute réellement est consignée dans le journal des événements des applications et signalée par l’ID d’événement 109.

Pour s’assurer que les opérations d’analyse complète démarrent sur un système, l’opérateur ayant la charge de ces opérations valide la présence de l’ID d’événement 109 pour chaque base de données de boîtes aux lettres dont l’index de contenu a été précédemment redéfini à l’ étape 2.

Exemple

Comme le montre l’exemple précédent, les fichiers d’index de contenu des bases de données NA1-ERICNOR-1-DB1 et NA1-ERICNOR-1-DB18 ont été redéfinies à l’aide du script ResetSearchIndex. Pour valider que le service Microsoft Exchange Search Indexer a lancé les opérations d’analyse complète, un ID d’événement 109 unique doit être présent pour chaque base de données de boîtes aux lettres sur le serveur de boîtes aux lettres. Ceci semble être le cas :

Type d’événement : Information
Source de l’événement : MSExchange Search Indexer
Catégorie d’événement : Général
ID d’événement : 109
Date : 5/10/2012
Heure : 2:22:19 PM
Ordinateur : NA1-ERICNOR-1-A
Description : le service Microsoft Exchange Search Indexer a créé un nouvel index de recherche et procèdera à une analyse complète de la base de données de boîtes aux lettres NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).

Type d’événement : Information
Source de l’événement : MSExchange Search Indexer
Catégorie d’événement : Général
ID d’événement : 109
Date : 5/10/2012
Heure : 2:22:20 PM
Ordinateur : NA1-ERICNOR-1-A
Description : le service Microsoft Exchange Search Indexer a créé un nouvel index de recherche et procèdera à une analyse complète de la base de données de boîtes aux lettres NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).

Remarque : plutôt que d’examiner visuellement le journal des événements, une autre technique viable peut être employée en utilisant simplement la cmdlet Get-EventLog et en écrivant les événements de démarrage au format CSV. Par exemple :

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

Étape 4 : Validation de la progression et de la fin du service Microsoft Exchange Search Indexer

Après avoir validé que les opérations d’analyse complète ont débuté (par la présence de l’ID d’événement 109), l’opérateur suit la progression globale du processus de reconstruction à l’aide du Moniteur système. Les objets et compteurs suivants sont généralement observés :

• MSExchange Search Indexer\Nombre de bases de données en cours d’analyse
• MSExchange Search Indexer\Nombre de bases de données indexées en cours d’actualisation via des notifications
• Index de recherche MSExchange\<Instance de base de données en cours d’analyse>\État du mode d’analyse complète
• Index de recherche MSExchange\<Instance de base de données en cours d’analyse>\Vitesse d’indexation des documents
• Index de recherche MSExchange\<Instance de base de données en cours d’analyse>\Nombre de boîtes aux lettres restant à analyser
• Index de recherche MSExchange\<Instance de base de données en cours d’analyse>\Nombre de boîtes aux lettres récemment déplacées et en cours d’analyse
• Index de recherche MSExchange\<Instance de base de données en cours d’analyse>\Nombre de lots en attente
• Index de recherche MSExchange\<Instance de base de données en cours d’analyse>\Valeur du délai de limitation

En examinant l’objet MSExchangeSearchIndexer, un opérateur peut facilement évaluer le nombre d’index de contenu à jour sur le serveur et combien parmi eux sont effectivement en cours d’analyse. Lorsqu’un serveur de boîtes aux lettres est entièrement à jour, la valeur du compteur Nombre de bases de données en cours d’analyse est toujours égale à 0 et celle du compteur « Nombre de bases de données indexées en cours d’actualisation via des notifications » est égale au nombre de bases de données de boîtes aux lettres activées à des fins d’indexation de contenu sur le serveur.

Dans mon exemple ci-dessous, je dispose de 18 bases de données de boîtes aux lettres sur mon serveur de messagerie ; deux de ces bases de données font actuellement l’objet d’une analyse complète. Ainsi la valeur du compteur Nombre de bases de données en cours d’analyse doit être égale à 2 et celle du compteur Nombre de bases de données indexées en cours d’actualisation via des notifications égale à 16, ce qui est le cas :

À mesure que vous effectuez une analyse complète individuelle pour chacune des bases de données de boîtes aux lettres, vous constaterez des changements précis apportés aux divers compteurs/objets dans le Moniteur système.

Au niveau du service MSExchange Search Indexer :

• Le compteur Nombre de bases de données en cours d’analyseest décrémenté de 1.
• Le compteur Nombre de bases de données indexées en cours d’actualisation via des notifications est incrémenté de 1.

Au niveau du ou des index de base de données de boîtes aux lettres :

• La valeur du compteur État du mode d’analyse complète dans la base de données concernée a été décrémentée à 0 (ce qui reflète la nouvelle valeur de l’ état d’intégrité des index de contenu telle qu’elle est déterminée par le thread MonitorAndUpdateMDBListdu moniteur).
• Le compteur Nombre de boîtes aux lettres restant à analyser doit dévoiler une valeur égale à 0.
• Bien que n’étant pas spécifiquement liée à une opération de reconstruction Analyse complète, la valeur du compteur Nombre de boîtes aux lettres récemment déplacées et en cours d’analyse doit également être 0 pour chaque index. À mesure que les boîtes aux lettres Exchange sont correctement déplacées entre les bases de données de boîtes aux lettres Exchange (à condition que la cible soit activée à des fins d’indexation de contenu), les notifications de recherche dans la base de données cible sont provisoirement suspendues. Le service Exchange Search Indexer procède ainsi pour pouvoir réaliser des analyses ponctuelles des boîtes aux lettres récemment déplacées et remettre à jour entièrement l’index principal. Une fois l’analyse ponctuelle terminée, les notifications de la banque reprennent. L’objectif ici est de souligner que, bien que l’analyse complète soit techniquement finie, il est toujours possible qu’une analyse ponctuelle survienne si les déplacements de boîtes aux lettres ont eu lieu en même temps que la reconstruction d’index de contenu. Pourvu que ce compteur soit égal à 0, toutes les activités d’analyse survenant dans la base de données de boîtes aux lettres seront définitivement menées à terme. Elles doivent donc être validées en tant que telles.

Le résultat attendu sur un serveur Exchange où tous les index de contenu sont entièrement à jour serait le suivant :

• Le compteur MSExchange Search Indexer\Nombre de bases de données en cours d’analyse est égal à 0.
• Le compteur MSExchange Search Indexer\Nombre de bases de données indexées en cours d’actualisation via des notificationsest égal au nombre de bases de données de boîtes aux lettres activées à des fins d’indexation sur le serveur de boîtes aux lettres.
• Le compteur État du mode d’analyse complète pour chaque instance de base de données de boîtes aux lettres Exchange sur le serveur de boîtes aux lettres est égal à 0.
• Le compteur Nombre de boîtes aux lettres restant à analyser pour chaque instance de base de données de boîtes aux lettres Exchange sur le serveur de boîtes aux lettres est égal à 0.
• Le compteur Nombre de boîtes aux lettres récemment déplacées et en cours d’analyse pour chaque instance de base de données de boîtes aux lettres Exchange sur le serveur de boîtes aux lettres est égal à 0.

Dans mon exemple, toutes ces valeurs ont la valeur True. Je peux donc raisonnablement supposer que les index ont été recréés avec succès et que le serveur est parfaitement Intègre du point de vue d’un index de contenu :

Une fois que tous les index de contenu semblent avoir été mis à jour à l’aide du Moniteur système, l’opérateur en charge examine habituellement le journal des événements des applications et valide la présence de l’ID d’événement 110, à savoir l’événement de fin du service Microsoft Exchange Search Indexer qui désigne une analyse complète. De la même manière que l’ID d’événement 109, une entrée d’événement 110 est disponible pour chaque base de données de boîtes aux lettres ayant été soumise à une analyse complète:

Type d’événement : Information
Source de l’événement : MSExchange Search Indexer
Catégorie d’événement : Général
ID d’événement : 110
Date : 5/10/2012
Heure : 5:39:47 PM
Computer: NA1-ERICNOR-1-A
Description Source de l’événement : le service Microsoft Exchange Search Indexer a procédé à une analyse complète (indexation) de la base de données de boîtes aux lettres NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129).

Type d’événement : Information
Source de l’événement : MSExchange Search Indexer
Catégorie d’événement : Général
ID d’événement : 110
Date : 5/10/2012
Heure : 5:11:47 PM
Ordinateur : NA1-ERICNOR-1-A
Description : le service Microsoft Exchange Search Indexer a procédé à une analyse complète (indexation) de la base de données de boîtes aux lettres NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16).

Remarque : plutôt que d’examiner visuellement le journal des événements, une autre technique viable peut être employée en utilisant simplement la cmdlet Get-EventLog et en écrivant les événements de fin au format CSV. Par exemple :

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

Étape 5 : Collecte des mesures de post-reconstruction

À l’ étape 5, il est supposé que l’opérateur a validé l’exécution à terme de l’analyse complète pour chaque base de données de boîtes aux lettres. C’est à ce moment précis que l’opérateur recueille des mesures de post-reconstruction afin de déterminer les caractéristiques de débit de chaque base de données de boîtes aux lettres soumise à une analyse complète.

Pour rassembler ces mesures, le script E2K7_IndexRebuildAnalyzer est utilisé avec le commutateur -PostRebuild.

Comme précisé plus haut, le paramètre -PostRebuild analyse les journaux des événements des applications afin de détecter la présence des ID d’événement 109 et 110. Dans le cas de la réplication continue en cluster (CCR), c’est le journal des événements des applications de chaque nœud du cluster CCR qui est évalué. Si le script parvient à localiser ces ID d’événement, il calcule le temps total (en divers incréments de temps) requis pour mener l’analyse complète à terme dans chaque base de données de boîtes aux lettres. Il renvoie ensuite à l’opérateur des caractéristiques de débit pour chaque opération de reconstruction unique.

Là encore, il faut surtout noter que toutes les bases de données de boîtes aux lettres sur le serveur de boîtes aux lettres seront évaluées, que leurs index de recherche aient été recréés ou non. Qui plus est, s’ils sont instanciés sans l’option -CSVFile, les résultats seront générés dans la fenêtre de la console. Au moment de calculer des statistiques de post-reconstruction, je conseille vivement le recours au paramètre -CSVFile car il facilite grandement la création de rapports, le tri, le filtrage et la rotation d’éléments lorsque vous travaillez dans Excel.

Exemple

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

Une fois l’exécution du script E2K7_IndexRebuildAnalyzer terminée, le fichier CSV peut être examiné. L’examen du fichier CSV montre que toutes les bases de données de boîtes aux lettres Exchange sur le serveur de boîtes aux lettres ont été traitées. La chaîne NoEventsFound est renvoyée pour un grand nombre de bases de données de boîtes aux lettres Exchange puisque les deux ID d’événement combinés du service Search Indexer sont introuvables. Dans le cas de mon exemple, 16 bases de données de boîtes aux lettres affichent la chaîne « NoEventsFound » et deux bases de données de boîtes aux lettres disposent de mesures de post-reconstruction valides :

Ces résultats peuvent être affinés encore en appliquant un simple filtre textuel dans Excel. Si je filtre des en-têtes de colonnes et désactive la chaîne NoEventFound, seules les bases de données dotées de mesures de post-reconstruction valides s’affichent :

Après application de ce filtre dans les résultats de l’exemple, seules les bases de données NA1-ERICNOR-1-DB1 et NA1-ERICNOR-1-DB18 sont visibles (c’est-à-dire les bases de données de boîtes aux lettres dont les index de contenu ont été redéfinis). Il apparaît aussi clairement que les mesures de post-reconstruction ont été correctement évaluées puisqu’ils existent des valeurs valides pour les divers en-têtes de post-reconstruction :

Résultat après application du filtre :

Étape 6 : Validation Test-ExchangeSearch

L’ étape 6 de l’infrastructure de reconstruction valide que toutes les boîtes aux lettres hébergées dans les bases de données de boîtes aux lettres et dont les index de contenu ont été redéfinis peuvent à présent renvoyer des réponses de recherche valides. Pour y parvenir, il suffit d’exploiter les fonctionnalités clés de la cmdlet Test-ExchangeSearch. La phase de validation finale est terminée lorsque toutes les boîtes aux lettres renvoient une valeur True en réponse à la cmdlet.

Exemple :

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

L’exécution en bonne et due forme de ce processus prend beaucoup de temps en fonction du nombre de boîtes aux lettres contenues dans la base de données. Un autre élément intéressant à noter est que lorsque vous effectuez des opérations en bloc avec Test-ExchangeSearch, les propriétés ResultFound et SearchTime sont visibles uniquement dans la fenêtre de la console après que toutes les boîtes aux lettres ont été traitées (sans tenir compte des résultats True ou False). Dans certains cas, il est également judicieux de stocker l’intégralité des résultats dans un fichier CSV à des fins de documentation.

Toutes les boîtes aux lettres d’utilisateurs finaux signalant un résultat False au test Test-ExchangeSearch sont traitées comme des problèmes ponctuels et sont corrigées dans cette optique.

Étape 7 : Analyse des mesures de post-reconstruction

Pour des raisons de lisibilité, je vais afficher les diverses mesures sous la forme d’un tableau plutôt que de les afficher nativement dans des colonnes Excel. Comme je l’ai précisé avant, deux bases de données de boîtes aux lettres sur le serveur de boîtes aux lettres en cluster NA1-ERICNOR-1 ont eu leurs index de contenu recréés : NA1-ERICNOR-1-DB1 et NA1-ERICNOR-1-DB18.

Mesures de post-reconstruction des bases de données de boîtes aux lettres :

Mesures de reconstruction des bases de données de boîtes aux lettres :

Les diverses mesures de reconstruction et de post-reconstruction sont ensuite ajoutées à la collection de données historiques pour pouvoir contribuer à l’évaluation de moyennes historiques pour de futures activités de reconstruction.

Conclusion

Dans le second billet de cette série, j’ai abordé les étapes de l’infrastructure de reconstruction de recherche. Dans mon billet suivant, le dernier, je vous présenterai les moyennes que nous avons observées au cours de nos déploiements chez Microsoft.

Eric Norberg
Ingénieur
Équipe Office 365

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Establishing Exchange Content Index Rebuild Baselines – Part 2