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

Artigo
07/23/2012

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 :

Paramètre	Obligatoire	Description
-CMS </cluster1,cluster2>	Obligatoire	Lorsque vous utilisez le paramètre -CMS, les statistiques de toutes les bases de données dans un serveur de boîtes aux lettres Exchange ou un serveur de boîtes aux lettres en cluster Exchange sont calculées. Les statistiques des bases de données dans plusieurs serveurs de boîtes aux lettres ou serveurs de boîtes aux lettres en cluster autonomes peuvent être calculées en séparant les noms des serveurs par des virgules.
-Database <nom_base_de_données,nom_base_de_données>	Obligatoire	Lorsque vous utilisez le paramètre -Database, les statistiques d’une base de données de boîtes aux lettres spécifique peuvent être calculées. Son utilisation implique que le nom de la base de données soit transmis dans le format suivant : “nom_serveur_de_ boîte_aux_lettres\nom_groupe_de_stockageStorageGroupName\nom_base_de_données” Les statistiques de plusieurs bases de données peuvent être calculées en séparant les noms des bases de données par des virgules. Les bases de données qui ne contiennent aucune boîte aux lettres utilisateur active ne seront pas traitées.
-All	Facultatif	Le commutateur -All calcule les statistiques de l’ensemble des bases de données de boîtes aux lettres dans l’organisation Exchange.
-CSVFile	Facultatif	Le paramètre -CSVFile génère toutes les mesures dans un fichier CSV.
-PostRebuild	Facultatif	Le commutateur -PostRebuild permet de distinguer les modes d’exécution du script. Plus précisément, lorsque vous appelez le commutateur -PostRebuild, le script analyse les journaux d’événements des applications et tente de calculer les mesures de performance pour les opérations de reconstruction d’index.
-Help	Facultatif	Affiche l’aide du script.

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 :

En-tête	Description
Serveur	Identité du serveur de boîtes aux lettres affiliée à la base de données traitée.
Base de données	Nom d’affichage de la base de données de boîtes aux lettres traitée.
Taille de fichier EDB (Go)	Taille (en gigaoctets) du fichier de base de données correspondant sur le disque.
Taille de fichier EDB (Mo)	Taille (en mégaoctets) du fichier de base de données correspondant sur le disque.
Nombre de boîtes aux lettres	Nombre de boîtes aux lettres Exchange actives pour la base de données traitée. Les boîtes aux lettres déconnectées ne sont pas traitées.
Base de données : Nombre total d’éléments	Nombre total d’éléments de messagerie présents dans une base de données de boîtes aux lettres Exchange.
Base de données : Taille totale des éléments (Mo)	Taille totale (en mégaoctets) de tous les éléments de messagerie présents dans la base de données de boîtes aux lettres traitée.
Base de données : Taille moyenne des messages (Mo)	Taille moyenne des messages pour tous les éléments de messagerie présents dans la base de données traitée.
Taille moyenne de boîte aux lettres par utilisateur (Mo)	Taille moyenne des boîtes aux lettres actives dans la base de données traitée.
Nombre moyen de boîtes aux lettres par utilisateur	Nombre moyen d’éléments de messagerie pour les boîtes aux lettres actives présentes dans la base de données traitée.

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 :

En-tête	Description
Heure de début de reconstruction d’index de contenu	Heure à laquelle le service Microsoft Exchange Search Indexer démarre l’analyse complète de la base de données de boîtes aux lettres.
Heure de fin de reconstruction d’index de contenu	Heure de fin à laquelle le service Microsoft Exchange Search Indexer termine l’analyse complète de la base de données de boîtes aux lettres.
Temps total de reconstruction : h:min:sec	Temps total (en heures:minutes:secondes) requis par le service Search Indexer pour procéder à une analyse complète de la base de données de boîtes aux lettres.
Temps total de reconstruction : minutes	Temps total (en minutes) requis par le service Search Indexerpour procéder à une analyse complète.
Temps total de reconstruction : secondes	Temps total (en secondes) requis par le service Search Indexer pour procéder à une analyse complète.
Temps moyen de reconstruction par BAL : sec.	Temps total (en secondes) pour réaliser une analyse complète par boîte aux lettres.
Reconstruction : Mo/sec.	Moyennes de débit (en mégaoctets par seconde) pour une analyse complète avec le service Search Indexer.
Reconstruction : éléments/sec.	Débit (en éléments de messagerie par seconde) pour une analyse complète avec le service Search Indexer.

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

Compartilhar via