Dimensionnement de la base de données Active Directory

Sur cette page

Dimensionnement de la base de données Active Directory
Résumé
Introduction
Architecture et composants de base de données Active Directory
Suppression des fichiers journaux devenus inutiles
Suppression d'enregistrements désactivés
Défragmentation de la base de données

Dimensionnement de la base de données Active Directory

Optimisation des caractéristiques de dimensionnement en prévision de l'extension du service Annuaire

Livre blanc

Résumé

Le service Active Directory de Microsoft Windows 2000 offre aux entreprises de nouveaux modes d'utilisation des services Annuaire. Les versions précédentes du système d'exploitation réseau Windows NT limitaient l'utilisation de l'annuaire à certaines fonctions d'administration réseau, telles que l'administration d'utilisateurs et de groupes d'utilisateurs. Le service Active Directory de Windows 2000 étend ces fonctions et d'autres capacités, permet d'utiliser l'annuaire comme banque de données et permet aux services réseau et aux applications avec extension annuaire de publier des informations sur un réseau à l'échelle de l'entreprise.

Remarque Cet article est extrait du document "Optimizing Network Trafic" (Optimisation du trafic réseau), tiré de la série "Notes From the Field" (Notes issues de l'expérience) de Microsoft Press qui présente diverses méthodes et procédures de gestion système recommandées, basées sur l'expérience acquise sur le terrain par les équipes des services MCS (Microsoft Consulting Services).

Pour plus d'informations sur ce Livre blanc, reportez-vous à au site Microsoft Press.

Introduction

Le service Active Directory de Microsoft Windows 2000 offre aux entreprises de nouveaux modes d'utilisation des services Annuaire. Les versions précédentes du système d'exploitation réseau Windows NT limitaient l'utilisation de l'annuaire à certaines fonctions d'administration réseau, telles que l'administration d'utilisateurs et de groupes d'utilisateurs. Le service Active Directory de Windows 2000 étend ces fonctions et d'autres capacités, permet d'utiliser l'annuaire comme banque de données et permet aux services réseau et aux applications avec extension annuaire de publier des informations sur un réseau à l'échelle de l'entreprise.

Le service Active Directory utilise le moteur de base de données employé dans Microsoft Exchange Server 5.5. Le service Active Directory est un service d'annuaire au niveau de l'entreprise qui s'intègre à des annuaires existants à l'aide de la synchronisation et prend en charge des applications de catégorie entreprise. Pour maintenir à jour la base de données Active Directory, des contrôleurs de domaine génèrent un trafic réseau de réplication.

Dans ce cadre, les administrateurs de réseau doivent réfléchir au dimensionnement de l'espace disponible sur le disque dur du serveur à prévoir en fonction de l'extension du service Annuaire. Outre cet aspect, ce Livre blanc aborde les sujets suivants :

• Présentation de l'architecture du service Active Directory de Windows 2000

• Description de la structure de base de données Active Directory et de son mode de fonctionnement

• Description détaillée des tests de dimensionnement de base de données

• Tests orientés scénario illustrant le dimensionnement d'une base de données dans la pratique

• Directives d'évaluation de la taille d'une base de données Active Directory

Architecture et composants de base de données Active Directory

Active Directory est un outil d'administration réseau, mais vous pouvez également vous en servir comme nœud dorsal pour les applications. Pour tirer parti de cette capacité, les nouvelles versions de certaines applications qui employaient précédemment des annuaires propriétaires transféreront dorénavant vers le service Active Directory toutes les informations associées aux annuaires. Par exemple, la prochaine version de Microsoft Exchange Server (nom de code Platinum) et des applications professionnelles R3 SAP intégreront le service Active Directory.

Pour comprendre l'impact de cette modification sur le dimensionnement d'un disque dur, vous devez connaître le mode de stockage des informations par la base de données. Les paragraphes suivants décrivent brièvement l'architecture de la base de données et présentent les résultats des tests effectués sur la taille d'une base de données d'annuaire.

Le service Active Directory de Windows 2000 fonctionne dans le domaine protégé et approuvé, et s'intègre dans le processus d'autorité de sécurité locale (LSASS.EXE) qui gère les lots d'authentification et authentifie les utilisateurs et les services. Le service Active Directory peut ainsi gérer en toute sécurité des informations confidentielles, telles que des mots de passe de comptes.

Le service Active Directory est mis en œuvre en trois couches : l'agent du service d'annuaire (DSA, Directory Service Agent) principal, la couche de base de données (DB) et le moteur d'enregistrement extensible (ESE, Extensible Storage Engine). D'autres composants au-dessus de ces couches assurent la communication avec d'autres services internes ou externes. L'interface LDAP (conforme à RFC 2222) donne accès à des clients LDAP, tels que des stations de travail Windows 2000 ou Windows 9x avec le package client Active Directory. L'interface de réplication assure la réplication d'annuaires avec d'autres contrôleurs de domaine Active Directory. L'interface SAM met en œuvre des services de sécurité.

Figure 10.1 Couches fonctionnelles de Active Directory

Le DSA principal applique les sémantiques d'annuaire, gère le schéma, garantit et gère l'identité des objets, et définit des types de données pour les attributs. Il contrôle également la structure des classes et les règles sémantiques, notamment l'héritage de classes (à partir de classes abstraites et structurelles), les classes auxiliaires et l'application des propriétés obligatoires. Le DSA assure la mise en œuvre de toutes les routines de contrôle d'accès.

La base de données ESE n'étant pas dotée d'un espace de noms hiérarchique, la couche de base de données fournit une hiérarchie d'objets abstraite.

Un objet d'annuaire a un nom unique (DN) qui contient les composants du nom DNS du domaine où réside l'objet. Le nom unique relatif (RDN) d'un objet est le nom de l'objet par rapport à son parent. Chaque objet de base de données possède également un ObjectGUID (identificateur unique global), ne pouvant pas être modifié après la création de l'objet.

L'interface LDAP présente les objets au moyen de leurs noms uniques. Certains attributs contiennent des références à d'autres objets Active Directory, tels que l'attribut gestionnaire d'un utilisateur. En interne, la valeur de ces attributs est l'ObjectGUID de l'objet auquel ils font référence. Cela garantit qu'une référence désigne toujours le même objet, même si cet objet est renommé ou déplacé. L'interface LDAP convertit automatiquement ces références au nom unique afin que lorsqu'un client LDAP lit ces attributs, il récupère un nom unique, et non un ObjectGUID.

La base de données ESE est composée de deux tables : la table de données et la table de liaisons. La table de données contient un nombre relativement restreint de colonnes fixes , où le stockage est alloué pour la colonne sur chaque ligne, et un nombre élevé de colonnes marquées , où le stockage est alloué uniquement si une valeur est présente. Les colonnes fixes servent à maintenir la structure de l'annuaire et sont généralement invisibles aux clients ; les colonnes marquées contiennent les attributs que les clients voient et prennent en compte.

L'identification d'un objet dans une table de données serait trop longue si le système devait toujours enregistrer et comparer des GUID volumineux, ainsi chaque objet est également identifié par une étiquette de nom unique (DNT). Cette valeur DWORD à quatre octets est incrémentée lorsqu'un nouvel objet est créé dans la banque de données ; elle représente donc le numéro de ligne de l'objet dans la base de données. C'est un exemple de colonne fixe. La relation de parent de chaque objet est enregistrée sous la forme d'une étiquette de nom unique de parent (PDNT, encore un DWORD). La résolution des relations parent-enfant est optimisée puisque le DNT et le PDNT sont des champs indexés dans la base de données.

La base de données Active Directory (NTDS.DIT) contient les tables suivantes :

La table du schéma, contenant les données représentant le schéma Active Directory : les types d'objets pouvant être créés dans Active Directory, leurs relations, ainsi que les attributs facultatifs et obligatoires de chaque type d'objet. Cette table étant relativement statique et beaucoup plus petite que la table de données, elle ne fera pas l'objet d'une description plus détaillée.

La table de liaisons, contenant les données représentant les attributs liés, qui contiennent des valeurs faisant référence à d'autres objets dans l'annuaire Active Directory (par exemple l'attribut MemberOf sur un objet utilisateur, qui contient des valeurs faisant référence à des groupes auxquels l'utilisateur appartient). Cette table est également beaucoup plus petite que la table de données et ne fera pas l'objet d'une description plus détaillée.

La table de données, contenant le reste des informations de l'annuaire Active Directory : utilisateurs, groupes, données spécifiques des applications et toutes les autres données enregistrées dans l'annuaire Active Directory après son installation. Dans la plupart des installations, cette table est beaucoup plus volumineuse que les tables de liaisons et de schémas, et sera donc décrite de façon détaillée dans le reste de ce Livre blanc.

La table de données est composée de lignes (chacune représentant une instance d'un objet, tel qu'un utilisateur) et de colonnes (chacune représentant un attribut dans le schéma, tel que GivenName). Pour chaque attribut dans le schéma, la table contient une colonne, également qualifiée de champ. La taille des champs peut être fixe ou variable. Les champs à taille fixe contiennent des données de type entier ou entier long ; les champs à taille variable contiennent généralement des données de type chaîne (par exemple, des chaînes Unicode). La base de données alloue simplement l'espace requis par un champ de taille variable : 16 bits pour une chaîne Unicode d'un caractère, 160 bits pour une chaîne Unicode de 10 caractères, et ainsi de suite.

Le tableau suivant présente une table de données réduite avec huit colonnes marquées (parmi les quelques 800 attributs actuellement disponibles avec le schéma par défaut).

En-têtes de colonnes pour une table de données à huit colonnes marquées

L'exemple suivant présente une ligne correspondant à un objet utilisateur et une ligne correspondant à un objet ordinateur d'annuaire. Le type d'un objet est défini par son attribut de classe (la colonne Classe d'objet). La table de données n'indique pas de règle structurelle, comme par exemple quels attributs peuvent être définis sur un objet utilisateur ou sur un objet ordinateur. Cette abstraction étant effectuée par le DSA parallèlement à la table du schéma, il y a des colonnes d'attributs qui ne s'appliquent pas aux utilisateurs (telles que Système d'exploitation) et des colonnes qui ne s'appliquent pas à des objets ordinateur (telles que Matricule). Aucune valeur ne pouvant être définie pour ces attributs, la base de données ne leur alloue pas d'espace d'enregistrement.

