Partager via

Vue d’ensemble des techniques de Change Tracking

  • Article

Les mécanismes de suivi des modifications peuvent différer de plusieurs façons :

  • Étendue du suivi des modifications : une application peut suivre les modifications apportées à un attribut unique d’un seul objet, à tous les objets d’un domaine, etc. Si le mécanisme correspond aux exigences de l’application, l’application reçoit un minimum de données non pertinentes, ce qui améliore les performances.

  • Rapidité : une application est informée de chaque modification à mesure qu’elle se produit, ou peut être informée de l’effet net des modifications sur une période de minutes ou d’heures.

    Le traitement de données moins opportuns peut être plus efficace, car plusieurs modifications peuvent être réduites en une seule. Par exemple, si un attribut change trois fois dans un intervalle d’une heure, une application avertie des modifications accumulées sur une heure ne sera avertie que d’une seule modification d’attribut, et non de trois.

    Lorsque vous pensez à la rapidité, tenez compte de l’effet de la latence de réplication. Une mise à jour qui provient d’un contrôleur de domaine ne se réplique pas instantanément sur un autre contrôleur de domaine. L’exigence d’une rapidité de suivi des modifications bien meilleure que la latence de réplication attendue n’offre souvent aucun avantage réel à l’application.

  • Interrogation et notification : avec l’interrogation, une application fait régulièrement une demande à un contrôleur de domaine pour recevoir des données de suivi des modifications. Avec la notification, le contrôleur de domaine envoie les modifications à l’application uniquement lorsque des modifications se produisent.

    La surcharge de l’interrogation est évidente : l’application peut demander des données de suivi des modifications lorsque rien de significatif ne s’est produit. La surcharge de notification est plus subtile. Le serveur doit conserver les données relatives aux demandes de notification et doit consulter ces données pour décider d’envoyer ou non une notification. Cela peut ajouter une surcharge aux demandes de mise à jour normales.

  • Expression des connaissances de l’application : persistante ou temporaire : chaque mécanisme de suivi des modifications doit inclure une méthode pour que le serveur qui conserve les données suivies pour comprendre l’état des connaissances de l’application, afin que l’idée de « modification » soit bien définie. Par exemple, l’état des connaissances de l’application peut être exprimé comme « Mis à jour avec toutes les modifications qui se sont produites sur dc d avant l’heure t ». Un mécanisme basé sur cette façon d’exprimer l’état des connaissances d’une application fournirait un moyen efficace pour l’application d’obtenir des modifications qui se sont produites après une heure spécifiée.

    Si l’expression des connaissances de l’application peut être conservée, c’est-à-dire stockée de manière récupérable, comme dans un fichier ou une base de données, le redémarrage de l’application nécessite moins de ressources que s’il ne peut pas. Dans l’exemple ci-dessus, l’expression des connaissances de l’application peut être conservée en enregistrant le contrôleur de domaine d et l’heure t. Certains mécanismes de notification des modifications n’autorisent pas la persistance de ces données. Le serveur et l’application doivent se synchroniser avec un autre mécanisme au démarrage de l’application. Cette opération nécessite beaucoup de ressources si plusieurs objets sont impliqués et peut impliquer une programmation complexe.

Utilisez les techniques suivantes pour suivre les modifications apportées à services de domaine Active Directory :

Le contrôle de notification de modification est conçu pour les applications ou les services qui nécessitent une notification raisonnablement rapide des modifications peu fréquentes. Par exemple, un service ou un programme qui stocke des données de configuration sur le serveur Active Directory et qui doit être averti rapidement lorsqu’une modification se produit. N’oubliez pas qu’il existe des limitations du contrôle de notification.

  • La promptitude des notifications dépend de la latence de réplication et de l’endroit où la modification s’est produite. Vous pouvez être averti rapidement lorsqu’une modification est répliquée dans le réplica que vous surveillez, mais la modification a peut-être été apportée beaucoup plus tôt sur d’autres réplica.
  • Le contrôle est limité à la surveillance d’un seul objet ou des enfants immédiats d’un conteneur. Les applications qui doivent surveiller plusieurs conteneurs ou objets non liés peuvent inscrire jusqu’à cinq demandes de notification.
  • Si trop de clients écoutent les modifications qui se produisent fréquemment, cela aura un impact sur les performances du serveur. En général, les applications doivent limiter leur utilisation de ce contrôle pour des raisons de performances sur le serveur. Si vous n’avez pas besoin de connaître les modifications immédiatement, il peut être préférable d’interroger régulièrement les modifications au lieu d’utiliser la notification de modification.

Les techniques de recherche DirSync et USNChanged sont conçues pour les applications qui maintiennent la cohérence entre les données sur le serveur Active Directory et les données correspondantes dans un autre stockage. Ces techniques sont utilisées par les applications qui interrogent régulièrement les modifications. La technique DirSync est basée sur un contrôle de serveur LDAP que vous pouvez utiliser via les API ADSI ou LDAP. Les inconvénients du contrôle DirSync sont qu’il ne peut être utilisé que par un compte hautement privilégié, tel qu’un administrateur de domaine. Voici une liste des limitations du contrôle DirSync :

  • Le contrôle DirSync ne peut être utilisé que par un compte hautement privilégié, tel qu’un administrateur de domaine.
  • Le contrôle DirSync ne peut surveiller qu’un contexte de nommage entier. Vous ne pouvez pas limiter l’étendue d’une recherche DirSync pour surveiller uniquement une sous-arborescence, un conteneur ou un objet spécifique dans un contexte de nommage.

La technique USNChanged n’a pas ces limitations, bien qu’elle soit un peu plus compliquée à utiliser que DirSync.