Planification de capacité pour Active Directory Domain Services

Cette rubrique a été initialement écrite par Ken Brumfield, chef de programme chez Microsoft. Elle fournit des recommandations relatives à la planification de capacité pour Active Directory Domain Services (AD DS).

Objectifs de la planification de capacité

La planification de capacité n’est pas la même chose que la résolution des incidents de performances. Elles sont étroitement liées, mais assez différentes. Les objectifs de la planification de capacité sont les suivants :

• Implémenter et faire fonctionner correctement un environnement
• Réduire le temps dédié à la résolution des problèmes de performances

Dans le cadre de la planification de capacité, une organisation peut avoir une cible de référence de 40 % d’utilisation du processeur pendant les périodes de pointe afin de répondre aux besoins de performances des clients et de tenir compte du temps nécessaire à la mise à niveau du matériel dans le centre de données. En revanche, pour être averti des incidents liés à des performances anormales, un seuil d’alerte de monitoring peut être défini à 90 % sur un intervalle de 5 minutes.

La différence est que lorsqu’un seuil de gestion de capacité est sans arrêt dépassé (un événement ponctuel ne pose pas problème), l’ajout de capacité (c’est-à-dire l’ajout d’autres processeurs ou de processeurs plus rapides) ou la mise à l’échelle du service sur plusieurs serveurs constituent une solution. Les seuils d’alerte de performances indiquent que l’expérience client est en train de souffrir et que des mesures immédiates sont nécessaires pour traiter le problème.

En guise d’analogie, la gestion de capacité consiste à prévenir un accident de voiture (conduite préventive, vérification du bon fonctionnement des freins, etc.), tandis que la résolution des problèmes de performance a trait aux interventions de la police, des pompiers et des professionnels de la médecine d’urgence après un accident. Il s’agit d’une « conduite préventive » à la sauce Active Directory.

Au cours des dernières années, les conseils en matière de planification de capacité pour les systèmes de scale-up ont considérablement changé. Les changements suivants dans les architectures système ont remis en question les principes fondamentaux de la conception et de la mise à l’échelle d’un service :

• Plateformes de serveur 64 bits
• Virtualisation
• Attention accrue à la consommation d’énergie
• Stockage SSD
• Scénarios cloud

En outre, l’approche est en train d’évoluer d’un exercice de planification de capacité en fonction des serveurs vers un exercice de planification de capacité en fonction des services. Active Directory Domain Services (AD DS), un service distribué arrivé à maturité que de nombreux produits Microsoft et tiers utilisent en tant que back-end, devient l’un des produits les plus essentiels pour planifier correctement la capacité nécessaire à l’exécution d’autres applications.

Conseils sur les exigences de référence pour la planification de capacité

Tout au long de cet article, les exigences de référence suivantes sont attendues :

• Les lecteurs ont lu et connaissent les recommandations relatives au réglage des performances pour Windows Server 2012 R2.
• La plateforme Windows Server est une architecture x64. Toutefois, même si votre environnement Active Directory est installé sur Windows Server 2003 x86 (à présent bien au-delà de la fin du cycle de vie du support) et dispose d’une arborescence d’informations d’annuaire (DIT) d’une taille inférieure à 1,5 Go facilement conservable en mémoire, les instructions données dans cet article sont toujours applicables.
• La planification de capacité est un processus continu et vous devez examiner régulièrement la façon dont l’environnement satisfait aux attentes.
• L’optimisation se produit sur plusieurs cycles de vie du matériel à mesure que les coûts matériels évoluent. Par exemple, la mémoire coûte de moins en moins cher, le coût par cœur diminue ou le prix des différentes options de stockage change.
• Planifiez la période de pointe de la journée. Il est recommandé de l’examiner par intervalles de 30 minutes ou d’une heure. Toute valeur supérieure risque de masquer les pics réels et toute valeur inférieure peut être faussée par des « pics temporaires ».
• Planifiez la croissance tout au long du cycle de vie du matériel pour l’entreprise. Cela peut inclure une stratégie de mise à niveau ou d’ajout de matériel de manière échelonnée, voire une actualisation complète tous les trois à cinq ans. Une telle stratégie nécessite de « supposer » quelle sera l’augmentation de la charge sur Active Directory. Les données historiques, si elles sont collectées, facilitent cette évaluation.
• Planifiez la tolérance de panne. Une fois qu’une estimation N est dérivée, planifiez des scénarios qui incluent N – 1, N – 2, N – x.

  • Ajoutez des serveurs supplémentaires en fonction des besoins de l’organisation pour veiller à ce que la perte d’un ou de plusieurs serveurs ne dépasse pas les estimations de capacité de pointe maximales.

  • Considérez également que le plan de croissance et le plan de tolérance de panne ont besoin d’être intégrés. Par exemple, si un contrôleur de domaine doit prendre en charge la charge, mais que l’estimation stipule que la charge sera doublée au cours de l’année suivante et qu’elle nécessite deux contrôleurs de domaine au total, la capacité ne sera pas suffisante pour prendre en charge la tolérance de panne. La solution consisterait à démarrer avec trois contrôleurs de domaine. Il pourrait également être prévu d’ajouter le troisième contrôleur de domaine après 3 ou 6 mois si les budgets sont serrés.

    Notes

    L’ajout d’applications prenant en charge Active Directory peut avoir un impact notable sur la charge du contrôleur de domaine, que la charge provienne des serveurs d’applications ou des clients.

Processus en trois étapes du cycle de planification de capacité

Dans le cadre de la planification de capacité, déterminez d’abord la qualité de service nécessaire. Par exemple, un centre de données de base prend en charge un niveau plus élevé d’accès concurrentiel et nécessite une expérience plus cohérente pour les utilisateurs et les applications consommatrices, ce qui nécessite de donner une plus grande attention à la redondance et de réduire les goulots d’étranglement du système et de l’infrastructure. En revanche, un emplacement satellite avec une poignée d’utilisateurs n’a pas besoin du même niveau d’accès concurrentiel ou de tolérance de panne. Ainsi, le bureau satellite n’a peut-être pas besoin d’autant d’attention pour optimiser le matériel et l’infrastructure sous-jacents, ce qui peut entraîner des réductions de coûts. L’ensemble des recommandations et conseils ci-après ont vocation à optimiser les performances et peuvent être assouplis de manière sélective pour les scénarios dont les exigences sont moins strictes.

La question suivante consiste à se demander si le scénario doit être virtualisé ou physique. Du point de vue de la planification de capacité, il n’y a pas de bonne ni de mauvaise réponse. Il n’y a qu’un ensemble différent de variables à utiliser. Les scénarios de virtualisation se résument à l’une des deux options suivantes :

• « Mappage direct » avec un seul invité par hôte (où la virtualisation existe uniquement pour abstraire le matériel physique du serveur)
• « Hôte partagé »

Les scénarios de test et de production indiquent que le scénario de « mappage direct » peut être traité de la même manière qu’un hôte physique. En revanche, un « hôte partagé » implique plusieurs considérations décrites plus en détail ultérieurement. Le scénario d’« hôte partagé » signifie qu’AD DS est également en concurrence pour les ressources et qu’il existe des pénalités et des considérations en matière réglage pour cela.

En gardant ces considérations à l’esprit, le cycle de planification de capacité est un processus itératif en trois étapes :

1. Mesurez l’environnement existant, déterminez où se trouvent actuellement les goulots d’étranglement du système et obtenez les bases environnementales nécessaires pour planifier la quantité de capacité nécessaire.
2. Déterminez le matériel nécessaire en fonction des critères décrits à l’étape 1.
3. Supervisez et vérifiez que l’infrastructure telle qu’elle est implémentée fonctionne dans le respect des spécifications. Certaines données collectées à cette étape deviennent la base de référence du prochain cycle de planification de capacité.

Application du processus

Pour optimiser les performances, veillez à ce que ces composants majeurs soient correctement sélectionnés et ajustés aux charges d’application :

1. Mémoire
2. Réseau
3. Stockage
4. Processeur
5. Net Logon

Les exigences de stockage de base d’AD DS et le comportement général des logiciels clients bien écrits permettent aux environnements comprenant de 10 000 à 20 000 utilisateurs de renoncer à un investissement lourd en termes de planification de capacité liée au matériel physique, étant donné que presque n’importe quel système de classe de serveur moderne va gérer la charge. Cela dit, le tableau suivant résume la manière d’évaluer un environnement existant afin de sélectionner le matériel approprié. Chaque composant est analysé dans le détail dans les sections ultérieures pour aider les administrateurs AD DS à évaluer leur infrastructure en utilisant les recommandations de référence et les principes propres à l’environnement.

En général :

• Tout dimensionnement basé sur les données actuelles est uniquement exact pour l’environnement actuel.
• Pour toutes les estimations, attendez-vous à ce que la demande augmente tout au long du cycle de vie du matériel.
• Déterminez si vous devez surdimensionner aujourd’hui pour évoluer dans un environnement plus grand ou ajouter de la capacité au cours du cycle de vie.
• Pour la virtualisation, les mêmes principes et méthodologies de planification de capacité s’appliquent, sauf que la surcharge de la virtualisation a besoin d’être ajoutée à tout ce qui a trait au domaine.
• La planification de capacité, à l’instar de toute prédiction, n’est PAS une science exacte. Ne vous attendez pas à ce que les calculs soient parfaits avec une précision à 100 %. Les conseils donnés ici sont les plus élémentaires : ajoutez de la capacité pour renforcer la sécurité et vérifiez en permanence que l’environnement maintient son cap.

Tables récapitulatives de la collecte de données

Nouvel environnement

Composant	Estimations
Taille de la base de données/du stockage	40 Ko à 60 Ko pour chaque utilisateur
Mémoire vive (RAM)	Taille de la base de données Recommandations de système d’exploitation de base Applications tierces
Réseau	1 Go
UC	1 000 utilisateurs simultanés pour chaque cœur

Critères d’évaluation généraux

Composant	Critères d’évaluation	Considérations relatives à la planification
Taille de la base de données/du stockage	Section intitulée « Pour activer la journalisation de l’espace disque libéré par la défragmentation » dans Limites de stockage
Performances de la base de données/du stockage	« Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/lecture », « Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/écriture », « Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/Transfert » « Disque logique(<Lecteur de base de données NTDS>)\Lectures/s », « Disque logique(<Lecteur de base de données NTDS>)\Écritures/s », « Disque logique(<Lecteur de base de données NTDS>)\Transferts/s »	Le stockage a deux préoccupations à traiter : L’espace disponible, qui, avec la taille du stockage classique ou SSD d’aujourd’hui, n’est pas pertinent pour la plupart des environnements AD. Les opérations d’entrée/sortie (E/S) disponibles : dans de nombreux environnements, elles sont souvent négligées. Toutefois, il est important d’évaluer uniquement les environnements qui n’ont pas suffisamment de RAM pour charger l’intégralité de la base de données NTDS dans la mémoire. Le stockage peut s’avérer un sujet complexe et doit impliquer l’expertise du fournisseur du matériel pour un dimensionnement approprié. Plus particulièrement avec des scénarios plus complexes comme les scénarios SAN, NAS et iSCSI. En revanche, le coût par gigaoctet de stockage est en règle général souvent en opposition directe avec le coût par E/S : RAID 5 a un coût par gigaoctet inférieur à Raid 1, mais Raid 1 a un coût par E/S inférieur. Les disques durs classiques ont un coût inférieur par gigaoctet, mais les disques SSD ont un coût inférieur par E/S. Après un redémarrage de l’ordinateur ou du service Active Directory Domain Services, le cache du moteur de stockage extensible est vide et les performances sont liées au disque pendant que le cache se réchauffe. Dans la plupart des environnements, AD est en lecture intensive d’E/S dans un modèle aléatoire sur les disques, ce qui annule une grande partie des avantages liés à la mise en cache et des stratégies d’optimisation de la lecture. De plus, AD dispose d’un cache en mémoire beaucoup plus grand que la plupart des caches de système de stockage.
Mémoire vive (RAM)	Taille de la base de données Recommandations de système d’exploitation de base Applications tierces	Le stockage est le composant le plus lent d’un ordinateur. Plus il est possible de résider dans la RAM, moins il est nécessaire d’accéder au disque. Vérifiez qu’une quantité suffisante de RAM est allouée au stockage du système d’exploitation, des agents (antivirus, sauvegarde, monitoring), de la base de données NTDS et de la croissance à venir. Pour les environnements où la maximisation de la quantité de RAM n’est pas rentable (par exemple, un emplacement satellite) ou impossible (arborescence d’informations d’annuaire trop grande), reportez-vous à la section Stockage pour vérifier que le stockage est correctement dimensionné.
Réseau	« Interface réseau(*)\Octets reçus/s » « Interface réseau(*)\Octets envoyés/s »	En général, le trafic envoyé à partir d’un contrôleur de domaine dépasse de loin le trafic envoyé à un contrôleur de domaine. Étant donné qu’une connexion Ethernet commutée est en duplex intégral, le trafic réseau entrant et le trafic réseau sortant ont besoin d’être dimensionnés indépendamment. La consolidation du nombre de contrôleurs de domaine augmente la quantité de bande passante utilisée pour renvoyer les réponses aux demandes clients de chaque contrôleur de domaine, mais elle sera suffisamment proche d’une valeur linéaire pour le site dans son ensemble. Si vous supprimez des contrôleurs de domaine d’emplacement satellite, n’oubliez pas d’ajouter la bande passante du contrôleur de domaine satellite dans les contrôleurs de domaine du hub et de l’utiliser pour évaluer la quantité de trafic WAN attendue.
UC	« Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/lecture » « Process(lsass)\% de temps processeur »	Après avoir éliminé le stockage en tant que goulot d’étranglement, traitez la quantité de puissance de calcul nécessaire. Bien qu’il ne soit pas parfaitement linéaire, le nombre de cœurs de processeur consommés sur tous les serveurs au sein d’une étendue spécifique (comme un site) peut être utilisé pour évaluer le nombre de processeurs nécessaires pour prendre en charge la charge totale du client. Ajoutez le minimum nécessaire pour maintenir le niveau de service actuel sur tous les systèmes au sein de l’étendue. Les modifications apportées à la cadence du processeur, y compris les modifications liées à la gestion de l’alimentation, ont un impact sur les chiffres dérivés de l’environnement actuel. En règle générale, il est impossible d’évaluer précisément comment le passage d’un processeur de 2,5 GHz à un processeur de 3 GHz va permettre de réduire le nombre de processeurs nécessaires.
Accès réseau (Netlogon)	« Netlogon()\Acquisitions de sémaphore » « Netlogon()\Expirations de sémaphore » « Netlogon(*)\Temps moyen de conservation de sémaphore »	Net Logon Secure Channel/MaxConcurrentAPI affecte uniquement les environnements avec des authentifications NTLM et/ou une validation PAC. La validation PAC est activée par défaut dans les versions du système d’exploitation antérieures à Windows Server 2008. Il s’agit d’un paramètre client, de sorte que les contrôleurs de domaine seront affectés jusqu’à ce que ce paramètre soit désactivé sur tous les systèmes clients. Les environnements avec une authentification d’approbation croisée significative, qui inclut des approbations intra-forêt, présentent un risque plus élevé s’ils ne sont pas dimensionnés correctement. Les consolidations de serveur augmenteront l’accès concurrentiel de l’authentification d’approbation croisée. Les augmentations doivent être prise en charge, notamment les basculements de cluster, à mesure que les utilisateurs se réauthentifient en masse auprès du nouveau nœud de cluster. Les systèmes clients individuels (comme un cluster) peuvent également avoir besoin d’être ajustés.

Planification

Pendant longtemps, la recommandation de la communauté quant au dimensionnement d’AD DS a été de « disposer d’autant de RAM que la taille de la base de données ». Pour une grande majorité, cette recommandation est la seule dont doivent se soucier la plupart des environnements. Mais l’écosystème consommant AD DS est devenu beaucoup plus grand, comme les environnements AD DS eux-mêmes, depuis son introduction en 1999. Bien que l’augmentation de la puissance de calcul et le passage des architectures x86 aux architectures x64 ont rendu les aspects plus subtils du dimensionnement à des fins de performances non pertinents pour un plus grand nombre de clients exécutant AD DS sur du matériel physique, l’augmentation de la virtualisation a réintroduit des problèmes de réglage pour un public plus large qu’auparavant.

Les conseils suivants expliquent donc comment déterminer et planifier les besoins d’Active Directory en tant que service, qu’il soit déployé dans un scénario physique, virtuel/physique mélangé ou purement virtualisé. Par conséquent, nous allons décomposer l’évaluation en chacun des quatre principaux composants : stockage, mémoire, réseau et processeur. En bref, afin de maximiser les performances sur AD DS, l’objectif est d’être aussi proche que possible des limites du processeur.

