Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
Voici un résumé des principales recommandations et considérations relatives à l’optimisation du matériel serveur pour les charges de travail Active Directory couvertes plus en détail dans l’article Planification de la capacité pour les services de domaine Active Directory . Les lecteurs sont vivement encouragés à examiner la planification de la capacité des services de domaine Active Directory pour une meilleure compréhension technique et des implications de ces recommandations.
Éviter d’accéder au disque
Active Directory met en cache autant de la base de données que la mémoire permet. L’extraction de pages à partir de la mémoire est des ordres de grandeur plus rapides que l’accès au support physique, que le média soit basé sur un disque spindle ou SSD. Ajoutez plus de mémoire pour réduire les E/S de disque.
Les meilleures pratiques d’Active Directory recommandent de placer suffisamment de RAM pour charger l’ensemble de l’unité d’accès réseau en mémoire, ainsi que de prendre en charge le système d’exploitation et d’autres applications installées, telles que les antivirus, les logiciels de sauvegarde, la surveillance, etc.
Pour connaître les limitations des plateformes héritées, consultez le processus d’utilisation de la mémoire par le processus de Lsass.exe sur les contrôleurs de domaine exécutant Windows Server 2003 ou Windows 2000 Server.
Utilisez un compteur de performances Mémoire\Durée de vie moyenne du cache de secours à long terme (s) > 30 minutes.
Placez le système d’exploitation, les journaux et la base de données sur des volumes distincts. Si la totalité ou la majorité des DIT peuvent être mises en cache, une fois que le cache est réchauffé et sous un état stable, cela devient moins pertinent et offre un peu plus de flexibilité dans la disposition du stockage. Dans les scénarios où l’ensemble de la DIT ne peut pas être mis en cache, l’importance de fractionner le système d’exploitation, les journaux et la base de données sur des volumes distincts devient plus importante.
Normalement, les ratios d’E/S par rapport au DIT sont d’environ 90 % en lecture et 10 % en écriture. Les scénarios où les volumes d’E/S d’écriture dépassent considérablement 10 à 20 % sont considérés comme des volumes à écriture intensive. Les scénarios lourds en écriture ne bénéficient pas considérablement du cache Active Directory. Pour garantir la durabilité transactionnelle des données écrites dans l’annuaire, Active Directory n’effectue pas de mise en cache d’écriture de disque. Au lieu de cela, il valide toutes les opérations d’écriture sur le disque avant de retourner un état d’achèvement réussi pour une opération, sauf s’il existe une demande explicite à ne pas effectuer cette opération. Par conséquent, les E/S de disque rapides sont importantes pour les performances des opérations d’écriture dans Active Directory. Voici les recommandations matérielles susceptibles d’améliorer les performances pour ces scénarios :
Contrôleurs RAID matériels
Augmenter le nombre de disques à faible latence/à haute vitesse qui hébergent le DIT et les fichiers journaux.
Écrire le cache sur le contrôleur
Passez en revue les performances du sous-système de disque individuellement pour chaque volume. La plupart des scénarios Active Directory sont principalement basés sur la lecture. Par conséquent, les statistiques sur le volume hébergeant le DIT sont les plus importantes à inspecter. Toutefois, n'oubliez pas de surveiller les autres disques, y compris ceux du système d'exploitation et ceux des fichiers journaux. Pour déterminer si le contrôleur de domaine est correctement configuré pour éviter que le stockage soit le goulot d’étranglement pour les performances, reportez-vous à la section sur les sous-systèmes de stockage pour les recommandations de stockage standard. Dans de nombreux environnements, la philosophie est de s'assurer qu'il y a suffisamment de marge de manœuvre pour prendre en charge des pics de charge. Ces seuils sont des seuils d’avertissement où la marge de manœuvre pour absorber des pics de charge devient limitée et la réactivité du client se dégrade. En bref, le dépassement de ces seuils n’est pas mauvais à court terme (5 à 15 minutes quelques fois par jour), mais un système qui fonctionne en continu avec ces types de statistiques ne met pas entièrement la base de données en cache et peut être surchargé et doit être vérifié.
Base de données ==> Instances(lsass/NTDSA)\Latence moyenne d’E/S de lecture de la base de données < 15 ms
Base de données ==> Instances(lsass/NTDSA)\E/S de lecture de la base de données par seconde < 10
Base de données ==> Instances(lsass/NTDSA)\Latence moyenne d’E/S d’écriture de journal < 10 ms
Base de données ==> Instances(lsass/NTDSA)\E/S d’écriture de journal par seconde – à titre d’information uniquement.
Pour maintenir la cohérence des données, toutes les modifications doivent être écrites dans le journal. Il n’y a pas de bon ou mauvais nombre ici, il ne s’agit que d’une mesure de la quantité de stockage prise en charge.
Planifiez les charges d’E/S de disque non cœur, telles que les analyses de sauvegarde et de virus, pour les périodes de charge non maximales. Utilisez également des solutions de sauvegarde et antivirus qui prennent en charge la fonctionnalité d’E/S basse priorité introduite dans Windows Server 2008 pour réduire la concurrence avec les besoins d’E/S d’Active Directory.
Ne pas trop taxer les transformateurs
Les processeurs qui n'ont pas suffisamment de cycles libres peuvent entraîner de longs temps d'attente pour que les threads soient exécutés. Dans de nombreux environnements, la philosophie est de s’assurer qu’il y a suffisamment de marge de manœuvre pour prendre en charge des variations ou des pics de charge afin de réduire l’impact sur la réactivité du système dans ces scénarios. En bref, le dépassement des seuils inférieurs n’est pas mauvais à court terme (5 à 15 minutes quelques fois par jour), mais un système qui fonctionne avec ce type de statistiques ne laisse aucune marge de manœuvre pour prendre en charge les charges anormales et peut facilement être placé dans un scénario de surcharge. Les systèmes qui dépensent des périodes prolongées au-dessus des seuils doivent être examinés pour déterminer comment réduire les charges du processeur.
Pour plus d’informations sur la sélection d’un processeur, consultez Optimisation des performances pour le matériel serveur.
Ajoutez du matériel, optimisez la charge, dirigez les clients ailleurs ou supprimez la charge de l’environnement pour réduire la charge du processeur.
Utilisez le compteur de performances Informations sur le processeur(_Total)\% d’utilisation du processeur < 60 %.
Éviter de surcharger la carte réseau
Tout comme avec les processeurs, l’utilisation excessive de la carte réseau entraîne des temps d’attente longs pour que le trafic sortant passe au réseau. Active Directory a tendance à avoir de petites demandes entrantes et relativement à des quantités de données beaucoup plus importantes retournées aux systèmes clients. Les données envoyées dépassent largement les données reçues. Dans de nombreux environnements, la philosophie est de s'assurer qu'il y a suffisamment de marge de manœuvre pour prendre en charge des pics de charge. Ce seuil est un seuil d’avertissement où la marge de manœuvre pour faire face à des surcharges ou des pics de charge devient limitée et la réactivité du client se dégrade. En bref, le dépassement de ces seuils n’est pas mauvais à court terme (5 à 15 minutes quelques fois par jour), mais un système qui s’exécute avec ces types de statistiques est surtaxé et doit être examiné.
Pour plus d’informations sur la façon de régler le sous-système réseau, consultez Optimisation des performances pour les sous-systèmes réseau.
Utilisez le compteur de performances Comparer NetworkInterface(*)\Octets envoyés/s avec NetworkInterface(*)\Bande passante actuelle. Le ratio doit être inférieur à 60 % d’utilisation.