Auswirkungen auf Directory-Enabled Anwendungen

Versionsschiefe

Versionsschiefe tritt auf, wenn Anwendungen dieselben Objekte aus verschiedenen Replikaten lesen, bevor eine Änderung repliziert wurde. Anwendungen, die das Remotereplikat lesen, erkennen das unveränderte Objekt. Versionsschiefe ist ein Problem, wenn eine bestimmte Anwendung oder eine bestimmte Gruppe von Anwendungen die Daten im Verzeichnis für die Zusammenarbeit verwendet.

Beispielsweise kann ein RPC-Dienst seine Endpunkte im Verzeichnis mithilfe von RPC-Standard-APIs (z. B. RpcNsBindingExport) veröffentlichen. Clients stellen eine Verbindung mit dem Dienst her, indem sie den gewünschten Endpunkt im Verzeichnis ( RpcNsBindingLookupBegin, RpcNsBindingLookupNext usw.) suchen und an ihn binden.

Angenommen, ein RPC-Dienst S₁ veröffentlicht den Endpunkt Es₁ und wechselt anschließend auf einen anderen Computer. Der ursprüngliche Endpunkt Es₁ wird in E_{s2 geändert,} was die Adresse des neuen Computers widerspiegelt. Clients, die Remotereplikate des Verzeichnisdiensts lesen, können erst dann eine Verbindung mit dem Dienst herstellen, wenn der aktualisierte Endpunkt repliziert wurde. Das Verschieben eines Diensts von einem Computer auf einen anderen ist jedoch ein seltenes Ereignis. Daher sollte diese Unterbrechung/Verzögerung selten auftreten, insbesondere wenn die Verlegung des Dienstes gut geplant ist.

Teilupdates

Im Allgemeinen erfolgt eine partielle Aktualisierung, wenn eine Anwendung einen Satz von Daten liest, während eine andere Anwendung in denselben Datensatz schreibt. Dies ist eine Situation, die bei jeder Anwendung in einem Multimastersystem auftreten kann. Es gibt viele Möglichkeiten, wie dies geschehen kann. Sie können mehrere Anwendungen gleichzeitig in dasselbe Dataset schreiben. Wenn Sie dies so betrachten, ist der Verzeichnisreplikationsdienst nur eine weitere Anwendung, die möglicherweise in dasselbe Dataset schreibt, das eine andere Anwendung möglicherweise liest. Dies kann ein potenzielles Problem für eine Anwendung sein. Das Zeitfenster, in dem sich ein partielles Update auf Ihre Anwendung auswirken kann, ist jedoch relativ klein. Dies sollte selten oder überhaupt ein Problem für Anwendungen sein, die nicht von der Synchronisierung mehrerer Objekte abhängig sind. Wenn Ihre Anwendung in hohem Maße von der Synchronisierung einer zugehörigen Gruppe von Objekten abhängig ist, sollten Sie die Auswirkungen einer partiellen Aktualisierung im Anwendungsentwurf berücksichtigen.

In Bezug auf die Verzeichnisreplikation erfolgt eine partielle Aktualisierung, wenn Anwendungen denselben Satz von Objekten aus verschiedenen Replikaten lesen, während die Replikation ausgeführt wird. Anwendungen auf dem Remotereplikat sehen einige, aber nicht alle Änderungen.

Hinweis

Das Fenster, in dem sich die partielle Aktualisierung auf eine Anwendung auswirken kann, ist klein: Die Anwendung muss mit dem Lesen von Objekten beginnen, während die eingehende Replikation ausgeführt wird, nachdem eines oder mehrere der zugehörigen geänderten Objekte empfangen wurden, aber bevor alle empfangen wurden. Die Zeit zwischen den Updates auf dem Quellreplikat wirkt sich direkt auf die Größe dieses Fensters aus. Updates, die rechtzeitig nah beieinander auftreten, werden rechtzeitig nahe beieinander repliziert. Eine teilweise Aktualisierung kann ein Problem sein, wenn eine Anwendung einen zugehörigen Satz von Objekten verwendet.

 