Table de données à huit colonnes marquées

L'espace de base de données utilisé pour répertorier un objet dépend du nombre d'attributs pour lesquels des valeurs sont définies et la taille de ces valeurs. Par exemple, si l'administrateur crée deux objets utilisateur (User1 et User2) et définit uniquement un minimum d'attributs sur ceux-ci, puis ajoute ultérieurement une description à 10 caractères à User2, User2 requiert un espace de 20 octets, supérieur à l'espace requis par User1.

Les enregistrements de base de données ne pouvant pas occuper plusieurs pages de base de données, chaque objet est limité à 8 Ko. Cependant, certaines valeurs d'attribut d'un objet ne respectent pas entièrement cette limite. Les valeurs longues, à longueur variable ne sont pas nécessairement enregistrées sur la même page que l'enregistrement de l'objet, laissant uniquement une référence de 9 octets. Un objet et tous ses attributs peuvent ainsi largement dépasser les 8 Ko.

La base de données Active Directory est stockée dans un fichier nommé Ntds.dit. Lorsque le service Annuaire doit accéder à des données, Lsass.exe charge des pages en mémoire à partir du fichier de base de données. Il réserve un pool de mémoire pour ces opérations et transfère les pages entre la base de données et le pool selon le principe Dernier récemment utilisé (LRU). Certaines pages dans la mémoire et dans le fichier de base de données perdent leur synchronisation lorsque le DSA effectue une opération sur un objet. Pour corriger cette situation, toutes les pages en mémoire sont vidées dans le fichier de base de données à chaque arrêt de la base de données. Le contrôleur de domaine permute également des pages de la mémoire au disque dur (en arrière-plan) lorsqu'il est en mode repos ou dans un état de faible charge.

