Article d’origine publié le mardi 26 juin 2012

L’une des premières actions qu’effectuent la plupart des administrateurs Exchange lorsqu’ils résolvent des problèmes suspects liés à l’indexation de contenu Exchange est de recréer les fichiers d’index de contenu de la base de données de boîtes aux lettres affectée (soit manuellement, soit au moyen du script ResetSearchIndex.ps1 situé dans le répertoire \Exchange Server\Scripts). Pendant plusieurs années, j’ai également travaillé avec bon nombre d’administrateurs Exchange qui préféraient proactivement recréer des index de recherche à divers moments de l’année civile ou à mesure que les diverses étapes d’un projet étaient validées (disons un projet de migration pour ne prendre qu’un exemple).

Quelle que soit la raison évoquée pour redéfinir les index, la plupart des administrateurs (si vous les interrogez à ce sujet) sont incapables d’estimer avec réalisme le temps nécessaire pour la réalisation de ce processus de A à Z. Les conséquences indésirables de cette absence d’estimation précise varient d’une entreprise à l’autre. Pour dissuader toute velléité de mettre des index côté serveur à la disposition des utilisateurs au cours d’une journée de travail, certains services informatiques peuvent invoquer une perte de productivité des utilisateurs finaux ou une hausse modérée des problèmes transmis au support technique. D’un point de vue opérationnel, ne pas connaître les délais de reconstruction à l’avance peut aussi empêcher les administrateurs d’être alertés en cas d’éventuels problèmes découlant du processus de reconstruction même. Quelles que soient vos motivations, une bonne maîtrise du temps d’exécution du processus est un atout.

Il faut reconnaître qu’il existe à l’heure actuelle peu d’informations sur le temps requis (ou mieux encore, le temps qu’il faudrait) pour recréer un index de contenu Exchange. Cette pénurie est soi-disant liée au caractère toujours variable des délais de reconstruction réels. De nombreux facteurs ont une influence sur les taux et le délai de reconstruction, et plus particulièrement les suivants :

• Variabilité du nombre total de boîtes aux lettres d’utilisateur final « hébergées » dans une base de données de boîtes aux lettres Exchange
• Variabilité de la taille des boîtes aux lettres au sein d’une base de données de boîtes aux lettres Exchange
• Variabilité du nombre d’éléments entre les boîtes aux lettres utilisateur hébergées dans une base de données de boîtes aux lettres Exchange
• Variabilité du nombre d’éléments entre les bases de données de boîtes aux lettres Exchange (lors de reconstructions simultanées)
• Variabilité de la taille des éléments résidant dans une base de données de boîtes aux lettres Exchange
• Variabilité du nombre et de la taille des pièces jointes de messagerie dans une base de données de boîtes aux lettres Exchange
• Types et nombre de filtres IFilter activés sur un serveur de boîtes aux lettres Exchange (permet l’indexation de divers formats de fichiers)
• Utilisation globale des ressources système d’un serveur de boîtes aux lettres procédant à une analyse (tenez compte de la limitation)
• Et bien plus encore…

Chez Microsoft (dans notre implémentation en entreprise comme dans diverses offres Office 365), nous utilisons une infrastructure de reconstruction de recherche que j’ai développée avec mon collègue Anatoly Girko. Cette infrastructure a été conçue au départ pour offrir à nos équipes opérationnelles internes un ensemble de procédures de validation exhaustives et d’indicateurs de progression dont elles pouvaient se servir pour recréer des index de contenu. Ces techniques sont employées à diverses étapes clés au cours du processus de reconstruction global pour assurer sa réalisation en bonne et due forme.

À mesure que l’infrastructure a évolué, nous y avons ajouté d’autres fonctionnalités qui nous permettraient de suivre et de stocker des mesures de débit historiques pour des opérations de reconstruction spécifiques et l’ensemble des opérations à la fois. Le volume progressif des données collectées et les tendances que nous avons pu dégager à partir de ces données ont démontré qu’il nous était possible de réaliser des estimations beaucoup plus avisées et précises sur le temps de réalisation nécessaire à une opération de reconstruction donnée. En tant qu’équipe opérationnelle, cette avancée nous a permis de prendre des décisions plus informées sur le moment opportun pour programmer des reconstructions afin de gêner au minimum notre clientèle d’utilisateurs finaux. Depuis sa mise en place, cette infrastructure a été utilisée pour chapeauter les opérations de reconstruction pour plusieurs milliers d’index de contenu dans divers environnements pris en charge.

Nous parlerons dans une série d’articles de cette « infrastructure de reconstruction » pour permettre aux parties concernées d’appliquer une méthodologie similaire dans leurs propres environnements si le besoin s’en fait sentir. Chaque étape de l’infrastructure sera examinée à la loupe et inclura des débats sur les divers ensembles d’outils que nous avons élaborés pour aider ce processus. Cette série conclura par une série de graphiques et de tableaux détaillant les statistiques que nous avons relevées lors du processus de reconstruction d’index de contenu et les conclusions à en tirer jusqu’ici. Pour les clients qui n’ont jamais recueilli de statistiques dans ce domaine auparavant, nous espérons que nos recherches serviront de point de référence utile. Elles vous offriront sans doute la possibilité de réaliser des estimations plus avisées sur les délais de reconstruction d’index de contenu Exchange dans vos environnements personnels. Cela dit, un point important à retenir est que vos mesures de reconstruction peuvent varier considérablement par rapport aux taux observés et présentés ici puisque tous les environnements Exchange sont uniques.

