quelques questions sur la table high water mark et le vecteur up to dateness



Attention ! Votre version de Flash Player est vulnérable, Mettre à jour Maintenant

Quelqu’un peut-il m’aider à essayer de comprendre «exactement» comment fonctionne la réplication d’AD (peut-être un membre de l’équipe des services d’annuaire Microsoft pourrait-il répondre à cet article),

Merci de ne pas me pointer vers des documents techniques car j’en ai lu plusieurs et un ou deux points ne sont toujours pas clairs,

Merci d’avance

Ce qui suit est un peu long, mais je voulais souligner ma compréhension actuelle afin de clarifier ma question (s’il-vous-plaît)

Un objet utilisateur (appelé Fred) dans le contexte de nommage par défaut (partition de domaine)

L’objet utilisateur a un attribut usnChanged (par exemple pour l’objet dans son ensemble), tandis que chaque attribut (téléphone) a son propre USN (qui peut ou non correspondre à l’USN d’origine, mais seulement si le changement est originaire de ce DC).

À son tour la partition elle-même (dans le cas de la partition de domaine) a son propre attribut usnChanged qui est incrémenté de 1 chaque fois qu’un usn (originaire ou répliqué) est mis à jour sur un objet

En d’autres termes, le nombre d’objets usnChanged est incrémenté de 1 lorsque jamais un attribut est modifié sur un objet. Par conséquent, la partition usnChanged est un compteur qui indique le nombre de modifications dans leur ensemble (local ou répliqué pour les objets de cette partition particulière).

Question 1 : Je crois que le nombre de partitions usnChanged est en effet le niveau High Water Mark pour cette partition ? (c’est-à-dire une seule et même valeur)

Le niveau de high water mark n’est pertinent que pour les partenaires de “réplication”, par exemple RepsFrom qui est un petit nombre de DC dans un grand domaine (pas tous les DC)

Chaque contrôleur de domaine maintient également une table appelée le vecteur UTDV (up to dateness) qui ne concerne que l’usn pour les écritures d’origine et les écritures non répliquées.

Question 2 :

L’usnChanged pour une partition (high water mark) est un simple compteur, si facile à comprendre. Cependant qu’en est-il de la table UTDV, est-elle incrémentée de 1 chaque fois qu’une écriture d’origine a lieu sur cette partition DCs ?

Pour le moment je ne comprends pas ce qui est exactement gardé sur la table UTDV (donc je fais des suppositions)

Donc, si vous aviez 100 000 objet est une partition et 4 des objets ont reçu une modification à un de leurs attributs à ce DC alors il y aurait 4 écritures d’origine et chaque objet usn et originn usn serait incrémenté de 1 (comme le ferait usnChanged pour l’objet, et la partition usnChanged serait incrémentée de 4)

UTDV est utilisé pour faciliter l’amortissement de la propagation (donc la même mise à jour n’est pas propagée plus d’une fois entre différents partenaires de réplication) en filtrant certains des attributs qui seraient sinon synchronisés sur la seule ligne des hautes eaux.

Ce dont je ne suis pas sûr, c’est la mécanique exacte de ceci, je pense que cela doit être quelque chose comme ceci, s’il vous plaît corriger si / où encouru

DC1 (destination) est en cours de synchronisation avec DC2 (source)

DC2 envoie à DC1 son HWMT et son UTDV

DC1 voit la dernière fois qu’il est synchronisé avec DC2, DC2 a un HWM de 1000 et cette fois il est 1100 alors DC1 sait qu’il y a 100 mises à jour à la partition DC2 depuis leur dernière synchronisation

Toutefois, à ce stade, DC1 ne sait pas «quels objets individuels» ces mises à jour se réfèrent à

DC1 est en possession de la table DC2 UTDV et surtout de sa propre UTDV (pour la partition en question)

Ensuite ( et c’est la partie sur laquelle je ne suis pas clair )
DC1 demande une liste d’objets de DC2 dont l’objet usnChanged sur DC2 est supérieur à 1000 (l’ancienne valeur HWM), mais filtre en même temps tous les objets dont le ‘originnn usn’ (de la table DC1 UTDV) correspond à ‘dans le UTDV il a reçu de DC2 au début du processus.