Les modifications sont apportées à des copies d'objets en mémoire. Lors de l'exécution d'une transaction, la modification est d'abord effectuée dans le fichier journal. L'écriture des modifications dans le fichier journal est beaucoup plus rapide que dans la base de données ; cela garantit que l'opération de modification est enregistrée, et n'est pas perdue en cas d'incident dans la base de données à ce moment précis. En arrière-plan, le moteur de base de données met continuellement à jour le fichier de base de données avec les modifications récemment validées, les obtenant directement de la mémoire (et non à partir des fichiers journaux).

Lorsque vous effectuez des opérations de chargement volumineuses dans l'annuaire (par exemple, pour des essais de performances ou de dimensionnement), vous voyez que le processus Ldass.exe devient de plus en plus important. Cela est dû à l'allocation de mémoire tampon dans la mémoire système de la base de données. La base de données continue à allouer de la mémoire jusqu'à ce que le système d'exploitation empêche la mise à disposition de mémoire tampon. Cet événement peut se produire lorsque le système approche des limites de mémoire physique ou si l'administrateur limite la mémoire disponible pour l'annuaire dans le Registre. Pour optimiser sa vitesse de fonctionnement, la base de données tente d'obtenir le maximum de mémoire possible. Lors de la mise à jour ultérieure de la base de données, les mémoires tampon sont de nouveau libérées et la taille de Lsass.exe diminue.

