Réplication d’A.D. et vecteurs à  jour

  Dans « Suivre une réplication d’A.D.», janvier 2001, j’expliquais comment AD (Active Directory) utilise les numéros de séquence de mise à  jour (USN, update sequence numbers) pour suivre les modifications apportées à  chaque copie du DC (domain controller) du contenu de l’AD. Chaque serveur se souvient de l’USN le plus récent obtenu de ses partenaires de réplication (c’est-à -dire, la marque haute) et utilise cet USN pour contrôler la réplication. Ainsi, DC1 pourrait dire à  DC2, « Dites-moi quelles mises à  jour vous avez faites depuis votre USN 10.000 ».

  Quand un administrateur crée un nouveau compte utilisateur sur DC1, cette mise à  jour incrémente l’USN de DC1, amenant DC2 à  demander les changements d’AD associés à  cette mise à  jour. Mais, quand DC2 intègre cette mise à  jour et incrémente son propre USN, le nouvel USN de DC2 amène DC1 à  demander une mise à  jour provenant de DC2 – incluant le nouveau compte utilisateur, dont DC1 connaît déjà  l’existence. Enregistrer cette mise à  jour aboutirait à  un cycle sans fin de réenregistrement du même élément d’information.

  Pour empêcher les changements d’entrer dans un cycle indéfini, AD mémorise non seulement l’USN local qui génère une mise à  jour, mais également le GUID (globally unique identifier) du DC qui est à  l’origine de la mise à  jour. Ainsi, AD peut faire la différence entre une mise à  jour qu’un DC à  l’origine génère et une qu’un DC se contente de transmettre à  un autre DC. Chaque DC mémorise non seulement le dernier USN reçu de chaque partenaire de réplication mais également l’USN associé à  la mise à  jour la plus récente émanant de chacun des autres DC du domaine. Le tableau qui contient les derniers USN à  l’origine est appelé up-to-date vector (vecteur à  jour).

  Les DC utilisent le vecteur à  jour pour empêcher des boucles de mise à  jour infinies. Supposons que la dernière mise à  jour à  l’origine que DC2 a reçu de DC1 soit USN 9871 et que la dernière mise à  jour dont DC2 est à  l’origine soit USN 1500. DSN dit à  DC1, « Informez-moi sur les mises à  jour que vous avez reçues depuis la dernière fois où vous m’avez mis à  jour, mais sautez celles émanant de DC1 et qui avaient un DSN 9871 ou moins et celles émanant de DC2 et qui avaient un USN de 1500 ou moins ». Supposons que DC1 ait une nouvelle mise à  jour, avec un USN de 10.001. Quand DC1 envoie cette mise à  jour à  DC2, ce dernier sauvegarde l’information comme USN 1553 mais se souvient également que l’USN à  l’origine était 10.001 et que la mise à  jour émanait de DC1. DC2 augmente son entrée de vecteur à  jour pour DC1 à  10.001. (DC1 modifie également son vecteur à  jour pour montrer que le vecteur à  jour de DC1 est 10.001.)

  Quand DC1 demande ensuite des mises à  jour à  DC2, DC1 dit « Je suis au courant de vos mises à  jour par l’intermédiaire de votre USN 1552, et j’ai vu toutes les mises à  jour émanant de DC1 par l’intermédiaire d’USN 10.001 et toutes les mises à  jour émanant de DC2 par l’intermédiaire d’USN 1500. Avez-vous des mises à  jour plus récentes ? » DC2 voit qu’il a un USN supérieur à  1552, mais que le DC à  l’origine était DC1 et que l’USN du DC à  l’origine était 10.001. Comme le vecteur mis à  jour de DC1 inclut toutes les entrées émanant de DC1 par l’intermédiaire d’USN 10.001, DC1 est au courant de l’USN 1553 de DC2 et n’enregistre pas une nouvelle mise à  jour. Vous pouvez utiliser la commande Repadmin /showvector pour visualiser un vecteur mis à  jour de DC. Pour transférer le vecteur pour dc1.acme.com dans un domaine appelé acme.com, tapez :

repadmin /showvector
dc=acme,dc=com
dc1.acme.com

  La figure 1 montre un exemple de sortie. Notons que la dernière ligne montre un GUID plutôt qu’un nom de DC: après le décommissionnement d’un DC, ses entrées apparaissent encore dans les vecteurs à  jour des autres DC, mais les entrées apparaissent sous l’ancienne GUID du DC plutôt que sous la forme d’un nom de DC.