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

Article d’origine publié le lundi 2 juillet 2012

Dans la Partie 1 de cette série de billets, j’ai expliqué le script E2K7_IndexRebuildAnalyzer.ps1 et dans la Partie 2, j’ai présenté l’infrastructure de récréation de recherche qu’Anatoly Girko et moi-même avons développée. Avant de conclure ce billet, je tiens à vous montrer une série de graphiques, ainsi qu’un tableau des « moyennes observées », pour illustrer les caractéristiques de recréation que nous avons observées depuis la mise en place de l’infrastructure. J’espère qu’ils vous aideront à bien comprendre ce concept et à améliorer vos estimations lors du calcul de vos propres taux de reconstruction.

Moyennes observées à ce jour chez Microsoft

Anatoly et moi avons longuement réfléchi sur le meilleur moyen de vous présenter ce qui suit et, comme vous pouvez l’imaginer, il existe un nombre infini de possibilités de présentation. Nous avons décidé de définir les graphiques et le tableau selon une taille de message que la plupart des architectes de stockage Exchange utilisent dans leur travail : 150 Ko par élément de messagerie. Nous avons ensuite appliqué un deuxième filtre au nombre de boîtes aux lettres et avons uniquement tenu compte des bases de données de boîtes aux lettres incluses dans nos ensembles de données et dotées au minimum de 100 boîtes aux lettres actives pour parvenir aux moyennes énoncées ci-dessous. Ceci fait, nous avons retiré de notre ensemble les 10 % d’opérations de reconstruction les plus performantes et les 10 % de celles avec la performance la plus médiocre dans le but d’extraire les moyennes employées pour créer les graphiques et les tableaux.

Remarque : dans les différents graphiques et le tableau qui suivent, les tailles moyennes des boîtes aux lettres en plusieurs incréments de plages sont visiblement manquantes. Ces données n’ont été ni oubliées, ni volontairement omises. L’absence de données statistiques pour ces plages est lié au fait qu’il n’existe aucune donnée valide dans les données historiques que nous avons collectées. En d’autres termes, nous n’avons jamais réalisé d’opérations de reconstruction d’index de contenu et/ou recueilli des mesures de post-reconstruction pour les bases de données dont les tailles moyennes des boîtes aux lettres des utilisateurs finaux figuraient dans les plages suivantes :

• 1700 à 1799 Mo
• 1800 à 1899 Mo
• 2000 à 2099 Mo
• 2100 à 2199 Mo

Graphiques

Nous allons vous présenter quatre graphiques croisés dynamiques Excel qui reflètent les caractéristiques de débit que nous avons observées jusqu’ici en nous basant sur l’ensemble filtré décrit plus haut. Ces graphiques croisés dynamiques ont pout but d’illustrer la relation qui existe entre les diverses propriétés à mesure qu’elles surviennent à l’intérieur ou à proximité de la banque de boîtes aux lettres (il peut s’agir, par exemple, du nombre de boîtes aux lettres, du nombre d’éléments et de la taille des fichiers EDB), puis de les comparer avec les délais d’exécution historiques requis pour réaliser des analyses complètes dans des banques de boîtes aux lettres dotées des mêmes caractéristiques.

Graphique 1

La vue présentée dans le graphique 1 décrit précisément la relation entre les nombres de boîtes aux lettres par base de données, la taille relative des bases de données de boîtes aux lettres en gigaoctets et tout l’impact de ceci au final sur le temps total nécessaire à la reconstruction des index de contenu des banques de boîtes aux lettres en quelques minutes.

