Méthodes de duplication

BDC.
AD utilise, en revanche, un modèle de mise à  jour multiple domaine maître, dans
lequel tous les contrôleurs de domaines ont des copies inscriptibles d’AD. Comme
tous les contrôleurs de domaines peuvent créer des mises à  jour, ils ont besoin
d’une méthode pour dupliquer mutuellement leurs changements. AD utilise deux méthodes
de duplication – l’une pour la duplication à  l’intérieur d’un site (c’est-à -dire
la duplication intra-site) et l’autre pour la duplication entre sites (c’est-à -dire
la duplication inter-sites).

Duplication intra-site. Lorsqu’un contrôleur de domaine subit
une modification, celle-ci doit se propager dans toute la partition d’annuaire
du contrôleur de domaine. A l’exception de certains cas spéciaux (par exemple
verrouillage de compte, changements de mot de passe), AD utilise un modèle de
duplication à  cohérence lâche pour propager les changements.
à€ cohérence lâche signifie que les changements intervenant sur un contrôleur de
domaine mettent un laps de temps fini (5 minutes par défaut) pour se propager
au voisin du contrôleur de domaine et à  travers la partition d’annuaire du contrôleur
de domaine.

Par exemple si les utilisateurs changent leurs numéros de pager, le temps mis
par les changements pour se propager à  travers le domaine dépend du nombre de
contrôleurs de domaine que possèdent les sites des utilisateurs, du nombre d’autres
sites auxquels s’étendent les domaines utilisateurs et du nombre de contrôleurs
de domaines se trouvant dans ces autres sites. Des cas spéciaux provoquent une
duplication urgente dans laquelle les contrôleurs de domaines n’attendent pas
les 5 minutes normales avant de déclencher la duplication.

AD utilise des objets de connexion pour supporter la duplication entre les contrôleurs
de domainesAD utilise des objets de connexion pour supporter la duplication entre
les contrôleurs de domaines. Un objet de connexion est un itinéraire unidirectionnel
de duplication entrante utilisant RPC, provenant de contrôleurs de domaines voisins
des contrôleurs de domaines, baptisés par Microsoft partenaires de duplication.
Tout comme, dans NT 4.0, deux approbations unidirectionnelles forment une approbation
bidirectionnelle, les partenaires de duplication utilisent deux objets de connexion
– un pour chaque direction – pour effectuer la duplication bidirectionnelle, comme
le montre la Figure 1.

On peut observer les objets de connexion d’un contrôleur de domaine dans la fenêtre
du composant enfichable Sites and Services de la MMC d’Active Directory. Double-cliquez
sur le conteneur d’un site pour obtenir une liste de ses contrôleurs de domaines.
Dans un site, chaque contrôleur de domaine a un objet NTDS, que l’on peut voir
en double-cliquant sur le contrôleur de domaine. Double-cliquez sur un objet NTDS
pour voir les objets de connexion qui transportent le trafic de duplication des
autres contrôleurs de domaines (c’est-à -dire les objets de connexion de duplication
vers l’intérieur) vers ce contrôleur de domaine. Cliquez à  droite sur l’objet
de connexion de duplication vers l’intérieur et sélectionnez l’option du menu
Repliquer maintenant pour demander une mise à  jour immédiate des partenaires de
duplication d’un contrôleur de domaine.

La gestion des objets de connexion d’AD nécessite trop de main d’oeuvre pour pouvoir
être exécutée manuellement. Heureusement, AD propose le KCC (Knowledge Consistency
Checker), qui configure et met à  jour dynamiquement les objets de connexion entre
les contrôleurs de domaine pour créer des chemins de duplication. Le KCC est actif
sur chaque contrôleur de domaine et constitue le ciment qui consolide AD. On ne
peut pas directement observer le KCC comme un service, mais on peut voir ses actions
dans le journal d’événements.
La gestion des objets de connexion d’AD nécessite trop de main d’oeuvre pour pouvoir
être exécutée manuellementLe KCC suit un algorithme spécifique pour connecter
les contrôleurs de domaines d’un site. Il génère une liste des serveurs du site,
contenant une partition d’annuaire donnée (par exemple la partition du domaine)
et utilise des objets de connexion pour unir les serveurs dans un anneau bidirectionnel
(Figure 2). Cette topologie en anneau garantit qu’en cas de défaillance d’un serveur,
les autres serveurs peuvent contourner le serveur défaillant pour se dupliquer
avec les autres serveurs.

Au fur et à  mesure de l’augmentation du nombre de contrôleurs de domaines d’un
site, le KCC modifie son algorithme pour éviter le processus de duplication interminable
provoqué par la transmission, par chaque contrôleur de domaine, de la mise à  jour
à  son voisin. Le KCC utilise la règle des trois tronçons selon laquelle un contrôleur
de domaine ne peut se trouver à  plus de trois tronçons de duplication d’un autre
contrôleur de domaine. Ainsi, une mise à  jour ne franchit pas plus de trois tronçons
avant d’atteindre un autre contrôleur de domaine ayant déjà  reçu la mise à  jour
par un autre chemin.