Mémoire vive (RAM)

En termes simples, plus il est possible de mettre en cache dans la RAM, moins il est nécessaire d’accéder au disque. Pour maximiser la scalabilité du serveur, la quantité minimale de RAM doit correspondre à la somme de la taille de la base de données actuelle, de la taille SYSVOL totale, de la quantité recommandée pour le système d’exploitation et des recommandations du fournisseur pour les agents (antivirus, monitoring, sauvegarde, etc.). Une quantité supplémentaire doit être ajoutée pour prendre en charge la croissance sur la durée de vie du serveur. Celle-ci est propre à l’environnement et dépend des estimations de la croissance de la base de données en fonction des changements environnementaux.

Pour les environnements où la maximisation de la quantité de RAM n’est pas rentable (par exemple, un emplacement satellite) ou impossible (arborescence d’informations d’annuaire trop grande), reportez-vous à la section Stockage pour vérifier que le stockage est correctement conçu.

Un corollaire qui apparaît dans le contexte général du dimensionnement de la mémoire est le dimensionnement du fichier de pagination. Dans le même contexte que tout ce qui est lié à la mémoire, l’objectif est de réduire l’accès au disque beaucoup plus lent. Par conséquent, la question n’est plus : « Comment le fichier de pagination doit-il être dimensionné ? » mais « Quelle quantité de RAM est nécessaire pour minimiser la pagination ? » La réponse à cette dernière question est décrite dans le reste de cette section. Elle laisse la grande partie du débat sur le dimensionnement du fichier de pagination aux mains des recommandations générales pour le système d’exploitation et au besoin de configurer le système pour les vidages de mémoire, qui ne sont pas liés aux performances AD DS.

Évaluation

La quantité de RAM dont un contrôleur de domaine a besoin constitue en fait un exercice complexe pour les raisons suivantes :

• Risque élevé d’erreur lors de la tentative d’utilisation d’un système existant pour évaluer la quantité de RAM nécessaire car LSASS est réduit dans des conditions de sollicitation de la mémoire, ce qui fait baisser artificiellement le besoin.
• Le fait subjectif qu’un contrôleur de domaine individuel n’a besoin de mettre en cache que ce qui est « intéressant » pour ses clients. Cela signifie que les données qui ont besoin d’être mises en cache sur un contrôleur de domaine d’un site doté d’un seul serveur Exchange seront très différentes des données qui ont besoin d’être mises en cache sur un contrôleur de domaine qui authentifie uniquement les utilisateurs.
• Le travail d’évaluation de la RAM pour chaque contrôleur de domaine au cas par cas est prohibitif et change à mesure que l’environnement évolue.
• Les critères sous-jacents à la recommandation vous aideront à prendre des décisions avisées :
• Plus il est possible de mettre en cache dans la RAM, moins il est nécessaire d’accéder au disque.
• Le stockage est de loin le composant le plus lent d’un ordinateur. L’accès aux données sur un support de stockage classique ou SSD est de l’ordre de 1 000 000 fois plus lent que l’accès aux données dans la RAM.

Ainsi, pour maximiser la scalabilité du serveur, la quantité minimale de RAM correspond à la somme de la taille de la base de données actuelle, de la taille SYSVOL totale, de la quantité recommandée pour le système d’exploitation et des recommandations du fournisseur pour les agents (antivirus, monitoring, sauvegarde, etc.). Ajoutez une quantité supplémentaire pour prendre en charge la croissance sur la durée de vie du serveur. Celle-ci est propre à l’environnement et dépend des estimations de la croissance de la base de données. Toutefois, pour les emplacements satellites qui ont un petit ensemble d’utilisateurs finaux, ces exigences peuvent être assouplies, car ces sites n’auront pas besoin d’une mise en cache si importante pour traiter la plupart des demandes.

Pour les environnements où la maximisation de la quantité de RAM n’est pas rentable (par exemple, un emplacement satellite) ou impossible (arborescence d’informations d’annuaire trop grande), reportez-vous à la section Stockage pour vérifier que le stockage est correctement dimensionné.

Notes

Un corollaire lors du dimensionnement de la mémoire est le dimensionnement du fichier de pagination. Étant donné que l’objectif est de minimiser l’accès au disque beaucoup plus lent, la question n’est plus : « Comment le fichier de pagination doit-il être dimensionné ? » mais « Quelle quantité de RAM est nécessaire pour minimiser la pagination ? » La réponse à cette dernière question est décrite dans le reste de cette section. Elle laisse la grande partie du débat sur le dimensionnement du fichier de pagination aux mains des recommandations générales pour le système d’exploitation et au besoin de configurer le système pour les vidages de mémoire, qui ne sont pas liés aux performances AD DS.

Éléments à prendre en compte en matière de virtualisation pour la RAM

Évitez de surengager la mémoire au niveau de l’hôte. L’objectif fondamental de l’optimisation de la quantité de RAM est de réduire le temps passé à accéder au disque. Dans les scénarios de virtualisation, le concept de surengagement de la mémoire existe quand la quantité de RAM allouée aux invités est supérieure à celle de la machine physique. Cela n’est pas un problème en soi. Cela le devient quand la mémoire totale activement utilisée par tous les invités dépasse la quantité de RAM sur l’hôte et que l’hôte sous-jacent démarre la pagination. Les performances deviennent liées au disque quand le contrôleur de domaine accède à NTDS.dit pour obtenir des données, ou quand le contrôleur de domaine accède au fichier de pagination pour obtenir des données, ou quand l’hôte accède au disque pour obtenir des données que l’invité pense être dans la RAM.

Exemple de résumé de calcul

Composant	Mémoire estimée (exemple)
RAM recommandée pour le système d’exploitation de base (Windows Server 2008)	2 Go
Tâches internes LSASS	200 Mo
Agent de monitoring	100 Mo
Antivirus	100 Mo
Base de données (catalogue global)	8,5 Go
Tampon pour que la sauvegarde s’exécute, les administrateurs se connectent sans impact	1 Go
Total	12 Go

Recommandé : 16 Go

Avec le temps, il est possible de partir du principe que d’autres données seront ajoutées à la base de données et que le serveur sera probablement en production pendant 3 à 5 ans. Sur la base d’une estimation de croissance de 33 %, 16 Go correspondent à une quantité raisonnable de RAM à placer dans un serveur physique. Dans une machine virtuelle, compte tenu de la facilité avec laquelle les paramètres peuvent être modifiés et de la RAM ajoutée à la machine virtuelle, il est raisonnable de commencer à 12 Go en envisageant un monitoring et une mise à niveau à l’avenir.

Réseau

Évaluation

Cette section concerne moins l’évaluation des besoins liés au trafic de réplication, qui se concentre sur le trafic qui traverse le WAN et qui est entièrement décrit dans Trafic de réplication Active Directory, que l’évaluation de la bande passante totale et de la capacité réseau nécessaires, requêtes du client, applications de stratégie de groupe, etc. comprises. Pour les environnements existants, vous pouvez les collecter à l’aide des compteurs de performances « Interface réseau(*)\Octets reçus/s » et « Interface réseau(*)\Octets envoyés/s ». Exemples d’intervalles pour les compteurs Interface réseau de 15, 30 ou 60 minutes. Toute valeur inférieure sera généralement trop volatile pour obtenir de bonnes mesures et toute valeur supérieure va trop lisser les pics quotidiens.

Notes

En règle générale, la majorité du trafic réseau sur un contrôleur de domaine est sortant, car le contrôleur de domaine répond aux requêtes du client. C’est la raison pour laquelle l’accent est mis sur le trafic sortant, même s’il est recommandé d’évaluer aussi chaque environnement en termes de trafic entrant. Les mêmes approches peuvent être utilisées pour traiter et passer en revue les besoins de trafic réseau entrant. Pour plus d’informations, consultez l’article de la Base de connaissances 929851 : La plage de ports dynamiques par défaut pour TCP/IP a changé depuis Windows Vista et dans Windows Server 2008.

Besoins de bande passante

La planification de la scalabilité du réseau couvre deux catégories distinctes : la quantité de trafic et la charge processeur à partir du trafic réseau. Chacun de ces scénarios est simple par rapport à certains des autres sujets traités dans cet article.

Lors de l’évaluation de la quantité de trafic à prendre en charge, il existe deux catégories uniques de planification de capacité pour AD DS en termes de trafic réseau. La première correspond au trafic de réplication qui transite entre les contrôleurs de domaine et qui est couvert en détail dans le document de référence Trafic de réplication Active Directory, toujours pertinent pour les versions actuelles d’AD DS. La seconde correspond au trafic client à serveur intrasite. Constituant l’un des scénarios les plus simples à planifier, le trafic intrasite reçoit principalement de petites demandes des clients par rapport aux grandes quantités de données renvoyées aux clients. 100 Mo sont généralement suffisants dans les environnements comptant jusqu’à 5 000 utilisateurs par serveur, dans un site. L’utilisation d’une carte réseau de 1 Go et la prise en charge de la mise à l’échelle côté réception (RSS) sont recommandées pour tout ce qui dépasse 5 000 utilisateurs. Pour valider ce scénario, en particulier dans le cadre de scénarios de consolidation de serveurs, examinez la valeur Interface réseau(*)\Octets/s sur tous les contrôleurs de domaine d’un site, additionnez-les et divisez-les par le nombre cible de contrôleurs de domaine pour vérifier que la capacité est adéquate. Le moyen le plus simple d’effectuer cette opération consiste à utiliser la vue « Zone empilée » dans l’Analyseur de fiabilité et de performances Windows (anciennement Perfmon), en veillant à ce que tous les compteurs soient mis à l’échelle de la même façon.

Prenons l’exemple suivant (également connu comme un moyen vraiment très complexe de vérifier que la règle générale s’applique à un environnement spécifique). Les hypothèses suivantes sont formulées :

• L’objectif est de réduire l’empreinte au nombre le plus petit possible de serveurs. Idéalement, un seul serveur porte la charge et un autre serveur est déployé pour la redondance (scénario N + 1).
• Dans ce scénario, la carte réseau actuelle ne prend en charge que 100 Mo et elle se trouve dans un environnement commuté. L’utilisation maximale de la bande passante réseau cible s’élève à 60 % dans un scénario N (perte d’un contrôleur de domaine).
• Chaque serveur a environ 10 000 clients connectés.

Connaissances acquises à partir des données du graphique (Interface réseau(*)\Octets envoyés/s) :

1. Le jour ouvrable commence à monter en puissance vers 5h30 et retombe à 19h00.
2. La période de pointe s’étale de 8h00 à 8h15, avec plus de 25 octets envoyés/s sur le contrôleur de domaine le plus sollicité.

   Notes

   Toutes les données de performances sont historiques. Ainsi, le point de données de pointe à 8h15 indique la charge entre 8h00 et 8h15.

3. Il existe des pics avant 4h00, avec plus de 20 octets envoyés/s sur le contrôleur de domaine le plus sollicité, ce qui peut indiquer une charge en provenance d’autres fuseaux horaires ou une activité d’infrastructure en arrière-plan, comme des sauvegardes. Étant donné que le pic de 8h00 dépasse cette activité, il n’est pas pertinent.
4. Il existe cinq contrôleurs de domaine dans le site.
5. La charge maximale s’élève à environ 5,5 Mo/s par contrôleur de domaine, ce qui représente 44 % de la connexion de 100 Mo. En utilisant ces données, il est possible d’estimer que la bande passante totale nécessaire entre 8h00 et 8h15 est de 28 Mo/s.

   Notes

   N’oubliez pas que les compteurs d’envoi/réception Interface réseau sont en octets alors que la bande passante réseau est mesurée en bits. 100 Mo ÷ 8 = 12,5 Mo, 1 Go ÷ 8 = 128 Mo.

Conclusions :

1. Cet environnement actuel répond au niveau N+1 de tolérance de panne à 60 % de l’utilisation cible. La mise hors connexion d’un système fait passer la bande passante par serveur d’environ 5,5 Mo/s (44 %) à environ 7 Mo/s (56 %).
2. Compte tenu de l’objectif précédemment défini de consolidation sur un seul serveur, ces résultats dépassent à la fois l’utilisation cible maximale et théoriquement l’utilisation possible d’une connexion de 100 Mo.
3. Avec une connexion de 1 Go, cela représente 22 % de la capacité totale.
4. Dans des conditions de fonctionnement normales dans le scénario N + 1, la charge du client est distribuée de manière relativement uniforme à environ 14 Mo/s par serveur, soit 11 % de la capacité totale.
5. Pour garantir que la capacité est suffisante en cas d’indisponibilité d’un contrôleur de domaine, les cibles de fonctionnement normal par serveur seraient d’environ 30 % d’utilisation du réseau ou 38 Mo/s par serveur. Les cibles de basculement seraient de 60 % d’utilisation du réseau ou 72 Mo/s par serveur.

En bref, le déploiement final des systèmes doit avoir une carte réseau de 1 Go et être connecté à une infrastructure réseau qui prend en charge ladite charge. Notez également qu’étant donné la quantité de trafic réseau générée, la charge processeur provenant des communications réseau peut avoir un impact significatif et limiter la scalabilité maximale d’AD DS. Ce même processus peut être utilisé pour estimer la quantité de communication entrante vers le contrôleur de domaine. Mais étant donné que le trafic sortant prédomine sur le trafic entrant, cet exercice est théorique pour la plupart des environnements. Il est important de garantir la prise en charge matérielle de RSS dans les environnements qui comptent plus de 5 000 utilisateurs par serveur. Pour les scénarios avec un trafic réseau élevé, l’équilibrage de la charge d’interruption peut être un goulot d’étranglement. Celui-ci peut être détecté par un pourcentage du temps d’interruption processeur(*) distribué de manière inégale entre les processeurs. Les cartes réseau compatibles RSS peuvent atténuer cette limitation et augmenter la scalabilité.

Notes

Une approche similaire peut être utilisée pour estimer la capacité supplémentaire nécessaire lors de la consolidation de centres de données ou de la mise hors service d’un contrôleur de domaine dans un emplacement satellite. Collectez simplement le trafic sortant et entrant vers les clients. Il correspondra à la quantité de trafic désormais présente sur les liaisons WAN.

Dans certains cas, vous risquez de rencontrer plus de trafic que prévu, car le trafic est plus lent, notamment quand la vérification des certificats ne parvient pas à respecter des délais d’expiration agressifs sur le WAN. C’est pourquoi le dimensionnement et l’utilisation du WAN doivent être un processus itératif et continu.

Éléments à prendre en compte en matière de virtualisation pour la bande passante réseau

Il est facile de faire des recommandations pour un serveur physique : 1 Go pour les serveurs prenant en charge plus de 5 000 utilisateurs. Une fois que plusieurs invités commencent à partager une infrastructure de commutateur virtuel sous-jacente, une attention supplémentaire est nécessaire pour veiller à ce que l’hôte dispose d’une bande passante réseau adéquate pour prendre en charge tous les invités sur le système, ce qui nécessite une plus grande rigueur. Il s’agit tout simplement de veiller à ce que l’infrastructure réseau convienne à l’ordinateur hôte. Indépendamment du fait que le réseau inclue le contrôleur de domaine s’exécutant en tant qu’invité de machine virtuelle sur un hôte avec le trafic réseau passant par un commutateur virtuel, ou qu’il soit connecté directement à un commutateur physique. Le commutateur virtuel n’est qu’un composant de plus où la liaison a besoin de prendre en charge la quantité de données transmises. Ainsi, la carte réseau physique de l’hôte physique liée au commutateur doit être en mesure de prendre en charge la charge du contrôleur de domaine ainsi que tous les autres invités partageant le commutateur virtuel connecté à la carte réseau physique.

Exemple de résumé de calcul

Système	Bande passante maximale
Contrôleur de domaine 1	6,5 Mo/s
Contrôleur de domaine 2	6,25 Mo/s
Contrôleur de domaine 3	6,25 Mo/s
Contrôleur de domaine 4	5,75 Mo/s
Contrôleur de domaine 5	4,75 Mo/s
Total	28,5 Mo/s

Recommandé : 72 Mo/s (28,5 Mo/s divisé par 40 %)

Nombre de systèmes cibles	Bande passante totale (comme ci-dessus)
2	28,5 Mo/s
Comportement normal obtenu	28,5 ÷ 2 = 14,25 Mo/s

Comme toujours, avec le temps, il est possible de partir du principe que la charge du client va augmenter et que cette augmentation doit être planifiée le mieux possible. Le montant recommandé à planifier permet une croissance estimée du trafic réseau de 50 %.

Stockage

La planification du stockage comprend deux composants :

• La capacité ou taille du stockage
• Performances