Ce graphique montre clairement un parallélisme tendanciel entre l’accroissement du nombre total de boîtes aux lettres actives dans une base de données de boîtes aux lettres Exchange et une augmentation de la taille des fichiers EDB dans le sous-système de stockage. Ce parallélisme a, à son tour, un impact sur le temps total d’une analyse complète d’un index de contenu. C’est une manière très élégante de faire passer le message suivant : plus le nombre de boîtes aux lettres actives est important, plus le nombre d’éléments de messagerie l’est également ; plus il y a d’éléments de messagerie, plus la taille des fichiers EDB sur le disque grossit ; plus la taille des fichiers EDB sur disque grossit, plus long « généralement » sera le temps requis pour recréer un index de contenu. La seule situation pour laquelle cette hypothèse ne vaut pas est dans le cas d’une base de données de boîtes aux lettres dont la quantité d’espace blanc dans le fichier est trop importante. Dans ce cas précis, le temps global nécessaire à la reconstruction d’un index de contenu sera sensiblement plus réduit que prévu. Cette anomalie a été observée dans les environnements que nous prenons en charge mais les statistiques obtenues ont été supprimées de notre ensemble à l’aide de la technique de filtrage évoquée plus haut.

Graphique 2

Le graphique 2 décrit la relation existante entre la taille moyenne des boîtes aux lettres (c’est-à-dire les boîtes aux lettres qui figurent dans des bases de données incluses dans le même jeu d’échantillons filtré) et son impact sur le délai d’exécution du processus de reconstruction d’index de contenu au niveau de la base de données de boîtes aux lettres, en secondes par boîte aux lettres.

Ce graphique confirme essentiellement l’argument présenté dans le graphique 1 même si c’est au niveau de la boîte aux lettres active. Il démontre surtout qu’à mesure que les tailles moyennes des boîtes aux lettres actives augmentent, le nombre moyen d’éléments de messagerie présents dans celles-ci augmente aussi. En moyenne donc, plus une boîte aux lettres contient d’éléments de messagerie, plus le service Search Indexer mettra du temps à analyser complètement une boîte aux lettres et ce phénomène aura lui-même un impact sur le temps requis pour une analyse complète dans l’ensemble des boîtes aux lettres au sein de la base de données.

Graphique 3

Le graphique 3 décrit la relation existante entre la taille moyenne des boîtes aux lettres (c’est-à-dire les boîtes aux lettres qui figurent dans des bases de données incluses dans le même jeu d’échantillons filtré) et son impact sur le délai d’exécution du processus de reconstruction d’index de contenu en mégaoctets par seconde.

Le graphique 3 est fondé sur l’hypothèse de départ évoquée dans le graphique 2. Il montre plus particulièrement qu’avec l’augmentation progressive de la taille moyenne des boîtes aux lettres et du nombre moyen d’éléments dans une base de données de boîtes aux lettres, il existe une relation négative par rapport au débit du service Search Indexer. Le graphique 3 définit cette relation en mégaoctets par seconde.

Graphique 4

Le graphique 4 décrit la relation existante entre la taille moyenne des boîtes aux lettres (c’est-à-dire les boîtes aux lettres qui figurent dans des bases de données incluses dans le même jeu d’échantillons filtré) et son impact sur le délai d’exécution du processus de reconstruction d’index de contenu en éléments par seconde ( sur la base de la taille moyenne des messages, soit 150 Ko)  :

Comme dans le graphique 3, le graphique 4 montre l’impact négatif en termes de performance par rapport au délai d’exécution en éléments par seconde.

Tableau des moyennes observées

Pour présenter le tableau, nous avons eu recours au même jeu d’échantillons filtré (décrit et présenté plus haut dans les graphiques) mais avons choisi de créer des moyennes ciblées en fonction de la taille moyenne des boîtes aux lettres. Nous avons ensuite divisé ces lignes par incréments de 99 mégaoctets pour créer des lignes individuelles. Le débit indiqué pour chaque ligne représente les moyennes agrégées pour toutes les bases de données de taille similaire qui ont été soumises à des opérations de reconstruction réalisées dans notre ensemble. Pour être plus précis, là où la taille moyenne des messages était de 15 Ko et où la taille moyenne de toutes les boîtes aux lettres actives dans ces bases de données figurait dans les plages définies dans la colonne A.

Les moyennes historiques dévoilées dans ce tableau présentent (à mon sens) trois moyens possibles d’estimer les temps nécessaires à la reconstruction d’index de contenu :