Beispielsweise kann ein RAS-Dienst das Verzeichnis verwenden, um Richtlinien- und Profildaten zu speichern. Die Richtliniendaten werden in einem Satz von Objekten und das Profil in einer anderen Gruppe gespeichert. Wenn ein Benutzer eine Verbindung mit dem RAS-Dienst herstellt, liest der RAS-Dienst die Richtlinie, um zu bestimmen, ob der Benutzer eine Verbindung herstellen darf und wenn ja, welches Profil auf die Benutzersitzung angewendet werden soll. Teilaktualisierungen können sich auf verschiedene Arten auf den RAS-Dienst auswirken:

• Wenn die Richtlinie komplex ist und aus mehreren Objekten besteht, liest der RAS-Dienst möglicherweise eine teilweise aktualisierte Richtlinie, was zu einer falschen Ablehnung oder Bereitstellung des Diensts für den Benutzer, zur Unfähigkeit zur Verarbeitung der Richtlinie aufgrund interner Inkonsistenzen usw. führt.
• Wenn sowohl die Richtlinie als auch die Profile aktualisiert wurden, verarbeitet der Dienst die Richtlinie möglicherweise ordnungsgemäß, wendet aber ein veraltetes Profil an, da die Richtlinienobjekte repliziert wurden, die Profilobjekte jedoch nicht.
• Wenn das Profil komplex ist und aus mehreren Objekten besteht, kann der Dienst die Richtlinie ordnungsgemäß verarbeiten, aber ein teilweise aktualisiertes Profil anwenden, da die Richtlinienobjekte repliziert wurden, aber nur einige der Profilobjekte dies getan haben.

Kollisionen

Konflikte treten auf, wenn die gleichen Attribute von zwei oder mehr Replikaten eines bestimmten Objekts während des gleichen Replikationsintervalls geändert werden. Der Replikationsprozess stimmt die Kollision ab; aufgrund der Abstimmung kann ein Benutzer oder eine Anwendung einen anderen Wert als den von ihnen geschriebenen "sehen".

Ein einfaches Beispiel sind Benutzeradresseninformationen: Ein Benutzer ändert eine Postanschrift am Replikat R1, und ein Administrator ändert dieselbe Postadresse im Replikat R2. Ein geschriebener Wert wird weitergegeben, bis ein anderer Wert vom Kollisionsabstimmungsmechanismus über diesen Wert ausgewählt wird. Solange ein Wert weiterhin gegen andere Werte im Konfliktauflösungsprozess "gewinnt", wird der Wert weiterhin weitergegeben. Letztendlich wird dieser "gewinnbringende" Wert an R1, R2 und alle anderen Replikate weitergegeben, wenn keine anderen Änderungen vorgenommen werden.

Die Kollisionsauflösung ist ein Problem für Anwendungen, die Annahmen über die interne Konsistenz von Objekten oder Gruppen von Objekten treffen. Beispielsweise speichert ein Netzwerkbandbreitenzuordnungsdienst Netzwerkbandbreitendaten für ein bestimmtes Netzwerksegment im Verzeichnis in einem O1-Objekt. Das -Objekt enthält die verfügbare Bandbreite in Bit pro Sekunde und die maximale Bandbreite, die ein einzelner Benutzer reservieren kann. Der Dienst erwartet, dass die vom Benutzer reservierte Bandbreite immer kleiner oder gleich der verfügbaren Bandbreite ist.

Gehen Sie dabei vom folgenden Ereignisablauf aus:

• Das Objekt im anfänglichen vollständig replizierten Zustand gibt die verfügbare Bandbreite mit 56 Kbbit pro Sekunde und die vom Benutzer reservierte Bandbreite auf 9.600 Bit pro Sekunde an.
• Ein Administrator im Replikat R₁ ändert die Werte in 64.000 bzw. 19.200.
• Ein Administrator im Replikat R² ändert die Werte in 10 Millionen bzw. 1 Million, bevor das Update von R₁ eintrifft.

Unter der Annahme, dass die betreffenden Attribute beim Auftreten der Updates die gleichen Versionsnummern aufweisen, besteht eine kleine, aber reale Möglichkeit, dass das Objekt eine maximale Bandbreite von 64.000 und eine vom Benutzer reservierte maximale Anzahl von 1 Million aufweist– wenn die Anwendung die Updates als separate Schreibvorgänge ausführt. Die Anwendung sollte immer beide Eigenschaften in einem einzelnen Vorgang aktualisieren.