Pour imposer la règle des trois tronçons, le KCC crée des connexions d’optimisation
(c’est-à -dire des raccourcis) sur les voies d’accès de duplication entre les contrôleurs
de domaines, comme le montre la Figure 3. Ces connexions d’optimisation sont créés
au hasard – et ne s’appliquent pas nécessairement aux trois contrôleurs. On peut
cliquer sur les conteneurs NTDS de chaque contrôleur de domaine dans le composant
enfichable Sites and Services et tracer des traits entre les contrôleurs de domaines
pour dessiner manuellement la topologie de duplication. Cette tâche devient de
plus en plus compliquée, mais l’outil Replmon permet un affichage plus détaillé
de la topologie de duplication. (Replmon est un Outil de support Windows 2000
qui s’installe à  partir du dossier \support\tools de Windows 2000 Advanced Server).
Le KCC s’exécute sur chaque contrôleur de domaine et tous les KCC utilisent le
même algorithme pour créer la topologie du site. Ainsi, les contrôleurs de domaines
se dupliqueront mutuellement jusqu’à  ce qu’ils contiennent tous les mêmes informations.

Une bonne conception de site peut prévoir le temps d’attente, c’est le temps nécessaire
à  une mise à  jour émise à  partir d’un contrôleur de domaine de la forêt pour se
propager à  un autre endroit de la forêt. Par exemple, pour une mise à  jour émise
à  partir d’un contrôleur de domaine A, comme sur la Figure 3, le temps maximum
nécessaire à  un changement pour se dupliquer autour d’un site (le contrôleur de
domaine B) est de 15 minutes, parce que l’intervalle de duplication par défaut
d’AD est de 5 minutes et que le KCC utilise la règle des trois tronçons.

Pour déterminer le laps de temps nécessaire à  un objet ou à  un attribut pour être
dupliqué à  travers la forêt, il faut tenir compte du type d’objet ou d’attribut
à  dupliquer. Par exemple, lorsque les utilisateurs changent leurs numéros de pager,
les changements ne se dupliquent qu’à  travers les domaines des utilisateurs. Cependant
lorsqu’ils changent leurs adresses e-mail, ces attributs se dupliquent à  tous
les serveurs de catalogue global de la forêt car les adresses e-mail sont des
objets du catalogue global. L’ajout d’un nouveau domaine à  la forêt est un autre
changement qui met plus de temps à  se dupliquer à  travers une forêt. Lorsque l’on
ajoute un domaine dans la partition de configuration, on crée une modification
qui doit être dupliquée à  travers tous les contrôleurs de domaine de la forêt.

Duplication inter-sites.Windows 2000 affecte la gestion
de la duplication inter-sites aux serveurs têtes de pont. (Pour parler de la duplication
inter-sites je suppose que vous n’utilisez qu’IP pour le transport inter-sites.
Si vous utilisez le transport inter-sites SMTP, voyez le Kit de ressources de
Windows 2000). Le KCC désigne automatiquement les serveurs têtes de pont. Mais
comme ceux-ci supportent plus de trafic réseau que d’autres contrôleurs de domaines
du site, il peut être nécessaire de sélectionner manuellement les serveurs têtes
de pont.

La sélection des serveurs têtes de pont présente plusieurs avantages. Elle permet
d’abord de désigner une machine à  grande capacité au lieu de laisser le KCC choisir
une machine dépourvue des ressources nécessaire.
Deuxièmement, le KCC pourrait sélectionner différents serveurs têtes de pont pour
chaque partition d’annuaire et catalogue global. Le choix manuel des serveurs
têtes de pont permet de décider comment les consolider.
Troisièmement, la désignation de serveurs têtes de pont favoris facilite le dépannage,
puisque les emplacements de ces serveurs sont déjà  connus. Mais pour passer outre
le KCC et sélectionner manuellement les serveurs, il faut créer plusieurs serveurs
têtes de pont favoris, afin d’avoir un serveur de secours en cas de panne du serveur
primaire.

La duplication inter-sites considère les sites comme des objets de la forêt, chacun
avec un moteur pour générer la topologie

Pour comprendre le processus de duplication inter-sites, prenez la méthode de
duplication intra-site, selon laquelle les contrôleurs de domaines sont des objets
à  l’intérieur du site, chacun avec un moteur (c’est-à -dire le KCC) pour générer
la topologie. Pour la duplication inter-sites, prenez la méthode de duplication
intra-site et faites-la monter d’un cran. La duplication inter-sites considère
les sites comme des objets de la forêt, chacun avec un moteur pour générer la
topologie. Ce moteur, c’est l’ISTG (Inter-Site Topology Generator). Son rôle est
assumé par un contrôleur de domaine par site (normalement le premier contrôleur
de domaine du site).
L’ISTG ne peut pas être désigné manuellement, bien que l’on puisse configurer
manuellement la duplication inter-sites. C’est le KCC du contrôleur de domaine
ISTG qui crée les connexions entre les contrôleurs de domaines de son site et
ceux des autres sites. Ces connexions comprennent les objets de connexion de duplication
vers l’intérieur pour tous les serveurs têtes de pont du site du contrôleur de
domaine.
Si l’ISTG s’arrête, c’est le contrôleur de domaine suivant possédant la GUID la
plus élevée – c’est-à -dire la valeur 128 bits qui identifie de manière unique
chaque objet AD – qui assume le rôle d’ISTG.
Pour voir l’ISTG d’un site, il suffit de cliquer sur l’objet de ce site dans composant
enfichable Sites and Services d’Active Directory. Dans la sous-fenêtre de droite
affichant les détails, cliquez à  droite sur l’objet NTDS Site Settings, puis sur
Propriétés. Le possesseur actuel du rôle (c’est-à -dire le contrôleur de domaine
ISTG) apparaît dans la case Serveur de l’ISTG.