Avant de plonger tête baissée dans le sujet, il faut également préciser que cette série n’a pas pour vocation d’être un guide de résolution des problèmes. Nous partons du principe que vos propres activités de résolution vous ont amené à la décision de procéder à une ou des reconstructions soit à la suite d’un problème, soit dans le cadre d’une démarche proactive. Tous les exemples présentés dans cette série se concentrent sur Exchange 2007. Pourquoi 2007 ? Parce que la probabilité de reconstruire des index 2007 est bien plus grande qu’avec Exchange 2010 (contrairement à Exchange 2007, la version 2010 a la possibilité de réamorcer des index de contenu à partir de sources redondantes saines, ce qui rend le besoin de procéder à des reconstructions d’index complètes beaucoup moins fréquent dans des architectures à copies multiples). Dans les semaines qui viennent, Anatoly et moi publierons un billet supplémentaire contenant la référence de script pour la version Exchange 2010 du script IndexRebuildAnalyzer à mesure que nous recueillons des exemples ad hoc liés à son utilisation.

Script IndexRebuildAnalyzer

En interne, chez Microsoft, le principal ensemble d’outils auquel nous faisons appel pour recréer des index de contenu est le script IndexRebuildAnalyzer. Anatoly et moi avons créé ce script spécifiquement dans le but de définir des lignes de base pour la reconstruction d’index de contenu. Comme je vous l’ai indiqué avant, il existe deux versions de ce script : une version Exchange 2007 et une version Exchange 2010. Pour calculer correctement vos statistiques, utilisez toujours le script correspondant à la version de la base de données de boîtes aux lettres Exchange dont vous allez recréer l’index. Le script IndexRebuildAnalyzer génère deux types de mesures en fonction du mode opérationnel communiqué par l’opérateur. En interne, nous parlons de « mesures de préreconstruction » et de « mesures de post-reconstruction » pour désigner ces deux modes (l’ensemble des propriétés répertoriées dans la section de référence aux éléments de script disponible plus bas).

Bien que ce script serve principalement à suivre des opérations de reconstruction d’index de contenu, les administrateurs Exchange pourraient sans doute utiliser le script en « mode préreconstruction » pour récolter des statistiques Point-In-Time (PIT) à diverses fins liées aux boîtes aux lettres (par exemple, nombre de boîtes aux lettres, nombre d’éléments dans une base de données, taille de message moyenne pour votre entreprise toute entière, etc.). Cette approche pourrait, par exemple, vous offrir des points de vue et des capacités supplémentaires pour l’analyse des tendances des utilisateurs si vous utilisez l’outil régulièrement en fonction de vos propres impératifs et besoins professionnels.

Les paramètres E2K7_IndexRebuildAnalyzer.ps1 script, de même que les exemples d’utilisation, peuvent être obtenus en transmettant le paramètre -Help dans la session PowerShell avant d’exécuter le script.

Le tableau qui suit décrit chacun des paramètres :

En-têtes des mesures de base de données

Préreconstruction

Comme je l’ai précisé plus haut, le « mode opératoire » du script est déterminé par la présence ou l’absence du commutateur -PostRebuild. Pour obtenir des mesures de préreconstruction, le commutateur -PostRebuild ne doit pas être utilisé. Lorsque vous instanciez le script en mode préreconstruction, les en-têtes suivants s’affichent avec les mesures correspondantes :

Post-reconstruction (utilisation du paramètre -PostRebuild)

Lorsque vous utilisez le commutateur -PostRebuild, IndexRebuildAnalyzer tente de calculer des mesures de débit pour la ou les opérations de reconstruction d’index de contenu. Il s’y prend en analysant le journal des événements des applications pour y rechercher à la fois l’heure de début (signalée par l’ID d’événement 109) et l’heure de fin (ID d’événement 110) pour chaque base de données de boîtes aux lettres sur le serveur de boîtes aux lettres. Pour pouvoir calculer correctement les mesures de post-reconstruction, les deux ID d’événement doivent être présents dans l’Observateur d’événements de chaque base de données de boîtes aux lettres dont l’index de contenu a été redéfini. Si les deux ID d’événement ne sont pas disponibles, le script ne peut pas calculer les statistiques. Dans ce cas précis, c’est la chaîne NoEventsFound qui est renvoyée. Les raisons pour lesquelles cette chaîne est renvoyée sont courantes :

• L’opération de reconstruction d’index de contenu pour une base de données précise ou un ensemble de bases de données n’est pas terminée.
• Le journal des événements des applicationsa dépassé sa taille maximale ou a été vidé (la méthode conseillée est de définir la valeur « Taille maximale du journal » sur la valeur la plus élevée et la plus durable.
• Les index de contenu des bases de données de boîtes aux lettres qui affichent le message NoEventsFound n’ont pas récemment été redéfinis (d’où l’absence des deux ID d’événement dans le journal des événements). Avec l’option -CSVFile et l’aide d’Excel, ces chaînes peuvent être facilement filtrées et extraites des résultats. J’aborderai ce sujet et fournirai des exemples de filtrage à l’étape 5 de l’infrastructure.

Tous les en-têtes et mesures de « préreconstruction » sont également calculés lorsque vous transmettez le commutateur -PostRebuild pour exécuter le script. L’utilisation du commutateur -PostRebuild inclut l’ajout des en-têtes et mesures suivants :

Conclusion

Vous pouvez télécharger le script IndexRebuildAnalyzer Exchange 2007 ici.

Dans la deuxième partie de cette série, je parlerai de l’infrastructure de reconstruction de recherche, puis dans la troisième et dernière partie, j’évoquerai ce que nous avons observé jusqu’ici 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 1