Beaucoup de temps et de nombreux documents sont consacrés à la planification de capacité, ce qui laisse souvent les performances complètement négligées. Avec les coûts matériels actuels, la plupart des environnements ne sont pas assez grands pour que l’un ou l’autre des composants soit réellement un problème, et la recommandation de « disposer d’autant de RAM que la taille de la base de données » couvre généralement le reste, bien qu’elle puisse être excessive pour les emplacements satellites dans des environnements plus grands.

Dimensionnement

Évaluation du stockage

Par rapport à il y a 13 ans, lors des débuts d’Active Directory, à l’époque où les lecteurs de 4 Go et 9 Go étaient les tailles de lecteur les plus courantes, le dimensionnement d’Active Directory n’est même pas un facteur à prendre en compte pour tous les environnements, à l’exception des plus grands. Avec les plus petites tailles de disque dur disponibles dans la gamme des 180 Go, l’ensemble du système d’exploitation, SYSVOL et NTDS.dit peuvent facilement tenir sur un seul lecteur. Par conséquent, il est recommandé de déprécier les investissements lourds dans ce domaine.

La seule recommandation à prendre en compte consiste à veiller à ce que 110 % de la taille de NTDS.dit soit disponible afin d’activer la défragmentation. En outre, des adaptations de croissance pendant la durée de vie du matériel doivent être effectuées.

La première considération et la plus importante consiste à évaluer la taille de NTDS.dit et SYSVOL. Ces mesures entraînent le dimensionnement de l’allocation de disque fixe et de RAM. En raison du coût (relativement) faible de ces composants, les calculs n’ont pas besoin d’être rigoureux et précis. Des informations sur la façon d’évaluer ces valeurs pour des environnements existants et nouveaux sont disponibles dans la série d’articles intitulée Stockage de données. Consultez notamment les articles suivants :

• Pour les environnements existants : La section intitulée « Pour activer la journalisation de l’espace disque libéré par la défragmentation » dans l’article Limites de stockage.

• Pour les nouveaux environnements : L’article intitulé Estimations de croissance pour les utilisateurs et les unités d’organisation Active Directory.

  Notes

  Les articles se basent sur les estimations de taille des données effectuées au moment de la publication d’Active Directory dans Windows 2000. Utilisez des tailles d’objet qui reflètent la taille réelle des objets inclus dans votre environnement.

Lors de l’étude d’environnements existants dotés de plusieurs domaines, des variations peuvent exister dans les tailles de base de données. Dans ce cas, utilisez les plus petites tailles de catalogue global (GC) et non-GC.

La taille de la base de données peut varier d’une version de système d’exploitation à l’autre. Les contrôleurs de domaine qui exécutent des systèmes d’exploitation antérieurs comme Windows Server 2003 ont une taille de base de données inférieure à celle d’un contrôleur de domaine qui exécute un système d’exploitation ultérieur comme Windows Server 2008 R2, notamment quand des fonctionnalités comme la corbeille Active Directory ou l’itinérance des informations d’identification sont activées.

Notes

• Pour les nouveaux environnements, notez que les estimations de croissance pour les utilisateurs et les unités d’organisation Active Directory indiquent que 100 000 utilisateurs (dans le même domaine) consomment environ 450 Mo d’espace. Notez que les attributs renseignés peuvent avoir un impact énorme sur la quantité totale. Les attributs seront renseignés sur de nombreux objets par des produits tiers et Microsoft, notamment Microsoft Exchange Server et Lync. Une évaluation basée sur le portefeuille des produits dans l’environnement est préférable, mais l’exercice qui consiste à détailler le calcul et les tests d’estimations précises pour tous les environnements sauf les plus grands risque de ne pas valoir la peine d’y consacrer beaucoup de temps et d’efforts.
• Assurez-vous que 110 % de la taille de NTDS.dit soit disponible en tant qu’espace libre afin de permettre la défragmentation hors connexion et planifiez une croissance sur une durée de vie du matériel comprise entre trois et cinq ans. Compte tenu du faible coût du stockage, il est prudent d’estimer le stockage à 300 % de la taille de l’arborescence d’informations d’annuaire (DIT) pour l’allocation de stockage afin de prendre en charge la croissance et les besoins potentiels de défragmentation hors connexion.

Éléments à prendre en compte en matière de virtualisation pour le stockage

Dans un scénario où plusieurs fichiers de disque dur virtuel (VHD) sont alloués sur un seul volume, utilisez un disque de taille fixe d’au moins 210 % (100 % de la DIT + 110 % d’espace libre) de la taille de la DIT pour garantir un espace réservé suffisant.

Exemple de résumé de calcul

Données collectées à partir de la phase d’évaluation	Taille
Taille de NTDS.dit	35 Go
Modificateur pour autoriser la défragmentation hors connexion	2,1 Go
Stockage total nécessaire	73,5 Go

Notes

Ce stockage nécessaire s’ajoute au stockage nécessaire à SYSVOL, au système d’exploitation, au fichier de pagination, aux fichiers temporaires, aux données mises en cache locales (comme les fichiers de programme d’installation) et aux applications.

Performances de stockage

Évaluation des performances du stockage

En tant que composant le plus lent dans un ordinateur, le stockage peut avoir l’impact négatif le plus grand sur l’expérience client. Pour les environnements suffisamment grands pour lesquels les recommandations de dimensionnement de la RAM ne sont pas réalisables, négliger la planification du stockage à des fins de performances peut avoir des conséquences dévastatrices. En outre, la complexité et la variété des technologies de stockage augmentent d’autant plus le risque de défaillance, car la pertinence des bonnes pratiques de longue date consistant à « placer le système d’exploitation, les journaux et la base de données » sur des disques physiques distincts est limitée dans les scénarios les plus utiles. Cela est dû au fait que cette bonne pratique de longue date repose sur le principe selon lequel un « disque » est une broche dédiée qui permet d’isoler les E/S. Ces principes ne sont plus pertinents avec l’introduction de ces éléments :

• RAID
• Nouveaux types de stockage et scénarios de stockage virtualisé et partagé
• Broches partagées sur un réseau de zone de stockage (SAN)
• Fichier VHD sur un SAN ou un stockage attaché au réseau
• Disques SSD
• Architectures de stockage hiérarchisé (c’est-à-dire, un niveau stockage SSD mettant en cache un stockage basé sur une broche plus grande)

Plus précisément, le stockage partagé (RAID, SAN, NAS, JBOD (c’est-à-dire, des espaces de stockage), VHD) a la capacité d’être sursouscrit/surchargé par d’autres charges de travail placées sur le stockage back-end. Elles ajoutent également les difficultés liées au fait que des problèmes de SAN/réseau/pilote (tout ce qui se trouve entre le disque physique et l’application AD) peuvent entraîner des limitations et/ou des retards. Pour être précis, il ne s’agit pas de configurations « incorrectes », mais de configurations plus complexes qui nécessitent que chaque composant fonctionne correctement, ce qui nécessite une attention supplémentaire pour vérifier que les performances sont acceptables. Pour obtenir des explications plus détaillées, consultez l’annexe C, sous-section « Présentation des SAN » et l’annexe D plus loin dans ce document. En outre, alors que les disques SSD ne sont pas limitées comme des disques traditionnels (disques durs) pour autoriser le traitement d’une seule E/S à la fois, ils ont quand même des limitations d’E/S et une surcharge/sursouscription des disques SSD est possible. En bref, l’objectif final de tous les efforts de performances du stockage, quelles que soient l’architecture et la conception de stockage sous-jacentes, consiste à veiller à ce que la quantité nécessaire d’opérations d’entrée/sortie par seconde (IOPS) soit disponible et que ces IOPS se produisent dans un laps de temps acceptable (comme spécifié ailleurs dans ce document). Pour les scénarios avec un stockage attaché localement, reportez-vous à l’annexe C pour connaître les principes de base des scénarios de conception de stockage local traditionnels. Ces principes s’appliquent généralement à des niveaux de stockage plus complexes et facilitent aussi le dialogue avec les fournisseurs qui prennent en charge les solutions de stockage back-end.

• Étant donné le large éventail des options de stockage disponibles, il est recommandé de faire appel à l’expertise des équipes de support matériel ou des fournisseurs pour veiller à ce que la solution spécifique réponde aux besoins d’AD DS. Les chiffres suivants correspondent aux informations qui seraient fournies aux spécialistes du stockage.

Pour les environnements où la base de données est trop volumineuse pour être conservée dans la RAM, utilisez les compteurs de performances pour déterminer la quantité d’E/S à prendre en charge :

• Disque logique(*)\Moyenne de disque en s/lecture (par exemple, si NTDS.dit est stocké sur le lecteur D:/, le chemin complet serait Disque logique(D:)\Moyenne de disque en s/lecture)
• Disque logique(*)\Moyenne de disque en s/écriture
• Disque logique(*)\Moyenne de disque en s/transfert
• Disque logique(*)\Lectures/s
• Disque logique(*)\Écritures/s
• Disque logique(*)\Transferts/s

Ces valeurs doivent être échantillonnées par intervalles de 15/30/60 minutes pour évaluer les exigences de l’environnement actuel.

Évaluation des résultats

Notes

L’accent est mis sur les lectures de la base de données, car il s’agit généralement du composant le plus exigeant. La même logique peut s’appliquer aux écritures dans le fichier journal en remplaçant Disque logique(<Journal NTDS>)\Moyenne de disque en s/écriture et Disque logique(<Journal NTDS>)\Écritures/s) :

• Disque logique(<NTDS>)\Moyenne de disque en s/lecture indique si le stockage actuel est correctement dimensionné. Si les résultats sont à peu près égaux à la durée d’accès au disque pour le type de disque, Disque logique(<NTDS>)\Lectures/s est une mesure valide. Vérifiez les spécifications du fabricant pour le stockage sur le back-end, mais les plages appropriées pour Disque logique(<NTDS>)\Moyenne de disque en s/lecture sont approximativement les suivantes :
  • 7200 – de 9 à 12,5 millisecondes (ms)
  • 10 000 – de 6 à 10 ms
  • 15 000 – de 4 à 6 ms
  • SSD – de 1 à 3 ms

  • Notes

    Certaines recommandations indiquent que les performances de stockage sont dégradées à des niveaux compris entre 15 ms à 20 ms (selon la source). La différence entre les valeurs ci-dessus et ces autres recommandations est que les valeurs ci-dessus constituent la plage de fonctionnement normale. Les autres recommandations correspondent à des conseils de résolution des problèmes permettant d’identifier à quel moment l’expérience client se dégrade considérablement et devient perceptible. Pour une explication plus approfondie, reportez-vous à l’annexe C.

• Disque logique(<NTDS>)\Lectures/s correspond à la quantité d’E/S en cours d’exécution.
  • Si Disque logique(<NTDS>)\Moyenne de disque en s/lecture se trouve dans la plage optimale pour le stockage back-end, Disque logique(<NTDS>)\Lectures/s peut être utilisé directement pour dimensionner le stockage.
  • Si Disque logique(<NTDS>)\Moyenne de disque en s/lecture ne se situe pas dans la plage optimale pour le stockage back-end, des E/S supplémentaires sont nécessaires selon la formule suivante : (Disque logique(<NTDS>)\Moyenne de disque en s/lecture) ÷ (Temps d’accès au disque physique) × (Disque logique(<NTDS>)\Moyenne de disque en s/lecture)

Considérations :

