Toujours une article du oiPro sur AD
Diagnostiquer les problèmes de performance d’AD
Par Gil Kirkpatrick. Mise en ligne : 28 Mai 2008, Publication : Fevrier 2007
Tôt ou tard, ça devait arriver : la performance de votre AD (Active
Directory) s’est brusquement dégradée sans raison
apparente. La semaine dernière encore, tout se passait bien ;
mais cette semaine vous avez reçu cinq ou six doléances
à propos de logons léthargiques, d’échecs
des consultations du carnet d’adresses Microsoft Exchange Server,
et de lents démarrages d’applications.
En appliquant
Performance Monitor à chacun de vos DC (domain controller), vous
constatez que, sur l’un d’eux, l’utilisation de la
CPU est bloquée à 100 % la plupart du temps. Pourtant
rien n’a changé et tout le reste semble fonctionner
correctement. Alors que faire ?
Heureusement il existe Windows Server 2003 Performance Advisor (SPA). C’est un utilitaire d’analyse de performances
aussi efficace qu’inconnu, que Microsoft propose depuis plus de
deux ans. Il automatise la collecte des données de
configuration, de ETW (Event Tracing for Windows) et du compteur de
performances provenant d’un ou plusieurs serveurs, passe à
la moulinette la masse de données ainsi obtenue et en tire des
rapports de performances d’une grande clarté, avec des
alertes et des recommandations sur la manière de redresser la
situation. SPA est livré avec des collecteurs de données
prédéfinis et des règles de performances pour des
serveurs de fichiers génériques, des DC AD, des serveurs
DNS et des serveurs utilisant Microsoft Internet Information Service
(IIS).
SPA n’est pas livré avec l’image Windows : vous devez le télécharger. Ensuite, téléchargez et installez .NET Framework Service Pack 1 (SP1) pour Windows Server 2003. Finalement,
Etape 1 : Télécharger et installer SPA
Il s’agit bien de télécharger la version la plus
récente et pas l’ancien serveur Performance Advisor 1.0.
Le fichier d’installation est spa_v2_msi.
L’exécution de SPA sur un serveur très actif, comme
un DC, peut générer beaucoup de données. Il faut
donc avoir plusieurs giga-octets d’espace disque libres pour le
dossier de stockage. L’idéal serait de placer le dossier
en question sur son propre axe disque, afin que
l’exécution de SPA ait un minimum d’impact sur les
performances. Il est facile d’installer SPA sur Windows 32 bits.
Exécutez le package Windows Installer que vous avez
téléchargé, acceptez le contrat de licence
d’utilisateur final (EULA, End-User License Agreement), acceptez
les valeurs par défaut proposées pour
l’installation, le stockage des données et les dossiers de
rapports, et vous pouvez vous lancer. L’installation de SPA sur
des versions 64 bits de Windows est un peu plus compliquée. SPA
requiert la version 1.1 de Microsoft .NET Framework, mais elle
n’existe pas pour des platesformes 64 bits. Vous pouvez toutefois
utiliser la version 32 bits du .NET Framework sur votre serveur 64 bits
et SPA fonctionnera bien. Faites simplement ceci :
téléchargez et installez le package redistribuable de .NET Framework version 1.1
installez SPA. Donc, l’Installer copie les exécutables et
crée les répertoires SPA. En plus, il crée
plusieurs tâches chargées de collecter
régulièrement des données de performances. Vous
pouvez voir ces tâches en cliquant sur l’icône
Schedule Tasks dans le Control Panel. Les tâches
créées par SPA sont en sommeil : elles sont
créées mais le moment de leur exécution
n’est pas prévu. Quand vous utilisez le client SPA pour
démarrer une connexion, le client planifie simplement la
tâche à exécuter. C’est un
procédé inhabituel, mais plus simple que la
création d’un service Windows, et tout aussi efficace.
Etape 2 : Exécuter SPA
Vous pouvez lancer le client SPA en cliquant sur Start, All Programs,
Server Performance Advisor. Le client SPA présente une UI
difficile à scruter au démarrage, cachant initialement la
hiérarchie de navigation. Pour exposer cette hiérarchie,
sélectionnez Scope Tree dans le menu View ou cliquez sur
l’icône document dans la bande grise sur le
côté gauche de la fenêtre.
Le
client SPA utilise la présentation classique de Microsoft
Management Console (MMC), avec la hiérarchie de navigation dans
le panneau de gauche et les données dans le panneau de droite.
Les noeuds Trace Providers et Performance Counters sont utiles pour
composer de nouveaux genres de collectes SPA. Mais c’est dans le
noeud Data Collectors and Reports que se trouve le contenu
intéressant.
SPA recueille les données de
performance à partir d’un serveur, à l’aide
d’un ensemble de collecteurs. On en distingue quatre types :
performance counter collectors, registry settings collectors, trace
collectors et kernel trace collectors. SPA organise les collecteurs de
données en data collector groups, dont chacun cible les
données de performance d’un système particulier,
comme IIS ou AD. SPA est livré avec environ 90 groupes de
collecteurs prédéfinis. Le processus d’installation
détecte pour quel(s) rôle(s) votre serveur est
configuré et ajoute un ou plusieurs des huit groupes de
données suivants, en fonction de ces rôles :
• Active Directory
• Active Directory/Application Mode (ADAM)
• DNS Server
• DNS Server Extended
• File
• ISS
• Print Spooler
• System Overview
SPA
valide les groupes de collecteurs appropriés à
l’installation et les affiche sous le noeud Data Collectors and
Reports dans le Scope Tree. Ainsi, par exemple, quand vous installez
SPA sur un DC, le groupe de collecteurs Active Directory
s’affichera. Vous pouvez activer ou désactiver des groupes
de collecteurs individuels à partir du client SPA en cliquant
sur File, Add/Repair Data Collector Groups, Server Roles.
SPA
est également livré avec des groupes de collecteurs
spécialisés que vous pouvez utiliser et modifier à
votre gré. Vous pouvez valider ces groupes de collecteurs en
cliquant sur File, Add/Repair Data Collector Groups et en choisissant
un groupe dans le menu.
J’ai installé un DC nommé DC2 sous Windows 2003 Pour lancer une collecte, démarrez simplement le client Par défaut, les
Etape 3 : Effectuer une collecte
SP1, en même temps que plusieurs machines client, pour
générer un chargement de test en utilisant le Active Directory Performance Testing Tool.
J’ai modifié les scripts AD Test pour
générer un mélange de trafic
d’authentification et de recherches LDAP plutôt mal
conçues et j’ai exécuté le script. Pour les
besoins pratiques, le DC a stoppé net. Pour voir l’analyse
de SPA de la charge sur le DC, j’ai effectué une collecte.
SPA, ouvrez le Scope Tree, sélectionnez le groupe de collecteurs
que vous voulez exécuter (ici, le groupe de collecteurs Active
Directory) et choisissez Start dans le menu Record (ou appuyez sur F9,
ou cliquez sur la flèche d’enregistrement verte sur la
barre d’outils). SPA planifie l’exécution
immédiate des tâches de collecte de données en
sommeil et affiche plusieurs icônes de collecte de données
en cours qui représentent les collecteurs de données
actuellement actifs. D’emblée, le groupe de collecteurs
Active Directory a quatre tâches de collecte, avec une
icône pour chacune : performance counter, registry, Active
Directory ETW et Kernel ETW.
collecteurs déversent leurs données brutes dans le
dossier C:\PerfLogs\Data\collector group name\Current. Au terme de la
collecte, SPA déplace les fichiers de données brutes dans
un répertoire de transfert puis exécute le programme
SPARPT, qui passe à la moulinette les données brutes et
produit un rapport XML. SPA stocke le rapport dans le répertoire
Reports dans un dossier libellé d’après le nom du
serveur et la date et l’heure de la collecte de données
(par exemple, C:\PerfLogs\Reports\Active Directory\DC2_200607051641)
Etape 4 : Examiner le rapport
Performance Monitor peut collecter, en grande partie, les mêmes
données que SPA. Mais ce dernier se distingue par son aisance
à résumer et à présenter des centaines de
méga-octets de données dans des rapports simples et
clairs. SPA présente les données de performance sous la
forme d’une page HTML unique et parfois très grande.
Le
client SPA organise les rapports de performances par groupes de
collecteurs de données. Pour examiner les rapports de
performances pour un groupe de collecteurs, ouvrez le noeud Reports
sous le groupe en question et sélectionnez Current. SPA affiche
les rapports disponibles dans le panneau de données à
droite, organisés d’abord par nom de machine puis par
année, mois, jour et heure. Pour visualiser un rapport, cliquez
pour ouvrir la machine ; cliquez pour ouvrir l’année ;
cliquez pour ouvrir le mois, et cliquez pour ouvrir le jour. Enfin,
cliquez sur le rapport particulier que vous souhaitez examiner : SPA le
présente dans le panneau de données.
Pour
faciliter la navigation, une table des matières au début
du rapport fournit des hyperliens conduisant aux sections du rapport :
la section Performance Advice, plusieurs sections de données de
performance spécifiques à l’AD, et des sections
détaillées concernant l’utilisation de la CPU, du
réseau, du disque et de la mémoire. Le rapport se termine
par quelques paramètres de réglage du système
provenant du registre et quelques informations générales
de configuration du système et de collecte des données.
Voyons quelques-unes des sections du rapport. Summary. Je
suggère d’examiner en premier la section Summary,
qu’illustre la figure 1. Elle contient les informations suivantes
:
• CPU Usage (%) : la charge de la CPU pendant la période de collecte
• Top Process Group : le processus responsable du plus grand bloc de cette charge (sur un DC, ce devrait être LSASS)
• Top Activity : l’opération la plus gourmande en CPU effectuée par ce processus
• Top Client : l’adresse IP du client ayant utilisé le plus la CPU
• Top Disk by IO Rate : le lecteur de disques le plus sollicité
SPA
peut montrer l’opération client et AD spécifique qui a
généré la plus forte charge de CPU et d’I/O
disque pendant la période de collecte. Ce renseignement suffit
souvent pour déterminer la cause du problème de
performance d’un DC. Quand vous cliquez sur une rubrique de
Summary, SPA vous dirige vers le détail approprié dans le
rapport.
Ensuite, cliquez sur le hotlink Warnings dans la section Performance Dans notre cas, nous avons trois avertissements, présentés dans la figure 2 :
Avertissements sur la performance
Advice de la table des matières pour obtenir des détails
sur les conditions de transgression des règles d’alerte de
performance. SPA fournit 17 règles d’alerte
spécifiques à l’AD plus 17 règles
d’alerte générales qui s’appliquent à
tous les rôles du serveur. Vous pouvez configurer chaque
règle en sélectionnant Rules dans le menu Edit.
• Le principal (top) client consomme 24,74 % de la CPU disponible : c’est beaucoup pour un seul client.
•
La longueur de la file d’attente de sortie du NIC du DC est
à 12, alors que la normale serait de 1 ou 2. La longue file
d’attente indique que le DC envoie beaucoup de données
vers l’extérieur sur le NIC.
• Les recherches
LDAP du client utilisent l’index ancestors. AD utilise
l’index ancestors pour faire une recherche sur un attribut non
indexé. Dans ce cas, AD doit lire et inspecter chaque objet
présent dans le conteneur. L’usage de l’index
ancestors peut indiquer une requête mal conçue ou la
nécessité de créer un nouvel index dans
l’AD.
Section Directory Search
Quand vous cliquez sur le hotlink dans la colonne Item d’un
warning, SPA affiche la section du rapport qui décrit
l’avertissement en question. Un tel clic pour le premier warning
de la figure 2 affiche la section Directory Search du rapport,
illustrée dans la figure 3. La table Clients with the Most CPU
Usage affiche une liste des adresses IP client et d’informations
sur la performance de recherche de clients. La table Unique Search
montre que les recherches générées par le client
à 10.70.0.131 utilisent une énorme quantité de
CPU. Dans la première ligne de cette table, l’indicateur
dans la colonne Index correspond à l’avertissement de
performance de la figure 2 et il vous indique que le client à
10.7.0.131 utilise 24,74 % de la CPU.
Si
vous cliquez sur le signe plus à gauche de l’adresse IP
d’un client dans la table Clients with the Most CPU Usage, vous
obtenez plus de détails sur toutes les recherches
attribuées à ce client, en même temps que les
paramètres de recherche et d’autres informations
liées à la recherche, comme le montre la figure 4. Chaque
ligne représente une ou plusieurs opérations de recherche
qui ont la même base de recherche LDAP, domaine, filtre et code
résultat. La notation Top: 3 de 7 dans la barre de titre de la
table indique que SPA ne montre que les trois premières
recherches LDAP. Pour voir d’autres entrées, cliquez sur
le 3 et tapez un autre nombre. Pour trier les données par
valeurs dans une colonne particulière, cliquez sur
l’en-tête de colonne. La plupart des tables du rapport SPA
se comportent ainsi.
La colonne Index montre l’index que
l’AD a utilisé dans sa recherche. Dans la recherche la
plus volumineuse, portant sur le schéma naming context (NC), le
filtre de recherche cn=*a* spécifie une recherche medial-string
(c’est-à-dire une recherche munie d’un filtre
contenant un joker qui n’est pas à la fin de la
chaîne) sur l’attribut Common Name (CN). L’attribut
CN est indexé par défaut dans AD, mais pas pour les
recherches medial-string, donc AD doit lire tous les objets
présents dans le schéma NC pour déterminer
s’il correspond au filtre.
En examinant les autres
recherches effectuées par ce client, vous verrez qu’elles
font la même chose que la recherche de schéma : elles
effectuent des recherches médiales dans la sous-arborescence sur
l’attribut CN, amenant l’AD à utiliser soit
l’index ancestors, soit l’index distinguished name tag
(dnt_index), dont aucun des deux n’est bon pour la performance.
Face à un grand nombre de recherches qui utilisent l’index
ancestors ou dnt_index, vous devez soit modifier le filtre de recherche
pour bénéficier des index qui existent déjà
dans l’AD, soit créer de nouveaux index. Par exemple, si
vous déterminez que cn=*a* est un filtre de recherche
légitime qu’il faut optimiser, vous pouvez ajouter un
index medial search sur l’attribut CN.
Ajouter un index à l’AD est simple, comme l’explique l’article Microsoft « Index an attribute in Active Directory
». Sachez que chaque index consomme de l’espace disque
supplémentaire et allongera les opérations de mise
à jour. Si vous avez déjà un grand Directory
Information Tree (DIT), cet espace disque supplémentaire
pourrait être substantiel. De plus, tous les objets
présents dans l’AD seront indexés, et pas
simplement ceux qui se trouvent dans un conteneur ou NC ; donc,
réfléchissez à l’influence d’un nouvel
index sur la performance et testez-le soigneusement avant de
procéder au changement.
Nous avons expliqué deux
des trois avertissements de performance avec lesquels nous avons
commencé. Voyons maintenant la longue file d’attente de
sortie du troisième NIC.
Revenez à la section Warnings en haut du rapport et cliquez sur La Mais alors pourquoi la file d’attente de sortie est-elle si longue ? On peut avancer plusieurs hypothèses : Bien
Section NIC performance counters
le hotlink pour le NIC output queue length warning. SPA va naviguer
jusqu’à la table Network Interface performance counter,
que montre la figure 5. En promenant le curseur sur l’indicateur
qui apparaît dans la colonne Mean sur le Output Queue Length
counter, on affiche une description de l’avertissement de
performance.
figure 5 contient plusieurs valeurs intéressantes. Le compteur
Current Bandwidth montre 100 mégabits, indiquant que le NIC
10/100 fonctionne en fait à 100 Mbps. Le compteur Bytes
Total/sec est à 3,6 Mbps, soit bien en dessous de la
capacité du réseau. (Je sais que sur le serveur qui a
produit ce rapport, tout le trafic du réseau sur le segment
allait vers le DC ou en venait.) Enfin, nous voyons que Bytes Sent/sec
représente la quasi-totalité du trafic. C’est
logique, compte tenu que les recherches LDSP extraient beaucoup de
données.
• Le NIC a atteint sa capacité maximale, ou s’en approche.
• Il y a trop peu de tampons de sortie configurés pour le NIC.
•
Le traitement des files d’attente de sortie est lent, tout
simplement parce que la CPU n’est pas assez puissante.
que, selon le rapport, le débit total moyen sur le NIC soit de
3,6 Mbps, il a connu une pointe à 10,8 Mbps, qui dépasse
le maximum théorique de 100 Mbps (environ 10 Mbps). Il semble
donc que le NIC soit parfois surchargé, ce qui laisse supposer
que d’autres composants sur le segment du réseau
pourraient l’être eux aussi. Comme la CPU est près
de son maximum, il ne servirait probablement à rien
d’ajouter un autre NIC. Il faudrait pousser l’analyse plus
loin pour parvenir à une réponse définitive, mais
le plus sage est probablement de réduire la charge sur le
serveur en optimisant les requêtes (ou en ajoutant un index) et,
si nécessaire, soit en passant à une CPU plus rapide,
soit en ajoutant un autre DC et en répartissant la charge de
requête.
Requêtes LDAP
Il reste
une autre anomalie à éclaircir. Dans la section Summary
de la figure 1, si vous cliquez sur le hotlink Top Client, SPA affiche
la sous-section Clients with the Most CPU Usage de la section LDAP
Request du rapport. A l’évidence, le client à
10.7.0.131 est le coupable numéro un.
Si
vous étendez l’entrée de cette adresse IP, SPA
affiche un résumé des opérations que le client a
effectuées et le pourcentage de ressources CPU consommées
par chacune d’elles, comme le montre la figure 6. Nous voyons que
le client à 10.7.0.131 a utilisé la plus grande partie de
la CPU en émettant des recherches nonDSE
(c’est-à-dire des recherches d’une certaine partie
de l’arbre des répertoires). Cet usage est dans la ligne
de ce que nous avons découvert précédemment.
Mais,
ce qui est plus surprenant, c’est la deuxième ligne dans
le résumé de l’opération, qui montre qu’un
nombre significatif de recherches du client a échoué avec
une erreur Size Limit Exceeded. Ces échecs de recherche ont
représenté une autre tranche de 12 % d’utilisation
de la CPU. Par conséquent, SPA a contribué à
dévoiler au moins un autre problème avec ce client : il
n’utilise pas des recherches pagées. La non-utilisation de
recherches pagées est une erreur de programmation applicative
courante à cause de laquelle l’AD risque de ne pas
renvoyer toutes les données que l’application recherche.
Nous Et
Qu’avons-nous réalisé ?
avons commencé avec un DC surchargé et, après avoir appliqué le groupe
de collecteurs de données SPA Active Directory sur le DC et avoir
généré un rapport, nous avons trouvé trois raisons aux problèmes de
performances :
• Les clients émettent des requêtes de recherche médiale sur un attribut non indexé pour des recherches médiales
• Les clients n’utilisent pas des recherches pagées
• Le NIC est surchargé.
peut-être aussi d’autres composants du système ou du réseau. Pas mal
pour 15 minutes de travail ! Vous pouvez aussi utiliser SPA pour
collecter et archiver des données de performance selon un certain
calendrier, pour générer des données ligne de base. Dans un prochain
article, nous verrons comment SPA peut collecter des données provenant
de multiples serveurs et comment générer les rapports sur un serveur de
reporting centralisé.