Cette liste ci-dessus est-elle correcte ?

En d’autres termes, le filtrage UTDV est-il effectué sur le DC source (celui sur l’envoi de la mise à jour) et non sur le DC de destination (celui qui demande les mises à jour), par exemple, ils ne sont pas filtrés ?

La chose que j’essaie de comprendre à propos de l’UTDV est la suivante

Les ‘usn originaires’ sont par attribut et par objet, ce qui, en grande AD, pourrait atteindre plusieurs millions. Donc je pense que la table UTDV pourrait être très grande si elle stocke une entrée pour chaque écriture d’origine sur une partition pour toutes les copies de cette partition sur le réseau (par exemple chaque DC avec une copie complète en lecture / écriture de la partition), plutôt que juste un compteur comme la table HWM. Cette table UTDV potentiellement volumineuse doit ensuite être synchronisée (tous entre les partenaires de réplication) sur chaque contrôleur de domaine du domaine (avec cette partition)

Quelqu’un peut-il m’aider à comprendre ce dernier point, l’UTDV est en effet une table contenant une liste de tous les usn d’origine pour un DC donné (chaque DC du domaine est représenté dans la table UTDV), et pourrait donc être très grand ?

Merci beaucoup

__Un autre utilisateur

AAnotherUser__

Salut,

Pour vos questions:

Q1: Je crois que le nombre de partitions usnChanged est en effet le niveau High Water Mark pour cette partition ?

Réponse: Ils sont deux attributs différents. La marque des hautes eaux stocke le USN max local
de la partition directement pour le partenaire direct (opposé DC). UsnChanged est le USN maximum local pour un attribut pour lui-même. Ci-dessous est la marque High Water et UsnChanged.

Q2: L’usnChanged pour une partition (high water mark) est un simple compteur, si facile à comprendre. Cependant qu’en est-il de la table UTDV, est-elle incrémentée de 1 chaque fois qu’une écriture d’origine a lieu sur cette partition DCs ?

Réponse: UTDV stocke l’USN d’origine pour tous les contrôleurs de domaine du domaine, il ne sera pas incrémenté de 1 à chaque fois que le contrôleur de domaine source envoie son vecteur de mise à jour à la destination à la fin d’un cycle de réplication réussi.

 

Q3: DC1 demande une liste d’objets de DC2 dont l’objet usnChanged sur DC2 est supérieur à 1000 (l’ancienne valeur HWM), mais filtre en même temps tous les objets dont le ‘originnn usn’ (de la table DC1 UTDV) correspond au ‘ provenant de l’UTDV qu’il a reçu de DC2 au début du processus. Cette liste ci-dessus est-elle correcte ?

Réponse: Non, DC1 enverra l’eau haute et l’ UTDV à DC2, vous pouvez vous référer aux informations ci-dessous:

Lorsqu’un contrôleur de domaine de destination demande des modifications pour une partition d’annuaire, il fournit son vecteur de mise à jour au contrôleur de domaine source.

Lors de la demande de modifications, le contrôleur de domaine de destination envoie sa valeur de repère supérieur au contrôleur de domaine source.

Q4: En d’autres termes, le filtrage UTDV est effectué sur le DC source (celui sur l’envoi de la mise à jour) et non sur le DC de destination (celui qui demande les mises à jour). sortir ?

Réponse: Oui, filtrage UTDV au Source DC.

Q5: Quelqu’un peut-il m’aider à comprendre ce dernier point, l’UTDV est-elle en effet une table contenant une liste de tous les usn d’origine pour un contrôleur de domaine donné (chaque DC du domaine est représenté dans la table UTDV), et pourrait donc très grand ?

Réponse: Oui, il suffit d’une table contenant une liste de tous les usn d’origine pour un DC donné, sa taille dépend de l’architecture de votre domaine. Voici la capture d’UTDv.

Pour plus d’informations, voir le lien ci-dessous:

Ce sont les mises à jour que vous recherchez

Fonctionnement du modèle de réplication Active Directory

Si vous avez des questions, n’hésitez pas à me contacter.

Meilleures salutations,

William

S’il vous plaît n’oubliez pas de marquer les réponses comme des réponses si elles aident et de les marquer si elles ne fournissent aucune aide.
Si vous avez des commentaires sur l’assistance aux abonnés TechNet, contactez .