Si le contrôleur de domaine ne peut pas s'arrêter normalement (incident correspondant généralement à une coupure de courant), la base de données n'est plus à jour puisque les pages en mémoire les plus récentes n'ont pas pu être écrites sur le disque. Les journaux des transactions sont alors employés pour récupérer la base de données. Toute modification apportée à la base de données est également ajoutée au fichier journal actif et son image disque est toujours maintenue à jour. La base de données subit les modifications suivantes :

1. Lsass.exe écrit la modification dans le fichier journal.

2. Lsass.exe écrit la modification dans une page de base de données dans la mémoire tampon.

3. Lsass.exe confirme la transaction.

4. La modification est écrite sur disque (lors de l'arrêt ou pendant les périodes d'inactivité).

Figure 10.2 Processus de modification de base de données

Si une interruption du service d'annuaire empêche le vidage du fichier de base de données sur le disque, la base de données effectue une récupération au prochain redémarrage. Fondamentalement, la base de données lit les fichiers journaux dans l'ordre et applique à nouveau les modifications jusqu'à ce que la base de données soit de nouveau cohérente et à jour.

ESE peut créer un nouveau fichier journal, lorsque le fichier courant devient saturé (enregistrement non circulaire), ou il peut remplacer le fichier le plus ancien lorsque le journal atteint le nombre maximal spécifié de fichiers (enregistrement circulaire). Un enregistrement non circulaire utilise de l'espace disque jusqu'à la suppression manuelle des anciens fichiers journaux après une sauvegarde ou un redémarrage, mais il enregistre toutes les modifications de base de données et ne supprime jamais automatiquement les fichiers journaux. Le service Active Directory effectue par défaut un enregistrement non circulaire. Vous pouvez remplacer cette valeur par défaut avec la clé du Registre suivante :

HKEY_LOCAL_MACHINE \CurrentControlSetServices \NTDS \Parameters \CircularLogging

Où : 1 = enregistrement circulaire ; 0 = enregistrement non circulaire.

L'exécution de tests de dimensionnement de base de données nécessite une méthode pour déterminer la taille du fichier Ntds.dit. Si vous vérifiez la taille du fichier Ntds.dit pendant qu'un contrôleur de domaine Active Directory effectue un grand nombre d'opérations d'écriture, la taille du fichier de base de données semble ne pas changer. En effet, NTFS enregistre la taille d'un fichier lors de son ouverture et ne la réactualise que lors de la fermeture du fichier. Le service Active Directory ouvre le fichier de base de données lors de l'amorçage du contrôleur de domaine et ne le referme que lors de l'arrêt de l'ordinateur. Par conséquent, vous ne pouvez pas employer la taille du fichier Ntds.dit indiquée par l'Explorateur Windows ni une commande pour déterminer la taille réelle du fichier.

Les méthodes suivantes permettent de déterminer de façon précise la taille du fichier NTDS.DIT :

• Redémarrez le contrôleur de domaine, ce qui ferme le fichier. Il est rouvert au redémarrage du service Annuaire et NTFS indique la taille exacte du fichier.

• Utilisez la boîte de dialogue Propriétés de l'Explorateur Windows sur la partition contenant le fichier Ntds.dit ; elle indique toujours avec précision l'espace disponible. Notez l'espace disponible avant et après le test pour calculer la taille précise du fichier (et le delta du test).

Pour améliorer les performances des contrôleurs de domaine devant traiter des débits élevés de demandes, placez le système d'exploitation Windows 2000 sur un premier disque dur, le fichier de base de données Active Directory sur un deuxième et les fichiers journaux sur un troisième. Utilisez toujours des lecteurs mis en miroir sur les contrôleurs de domaine pour éviter la perte de données résultant d'un incident de disque dur .

