Architecture de l’annuaire et bases de données

les deux par dessus ESE (Extensible Storage Engine). ESE est une
variante du moteur de base de données Jet utilisé par Microsoft dans d’autres
produits. Les deux annuaires utilisent le même modèle de consignation des transactions
pour saisir les données et s’assurer qu’elles vont dans la base de données.
Comme le montre la figure 2, AD écrit les transactions dans le buffer du journal,
puis les enregistre dans le journal courant des transactions et dans une mémoire
cache. Si la transaction est terminée, le moteur de la base de données exécute
la transaction dans la base de données, lorsque la charge du système le permet,
ou lorsqu’AD vide ses buffers (par exemple comme dans une sauvegarde complète
en ligne).
Pour marquer la dernière écriture ayant réussi, le moteur de la base de données
fait avancer le fichier de contrôle au fur et à  mesure qu’il exécute les transactions
dans la base de données.

La figure 2 illustre les méthodes utilisées par le moteur de la base de données
pour exécuter les transactions à  la fois dans AD et dans le Directory Store.
Il existe des différences mineures entre les noms de fichiers : dans AD, c’est
le fichier lsass.exe qui gère les transactions au lieu du fichier dsamain.exe,
et l’annuaire écrit les données dans la base de données d’AD, ntds.dit, au lieu
de dir.edb dans Exchange Server 3.5. Microsoft a également introduit des modifications
mineures de mise en oeuvre – par exemple, les journaux de transactions contiennent
10 Mo de données au lieu de 5 Mo.

Mais les administrateurs systèmes Exchange vont devoir se familiariser avec le
modèle de consignation des transactions de la figure 2, car c’est le même modèle
que celui utilisé par l’Information Store (IS).

Lorsque vous migrerez à  Windows 2000 et Exchange
2000, il faudra vous souvenir de certaines leçons durement apprises dans Exchange
Server

Lorsque vous migrerez à  Windows 2000 et Exchange 2000, il faudra vous souvenir
de certaines leçons durement apprises dans Exchange Server. La plus évidente est
la nécessité d’assurer une protection, la plus complète possible, du Directory
Store.

En effet, il n’est pas facile de récupérer un Directory Store altéré. AD n’est
pas comme la base de données SAM de NT. C’est une base de données plus complexe
capable d’évoluer pour stocker des millions d’objets. Selon une excellente pratique
héritée d’Exchange Server les administrateurs doivent placer la base de données
d’AD dans un volume RAID 5 ou RAID 0+1 et mettre les journaux de transaction sur
un volume physique séparé RAID 1.

Il est indispensable d’effectuer des sauvegardes quotidiennes et d’élaborer un
plan de récupération après incident décrivant comment restaurer une base de données
AD endommagée. En cas de défaillance d’un contrôleur de domaine ou d’un Catalogue
global (GC), il faut comprendre comment remettre le serveur de nouveau en ligne
le plus vite possible.

Microsoft a fait beaucoup d’efforts pour comprendre les problèmes rencontrés par
le Directory Store en production et apporter les modifications nécessaires à  AD.
C’est notamment dans le domaine de la duplication que ces efforts seront particulièrement
appréciés. La duplication du Directory Store se fait par objets. Toute modification
d’un attribut de boîte à  lettres (par exemple le numéro de téléphone, le nom d’affichage)
entraînera par conséquent celle de l’objet tout entier. C’est pourquoi, à  chaque
modification d’un objet (même minime), ce sont 3,5 à  4,5 Ko de données qui doivent
être dupliquées.

En revanche, la duplication d’AD se fait par attribut. En cas de modification
d’un attribut d’un objet utilisateur Windows 2000, seules les données de l’attribut
modifié sont dupliquées sur les autres serveurs. La quantité exacte de données
dépend du type d’attribut modifié, mais pour un simple attribut d’une chaîne,
comme le nom d’affichage, ce sont environ 100 octets qui se dupliquent.

La duplication par attribut est nécessaire lorsque le Service d’annuaire traite
les objets à  la fois pour le système d’exploitation et pour les applications.
Un objet utilisateur peut contenir beaucoup plus d’attributs qu’une boîte à  lettre
Exchange Server 5.5 et occupe par conséquent plus d’espace par objet au sein de
l’annuaire – probablement environ 6 Ko par objet utilisateur de la boîte à  lettres.
Les attributs associés à  un objet peuvent être étendus en modifiant le schéma
d’AD. Par exemple, Exchange 2000 modifie le schéma d’AD pour ajouter le support
des adresses de messagerie.
Un supplément d’attributs signifie davantage de données à  dupliquer et de par
la nature extensible de l’annuaire, chaque application installée risque d’augmenter
la charge du système au point de faire s’effondrer le modèle de duplication tout
entier. La duplication par attribut résout ces problèmes, mais pas tous les autres
problèmes rencontrés par les systèmes de duplication.

Exchange 2000 modifie le schéma d’AD pour ajouter le support des
adresses de messagerie