Salut,

Merci pour votre question.
J’essaie d’impliquer quelqu’un de familier avec ce sujet pour examiner plus loin ce problème. Il pourrait y avoir une période de délai. Remercions de votre patience.
Merci de votre compréhension et de votre soutien.

Meilleures salutations,

William

S’il vous plaît n’oubliez pas de marquer les réponses comme des réponses si elles aident et de les marquer si elles ne fournissent aucune aide.
Si vous avez des commentaires sur l’assistance aux abonnés TechNet, contactez .

Salut,

Pour vos questions:

Q1: Je crois que le nombre de partitions usnChanged est en effet le niveau High Water Mark pour cette partition ?

Réponse: Ils sont deux attributs différents. La marque des hautes eaux stocke le USN max local
de la partition directement pour le partenaire direct (opposé DC). UsnChanged est le USN maximum local pour un attribut pour lui-même. Ci-dessous est la marque High Water et UsnChanged.

Q2: L’usnChanged pour une partition (high water mark) est un simple compteur, si facile à comprendre. Cependant qu’en est-il de la table UTDV, est-elle incrémentée de 1 chaque fois qu’une écriture d’origine a lieu sur cette partition DCs ?

Réponse: UTDV stocke l’USN d’origine pour tous les contrôleurs de domaine du domaine, il ne sera pas incrémenté de 1 à chaque fois que le contrôleur de domaine source envoie son vecteur de mise à jour à la destination à la fin d’un cycle de réplication réussi.

 

Q3: DC1 demande une liste d’objets de DC2 dont l’objet usnChanged sur DC2 est supérieur à 1000 (l’ancienne valeur HWM), mais filtre en même temps tous les objets dont le ‘originnn usn’ (de la table DC1 UTDV) correspond au ‘ provenant de l’UTDV qu’il a reçu de DC2 au début du processus. Cette liste ci-dessus est-elle correcte ?

Réponse: Non, DC1 enverra l’eau haute et l’ UTDV à DC2, vous pouvez vous référer aux informations ci-dessous:

Lorsqu’un contrôleur de domaine de destination demande des modifications pour une partition d’annuaire, il fournit son vecteur de mise à jour au contrôleur de domaine source.

Lors de la demande de modifications, le contrôleur de domaine de destination envoie sa valeur de repère supérieur au contrôleur de domaine source.

Q4: En d’autres termes, le filtrage UTDV est effectué sur le DC source (celui sur l’envoi de la mise à jour) et non sur le DC de destination (celui qui demande les mises à jour). sortir ?

Réponse: Oui, filtrage UTDV au Source DC.

Q5: Quelqu’un peut-il m’aider à comprendre ce dernier point, l’UTDV est-elle en effet une table contenant une liste de tous les usn d’origine pour un contrôleur de domaine donné (chaque DC du domaine est représenté dans la table UTDV), et pourrait donc très grand ?

Réponse: Oui, il suffit d’une table contenant une liste de tous les usn d’origine pour un DC donné, sa taille dépend de l’architecture de votre domaine. Voici la capture d’UTDv.

Pour plus d’informations, voir le lien ci-dessous:

Ce sont les mises à jour que vous recherchez

Fonctionnement du modèle de réplication Active Directory

Si vous avez des questions, n’hésitez pas à me contacter.

Meilleures salutations,

William

S’il vous plaît n’oubliez pas de marquer les réponses comme des réponses si elles aident et de les marquer si elles ne fournissent aucune aide.
Si vous avez des commentaires sur l’assistance aux abonnés TechNet, contactez .

….
Merci beaucoup William, ça répond à toutes mes questions 🙂

AAnotherUser__

Salut,

Je suis heureux de savoir que l’information vous est utile.

S’il y a autre chose que nous pouvons faire pour vous, n’hésitez pas à poster dans le forum.

Meilleures salutations,
William

S’il vous plaît n’oubliez pas de marquer les réponses comme des réponses si elles aident et de les marquer si elles ne fournissent aucune aide.
Si vous avez des commentaires sur l’assistance aux abonnés TechNet, contactez .

%d blogueurs aiment cette page :