Impact sur les applications Directory-Enabled

  • Article

Asymétrie de version

L’asymétrie de version se produit lorsque les applications lisent les mêmes objets à partir de réplicas différents avant qu’une modification n’ait été répliquée. Les applications lisant l’réplica distante 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 du 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, etc.) et en s’y liant.

Supposons qu’un service RPC S₁ publie le point de terminaison Es₁ et se déplace ensuite vers un autre ordinateur. Le point de terminaison d’origine Es₁ est remplacé par Es2, ce qui reflète l’adresse du nouvel ordinateur. Les clients lisant 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 à un autre est rare; par conséquent, cette interruption/retard devrait rarement être rencontrée, surtout si le déplacement du service est bien planifié.

Mises à jour partielles

En général, une mise à jour partielle se produit lorsqu’une application lit un ensemble de données tandis 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îtré. Il existe de nombreuses façons de procéder. Vous pouvez avoir plusieurs applications qui écrivent simultanément dans le même jeu de données. Si vous le regardez de cette façon, le service de réplication d’annuaire 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 pendant laquelle une mise à jour partielle peut affecter votre application est relativement petite. Cela devrait rarement, voire jamais, être un problème pour les applications qui ne dépendent pas de la synchronisation de plusieurs objets. Si votre application est fortement dépendante de la synchronisation d’un ensemble d’objets associé, vous devez prendre en compte les effets d’une mise à jour partielle dans la conception de votre application.

En termes de réplication d’annuaire, une mise à jour partielle se produit lorsque les applications lisent le même ensemble d’objets à partir de réplicas différents pendant que la réplication est en cours. Les applications à distance réplica 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 modifiés associés ont été reçus, mais avant tous ont été reçus. Le temps entre les mises à jour à la source réplica affecte directement la taille de cette fenêtre : les mises à jour qui se produisent de près dans le temps sont répliquées à 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 des 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 dans 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, le cas échéant, quel 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, ce qui entraîne un refus incorrect ou l’octroi du service à l’utilisateur, l’incapacité de traiter la stratégie en raison d’une incohérence interne, etc.
  • 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 pas les objets de profil.
  • 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 seuls certains objets de profil l’ont fait.

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 rapproche la collision ; en raison du rapprochement, un utilisateur ou une application peut « voir » une valeur autre que celle qu’il a écrite.

Les informations d’adresse utilisateur sont un exemple simple : un utilisateur modifie une adresse postale à réplica R1 et un administrateur modifie la même adresse postale 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 de « gagner » par rapport à d’autres valeurs dans le processus de résolution de collision, la valeur continue de se propager. Au final, 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 des collisions 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 l’allocation de bande passante réseau stocke les données de bande passante réseau pour un segment réseau donné dans le répertoire dans un objet O1. L’objet contient la bande passante disponible en bits par seconde et la bande passante maximale qu’un utilisateur 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 l’utilisateur à 9 600 bits par seconde.
  • Un administrateur à réplica R₁ remplace les valeurs par 64 000 et 19 200 respectivement.
  • Un administrateur à réplica R₁ modifie les valeurs respectivement à 10 millions et 1 million 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 possibilité faible, mais réelle, que l’objet se retrouve avec une bande passante maximale de 64 000 et un maximum de 1 million d’utilisateurs, si l’application effectue les mises à jour en tant qu’opérations d’écriture distinctes. L’application doit toujours mettre à jour les deux propriétés en une seule opération.