Un nettoyage de la mémoire est effectué sur chaque contrôleur de domaine (toutes les 12 heures d'exploitation), supprimant les objets et les fichiers n'étant plus requis par le service Annuaire. Cela signifie que si un contrôleur de domaine est redémarré régulièrement à des intervalles inférieurs à 12 heures, la taille des fichiers de base de données et des fichiers journaux continue d'augmenter. Il est donc préférable de ne pas effectuer de redémarrages inutiles. Le nettoyage de la mémoire effectue les tâches suivantes :

Suppression des fichiers journaux devenus inutiles

Un fichier journal devient inutile une fois que toutes les modifications (et tous les fichiers journaux précédents) ont été écrits dans le fichier de base de données.

Suppression d'enregistrements désactivés

Plutôt que de supprimer physiquement des objets de la base de données, le service Annuaire retire la plupart des attributs et indique que l'objet est dans l'état enregistrement désactivé pour avertir les partenaires de réplication que l'objet a été supprimé. La base de données supprime les enregistrements désactivés après un délai configurable (la durée de vie des enregistrements désactivés, 60 jours par défaut). Vous ne devez pas modifier cette valeur par défaut : les enregistrements désactivés servent à répliquer les suppressions d'objets. Si vous restaurez un serveur d'annuaire à partir d'une bande de sauvegarde plus ancienne que la durée de vie des enregistrements désactivés, le serveur n'a pas eu connaissance de certaines suppressions, ce qui peut conduire à des incohérences entre les contrôleurs de domaine. L'utilitaire de restauration tente d'éviter cet incident, mais il ne peut pas vous empêcher de modifier la durée de vie des enregistrements désactivés. Pour prendre en compte l'interruption occasionnelle de la réplication due à des incidents de communication, définissez une durée de vie pour les enregistrements désactivés beaucoup plus longue que le temps de latence de réplication prévu.

Défragmentation de la base de données

Pour mettre à jour le fichier de base de données, le système de base de données emploie la méthode la plus rapide (pas toujours la plus efficace) pour remplir des pages de base de données. La défragmentation redéfinit le mode d'écriture des données dans la base de données. La défragmentation en ligne ne réduit pas la taille du fichier de base de données, mais elle augmente l'espace disponible pour de nouveaux objets.

Vous pouvez également défragmenter le fichier de base de données en mode hors connexion. Mettez le contrôleur de domaine en mode hors connexion, démarrez-le en mode de réparation des services d'annuaire à l'aide de la touche F8 lors du redémarrage du système et employez Ntdsutil.exe. Vous créez ainsi une deuxième version défragmentée du fichier de base de données qui est considérablement plus petite que le fichier de base de données d'origine. Vous pouvez alors choisir le fichier de base de données à utiliser sur le contrôleur de domaine.

Recommandation Utilisez la défragmentation uniquement lorsque vous savez que le contenu de la base de données a été réduit considérablement (par exemple, lorsqu'un serveur de catalogue global devient un contrôleur de domaine normal) et que vous devez libérer de l'espace pour d'autres utilisations. Conservez le fichier Ntds.dit d'origine jusqu'à ce que le contrôleur de domaine ait redémarré avec le fichier défragmenté. Une fois que vous n'avez plus aucun doute quant à la cohérence de la base de données, vous pouvez supprimer le fichier de base de données d'origine (fragmenté).

Lorsque vous testez l'extension de la base de données lors du chargement d'un ensemble spécifique d'objets, gardez à l'esprit les observations suivantes :

1. Lorsque des objets sont chargés dans l'annuaire, la base de données est dans un état fragmenté, rendant ainsi impossible l'évaluation de l'espace réellement occupé par les objets dans le fichier de base de données.

2. La défragmentation en ligne libère de l'espace, mais ne diminue pas la taille du fichier de base de données. Le résultat de la défragmentation indique toutefois la réelle consommation d'espace.

3. Seule la défragmentation en mode hors connexion permet d'évaluer de façon précise la réelle consommation d'espace.

Dans un environnement de production, sélectionnez toujours la défragmentation en ligne ; elle donne les mêmes résultats que le processus en mode hors connexion sans qu'il soit nécessaire de mettre l'ordinateur en mode hors connexion. Pour les tests d'extension de la base de données, vous devez toutefois défragmenter la base de données d'annuaire en mode hors connexion après un chargement volumineux d'objets puisque seule la version défragmentée en mode hors connexion de la base de données d'annuaire permet d'évaluer la quantité d'espace consommée. Pour souligner ces différences, certains des tests de chargement de base de données suivants illustrent les résultats des versions fragmentées et défragmentées en mode hors connexion du fichier de base de données.

Dernière mise à jour le mardi 9 mai 2000