• Notez que si le serveur est configuré avec une quantité de RAM inférieure à la quantité optimale, ces valeurs seront inexactes pour la planification. Elles seront à tort trop élevées et pourront quand même être utilisées en tant que scénario le plus pessimiste.
• L’ajout/l’optimisation de la RAM entraîne particulièrement une diminution de la quantité d’E/S de lecture (Disque logique(<NTDS>)\Lectures/s. Cela signifie que la solution de stockage n’a peut-être pas besoin d’être aussi robuste que celle initialement calculée. Malheureusement, toute précision complémentaire à cette déclaration générale dépend de la charge du client. Il est donc impossible de fournir des recommandations générales. La meilleure option consiste à ajuster le dimensionnement du stockage après avoir optimisé la RAM.

Éléments à prendre en compte en matière de virtualisation pour les performances

À l’instar de toute la discussion précédente sur la virtualisation, l’important ici est de veiller à ce que l’infrastructure partagée sous-jacente puisse supporter la charge du contrôleur de domaine, ainsi que les autres ressources à l’aide du média partagé sous-jacent et de tous les chemins qui y mènent. Cela se vérifie si un contrôleur de domaine physique partage le même média sous-jacent sur une infrastructure SAN, NAS ou iSCSI que d’autres serveurs ou applications, s’il s’agit d’un invité utilisant un accès direct à une infrastructure SAN, NAS ou iSCSI qui partage le média sous-jacent ou si l’invité utilise un fichier VHD qui réside sur un média partagé localement ou une infrastructure SAN, NAS ou iSCSI. L’exercice de planification vise à vérifier que le média sous-jacent peut supporter la charge totale de tous les consommateurs.

En outre, du point de vue de l’invité, comme il existe d’autres chemins de code à parcourir, devoir passer par un hôte pour accéder au stockage a un impact sur les performances. Sans surprise, les tests de performances du stockage indiquent que la virtualisation a un impact sur le débit propre à l’utilisation du processeur du système hôte (consultez l’annexe A : Critères de dimensionnement des processeurs), qui est évidemment influencée par les ressources de l’hôte demandées par l’invité. Ces éléments s’ajoutent aux éléments à prendre en compte en matière de virtualisation pour les besoins de traitement dans un scénario virtualisé (consultez Éléments à prendre en compte en matière de virtualisation pour le traitement).

Le fait qu’il existe une diversité d’options de stockage disponibles dont l’impact sur les performances est différent ajoute encore de la complexité. Pour obtenir une estimation prudente lors de la migration d’un environnement physique vers un environnement virtuel, utilisez un coefficient multiplicateur de 1,10 pour adapter les différentes options de stockage pour les invités virtualisés sur Hyper-V, comme un stockage direct, une carte SCSI ou un IDE. Les adaptations nécessaires lors du transfert entre les différents scénarios de stockage sont sans rapport avec la nature du stockage (local, SAN, NAS ou iSCSI).

Exemple de résumé de calcul

Détermination de la quantité d’E/S nécessaires pour un système sain dans des conditions de fonctionnement normales :

• Disque logique(<Lecteur de base de données NTDS>)\Transferts/s pendant la période de pointe de 15 minutes
• Pour déterminer la quantité d’E/S nécessaires pour le stockage quand la capacité du stockage sous-jacent est dépassée :

  IOPS nécessaires = (Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/lecture ÷ <Moyenne de disque cible en s/lecture>) × Disque logique(<Lecteur de base de données NTDS>)\Lectures/s

Compteur	Valeur
Disque logique réel(<Lecteur de base de données NTDS>)\Moyenne de disque en s/Transfert	0,02 secondes (20 millisecondes)
Disque logique cible(<Lecteur de base de données NTDS>)\Moyenne de disque en s/Transfert	0,01 secondes
Coefficient multiplicateur en cas de changement des E/S disponibles	0,02 ÷ 0,01 = 2

Nom de la valeur	Valeur
Disque logique(<Lecteur de base de données NTDS>)\Transferts/s	400
Coefficient multiplicateur en cas de changement des E/S disponibles	2
Nombre total d’IOPS nécessaires pendant la période de pointe	800

Pour déterminer la vitesse à laquelle le cache doit se réchauffer :

• Déterminez la durée maximale acceptable pour réchauffer le cache. Il s’agit du temps nécessaire pour charger l’intégralité de la base de données à partir du disque, ou pour les scénarios dans lesquels la base de données entière ne peut pas être chargée dans la RAM, il s’agit du temps maximal pour remplir la RAM.
• Déterminez la taille de la base de données, hors espaces blancs. Pour plus d’informations, consultez Évaluation du stockage.
• Divisez la taille de la base de données par 8 Ko. Vous obtenez ainsi le nombre total d’E/S nécessaires pour charger la base de données.
• Divisez le nombre total d’E/S par le nombre de secondes dans la période définie.

Notez que le débit calculé, bien que précis, ne sera pas exact, car les pages précédemment chargées sont supprimées si le moteur de stockage extensible n’est pas configuré pour avoir une taille de cache fixe et qu’AD DS utilise par défaut une taille de cache variable.

Points de données à collecter	Valeurs
Délai maximal acceptable de réchauffement	10 minutes (600 secondes)
Taille de la base de données	2 Go

Étape de calcul	Formule	Résultat
Calculer la taille de la base de données en pages	(2 Go × 1024 × 1024) = Taille de la base de données en Ko	2 097 152 Ko
Calculer le nombre de pages dans la base de données	2 097 152 Ko ÷ 8 Ko = Nombre de pages	262 144 pages
Calculer les IOPS nécessaires pour réchauffer entièrement le cache	262 144 pages ÷ 600 secondes = IOPS nécessaires	437 IOPS

Traitement en cours

Évaluation de l’utilisation du processeur Active Directory

Pour la plupart des environnements, une fois le stockage, la RAM et la mise en réseau correctement configurés, comme décrit dans la section Planification, la gestion de la capacité de traitement constitue le composant qui mérite le plus d’attention. L’évaluation de la capacité du processeur doit relever deux défis :

• Déterminer si les applications de l’environnement se comportent correctement dans une infrastructure de services partagés, sujet traité dans la section intitulée « Détection des recherches coûteuses et inefficaces » de l’article Création d’applications avec Microsoft Active Directory plus efficaces, ou si elles migrent depuis des appels SAM élémentaires vers des appels LDAP.

  Dans les environnements plus grands, la raison pour laquelle cette question est importante est que les applications codées de façon médiocre peuvent entraîner une volatilité de la charge processeur, « voler » une quantité excessive de temps processeur à d’autres applications, faire monter artificiellement les besoins en capacité et répartir de manière inégale la charge sur les contrôleurs de domaine.

• Comme AD DS est un environnement distribué avec une grande variété de clients potentiels, l’estimation de la dépense d’un « client unique » est propre à l’environnement en raison des modèles d’utilisation et du type ou de la quantité d’applications exploitant AD DS. En bref, à l’instar de la section relative à la mise en réseau, pour une applicabilité large, il est préférable de partir de la perspective de l’évaluation de la capacité totale nécessaire dans l’environnement.

Pour les environnements existants, comme le dimensionnement du stockage a été décrit précédemment, le principe est que le stockage est maintenant correctement dimensionné et que les données relatives à la charge processeur sont valides. À titre de rappel, il est primordial de veiller à ce que le goulot d’étranglement dans le système ne correspondent pas aux performances du stockage. Lorsqu’un goulot d’étranglement existe et que le processeur est en attente, les états inactifs disparaissent une fois le goulot d’étranglement supprimé. À mesure que les états d’attente du processeur sont supprimés, par définition, l’utilisation du processeur augmente, car il n’a plus besoin d’attendre les données. Par conséquent, collectez les compteurs de performances « Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/lecture » et « Process(lsass)\% temps processeur ». Les données dans « Process(lsass)\% temps processeur » sont artificiellement faibles si « Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/lecture » dépasse 10 à 15 ms, ce qui est un seuil général utilisé par le support Microsoft pour résoudre les problèmes de performances liés au stockage. Comme précédemment, il est recommandé que les intervalles échantillons soient de 15, 30 ou 60 minutes. Toute valeur inférieure sera généralement trop volatile pour obtenir de bonnes mesures et toute valeur supérieure va trop lisser les pics quotidiens.

Introduction

Pour prévoir la planification de capacité des contrôleurs de domaine, la puissance de traitement nécessite le plus d’attention et de compréhension. Lors du dimensionnement des systèmes pour garantir des performances maximales, il existe toujours un composant qui est le goulot d’étranglement et, dans un contrôleur de domaine correctement dimensionné, il s’agit du processeur.

Comme dans la section sur la mise en réseau dans laquelle la demande de l’environnement est examinée site par site, il s’agit de faire de même pour la capacité de calcul exigée. Contrairement à la section sur la mise en réseau, dans laquelle les technologies de mise en réseau disponibles dépassent de loin la demande normale, faites plus attention au dimensionnement de la capacité du processeur. Comme n’importe quel environnement, même de taille modérée, tout ce qui dépasse quelques milliers d’utilisateurs simultanés peut entraîner une charge importante sur le processeur.

Malheureusement, en raison de l’énorme variabilité des applications clientes qui exploitent AD, une estimation générale des utilisateurs par processeur est inapplicable à tous les environnements. Plus précisément, les exigences de calcul sont soumises au comportement utilisateur et au profil des applications. Par conséquent, chaque environnement a besoin d’être dimensionné individuellement.

Profil de comportement de site cible

Comme mentionné précédemment, lors de la planification de capacité pour l’ensemble d’un site, l’objectif est de cibler une conception avec une capacité N + 1, de sorte que la défaillance d’un système pendant la période de pointe permettra la poursuite du service à un niveau de qualité raisonnable. Cela signifie que dans un scénario « N », la charge doit être inférieure à 100 % (mieux encore, inférieure à 80 %) pendant les périodes de pointe.

En outre, si les applications et les clients du site respectent les bonnes pratiques pour localiser les contrôleurs de domaine (c’est-à-dire, l’utilisation de la fonction DsGetDcName), les clients doivent être distribués de manière relativement uniforme avec des pics temporaires mineurs dus à certains facteurs.

Dans l’exemple suivant, les hypothèses suivantes sont formulées :

• Chacun des cinq contrôleurs de domaine du site a quatre processeurs.
• L’utilisation totale du processeur cible pendant les heures de bureau s’élève à 40 % dans des conditions normales de fonctionnement (« N + 1 ») et à 60 % sinon (« N »). En dehors des heures de bureau, l’utilisation du processeur cible s’élève à 80 %, car les logiciels de sauvegarde et d’autres opérations de maintenance sont supposés consommer toutes les ressources disponibles.

Analyse des données du graphique (Processor Information(_Total)\% Processor Utility) pour chacun des contrôleurs de domaine :

• Dans la plupart des cas, la charge est distribuée de manière relativement uniforme, ce qui est normal quand les clients utilisent le localisateur de contrôleur de domaine et qu’ils disposent de recherches bien écrites.

• Il existe plusieurs pics de cinq minutes à 10 %, dont certains peuvent atteindre 20 %. En règle générale, sauf s’ils entraînent un dépassement de la cible du plan de capacité, cela ne vaut pas la peine de les investiguer.

• La période de pointe pour tous les systèmes est comprise entre 8h00 et 9h15. Avec la transition en douceur de 5h00 à 17h00 environ, cela indique généralement le cycle des opérations. Les pics plus aléatoires d’utilisation du processeur dans un scénario zone par zone entre 17h00 et 4h00 sortent du champ des préoccupations de la planification de capacité.

  Notes

  Sur un système bien géré, ces pics peuvent correspondre à des logiciels de sauvegarde en cours d’exécution, des analyses antivirus du système complètes, un inventaire matériel ou logiciel, un déploiement de logiciels ou de correctifs, etc. Étant donné qu’ils ne se situent pas dans le cycle des opérations utilisateur de pointe, les cibles ne sont pas dépassées.

• Comme chaque système représente environ 40 % et que tous les systèmes ont le même nombre de processeurs, en cas d’échec ou de mise hors connexion, les systèmes restants s’exécuteraient à un niveau estimé à 53 % (la charge de 40 % du système D est répartie uniformément et ajoutée à la charge existante de 40 % du système A et du système C). Pour plusieurs raisons, cette hypothèse linéaire n’est PAS parfaitement exacte, mais elle offre suffisamment de précision pour une évaluation.

  Autre scénario : deux contrôleurs de domaine s’exécutant à 40 % avec un contrôleur de domaine qui échoue. L’utilisation du processeur estimée sur le contrôleur de domaine restant est estimé à 80 %. Cela dépasse largement les seuils décrits ci-dessus pour le plan de capacité et commence également à limiter sévèrement la marge pour les 10 % à 20 % observés dans le profil de charge ci-dessus, ce qui signifie que les pics porteraient le contrôleur de domaine à 90 % voire 100 % pendant le scénario « N », ce qui dégraderait assurément la réactivité.

Calcul des demandes processeur

Le compteur de performances « Process\% temps processeur » calcule le total des temps que tous les threads d’une application passent sur le processeur et divise le résultat par la quantité totale de temps système qui s’est écoulée. L’effet de cette addition est qu’une application multithread sur un système multiprocesseur peut dépasser 100 % de temps processeur, ce qui serait interprété d’une manière TRÈS différente de « Informations processeur\% de rendement du processeur ». Dans la pratique, « Process(lsass)\% temps processeur » peut être considéré comme le nombre de processeurs s’exécutant à 100 % nécessaires pour prendre en charge les demandes du processus. Une valeur de 200 % signifie que 2 processeurs, chacun à 100 %, sont nécessaires pour prendre en charge toute la charge AD DS. Bien qu’un processeur s’exécutant à 100 % de capacité soit le plus rentable en termes de dépenses dédiées aux processeurs, à l’alimentation et à la consommation d’énergie, pour plusieurs raisons détaillées dans l’annexe A, la réactivité sur un système multithread est meilleure quand le système ne fonctionne pas à 100 %.

Pour tenir compte des pics temporaires de la charge du client, il est recommandé de cibler une période de pointe de processeur comprise entre 40 % et 60 % de la capacité du système. En utilisant l’exemple ci-dessus, cela signifie qu’entre 3,33 (cible de 60 %) et 5 (cible de 40 %) processeurs sont nécessaires pour la charge AD DS (processus lsass). Une capacité supplémentaire doit être ajoutée en fonction des demandes du système d’exploitation de base et d’autres agents nécessaires (comme l’antivirus, la sauvegarde, le monitoring, etc.). Même si l’impact des agents a besoin d’être évalué environnement par environnement, il est possible d’estimer entre 5 % et 10 % d’un seul processeur. Dans l’exemple actuel, cela suggère qu’entre 3,43 (cible de 60 %) et 5,1 (cible de 40 %) processeurs sont nécessaires pendant les périodes de pointe.

Le moyen le plus simple d’effectuer ce calcul consiste à utiliser la vue « Zone empilée » dans l’Analyseur de fiabilité et de performances Windows (perfmon), en veillant à ce que tous les compteurs soient mis à l’échelle de la même façon.

Il est supposé que :

• L’objectif est de réduire l’empreinte au nombre le plus petit possible de serveurs. Idéalement, un seul serveur porte la charge et un autre serveur est ajouté pour la redondance (scénario N + 1).

Connaissances acquises à partir des données du graphique (Process(lsass)\% temps processeur) :

• Le jour ouvrable commence à monter en puissance vers 7h00 et diminue à 17h00.
• La période d’activité de pointe s’étale de 9h30 à 11h00.

  Notes

  Toutes les données de performances sont historiques. Le point de données de pointe à 9h15 indique la charge entre 9h00 et 9h15.

• Il existe des pics avant 7h00, ce qui peut indiquer une charge en provenance d’autres fuseaux horaires ou une activité d’infrastructure en arrière-plan, comme des sauvegardes. Étant donné que le pic de 9h30 dépasse cette activité, il n’est pas pertinent.
• Le site comprend trois contrôleurs de domaine.

Au niveau de la charge maximale, lsass consomme environ 485 % d’un seul processeur, soit 4,85 processeurs s’exécutant à 100 %. Conformément au calcul précédent, cela signifie que le site a besoin d’environ 12,25 processeurs pour AD DS. Ajoutez les suggestions ci-dessus de 5 % à 10 % pour les processus en arrière-plan, ce qui signifie que le remplacement du serveur aujourd’hui nécessiterait environ 12,30 à 12,35 processeurs pour supporter la même charge. Une estimation environnementale de la croissance doit maintenant être prise en compte.

Quand régler des pondérations LDAP

Dans plusieurs scénarios, le réglage de LdapSrvWeight doit être envisagé. Dans le contexte de la planification de capacité, cette opération est effectuée quand les charges d’application ou d’utilisateur ne sont pas bien équilibrées ou que les systèmes sous-jacents ne sont pas bien équilibrés en termes de capacité. Les raisons à cela au-delà de la planification de capacité n’entrent pas dans le cadre de cet article.

Il existe deux raisons courantes de régler des pondérations LDAP :

• L’émulateur PDC est un exemple qui affecte chaque environnement pour lequel le comportement de la charge utilisateur ou application n’est pas distribué uniformément. Étant donné que certains outils et actions ciblent l’émulateur PDC, comme les outils de gestion de stratégie de groupe, les deuxièmes tentatives en cas d’échecs d’authentification ou d’établissement d’approbation, etc., les ressources processeur sur l’émulateur PDC risquent d’être plus demandées qu’ailleurs dans le site.
  • Il ne s’avère utile de les régler que s’il existe une différence notable dans l’utilisation du processeur afin de réduire la charge sur l’émulateur PDC et d’augmenter la charge sur d’autres contrôleurs de domaine pour répartir plus uniformément de la charge.
  • Dans ce cas, définissez LDAPSrvWeight entre 50 et 75 pour l’émulateur PDC.
• Serveurs avec des nombres différents de processeurs (et de vitesses) dans un site. Par exemple, supposons qu’il existe deux serveurs à huit cœurs et un serveur à quatre cœurs. Le dernier serveur a la moitié des processeurs des deux autres serveurs. Cela signifie qu’une charge du client bien distribuée va augmenter la charge moyenne du processeur sur la zone à quatre cœurs environ deux fois plus que sur celle à huit cœurs.
  • Par exemple, les deux zones à huit cœurs s’exécutent à 40 % et celle à quatre cœurs s’exécute à 80 %.
  • Considérez également l’impact de la perte d’une zone à huit cœurs dans ce scénario, notamment le fait que la zone à quatre cœurs se retrouve alors surchargée.

Exemple 1 – Contrôleur de domaine principal

Système	Utilisation avec les valeurs par défaut	Nouveau LdapSrvWeight	Nouvelle utilisation estimée
Contrôleur de domaine 1 (émulateur de contrôleur de domaine principal)	53 %	57	40%
Contrôleur de domaine 2	33 %	100	40%
Contrôleur de domaine 3	33 %	100	40%

Le problème ici est que si le rôle d’émulateur de contrôleur de domaine principal est transféré ou saisi, en particulier vers un autre contrôleur de domaine dans le site, une augmentation considérable aura lieu sur le nouvel émulateur de contrôleur de domaine principal.

À l’aide de l’exemple issu de la section Profil de comportement de site cible, une hypothèse a été faite que les trois contrôleurs de domaine du site avaient quatre processeurs. Que devrait-il se passer, dans des conditions normales, si l’un des contrôleurs de domaine avait huit processeurs ? Il y aurait deux contrôleurs de domaine à 40 % d’utilisation et un à 20 % d’utilisation. Bien qu’elle ne soit pas incorrecte, il est possible d’équilibrer la charge un peu mieux. Pour cela, tirez parti des pondérations LDAP. Voici un exemple de scénario :

Exemple 2 – Nombres de processeurs différents

Système	Informations processeur\% de rendement du processeur(_Total) Utilisation avec les valeurs par défaut	Nouveau LdapSrvWeight	Nouvelle utilisation estimée
Contrôleur de domaine 1 à 4 processeurs	40	100	30 %
Contrôleur de domaine 2 à 4 processeurs	40	100	30 %
Contrôleur de domaine 3 à 8 processeurs	20	200	30 %

Soyez toutefois très prudent avec ces scénarios. Comme observé ci-dessus, le calcul semble idéal sur le papier. Mais tout au long de cet article, la planification d’un scénario « N + 1 » est d’une importance capitale. L’impact de la mise hors connexion d’un seul contrôleur de domaine doit être calculé pour chaque scénario. Dans le scénario précédent, où la distribution de la charge est uniforme, afin de garantir une charge de 60 % pendant un scénario « N », la charge étant équilibrée uniformément sur tous les serveurs, la distribution reste correcte tant que les ratios restent cohérents. Si vous examinez le scénario de réglage de l’émulateur de contrôleur de domaine principal et, en général, tous les scénarios où la charge utilisateur ou application n’est pas équilibrée, l’effet est très différent :

Système	Utilisation ajustée	Nouveau LdapSrvWeight	Nouvelle utilisation estimée
Contrôleur de domaine 1 (émulateur de contrôleur de domaine principal)	40%	85 %	47 %
Contrôleur de domaine 2	40%	100	53 %
Contrôleur de domaine 3	40%	100	53 %

Éléments à prendre en compte en matière de virtualisation pour le traitement

Il existe deux couches de planification de capacité à effectuer dans un environnement virtualisé. Au niveau de l’hôte, à l’instar de l’identification du cycle d’activité décrit précédemment pour le traitement des contrôleurs de domaine, des seuils ont besoin d’être identifiés pendant la période de pointe. Étant donné que les principes sous-jacents sont les mêmes pour une machine hôte qui planifie des threads invités sur le processeur que pour des threads AD DS sur le processeur d’une machine physique, le même objectif de 40 % à 60 % sur l’hôte sous-jacent est recommandé. Au niveau de la couche suivante, la couche de l’invité, étant donné que les principes de la planification des threads n’ont pas changé, l’objectif au sein de l’invité reste dans la plage des 40 % à 60 %.

Dans un scénario mappé direct, avec un seul invité par hôte, toute la planification de capacité effectuée à ce stade doit être additionnée aux exigences (RAM, disque, réseau) du système d’exploitation hôte sous-jacent. Dans un scénario d’hôte partagé, les tests indiquent qu’il existe un impact de 10 % sur l’efficacité des processeurs sous-jacents. Cela signifie que si un site a besoin de 10 processeurs à une cible de 40 %, la quantité recommandée de processeurs virtuels à allouer sur tous les invités « N » s’élève à 11. Dans un site avec une distribution mixte de serveurs physiques et de serveurs virtuels, le modificateur s’applique uniquement aux machines virtuelles. Par exemple, si un site a un scénario « N + 1 », un seul serveur physique ou directement mappé avec 10 processeurs équivaut à environ un seul invité avec 11 processeurs sur un hôte, 11 processeurs étant réservés au contrôleur de domaine.

Tout au long de l’analyse et du calcul des quantités de processeurs nécessaires pour supporter la charge AD DS, les nombres de processeurs correspondant à ce qui peut être acheté en termes de matériel physique ne correspondent pas nécessairement de manière exacte. La virtualisation élimine la nécessité d’arrondir. La virtualisation réduit les efforts nécessaires pour ajouter une capacité de calcul à un site, compte tenu de la facilité avec laquelle un processeur peut être ajouté à une machine virtuelle. Cela n’élimine pas la nécessité d’évaluer avec précision la puissance de calcul nécessaire afin que le matériel sous-jacent soit disponible lorsque des processeurs supplémentaires ont besoin d’être ajoutés aux invités. Comme toujours, n’oubliez pas de planifier et de superviser la croissance de la demande.

Exemple de résumé de calcul

Système	Processeur de pointe
Contrôleur de domaine 1	120%
Contrôleur de domaine 2	147 %
Contrôleur de domaine 3	218 %
Processeur total utilisé	485 %

Nombre de systèmes cibles	Bande passante totale (comme ci-dessus)
Processeurs nécessaires à une cible de 40 %	4,85 ÷ 0,4 = 12,125

Encore une fois, en raison de l’importance de ce point, n’oubliez pas de planifier la croissance. En supposant une croissance de 50 % au cours des trois prochaines années, cet environnement aura besoin de 18,375 processeurs (12,25 × 1,5) d’ici trois ans. Un autre plan consisterait à effectuer une révision à l’issue de la première année afin d’ajouter une capacité supplémentaire selon les besoins.

Charge d’authentification du client avec approbation croisée pour NTLM

Évaluation de la charge d’authentification du client avec approbation croisée

De nombreux environnements peuvent avoir un ou plusieurs domaines connectés par une approbation. Une demande d’authentification effectuée pour une identité située dans un autre domaine qui n’utilise pas l’authentification Kerberos a besoin de traverser une approbation à l’aide du canal sécurisé du contrôleur de domaine jusqu’à un autre contrôleur de domaine situé soit dans le domaine de destination, soit dans le domaine suivant du chemin vers le domaine de destination. Le nombre d’appels simultanés utilisant le canal sécurisé qu’un contrôleur de domaine peut effectuer à un contrôleur de domaine situé dans un domaine approuvé est contrôlé par un paramètre appelé MaxConcurrentAPI. Pour les contrôleurs de domaine, vous pouvez vérifier que le canal sécurisé est capable de gérer la charge grâce à l’une de deux approches : régler MaxConcurrentAPI ou, au sein d’une forêt, créer des raccourcis d’approbation. Pour évaluer le volume de trafic dans une approbation individuelle, reportez-vous Guide pratique pour effectuer un réglage des performances de l’authentification NTLM à l’aide du paramètre MaxConcurrentApi.

Pendant la collecte des données, cette valeur, comme dans tous les autres scénarios, doit être collectée pendant les périodes d’activité de pointe de la journée pour que les données s’avèrent utiles.

Notes

Les scénarios intraforêt et interforêt peuvent entraîner une authentification qui traverse plusieurs approbations, dont chaque étape a besoin d’être paramétrée.

Planification

Plusieurs applications utilisent l’authentification NTLM par défaut ou elles l’utilisent dans un scénario de configuration spécifique. Les serveurs d’applications augmentent en capacité et desservent un nombre croissant de clients actifs. Il existe également une tendance selon laquelle les clients gardent des sessions ouvertes pendant un temps limité et préfèrent se reconnecter régulièrement (par exemple, une synchronisation d’extraction d’e-mails). Un autre exemple courant de charge NTLM élevée a trait aux serveurs proxy web qui nécessitent une authentification pour l’accès à Internet.

Ces applications peuvent entraîner une charge importante pour l’authentification NTLM, ce qui peut mettre des tensions considérables sur les contrôleurs de domaine, notamment lorsque les utilisateurs et les ressources se trouvent dans des domaines différents.

Il existe plusieurs approches pour gérer la charge d’approbation croisée, qui dans la pratique sont utilisées conjointement plutôt que dans un scénario où elles s’excluent mutuellement. Les options possibles sont les suivantes :

• Réduisez l’authentification du client avec une approbation croisée en localisant les services qu’un utilisateur consomme dans le même domaine que celui dans lequel l’utilisateur réside.
• Augmentez le nombre de canaux sécurisés disponibles. Cela concerne le trafic intraforêt et interforêt. Ces canaux sont appelés des raccourcis d’approbation.
• Réglez les paramètres par défaut pour MaxConcurrentAPI.

Pour paramétrer MaxConcurrentAPI sur un serveur existant, l’équation est la suivante :

New_MaxConcurrentApi_setting ≥ (semaphore_acquires + semaphore_time-outs) × average_semaphore_hold_time ÷ time_collection_length

Pour plus d’informations, consultez l’article de la base de connaissances 2688798 : Guide pratique pour effectuer un réglage des performances de l’authentification NTLM à l’aide du paramètre MaxConcurrentApi.

Éléments à prendre en compte en matière de virtualisation

Aucun, il s’agit d’un paramètre du système d’exploitation.

Exemple de résumé de calcul

Type de données	Valeur
Acquisitions de sémaphore (minimum)	6 161
Acquisitions de sémaphore (maximum)	6 762
Expirations de sémaphore	0
Temps moyen de conservation de sémaphore	0,012
Durée de la collecte (secondes)	1 minute 11 secondes (71 secondes)
Formule (extraite de la base de connaissances 2688798)	((6762 – 6161) + 0) × 0,012 /
Valeur minimale de MaxConcurrentAPI	((6762 – 6161) + 0) × 0,012 ÷ 71 = 0,101

Pour ce système, les valeurs par défaut sont acceptables pendant cette période.

Monitoring de la conformité avec des objectifs de planification de capacité

Tout au long de cet article, il a été expliqué que la planification et la mise à l’échelle visent des objectifs d’utilisation. Voici un tableau récapitulatif des seuils recommandés à superviser pour veiller à ce que les systèmes fonctionnent avec les seuils de capacité adéquats. N’oubliez pas qu’il ne s’agit pas de seuils de performances, mais de seuils de planification de capacité. Un serveur qui opère au-delà de ces seuils continue de fonctionner, mais il est alors justifié de commencer à vérifier que toutes les applications se comportent normalement. Si ces applications se comportent normalement, il convient de commencer à évaluer des mises à niveau de matériel ou d’autres modifications de configuration.

Category	Compteur de performances	Intervalle/Échantillonnage	Cible	Avertissement
Processeur	Informations processeur(_Total)\% de rendement du processeur	60 min	40%	60%
RAM (Windows Server 2008 R2 ou version antérieure)	Mémoire\Mo disponibles	< 100 Mo	N/A	< 100 Mo
RAM (Windows Server 2012)	Mémoire\Durée(s) de vie moyenne(s) du cache de secours à long terme	30 min	À tester	À tester
Réseau	Interface réseau(*)\Octets envoyés/s Interface réseau(*)\Octets reçus/s	30 min	40%	60%
Stockage	Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/lecture Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/écriture	60 min	10 ms	15 ms
Services AD	Netlogon(*)\Temps moyen de conservation de sémaphore	60 min	0	1 seconde

Annexe A : Critères de dimensionnement des processeurs

Définitions

Processeur (microprocesseur) : composant qui lit et exécute les instructions du programme

Processeur : unité centrale

Processeur multicœur : plusieurs processeurs sur le même circuit intégré

Multiprocesseur : plusieurs processeurs qui ne sont pas sur le même circuit intégré

Processeur logique : un moteur de calcul logique unique du point de vue du système d’exploitation

Cela inclut un processeur hyper-thread, un monocœur sur un processeur multicœur ou un processeur monocœur.

Comme les systèmes serveur d’aujourd’hui ont plusieurs processeurs, plusieurs processeurs multicœurs et la technologie hyper-threading, ces informations sont généralisées pour couvrir les deux scénarios. Par conséquent, le terme processeur logique est utilisé car il représente le point de vue des moteurs de calcul disponibles pour le système d’exploitation et l’application.

Parallélisme au niveau des threads

Chaque thread est une tâche indépendante, car il possède sa propre pile et ses propres instructions. Étant donné qu’AD DS est multithread et que le nombre de threads disponibles peut être ajusté conformément au guide pratique pour afficher et définir une stratégie LDAP dans Active Directory à l’aide de Ntdsutil.exe, il se met convenablement à l’échelle sur plusieurs processeurs logiques.

Parallélisme au niveau des données

Celui-ci implique de partager les données entre plusieurs threads au sein d’un seul processus (en cas de processus AD DS seul) et entre plusieurs threads dans plusieurs processus (cas général). En simplifiant à l’extrême le cas, cela signifie que toutes les modifications apportées aux données sont répercutées sur tous les threads en cours d’exécution dans tous les différents niveaux de cache (L1, L2, L3) sur tous les cœurs exécutant ces threads et mettant à jour la mémoire partagée. Les performances peuvent se dégrader pendant les opérations d’écriture, pendant que tous les différents emplacements de mémoire redeviennent cohérents pour que le traitement des instructions puisse se poursuivre.

Considérations relatives à la vitesse du processeur et des cœurs multiples

La règle générale est que les processeurs logiques plus rapides réduisent la durée nécessaire pour traiter une série d’instructions, tandis que des processeurs logiques en plus grand nombre signifient que plus de tâches peuvent être exécutées en même temps. Ces règles de base se ramifient à mesure que les scénarios deviennent intrinsèquement plus complexes avec des considérations relatives à l’extraction des données de la mémoire partagée, à l’attente du parallélisme au niveau des données et à la surcharge liée à la gestion de plusieurs threads. C’est également la raison pour laquelle la scalabilité dans les systèmes multicœurs n’est pas linéaire.

Considérez l’analogie suivante pour illustrer ces considérations : prenez l’exemple d’une autoroute, avec chaque thread qui correspond à une voiture individuelle, chaque voie étant un cœur et la limite de vitesse étant la vitesse d’horloge.

1. S’il n’y a qu’une seule voiture sur l’autoroute, peu importe qu’il y ait deux ou 12 voies. Cette voiture va aller aussi vite que la limite de vitesse le permet.
2. Supposons que les données dont le thread a besoin ne soient pas immédiatement disponibles. Dans l’analogie, cela correspond à un tronçon de route fermé. S’il n’y a qu’une seule voiture sur l’autoroute, peu importe la limite de vitesse jusqu’à ce que la voie soit rouverte (les données sont extraites de la mémoire).
3. À mesure que le nombre de voitures augmente, la surcharge liée à la gestion du nombre de voitures augmente. Comparez l’expérience de conduite et la quantité d’attention nécessaire lorsque la route est pratiquement déserte (par exemple, tard le soir) et lorsque la circulation est dense (par exemple, en milieu d’après-midi, mais pas à l’heure de pointe). Tenez aussi compte de la quantité d’attention nécessaire lorsque vous conduisez sur une autoroute à deux voies, où il n’y a qu’une seule autre voie sur laquelle surveiller les autres conducteurs, par rapport à une autoroute à six voies où votre vigilance doit porter sur un nombre beaucoup plus élevé de conducteurs.

   Notes

   L’analogie du scénario à l’heure de pointe est développée dans la section suivante : Temps de réponse/Impact de l’activité système sur les performances.

Par conséquent, choisir d’augmenter le nombre de processeurs ou d’utiliser des processeurs plus rapides dépend fortement du comportement de l’application, qui dans le cas d’AD DS, est propre à l’environnement et varie même d’un serveur à l’autre au sein d’un environnement. C’est pourquoi les références mentionnées plus haut dans l’article n’ont pas vocation à être rigoureusement précises. Une marge de sécurité est incluse dans les calculs. Lorsque vous prenez des décisions d’achat en fonction d’un budget, il est recommandé d’optimiser d’abord l’utilisation des processeurs à 40 % (ou le nombre souhaité pour l’environnement), avant d’envisager d’acheter des processeurs plus rapides. Une synchronisation accrue entre davantage de processeurs réduit le véritable bénéfice d’un plus grand nombre de processeurs dans la progression linéaire (le double de processeurs fournit moins du double de puissance de calcul supplémentaire disponible).

Notes

Les lois d’Amdahl et de Gustafson sont des concepts pertinents ici.

Temps de réponse/Impact de l’activité système sur les performances

La théorie de la mise en file d’attente correspond à l’étude mathématique des files d’attente. Dans la théorie de la mise en file d’attente, la loi d’utilisation est représentée par l’équation suivante :

U k = B ÷ T

Où U k est le pourcentage d’utilisation, B est la durée d’activité et T est la durée totale pendant laquelle le système a été observé. Traduit dans le contexte de Windows, cela signifie le nombre de threads d’intervalle de 100 nanosecondes (ns) qui sont dans un état d’exécution divisé par le nombre d’intervalles de 100 ns disponibles dans un intervalle de temps donné. Il s’agit exactement de la formule de calcul du % de rendement du processeur (objet processeur de référence et PERF_100NSEC_TIMER_INV).

La théorie de la mise en file d’attente fournit également la formule suivante : N = U k ÷ (1 – U k) pour estimer le nombre d’éléments en attente en fonction de l’utilisation (N est la longueur de la file d’attente). La création d’un graphique sur tous les intervalles d’utilisation fournit les estimations suivantes de la durée de la file d’attente avant d’accéder au processeur à une charge processeur donnée.

Il est observé qu’après une charge processeur de 50 % en moyenne, il y a toujours une attente d’un seul autre élément dans la file d’attente, avec une augmentation sensiblement rapide après environ 70 % d’utilisation du processeur.

Revenons à l’analogie de l’autoroute utilisée précédemment dans cette section :

• Les heures d’affluence du « milieu de l’après-midi » se situeraient, hypothétiquement, dans la plage de 40 % à 70 %. Il y a suffisamment de circulation pour que la capacité d’un conducteur à choisir une voie ne soit pas très limitée, et le risque qu’un autre conducteur soit devant, bien qu’élevé, ne nécessite pas un niveau d’effort soutenu pour « assurer » une distance de sécurité avec les autres voitures sur la voie.
• Il est à noter que le trafic approche l’heure de pointe, le système de voies approche les 100 % de sa capacité. Changer de voie peut devenir très difficile parce que les voitures sont si proches les unes des autres qu’il faut faire preuve d’une plus grande prudence.

C’est pourquoi les moyennes à long terme pour la capacité estimées de manière prudente à 40 % permettent d’avoir une marge pour les pics de charge anormaux, qu’il s’agisse de pics transitoires (comme des requêtes mal codées qui s’exécutent pendant quelques minutes) ou de rafales anormales dans la charge générale (le matin du premier jour après un long week-end).

L’affirmation ci-dessus qui considère que le calcul du pourcentage de temps processeur s’apparente à la loi d’utilisation est une simplification pour faciliter la compréhension générale. Pour les plus rigoureux du point de vue mathématique :

• Traduction de PERF_100NSEC_TIMER_INV
  • B = Nombre d’intervalles de 100 ns que le thread « inactif » dépense sur le processeur logique. Modification de la variable « X » dans le calcul de PERF_100NSEC_TIMER_INV.
  • T = Nombre total d’intervalles de 100 ns dans un intervalle de temps donné. Modification de la variable « Y » dans le calcul de PERF_100NSEC_TIMER_INV.
  • U k = Pourcentage d’utilisation du processeur logique par « thread inactif » ou % de temps d’inactivité.
• Description du calcul :
  • U k = 1 – % temps processeur
  • % temps processeur = 1 – U k
  • % temps processeur = 1 – B / T
  • % temps processeur = 1 – X1 – X0 / Y1 – Y0

Application des concepts à la planification de capacité

Les calculs précédents peuvent donner une apparence extrêmement complexe aux déterminations du nombre de processeurs logiques nécessaires dans un système. C’est pourquoi l’approche du dimensionnement des systèmes se concentre sur la détermination de l’utilisation cible maximale en fonction de la charge actuelle et sur le calcul du nombre de processeurs logiques nécessaires pour y parvenir. En outre, alors que les vitesses de processeur logique ont un impact significatif sur les performances, ce sont l’efficacité du cache, les besoins de cohérence de la mémoire, la planification et la synchronisation des threads, ainsi que la charge du client équilibrée de manière imparfaite qui ont tous un impact significatif sur les performances, qui varie serveur par serveur. Avec le coût relativement faible de la puissance de calcul, essayer d’analyser et de déterminer le nombre parfait de processeurs nécessaires devient plus un exercice théorique qu’une manière d’ajouter de la valeur métier.

Quarante pour cent ne correspondent pas à une exigence difficile et rapide, il s’agit d’un point de départ raisonnable. Différents consommateurs d’Active Directory nécessitent différents niveaux de réactivité. Il peut y avoir des scénarios dans lesquels les environnements peuvent s’exécuter à 80 % ou 90 % d’utilisation en moyenne soutenue, car les temps d’attente accrus pour l’accès au processeur n’auront pas d’impact notable sur les performances du client. Il est important de réitérer qu’il existe de nombreuses zones dans le système qui sont beaucoup plus lentes que son processeur logique, notamment l’accès à la RAM, l’accès au disque et la transmission de la réponse sur le réseau. Tous ces éléments ont besoin d’être réglés conjointement. Exemples :

• L’ajout de processeurs supplémentaires à un système lié au disque s’exécutant à 90 % ne va probablement pas améliorer considérablement les performances. Une analyse plus approfondie du système permettra probablement d’identifier qu’il existe un grand nombre de threads qui n’arrivent même pas sur le processeur, car ils attendent que les E/S se terminent.
• La résolution des problèmes liés au disque signifie éventuellement que les threads qui passaient auparavant beaucoup de temps dans un état d’attente ne sont plus dans un état d’attente pour les E/S et que la concurrence est plus forte vis-à-vis du temps processeur, ce qui signifie que l’utilisation à 90 % de l’exemple précédent va atteindre 100 % (car elle ne peut pas aller au-delà). Les deux composants ont besoin d’être réglés conjointement.

  Notes

  Informations processeur(*)\% de rendement du processeur peut dépasser 100 % avec des systèmes qui disposent d’un mode « Turbo ». C’est là que le processeur dépasse la vitesse du processeur évaluée pendant de courtes périodes. Pour plus d’informations, consultez la documentation des fabricants de processeurs et la description du compteur.

Les considérations liées à l’utilisation de l’ensemble du système amène également le sujet des contrôleurs de domaine en tant qu’invités virtualisés. La section Temps de réponse/Impact de l’activité système sur les performances s’applique à la fois à l’hôte et à l’invité dans un scénario virtualisé. C’est pourquoi, dans un hôte comprenant un seul invité, un contrôleur de domaine (et généralement tout système) offre presque les mêmes performances que sur du matériel physique. L’ajout d’invités supplémentaires aux hôtes augmente l’utilisation de l’hôte sous-jacent, ce qui augmente les temps d’attente pour accéder aux processeurs, comme expliqué précédemment. En bref, l’utilisation de processeurs logiques a besoin d’être gérée à la fois au niveau de l’hôte et au niveau de l’invité.

En reprenant les analogies précédentes, où l’autoroute correspond au matériel physique, la machine virtuelle invitée prend les traits d’un bus (un bus express qui va directement à la destination souhaitée par le voyageur). Imaginez les quatre scénarios suivants :

• En dehors des heures de forte affluence, un passager monte dans un bus qui est presque vide, et le bus arrive sur une voie qui est aussi presque déserte. Comme le trafic est très fluide, le passager profite d’un agréable voyage et arrive à sa destination aussi vite que s’il avait conduit sa propre voiture. Le temps de trajet du passager est quand même restreint par la limite de vitesse.
• Nous sommes en dehors des heures de forte affluence, donc le bus est presque vide, mais la plupart des voies sont fermées, si bien que l’autoroute est quand même engorgée. Le passager se trouve dans un bus presque vide sur une route engorgée. Bien que le passager n’ait pas beaucoup de concurrence dans le bus pour trouver un siège, le temps de trajet total est quand même imposé par le reste du trafic environnant.
• C’est maintenant l’heure de pointe, donc l’autoroute et le bus sont congestionnés. Non seulement le voyage prend plus de temps, mais c’est un cauchemar que de monter et descendre du bus parce que les passagers se bousculent et sur l’autoroute, ce n’est pas beaucoup mieux. L’ajout d’autres bus (de processeurs logiques à l’invité) ne veut pas dire qu’ils pourront trouver de la place sur la route facilement, ni que le voyage durera moins longtemps.
• Le dernier scénario, même s’il déforme un peu l’analogie, est celui dans lequel le bus est complet, mais la route n’est pas encombrée. Même si le passager a quand même des difficultés pour monter et descendre du bus, le trajet sera efficace une fois le bus sur la route. Il s’agit du seul scénario dans lequel l’ajout de bus supplémentaires (de processeurs logiques à l’invité) permet d’améliorer les performances de l’invité.

Ainsi, il est relativement facile d’extrapoler qu’il existe plusieurs scénarios entre un état d’utilisation compris entre 0 % et 100 % de la route et un état d’utilisation compris entre 0 % et 100 % du bus dont les degrés d’impact varient.

L’application des principes ci-dessus d’une utilisation à 40 % du processeur comme cible raisonnable pour l’hôte et l’invité constitue donc un point de départ judicieux pour le même raisonnement que ci-dessus, la quantité de mise en file d’attente.

Annexe B : Considérations relatives aux différentes vitesses du processeur et à l’effet de la gestion de l’alimentation du processeur sur les vitesses du processeur

Dans les sections sur la sélection des processeurs, l’hypothèse est faite que le processeur fonctionne à 100 % de sa vitesse d’horloge pendant toute la durée de la collecte des données et que les systèmes de remplacement ont des processeurs de même cadence. Bien que les deux hypothèses soient fausses dans la pratique, notamment avec Windows Server 2008 R2 et versions ultérieures, où le mode de gestion de l’alimentation par défaut est équilibré, la méthodologie reste la même avec l’approche conservatrice. Bien que le taux d’erreur potentielle puisse augmenter, il augmente seulement la marge de sécurité à mesure que la vitesse du processeur augmente.

• Par exemple, dans un scénario où 11,25 processeurs sont exigés, si les processeurs s’exécutaient à la moitié de leur vitesse au moment de la collecte des données, l’estimation la plus précise s’élèverait à 5,125 ÷ 2.
• Il est impossible de garantir que le doublement des vitesses d’horloge doublerait la quantité de traitement qui se produit pendant une période donnée. Cela est dû au fait que le temps que les processeurs passent à attendre la RAM ou d’autres composants système peut rester le même. L’effet net est que les processeurs plus rapides peuvent rester inactifs un plus grand pourcentage du temps pendant l’attente de l’extraction des données. Là encore, il est recommandé de s’en tenir au plus petit dénominateur commun, d’être prudent et d’éviter d’essayer de calculer un niveau de précision potentiellement faux en supposant une comparaison linéaire entre les vitesses de processeur.

Ou sinon, si la vitesse du processeur dans le matériel de remplacement est inférieure à celle du matériel actuel, il est prudent d’augmenter l’estimation des processeurs nécessaires d’une quantité proportionnelle. Par exemple, vous avez calculé que 10 processeurs sont nécessaires pour soutenir la charge dans un site, et que les processeurs actuels s’exécutent à 3,3 Ghz tandis que les processeurs de remplacement s’exécutent à 2,6 Ghz, soit une baisse de 21 % de la cadence. Dans ce cas, la quantité recommandée s’élève à 12 processeurs.

Cela dit, cette variabilité ne modifie pas les cibles d’utilisation des processeurs dans la gestion de la capacité. Comme les vitesses d’horloge de processeur sont ajustées de façon dynamique en fonction de la charge demandée, l’exécution du système sous des charges plus élevées génère un scénario dans lequel le processeur passe plus de temps dans un état de vitesse d’horloge plus élevé, ce qui permet d’atteindre l’objectif final visant les 40 % d’utilisation dans un état de vitesse d’horloge de 100 % en pointe. Toute valeur inférieure génère des économies d’énergie, car les vitesses de processeur sont limitées pendant les scénarios en dehors des heures de pointe.

Notes

Une option consiste à désactiver la gestion de l’alimentation sur les processeurs (en définissant le plan d’alimentation sur Hautes performances) pendant la collecte des données. Cela donne une représentation plus précise de la consommation processeur sur le serveur cible.

Pour ajuster les estimations pour différents processeurs, il était prudent de supposer, en excluant les autres goulots d’étranglement du système décrits ci-dessus, que le doublement des vitesses de processeur doublerait la quantité de traitement pouvant être effectuée. Aujourd’hui, l’architecture interne des processeurs est suffisamment différente entre les processeurs pour qu’un moyen plus sûr d’évaluer les effets de l’utilisation de processeurs différents consiste à exploiter la référence SPECint_rate2006 de l’association Standard Performance Evaluation Corporation.

1. Recherchez les scores SPECint_rate2006 des processeurs en cours d’utilisation et que vous envisagez d’utiliser.

   1. Sur le site web de l’association Standard Performance Evaluation Corporation, sélectionnez Results, mettez en surbrillance CPU2006, puis sélectionnez Search all SPECint_rate2006 results (Rechercher dans tous les résultats SPECint_rate2006).
   2. Sous Simple Request (Demande simple), entrez les critères de recherche du processeur cible, par exemple Processor Matches E5-2630 (baselinetarget) et Processor Matches E5-2650 (baseline).
   3. Recherchez la configuration du serveur et du processeur à utiliser (ou une configuration proche, si aucune correspondance exacte n’est disponible) et notez la valeur indiquée dans les colonnes Result et # Cores.

2. Pour déterminer le modificateur, utilisez l’équation suivante :

   ((Valeur du score par cœur de la plateforme cible) × (MHz par cœur de la plateforme de référence)) ÷ ((Valeur du score par cœur de référence) × (MHz par cœur de la plateforme cible))

   En utilisant l’exemple ci-dessus :

   (35,83 × 2000) ÷ (33,75 × 2300) = 0,92

3. Multipliez le nombre estimé de processeurs par le modificateur. Dans le cas ci-dessus, pour passer du processeur E5-2650 au processeur E5-2630, multipliez les 11,25 processeurs calculés par 0,92, ce qui permet d’obtenir 10,35 processeurs nécessaires.

Annexe C : Notions de base relatives à l’interaction du système d’exploitation avec le stockage

Les concepts de la théorie de la mise en file d’attente décrits dans Temps de réponse/Impact de l’activité système sur les performances sont également applicables au stockage. Maîtriser la façon dont le système d’exploitation gère les E/S est nécessaire pour appliquer ces concepts. Dans le système d’exploitation Microsoft Windows, une file d’attente est créée pour chaque disque physique afin de contenir les demandes d’E/S. Néanmoins, il est nécessaire de clarifier ce qu’est un disque physique. Les contrôleurs de baie et les réseaux de zone de stockage (SAN) présentent les agrégations de broches au système d’exploitation sous forme de disques physiques uniques. En outre, les contrôleurs de baie et les SAN peuvent agréger plusieurs disques en un seul ensemble de baies, puis fractionner cet ensemble de baies en plusieurs « partitions », qui sont à leur tour présentées au système d’exploitation sous forme de disques physiques multiples (reportez-vous à la figure).

Dans cette figure, les deux broches sont mises en miroir et fractionnées en zones logiques pour le stockage des données (Data 1 et Data 2). Ces zones logiques sont considérées par le système d’exploitation comme des disques physiques distincts.

Bien que cela puisse prêter à confusion, la terminologie suivante est utilisée tout au long de cette annexe pour identifier les différentes entités :

• Broche : appareil physiquement installé sur le serveur.
• Baie : collection de broches agrégées par le contrôleur.
• Partition de baie : partitionnement de la baie agrégée.
• Numéro d’unité logique (LUN) : baie utilisée en référence à des SAN.
• Disque : ce que le système d’exploitation observe comme étant un seul disque physique.
• Partition : partitionnement logique de ce que le système d’exploitation perçoit comme un disque physique.

Considérations liées à l’architecture du système d’exploitation

Le système d’exploitation crée une file d’attente d’E/S FIFO (First In/First Out) pour chaque disque observé. Ce disque peut représenter une broche, une baie ou une partition de baie. Du point de vue du système d’exploitation, en ce qui concerne la gestion des E/S, plus les files d’attente sont actives, mieux c’est. Comme une file d’attente FIFO est sérialisée, cela signifie que toutes les E/S émises sur le sous-système de stockage doivent être traitées dans l’ordre d’arrivée de la requête. En corrélant chaque disque observé par le système d’exploitation avec une broche/baie, le système d’exploitation gère maintenant une file d’attente d’E/S pour chaque ensemble unique de disques, éliminant ainsi toute contention pour des ressources d’E/S rares sur les disques et isolant la demande d’E/S sur un seul disque. À titre d’exception, Windows Server 2008 introduit le concept de hiérarchisation des E/S, et les applications conçues pour utiliser la priorité « Faible » ne respectent pas cet ordre normal et passent au second plan. Les applications qui ne sont pas spécifiquement codées pour exploiter la priorité « Faible » ont la valeur « Normale » par défaut.

Présentation des sous-systèmes de stockage simples

À partir d’un exemple simple (un seul disque dur à l’intérieur d’un ordinateur), une analyse composant par composant vous est donnée. Voici les principaux composants du sous-système de stockage du système :

• 1 disque dur Ultra Fast SCSI à 10 000 tours/min (taux de transfert de 20 Mo/s)
• 1 bus SCSI (le câble)
• 1 carte SCSI Ultra Fast
• 1 bus PCI 32 bits 33 MHz

Une fois les composants identifiés, une idée de la quantité de données pouvant transiter par le système ou de la quantité d’E/S pouvant être gérées peut être calculée. Notez que la quantité d’E/S et la quantité de données pouvant transiter par le système sont corrélées, mais pas identiques. Cette corrélation dépend du caractère aléatoire ou séquentiel des E/S disque et de la taille de bloc. (Toutes les données sont écrites sur le disque sous forme de bloc, mais les différentes applications utilisent des tailles de bloc différentes.) Voici des détails composant par composant :

• Le disque dur : Le disque dur à 10 000 tours/min en moyenne a un temps de recherche de 7 millisecondes (ms) et un temps d’accès de 3 ms. Le temps de recherche correspond au temps moyen nécessaire à la tête de lecture/écriture pour se déplacer jusqu’à un emplacement sur le plateau. Le temps d’accès correspond au temps moyen nécessaire pour lire ou écrire les données sur le disque, une fois que la tête se trouve à l’emplacement approprié. Ainsi, la durée moyenne de lecture d’un bloc de données unique sur un disque dur à 10 000 tours/min constitue une recherche et un accès, soit un total d’environ 10 ms (ou 0,01 seconde) par bloc de données.

  Quand chaque accès au disque nécessite un déplacement de la tête à un nouvel emplacement sur le disque, le comportement de lecture/écriture est dit « aléatoire ». Ainsi, quand toutes les E/S sont aléatoires, un disque dur à 10 000 tours/min peut gérer environ 100 E/S par seconde (IOPS) (la formule est 1 000 ms par seconde divisées par 10 ms par E/S, soit 1000/10 =100 IOPS).

  Par ailleurs, quand toutes les E/S se produisent à partir de secteurs adjacents sur le disque dur, il s’agit d’E/S séquentielles. Les E/S séquentielles n’ont pas de temps de recherche, car lorsque la première E/S est terminée, la tête de lecture/écriture se trouve au départ de l’emplacement où le bloc de données suivant est stocké sur le disque dur. Ainsi, un disque dur de 10 000 tours/min est capable de gérer environ 333 E/S par seconde (1 000 ms par seconde divisées par 3 ms par E/S).

  Notes

  Cet exemple ne reflète pas le cache de disque, où les données d’un seul cylindre sont généralement conservées. Dans ce cas, les 10 ms sont nécessaires sur la première E/S et le disque lit tout le cylindre. Toutes les autres E/S séquentielles sont satisfaites à partir du cache. Par conséquent, les caches sur disque peuvent améliorer les performances des E/S séquentielles.

  Jusqu’à présent, le taux de transfert du disque dur n’a pas été pertinent. Que le disque dur soit un Ultra Wide de 20 Mo/s ou un Ultra3 de 160 Mo/s, la quantité réelle d’E/S par seconde que peut gérer le disque dur à 10 000 tours/min est d’environ 100 E/S aléatoires ou 300 E/S séquentielles. À mesure que la taille de bloc évolue selon l’écriture de l’application sur le lecteur, la quantité de données extraites par E/S est différente. Par exemple, si la taille de bloc est de 8 Ko, 100 opérations d’E/S lisent ou écrivent sur le disque dur un total de 800 Ko. Toutefois, si la taille de bloc est de 32 Ko, 100 E/S lisent/écrivent 3 200 Ko (3,2 Mo) sur le disque dur. Tant que le taux de transfert SCSI est supérieur à la quantité totale de données transférées, l’obtention d’un lecteur avec un taux de transfert « plus rapide » ne permet aucun gain. Consultez les tableaux suivants pour obtenir une comparaison.

  Description	7 200 tours/min, recherche de 9 ms, accès de 4 ms	10 000 tours/min, recherche de 7 ms, accès de 3 ms	15 000 tours/min, recherche de 4 ms, accès de 2 ms
  E/S aléatoires	80	100	150
  E/S séquentielles	250	300	500

  Lecteur à 10 000 tours/min	Taille de bloc de 8 Ko (Active Directory Jet)
  E/S aléatoires	800 Ko/s
  E/S séquentielles	2 400 Ko/s

• Fond de panier (bus) SCSI : La compréhension de l’impact qu’exerce le « fond de panier (bus) SCSI », ou dans ce scénario le câble ruban, sur le débit du sous-système de stockage dépend de la connaissance de la taille de bloc. En bref, la question consiste à déterminer combien d’E/S le bus est capable de gérer si l’E/S se trouve dans des blocs de 8 Ko. Dans ce scénario, le bus SCSI est de 20 Mo/s, soit 20 480 Ko/s. 20 480 Ko/s divisés par des blocs de 8 Ko donnent un maximum d’environ 2500 IOPS prises en charge par le bus SCSI.

  Notes

  Les chiffres indiqués dans le tableau suivant représentent un exemple. La plupart des périphériques de stockage attachés utilisent actuellement PCI Express, qui offre un débit beaucoup plus élevé.

  E/S prises en charge par le bus SCSI par taille de bloc	Taille de bloc de 2 Ko	Taille de bloc de 8 Ko (AD Jet) (SQL Server 7.0/SQL Server 2000)
  20 Mo/s	10 000	2 500
  40 Mo/s	20 000	5 000
  128 Mo/s	65 536	16 384
  320 Mo/s	160 000	40 000

  Comme ce graphique permet de le déterminer, dans le scénario présenté, quelle que soit l’utilisation, le bus ne sera jamais un goulot d’étranglement, car le nombre maximal de broches s’élève à 100 E/S, ce qui est bien en dessous de tous les seuils ci-dessus.

  Notes

  Cela permet de partir du principe que le bus SCSI est efficace à 100 %.

• Carte SCSI : Pour déterminer la quantité d’E/S que celle-ci peut gérer, les spécifications du fabricant ont besoin d’être vérifiées. Diriger les demandes d’E/S vers le périphérique approprié nécessite un traitement quelconque. Par conséquent, la quantité d’E/S qui peut être gérée dépend du processeur de la carte SCSI (ou du contrôleur de baie).

  Dans cet exemple, l’hypothèse choisie est que 1 000 E/S peuvent être gérées.

• Bus PCI : Il s’agit d’un composant souvent négligé. Dans cet exemple, il ne va pas s’agir du goulot d’étranglement. Néanmoins, à mesure que les systèmes effectuent un scale-up, ce composant peut devenir un goulot d’étranglement. À titre de référence, un bus PCI 32 bits fonctionnant à 33 Mhz peut en théorie transférer 133 Mo/s de données. L’équation est la suivante :

  32 bits ÷ 8 bits par octet × 33 MHz = 133 Mo/s.

  Notez qu’il s’agit de la limite théorique. Dans la réalité, seulement environ 50 % du maximum sont réellement atteints, bien que dans certains scénarios de rafale, une efficacité à 75 % puisse être obtenue pendant de courtes périodes.

  Un bus PCI 64 bits 66 Mhz peut prendre en charge un maximum théorique de (64 bits ÷ 8 bits par octet × 66 MHz) = 528 Mo/s. En outre, tout autre périphérique (comme la carte réseau, le deuxième contrôleur SCSI, etc.) réduit la bande passante disponible à mesure que celle-ci est partagée et que les périphériques entrent en compétition pour les ressources limitées.

Après analyse des composants de ce sous-système de stockage, la broche est le facteur limitant de la quantité d’E/S pouvant être demandées et, par conséquent, de la quantité de données pouvant transiter par le système. Plus précisément, dans un scénario AD DS, il s’agit de 100 E/S aléatoires par seconde par incréments de 8 Ko, pour un total de 800 Ko par seconde lors de l’accès à la base de données Jet. Ou bien, le débit maximal d’une broche exclusivement allouée aux fichiers journaux subirait les limitations suivantes : 300 E/S séquentielles par seconde par incréments de 8 Ko, pour un total de 2 400 Ko (2,4 Mo) par seconde.

Maintenant, après l’analyse d’une configuration simple, le tableau suivant montre où le goulot d’étranglement se produit lorsque des composants du sous-système de stockage sont changés ou ajoutés.

Notes	Analyse des goulots d’étranglement	Disque	Bus	Adaptateur	Bus PCI
Il s’agit de la configuration du contrôleur de domaine après l’ajout d’un deuxième disque. La configuration du disque représente le goulot d’étranglement à 800 Ko/s.	Ajouter 1 disque (Total = 2) E/S aléatoires Taille de bloc de 4 Ko Disque dur à 10 000 tours/min	Total de 200 E/S Total de 800 Ko/s
Après avoir ajouté 7 disques, la configuration de disque représente toujours le goulot d’étranglement à 3 200 Ko/s.	Ajouter 7 disques (Total = 8) E/S aléatoires Taille de bloc de 4 Ko Disque dur à 10 000 tours/min	Total de 800 E/S Total de 3 200 Ko/s
Après le passage à des E/S séquentielles, la carte réseau devient le goulot d’étranglement, car elle est limitée à 1 000 E/S par seconde.	Ajouter 7 disques (Total = 8) E/S séquentielles Taille de bloc de 4 Ko Disque dur à 10 000 tours/min			2 400 E/S peuvent être lues/écrites sur le disque, le contrôleur est limité à 1 000 IOPS
Après avoir remplacé la carte réseau par une carte SCSI prenant en charge 10 000 E/S par seconde, le goulot d’étranglement revient à la configuration de disque.	Ajouter 7 disques (Total = 8) E/S aléatoires Taille de bloc de 4 Ko Disque dur à 10 000 tours/min Mettre à niveau la carte SCSI (elle prend désormais en charge 10 000 E/S)	Total de 800 E/S Total de 3 200 Ko/s
Après avoir augmenté la taille de bloc à 32 Ko, le bus devient le goulot d’étranglement, car il ne prend en charge que 20 Mo/s.	Ajouter 7 disques (Total = 8) E/S aléatoires Taille de bloc de 32 Ko Disque dur à 10 000 tours/min		Total de 800 E/S 25 600 Ko/s (25 Mo/s) peuvent être lus/écrits sur le disque. Le bus prend uniquement en charge 20 Mo/s.
Après la mise à niveau du bus et l’ajout de disques supplémentaires, le disque reste le goulot d’étranglement.	Ajouter 13 disques (Total = 14) Ajouter une deuxième carte SCSI avec 14 disques E/S aléatoires Taille de bloc de 4 Ko Disque dur à 10 000 tours/min Mettre à niveau vers un bus SCSI à 320 Mo/s	2 800 E/S 11 200 Ko/s (10,9 Mo/s)
Après le passage à des E/S séquentielles, le disque reste le goulot d’étranglement.	Ajouter 13 disques (Total = 14) Ajouter une deuxième carte SCSI avec 14 disques E/S séquentielles Taille de bloc de 4 Ko Disque dur à 10 000 tours/min Mettre à niveau vers un bus SCSI à 320 Mo/s	8 400 E/S 33 600 Ko/s (32,8 Mo/s)
Après avoir ajouté des disques durs plus rapides, le disque reste le goulot d’étranglement.	Ajouter 13 disques (Total = 14) Ajouter une deuxième carte SCSI avec 14 disques E/S séquentielles Taille de bloc de 4 Ko Disque dur à 15 000 tours/min Mettre à niveau vers un bus SCSI à 320 Mo/s	14 000 E/S 56 000 Ko/s (54,7 Mo/s)
Après avoir augmenté la taille de bloc à 32 Ko, le bus PCI devient le goulot d’étranglement.	Ajouter 13 disques (Total = 14) Ajouter une deuxième carte SCSI avec 14 disques E/S séquentielles Taille de bloc de 32 Ko Disque dur à 15 000 tours/min Mettre à niveau vers un bus SCSI à 320 Mo/s				14 000 E/S 448 000 Ko/s (437 Mo/s) correspondent à la limite de lecture/écriture sur la broche. Le bus PCI prend en charge un maximum théorique de 133 Mo/s (75 % d’efficacité au mieux).

Présentation de RAID

La nature d’un sous-système de stockage ne change pas considérablement lorsqu’un contrôleur de baie est introduit. Celui-ci remplace simplement la carte SCSI dans les calculs. Ce qui change, c’est le coût de la lecture et de l’écriture des données sur le disque lors de l’utilisation des différents niveaux de baie (comme RAID 0, RAID 1 ou RAID 5).

Avec RAID 0, les données sont réparties sur tous les disques du jeu RAID. Cela signifie que lors d’une opération de lecture ou d’écriture, une partie des données est extraite de chaque disque ou envoyée à chaque disque, ce qui augmente la quantité de données pouvant transiter par le système pendant la même période. Ainsi, en une seconde, sur chaque broche (toujours avec des lecteurs à 10 000 tours/min), 100 opérations d’E/S peuvent être effectuées. La quantité totale d’E/S pouvant être prise en charge s’élève à N broches multipliées par 100 E/S par seconde et par broche (soit 100*N E/S par seconde).

Avec RAID 1, les données sont mises en miroir (dupliquées) sur une paire de broches à des fins de redondance. Ainsi, lorsqu’une opération d’E/S de lecture est effectuée, les données peuvent être lues à partir des deux broches du jeu. Cela rend effectivement la capacité d’E/S des deux disques disponible pendant une opération de lecture. L’inconvénient est que les opérations d’écriture ne tirent aucun avantage en matière de performances avec un RAID 1. Cela est dû au fait que les mêmes données ont besoin d’être écrites sur les deux lecteurs pour des raisons de redondance. Bien que cela ne prenne pas plus de temps, car l’écriture de données se produit simultanément sur les deux broches, étant donné que les deux broches sont occupées à dupliquer les données, une opération d’E/S d’écriture empêche la survenue de deux opérations de lecture. Ainsi, chaque E/S d’écriture coûte deux E/S de lecture. Une formule peut être créée à partir de ces informations pour déterminer le nombre total d’opérations d’E/S qui se produisent :

E/S de lecture + 2 × E/S d’écriture = Total des E/S disque disponibles consommées

Lorsque le rapport lectures/écritures et le nombre de broches sont connus, l’équation suivante peut être dérivée de l’équation ci-dessus pour identifier le nombre maximal d’E/S pouvant être prises en charge par la baie :

Nombre maximal d’IOPS par broche × 2 broches × [(% de lectures + % d’écritures) ÷ (% de lectures + 2 × % d’écritures)] = Nombre total d’IOPS

RAID 1+ 0 se comporte exactement comme RAID 1 en ce qui concerne la dépense en lecture et écriture. Toutefois, les E/S sont désormais réparties sur chaque jeu mis en miroir. Si

Nombre maximal d’IOPS par broche × 2 broches × [(% de lectures + % d’écritures) ÷ (% de lectures + 2 × % d’écritures)] = Nombre total d’E/S

Dans un jeu RAID 1, quand un multiple (N) des jeux RAID 1 est réparti, le nombre total d’E/S pouvant être traitées devient N × E/S par jeu RAID 1 :

N × {Nombre maximal d’IOPS par broche × 2 broches × [(% de lectures + % d’écritures) ÷ (% de lectures + 2 × % d’écritures)] } = Nombre total d’IOPS

Avec RAID 5, parfois appelé RAID N + 1, les données sont réparties sur N broches et les informations de parité sont écrites dans la broche « + 1 ». Toutefois, RAID 5 est beaucoup plus coûteux lors de l’exécution d’une E/S d’écriture que RAID 1 ou 1 + 0. RAID 5 effectue le processus suivant chaque fois qu’une E/S d’écriture est soumise à la baie :

1. Lire les anciennes données
2. Lire l’ancienne parité
3. Écrire les nouvelles données
4. Écrire la nouvelle parité

Étant donné que chaque demande d’E/S d’écriture soumise au contrôleur de baie par le système d’exploitation nécessite quatre opérations d’E/S, les demandes d’écriture soumises prennent quatre fois plus de temps pour se terminer qu’une seule E/S de lecture. Pour dériver une formule afin de traduire les demandes d’E/S du point de vue du système d’exploitation vers celles expérimentées par les broches :

E/S de lecture + 4 × E/S d’écriture = Nombre total d’E/S

De même, dans un jeu RAID 1, lorsque le rapport lectures/écritures et le nombre de broches sont connus, l’équation suivante peut être dérivée de l’équation ci-dessus pour identifier le nombre maximal d’E/S qui peuvent être prises en charge par la baie (notez que le nombre total de broches n’inclut pas le « lecteur » perdu en faveur de la parité) :

IOPS par broche × (Broches – 1) × [(% de lectures + % d’écritures) ÷ (% de lectures + 4 × % d’écritures)] = Nombre total d’IOPS

Présentation des SAN

En développant la complexité du sous-système de stockage, lorsqu’un SAN est introduit dans l’environnement, les principes de base décrits ne changent pas, mais le comportement des E/S pour tous les systèmes connectés au SAN doit être pris en compte. Étant donné que l’un des principaux avantages de l’utilisation d’un SAN est une redondance accrue sur le stockage attaché en interne ou en externe, la planification de capacité doit maintenant prendre en compte les besoins de tolérance de panne. En outre, d’autres composants qui doivent être évalués sont introduits. Voici les composants d’un SAN :

• Disque dur SCSI ou Fibre Channel
• Fond de panier du canal d’unité de stockage
• Unités de stockage
• Module du contrôleur de stockage
• Commutateur(s) SAN
• Carte(s) de bus hôte (HBA)
• Bus PCI

Lors de la conception d’un système à des fins de redondance, des composants supplémentaires sont inclus pour tenir compte du risque de défaillance. Il est très important, lors de la planification de capacité, d’exclure le composant redondant des ressources disponibles. Par exemple, si le SAN a deux modules de contrôleur, la capacité d’E/S d’un seul module de contrôleur correspond à tout ce qui doit être utilisé pour le débit d’E/S total disponible pour le système. Cela est dû au fait qu’en cas d’échec d’un contrôleur, toute la charge d’E/S demandée par tous les systèmes connectés va avoir besoin d’être traitée par le contrôleur restant. Comme toute la planification de capacité est effectuée pour les périodes d’utilisation de pointe, les composants redondants ne doivent pas être pris en compte dans les ressources disponibles et l’utilisation de pointe planifiée ne doit pas dépasser 80 % de saturation du système (afin de tenir compte des rafales ou d’un comportement anormal du système). De même, le commutateur SAN redondant, l’unité de stockage et les broches ne doivent pas être pris en compte dans les calculs d’E/S.

Lors de l’analyse du comportement du disque dur SCSI ou Fibre Channel, la méthode d’analyse décrite précédemment ne change pas. Bien qu’il existe certains avantages et inconvénients à chaque protocole, le facteur de limitation disque par disque correspond à la limitation mécanique du disque dur.

L’analyse du canal sur l’unité de stockage revient exactement à calculer les ressources disponibles sur le bus SCSI, ou la bande passante (comme 20 Mo/s) que vous diviserez par la taille de bloc (par exemple, 8 Ko). La différence par rapport à l’exemple simple précédent se situe dans l’agrégation de plusieurs canaux. Par exemple, s’il existe 6 canaux, chacun prenant en charge un taux de transfert maximal de 20 Mo/s, la quantité totale d’E/S et de transfert de données disponibles s’élève à 100 Mo/s (cette valeur est correcte, elle n’atteint pas les 120 Mo/s). Là encore, la tolérance de panne joue un rôle majeur dans ce calcul, en cas de perte d’un canal entier, il ne reste au système que 5 canaux fonctionnels. Ainsi, pour assurer la continuité de la satisfaction aux attentes en matière de performances en cas de défaillance, le débit total de tous les canaux de stockage ne doit pas dépasser 100 Mo/s (cela suppose que la charge et la tolérance de panne sont réparties uniformément sur tous les canaux). En faire un profil d’E/S dépend du comportement de l’application. Dans le cas d’E/S Active Directory Jet, cela correspond à environ 12 500 E/S par seconde (100 Mo/s ÷ 8 Ko par E/S).

Ensuite, l’obtention des spécifications du fabricant pour les modules de contrôleur est nécessaire pour comprendre le débit que chaque module peut prendre en charge. Dans cet exemple, le SAN a deux modules de contrôleur qui prennent en charge 7 500 E/S chacun. Le débit total du système peut s’élever à 15 000 IOPS si la redondance n’est pas voulue. Lors du calcul du débit maximal en cas de défaillance, la limitation correspond au débit d’un seul contrôleur, soit 7 500 IOPS. Ce seuil est bien inférieur au maximum de 12 500 IOPS (pour une taille de bloc de 4 Ko) qui peut être pris en charge par tous les canaux de stockage, ce qui constitue donc actuellement le goulot d’étranglement dans l’analyse. Toujours à des fins de planification, le nombre maximal d’E/S souhaité à planifier s’élève à 10 400 E/S.

Lorsque les données quittent le module de contrôleur, elles transitent par une connexion Fibre Channel évaluée à 1 Go/s (soit 1 gigoctet par seconde). Pour mettre cela en corrélation avec les autres métriques, 1 Go/s devient 128 Mo/s (1 Go/s ÷ 8 bits/octet). Étant donné que cette valeur dépasse la bande passante totale sur tous les canaux de l’unité de stockage (100 Mo/s), le système ne sera pas engorgé. En outre, comme il ne s’agit que de l’un des deux canaux (la connexion Fibre Channel supplémentaire de 1 Go/s étant destinée à la redondance), si une seule connexion échoue, la connexion restante dispose toujours d’une capacité suffisante pour gérer tous les transferts de données demandés.

En route vers le serveur, les données vont probablement passer par un commutateur SAN. Étant donné que le commutateur SAN doit traiter la demande d’E/S entrante et la transférer au port approprié, le commutateur est limité quant à la quantité d’E/S pouvant être gérées. Toutefois, les spécifications des fabricants sont nécessaires pour déterminer cette limite. Par exemple, s’il existe deux commutateurs et que chacun d’eux peut gérer 10 000 IOPS, le débit total s’élève à 20 000 IOPS. Là encore, la tolérance de panne étant une préoccupation, si un seul commutateur échoue, le débit total du système s’élève à 10 000 IOPS. Comme il est souhaitable de ne pas dépasser une utilisation à 80 % dans le cadre d’un fonctionnement normal, l’utilisation d’un maximum de 8 000 E/S doit être ciblée.

Enfin, la carte de bus hôte (HBA) installée sur le serveur est également limitée quant à la quantité d’E/S qu’elle peut gérer. En règle générale, une deuxième HBA est installée pour la redondance, mais comme avec le commutateur SAN, lors du calcul des E/S maximales pouvant être gérées, le débit total de N – 1 HBA correspond à la scalabilité maximale du système.

Considérations relatives à la mise en cache

Les caches sont l’un des composants susceptibles d’exercer un impact significatif sur les performances globales à tous les égards dans le système de stockage. L’analyse détaillée des algorithmes de mise en cache dépasse le cadre de cet article. Néanmoins, certaines affirmations de base sur la mise en cache sur des sous-systèmes de disque méritent d’être portées à votre attention :

• La mise en cache améliore les E/S d’écriture séquentielles durables car elle peut mettre en mémoire tampon de nombreuses opérations d’écriture plus petites dans des blocs d’E/S plus grands et déplacer le stockage dans des tailles de bloc moins nombreuses, mais plus grandes. Cela réduira le nombre total d’E/S aléatoires et d’E/S séquentielles, offrant ainsi une plus grande disponibilité des ressources pour d’autres E/S.

• La mise en cache n’améliore pas le débit d’E/S d’écriture durable du sous-système de stockage. Elle permet uniquement la mise en mémoire tampon des écritures jusqu’à ce que les broches soient disponibles pour valider les données. Lorsque toutes les E/S disponibles des broches dans le sous-système de stockage sont saturées pendant de longues périodes, le cache finit par se remplir. Pour vider le cache, vous devez allouer suffisamment de temps entre les rafales ou les broches supplémentaires afin de fournir suffisamment d’E/S pour permettre le vidage du cache.

  Les caches plus volumineux permettent uniquement de mettre en mémoire tampon davantage de données. Cela signifie que des périodes de saturation plus longues peuvent être considérées.

  Dans un sous-système de stockage qui fonctionne normalement, le système d’exploitation voit ses performances d’écriture améliorées, car les données doivent uniquement être écrites dans le cache. Une fois que le média sous-jacent est saturé d’E/S, le cache se remplit et les performances d’écriture reviennent à la vitesse du disque.

• Lors de la mise en cache des E/S de lecture, le scénario dans lequel le cache est le plus avantageux est celui où les données sont stockées séquentiellement sur le disque et où le cache peut les lire à l’avance (il part du principe que le secteur suivant contient les données qui seront demandées ensuite).

• Lorsque les E/S de lecture sont aléatoires, la mise en cache au niveau du contrôleur de lecteur est peu susceptible d’améliorer la quantité de données pouvant être lues à partir du disque. Toute amélioration est inexistante si la taille du cache basée sur le système d’exploitation ou l’application est supérieure à la taille du cache basée sur le matériel.

  Dans le cas d’Active Directory, le cache est limité uniquement par la quantité de RAM.

Considérations relatives aux disques SSD

Les disques SSD sont une technologie complètement différente de celle des disques durs à base de broches. Pourtant, les deux principaux critères restent : « Combien d’IOPS peuvent-ils gérer ? » et « Quelle est la latence de ces IOPS ? » Par rapport aux disques durs à base de broches, les disques SSD peuvent gérer des volumes d’E/S plus élevés et leurs latences peuvent être plus faibles. En règle générale et au moment de la rédaction de cet article, bien que le coût d’un disque SSD soit toujours élevé par gigaoctet, leur coût est très faible par E/S et ils méritent la meilleure considération pour leurs performances de stockage.

Considérations :

• Les IOPS et les latences dépendent fortement des conceptions des fabricants et, dans certains cas, leurs moindres performances ont été observées par rapport aux technologies à base de broches. En bref, le plus important, c’est de passer en revue et de vérifier les spécifications du fabricant lecteur par lecteur et de ne pas faire de généralités.
• Les types d’IOPS peuvent obtenir des chiffres très différents selon qu’il s’agit de lecture ou d’écriture. Les services AD DS, en règle générale, étant principalement basés sur la lecture, sont moins affectés que d’autres scénarios d’application.
• L’« endurance à l’écriture » correspond au concept selon lequel les cellules SSD finissent par s’user. Les différents fabricants font face à ce défi de différentes manières. Au moins pour le lecteur de base de données, le profil d’E/S de lecture prédominant permet d’atténuer ce problème, car les données ne sont pas hautement volatiles.

Résumé

Une façon de penser au stockage consiste à imaginer la plomberie d’une maison. Imaginez que les IOPS du média sur lequel les données sont stockées sont le collecteur principal de la maison. Quand celui-ci est bouché (des racines ont percé le tuyau) ou limité (il est réduit ou trop petit), tous les lavabos de la maison refoulent quand une quantité d’eau trop importante est utilisée (trop d’invités). Cela est parfaitement comparable à un environnement partagé où un ou plusieurs systèmes exploitent le stockage partagé sur un SAN/NAS/iSCSI avec le même média sous-jacent. Différentes approches peuvent être adoptées pour résoudre les différents scénarios :

• Un collecteur endommagé ou sous-dimensionné nécessite un remplacement et une réparation à grande échelle. Cela revient à ajouter du nouveau matériel ou à redistribuer les systèmes à l’aide du stockage partagé dans l’ensemble de l’infrastructure.
• Une canalisation « bouchée » implique généralement d’identifier un ou plusieurs problèmes avant de les éliminer. Dans un scénario de stockage, il peut s’agir de sauvegardes au niveau du stockage ou du système, d’analyses antivirus synchronisées sur tous les serveurs et de logiciels de défragmentation synchronisés s’exécutant pendant les périodes de pointe.

Dans toute conception de plomberie, plusieurs collecteurs alimentent le collecteur principal. Si quelque chose stoppe l’un de ces collecteurs ou un raccord, seuls les éléments situés derrière ce raccord s’accumulent. Dans un scénario de stockage, il peut s’agir d’un commutateur surchargé (scénario SAN/NAS/iSCSI), de problèmes de compatibilité de pilotes (combinaison incorrecte de pilote/microprogramme HBA/storport.sys) ou de sauvegarde/antivirus/défragmentation. Pour déterminer si le « canal » de stockage est suffisamment grand, la taille des E/S par seconde et des E/S doit être mesurée. À chaque raccord, additionnez-les ensemble pour garantir un « diamètre » adéquat.

Annexe D : Discussion sur la résolution des problèmes de stockage dans les environnements où la configuration d’au moins autant de RAM que la taille de la base de données n’est pas une option viable

Il est utile de comprendre pourquoi ces recommandations existent afin que les modifications apportées à la technologie de stockage puissent être prises en compte. Ces recommandations existent pour deux raisons. La première est l’isolation des E/S, de sorte que les problèmes de performance (c’est-à-dire de pagination) sur la broche du système d’exploitation n’ont pas d’impact sur les performances de la base de données et des profils d’E/S. La seconde est que les fichiers journaux pour AD DS (et la plupart des bases de données) sont séquentiels par nature, et que les disques durs à base de broches et les caches présentent un énorme avantage en matière de performances lorsqu’ils sont utilisés avec des E/S séquentielles par rapport aux modèles d’E/S plus aléatoires du système d’exploitation et aux modèles d’E/S presque purement aléatoires du lecteur de base de données AD DS. En isolant les E/S séquentielles sur un lecteur physique distinct, le débit peut être augmenté. Les difficultés que présentent les options de stockage d’aujourd’hui sont liées au fait que les principes fondamentaux derrière ces recommandations ne sont plus vrais. Dans de nombreux scénarios de stockage virtualisé, comme iSCSI, SAN, NAS et les fichiers image de disque virtuel, le support de stockage sous-jacent est partagé entre plusieurs hôtes, ce qui annule complètement les avantages de l’« isolation des E/S » et de l’« optimisation des E/S séquentielle ». En fait, ces scénarios ajoutent une couche supplémentaire de complexité du fait que d’autres hôtes qui accèdent au support partagé peuvent dégrader la réactivité du contrôleur de domaine.

Lors de la planification des performances de stockage, il existe trois catégories à prendre en compte : état du cache froid, état du cache réchauffé et sauvegarde/restauration. L’état du cache froid intervient dans des scénarios où le contrôleur de domaine est initialement réamorcé ou le service Active Directory est redémarré alors qu’il n’y a pas de données Active Directory dans la RAM. L’état du cache réchauffé intervient quand le contrôleur de domaine est dans un état stable et la base de données mise en cache. Il est important de noter qu’ils entraînent des profils de performances très différents, et le fait d’avoir suffisamment de RAM pour mettre en cache toute la base de données n’aide pas les performances lorsque le cache est froid. Vous pouvez envisager de concevoir les performances pour ces deux scénarios avec l’analogie suivante : le réchauffement du cache froid est un « sprint » et l’exécution d’un serveur avec un cache réchauffé est un « marathon ».

Pour le scénario de cache froid et de cache réchauffé, la question porte sur la vitesse à laquelle le stockage peut déplacer les données du disque vers la mémoire. Le réchauffement du cache est un scénario où, au fil du temps, les performances s’améliorent puisque d’autres requêtes réutilisent les données, le taux d’accès au cache augmente et la fréquence du besoin d’accéder au disque diminue. Par conséquent, l’impact négatif sur les performances de l’accès au disque diminue. Toute dégradation des performances est temporaire car liée à l’attente que le cache se réchauffe et augmente jusqu’à la taille maximale autorisée en fonction du système. Le débat peut être ramené à la rapidité avec laquelle les données peuvent être extraites du disque. Il s’agit d’une mesure simple des E/S par seconde disponibles pour Active Directory, ce qui dépend des IOPS disponibles à partir du stockage sous-jacent. Du point de vue de la planification, étant donné que les scénarios de réchauffement du cache et de sauvegarde/restauration se produisent de manière exceptionnelle, normalement en dehors des heures de pointe, et qu’ils sont propres à la charge du contrôleur de domaine, il n’existe pas de recommandations générales, sauf dans le cas où ces activités sont planifiées pour des scénarios en dehors des heures de pointe.

Dans la plupart des scénarios, AD DS est majoritairement concerné par des E/S de lecture, avec un rapport de 90 % de lecture pour 10 % d’écriture. Les E/S de lecture ont souvent tendance à être le goulot d’étranglement pour l’expérience utilisateur et, avec les E/S d’écriture, elles entraînent une dégradation des performances d’écriture. Étant donné que les E/S sur NTDS.dit sont principalement aléatoires, les caches ont tendance à offrir un avantage minimal aux E/S de lecture, ce qui rend beaucoup plus importante la configuration correcte du stockage pour le profil d’E/S de lecture.

Dans des conditions normales de fonctionnement, l’objectif de planification du stockage consiste à réduire les temps d’attente pour qu’une demande provenant d’AD DS soit retournée à partir du disque. Cela signifie finalement que le nombre d’E/S en attente est inférieur ou équivalent au nombre de chemins vers le disque. Il existe plusieurs façons de mesurer ce nombre : Dans un scénario de monitoring des performances, la recommandation générale stipule que la valeur de Disque logique(<Lecteur de base de données NTDS>)\Moyenne de disque en s/lecture soit inférieure à 20 ms. Le seuil de fonctionnement souhaité doit être beaucoup plus bas, de préférence aussi proche que possible de la vitesse du stockage, dans une plage comprise entre 2 et 6 millisecondes (0,002 et 0,006 seconde) selon le type de stockage.

Exemple :

Analyse du graphique :

• Ovale vert à gauche : La latence reste cohérente à 10 ms. La charge augmente de 800 IOPS à 2 400 IOPS. Il s’agit du plancher absolu de la rapidité avec laquelle une demande d’E/S peut être traitée par le stockage sous-jacent. Cette valeur dépend des spécificités de la solution de stockage.
• Ovale rouge à droite : Le débit reste plat depuis la sortie du cercle vert jusqu’à la fin de la collecte de données, tandis que la latence continue d’augmenter. Cela montre que lorsque les volumes de demandes dépassent les limitations physiques du stockage sous-jacent, plus les requêtes passent du temps dans la file d’attente à attendre d’être envoyées au sous-système de stockage.

Application de ces connaissances :

• Impact sur un utilisateur interrogeant l’appartenance à un grand groupe : En supposant que cela nécessite de lire 1 Mo de données à partir du disque, la quantité d’E/S et le temps nécessaire peuvent être évalués comme suit :
  • Les pages de base de données Active Directory ont une taille de 8 Ko.
  • Un minimum de 128 pages doivent être lues à partir du disque.
  • En supposant que rien n’est mis en cache, au niveau du plancher (10 ms), cela prendra au moins 1,28 seconde pour charger les données à partir du disque afin de les renvoyer au client. À 20 ms, où le débit sur le stockage a depuis longtemps atteint son maximum et correspond aussi au maximum recommandé, 2,5 secondes sont nécessaires pour récupérer les données à partir du disque afin de les renvoyer à l’utilisateur final.
• Vitesse de réchauffement du cache : En supposant que la charge du client va maximiser le débit sur ce stockage, le cache va se réchauffer à un débit de 2 400 IOPS × 8 Ko par E/S. Soit, environ 20 Mo par seconde, ce qui permet de charger environ 1 Go de la base de données dans la RAM toutes les 53 secondes.

Notes

Il est normal, pendant de courtes périodes, d’observer que les latences grimpent lorsque les composants lisent ou écrivent de manière agressive sur le disque, notamment quand le système est sauvegardé ou quand AD DS exécute un nettoyage de la mémoire. Une marge supplémentaire sur les calculs doit être prévue pour tenir compte de ces événements périodiques. L’objectif étant de fournir un débit suffisant pour prendre en charge ces scénarios sans impacter le fonctionnement normal.

Comme vous pouvez le voir, il existe une limite physique selon la conception du stockage à la vitesse à laquelle le cache peut se réchauffer. Ce qui réchauffe le cache, ce sont les demandes de client entrantes, à hauteur du débit que peut fournir le stockage sous-jacent. L’exécution de scripts pour « préchauffer » le cache pendant les heures de pointe fournit une concurrence à la charge pilotée par des demandes de client réelles. Cela peut nuire à la remise des données dont les clients ont besoin en premier lieu parce que, par nature, cela va générer de la concurrence pour les ressources de disque rares, car les tentatives artificielles de réchauffement du cache vont charger des données qui ne sont pas pertinentes pour les clients qui contactent le contrôleur de domaine.