• Une « moyenne historique » peut être mise en place sur la base de la taille moyenne des boîtes aux lettres dans lesquelles la taille de message moyenne des éléments résidant dans ces boîtes aux lettres est de 150 Ko.Du fait de la quantité considérable de données de reconstruction historiques dont nous disposons dans notre ensemble, nous avons choisi d’exploiter cette moyenne. Pour obtenir notre estimation, il nous faut déterminer la valeur de la taille moyenne des boîtes aux lettres au moyen de mesures de « préreconstruction », puis comparer tout cela à la moyenne historique. Reste ensuite à prendre la moyenne composite de la colonne Reconstruction : secondes par BALet à multiplier ce chiffre par le nombre de boîtes aux lettres dans la base de données qui nécessitent une analyse pour déterminer le temps total d’exécution nécessaire.
• Une « moyenne organisationnelle » peut également être établie d’après la taille moyenne des messagessans tenir compte du nombre d’éléments et de la taille moyenne des boîtes aux lettres dans l’ensemble de l’organisation (cette moyenne organisationnelle est précisée sur la ligne Moyennes dans le tableau ci-dessus).
• Une moyenne composite entre la moyenne historique et la moyenne organisationnelle.

Par exemple, si je dispose d’un index de contenu à reconstruire pour une base de données dont les utilisateurs disposent d’une taille moyenne de boîte aux lettres agrégée dans une plage de 500 à 599 Mo et si la taille moyenne des messages est de 150 Ko, je peux obtenir une estimation de trois manières possibles si cette base de données affiche un nombre de 200 utilisateurs :

Tableau des moyennes historiques :

200 boîtes aux lettres * 63 secondes = 12 600 secondes au total. Ceci équivaut à 210 minutes ou à environ 3,5 heures requises pour l’analyse complète.

Moyenne organisationnelle :

200 boîtes aux lettres * 108 secondes = 21 600 secondes au total. Ceci équivaut à 360 minutes ou à environ 6,0 heures requises pour l’analyse complète.

Moyenne composite (moyenne historique + moyenne organisationnelle) :

3,5 + 6,0 = 9,5 heures

9,5 / 2 = 4,75 heures

Conclusion

Le temps total nécessaire à la reconstruction d’un index de contenu est toujours variable puisque le contenu des messages et les éléments à cet égard varient aussi en permanence. Lors de la reconstruction d’index de contenu, les estimations les plus précises et les plus solides sont toujours obtenues en exploitant les moyennes historiques. Je voulais aussi souligner que lorsque nous prenons la décision de reconstruire des index de contenu en interne chez MSFT, nous faisons de notre mieux pour les planifier avec des intervalles de temps avec un « impact utilisateur minime ». Cependant, les structures que nous mettons en place sont mondiales et il est plus ou moins impossible d’éliminer radicalement tout risque d’impact sur les utilisateurs finaux. Le mieux que l’on puisse espérer est de réduire l’impact sur la surface exposée. Qui plus est, dans les données que nous collectons, nous ne tenons pas compte des délais de limitation du service Microsoft Exchange Search Indexer. Les délais qui limitent le processus de reconstruction du service Search Indexer sont, en tout ou partie, gérés et maîtrisés à l’instant T et ont une valeur représentative dans les tickets individuels qui parviennent à l’équipe des opérations. En exploitant les techniques de filtrage employées tout au long de ce billet, vous isolez vos chiffres de ces moyennes négatives (la même chose vaut pour les opérations de reconstruction à débit excessif) et améliorez considérablement la précision de vos estimations globales.

Si vous avez une propension à parier sur les moyennes, pour ma part, je préfère m’en tenir à notre tableau. Si le recours à une méthode scientifique plus exacte est nécessaire, je suggère de mettre en place une infrastructure semblable à celle que nous avons détaillée dans cette série de billets.

Nous espérons que cette série vous aura été utile (et plus encore) et que vous aurez le sentiment d’avoir appris quelque chose de nouveau !

Bonne continuation !

Eric Norberg
Ingénieur
Équipe Office 365

Ce billet de blog a été traduit de l’anglais. La version originale est disponible à la page Establishing Exchange Content Index Rebuild Baselines – Part 3