Impact sur les applications Directory-Enabled

Asymétrie de version

L’asymétrie de version se produit lorsque les applications lisent les mêmes objets à partir de différents réplicas avant qu’une modification ait été répliquée. Les applications qui lisent le réplica distant reconnaissent l’objet inchangé. L’asymétrie de version est un problème lorsqu’une application ou un ensemble d’applications donnés utilisent les données dans le répertoire pour interagir.

Par exemple, un service RPC peut publier ses points de terminaison dans le répertoire à l’aide d’API RPC standard (telles que RpcNsBindingExport). Les clients se connectent au service en recherchant le point de terminaison souhaité dans le répertoire ( RpcNsBindingLookupBegin, RpcNsBindingLookupNext, et ainsi de suite) et en le liant.

Supposons qu’un service RPC S₁ publie des points de terminaison Es₁ et se déplace ensuite vers un autre ordinateur. Le point de terminaison d’origine Es₁ est modifié en Es2, reflétant l’adresse du nouvel ordinateur. Les clients qui lisent des réplicas distants du service d’annuaire ne peuvent pas se connecter au service tant que le point de terminaison mis à jour n’est pas répliqué. Toutefois, le déplacement d’un service d’un ordinateur vers un autre est une occurrence rare; par conséquent, cette interruption/retard doit rarement être rencontrée, en particulier si le déplacement du service est bien planifié.

Mises à jour partielles

En général, la mise à jour partielle se produit lorsqu’une application lit un jeu de données alors qu’une autre application écrit dans ce même jeu de données. Il s’agit d’une situation qui peut se produire avec n’importe quelle application dans un système multimaître. Il existe de nombreuses façons de se produire. Vous pouvez avoir plusieurs applications écrivant dans le même jeu de données à la fois. Si vous examinez cette façon, le service de réplication d’annuaires n’est qu’une autre application qui peut potentiellement écrire dans le même jeu de données qu’une autre application peut lire. Il peut s’agir d’un problème potentiel pour une application. Toutefois, la fenêtre de temps dans laquelle une mise à jour partielle peut affecter votre application est relativement petite. Cela doit rarement s’avérer un problème pour les applications qui ne dépendent pas de la synchronisation de plusieurs objets. Si votre application dépend fortement de la synchronisation d’un ensemble d’objets associé, vous devez prendre en compte les effets d’une mise à jour partielle dans votre conception d’application.

En termes de réplication d’annuaire, la mise à jour partielle se produit lorsque les applications lisent le même ensemble d’objets à partir de différents réplicas pendant que la réplication est en cours. Les applications sur le réplica distant voient certaines modifications, mais pas toutes.

Notes

La fenêtre dans laquelle la mise à jour partielle peut affecter une application est petite : l’application doit commencer à lire des objets pendant que la réplication entrante est en cours, après qu’un ou plusieurs des objets associés ont été reçus, mais avant que tous n’aient été reçus. Le temps entre les mises à jour au niveau du réplica source affecte directement la taille de cette fenêtre : les mises à jour qui se produisent ensemble sont répliquées ensemble en temps. La mise à jour partielle peut être un problème lorsqu’une application utilise un ensemble d’objets associé.

 

Par exemple, un service d’accès à distance peut utiliser l’annuaire pour stocker les données de stratégie et de profil. Les données de stratégie sont stockées dans un ensemble d’objets et le profil d’un autre ensemble. Lorsqu’un utilisateur se connecte au service d’accès à distance, le service d’accès à distance lit la stratégie pour déterminer si l’utilisateur est autorisé à se connecter, et si tel profil à appliquer à la session utilisateur. La mise à jour partielle peut affecter le service d’accès à distance de plusieurs façons :

  • Si la stratégie est complexe et se compose de plusieurs objets, le service d’accès à distance peut lire une stratégie partiellement mise à jour entraînant un déni incorrect ou l’octroi du service à l’utilisateur, l’incapacité à traiter la stratégie en raison d’incohérences internes, et ainsi de suite.
  • Si la stratégie et les profils ont été mis à jour, le service peut traiter correctement la stratégie, mais appliquer un profil obsolète, car les objets de stratégie ont été répliqués, mais les objets de profil n’ont pas.
  • Si le profil est complexe et se compose de plusieurs objets, le service peut traiter correctement la stratégie, mais appliquer un profil partiellement mis à jour, car les objets de stratégie ont été répliqués, mais seulement certains des objets de profil ont effectué cette opération.

Collisions

Les collisions se produisent lorsque les mêmes attributs de deux réplicas ou plus d’un objet donné sont modifiés pendant le même intervalle de réplication. Le processus de réplication réconcilie la collision ; en raison de la réconciliation d’un utilisateur ou d’une application peut « voir » une valeur autre que celle qu’ils ont écrite.

Un exemple simple est les informations d’adresse utilisateur : un utilisateur modifie une adresse de publipostage au réplica R1 et un administrateur modifie la même adresse de publipostage au réplica R2. Une valeur écrite se propage jusqu’à ce qu’une autre valeur soit sélectionnée sur cette valeur par le mécanisme de rapprochement de collision. Tant qu’une valeur continue à « gagner » contre d’autres valeurs dans le processus de résolution de collision, la valeur continue à se propager. En fin de compte, cette valeur « gagnante » est propagée à R1,R2 et tous les autres réplicas si aucune autre modification n’est apportée.

La résolution de collision est un problème pour les applications qui font des hypothèses sur la cohérence interne des objets ou des ensembles d’objets. Par exemple, un service de gestion de la bande passante réseau stocke les données de bande passante réseau pour un segment réseau donné dans le répertoire d’un objet O1. L’objet contient la bande passante disponible en bits par seconde et la bande passante maximale que n’importe quel utilisateur unique peut réserver. Le service s’attend à ce que la bande passante réservable par l’utilisateur soit toujours inférieure ou égale à la bande passante disponible.

Regardez la séquence d’événements suivante :

  • L’objet dans l’état initial entièrement répliqué donne la bande passante disponible à 56 kilobits par seconde, et la bande passante réservée par utilisateur est de 9 600 bits par seconde.
  • Un administrateur au réplica R₁ modifie les valeurs en 64 000 et 19 200 respectivement.
  • Un administrateur au réplica R cumulative modifie les valeurs à 10 millions et 1 million respectivement avant l’arrivée de la mise à jour de R₁.

En supposant que les attributs en question ont des numéros de version égaux lorsque les mises à jour se produisent, il existe une petite, mais réelle, possibilité que l’objet se termine par une bande passante maximale de 64k et qu’un utilisateur réservable maximum de 1 million , si l’application effectue les mises à jour comme opérations d’écriture distinctes. L’application doit toujours mettre à jour les deux propriétés dans une seule opération.