Zusammenfassung

  • RFC 3384 verlangte von Multi-Master-Replikaten einen gemeinsamen Live-Zustand, ließ aber die bei der Konfliktlösung verdrängte Information nicht einfach verschwinden.
  • Der unterlegene Wert musste gespeichert, der Administrator benachrichtigt und eine mögliche Korrektur offengehalten werden; die Ankunftsreihenfolge durfte den Sieger nicht bestimmen.

Zwei Master nehmen während einer Netztrennung unterschiedliche Änderungen desselben Attributs an. Nach der Wiederverbindung sollen alle Leser wieder dieselbe Antwort sehen. Dafür muss das System einen Live-Wert wählen. Doch die Wahl beantwortet nicht, ob die andere Änderung wertlos war. RFC 3384 setzte genau hier eine Grenze: Konvergenz durfte nicht durch die Vernichtung der Gegenhistorie erkauft werden.

Das Dokument erschien im Oktober 2002 als Informational RFC. Es sammelte grundlegende Anforderungen an interoperable LDAPv3-Verzeichnisreplikation, spezifizierte aber weder ein vollständiges Protokoll noch einen einheitlichen Konfliktalgorithmus. Ebenso wenig belegt es die Implementierung durch ein bestimmtes Produkt. Es beschreibt die Mindestmerkmale einer vertretbaren Lösung, nicht deren spätere Verbreitung.

LDAP regelte bereits den Verkehr zwischen Client und Server. Replikation zwischen Servern eröffnete eine andere Ebene. Sie konnte Daten näher an Leser bringen und Ausfälle abfedern. Gleichzeitig musste sie Topologie, Teilreplikate, Schema, Zugriffskontrolle, Wiederholung und konkurrierende Schreibvorgänge über unsichere Verbindungen hinweg zusammenhalten.

Eine Replikationszone war ein konfigurierbarer Teil des Directory Information Tree. Zonen konnten sich überlappen oder ineinander liegen. Ein Replikat war eine Instanz einer solchen Zone; eine Replikatgruppe umfasste die Server, die sie hielten. Die Replikationsvereinbarung regelte Zone, Zugriff, Berechtigungsnachweise, Vertraulichkeit und Weitergabe. „Synchron“ war deshalb immer eine Aussage über einen benannten Bereich und eine konkrete Vereinbarung.

RFC 3384 betrachtete fünf Konsistenzmodelle. Transaktionale Konsistenz bot die bekannten ACID-Eigenschaften, doch die Komplexität eines verteilten Zwei-Phasen-Commits führte dazu, dass dieser Weg damals nicht weiterverfolgt wurde. Im Mittelpunkt standen Eventual Consistency und Limited-Effort Eventual Consistency. Zeitweilige Abweichung gehörte damit zum Modell, nicht automatisch zur Fehlerklasse.

Beliebigkeit war trotzdem ausgeschlossen. M3 verlangte, dass ein Attribut in allen Replikaten des Eintrags schließlich auf dieselbe Wertemenge konvergiert. MM6 wiederholte dies für Attribute und Einträge im Multi-Master-Fall. Eine Partition durfte Einigkeit verzögern, aber nicht die Pflicht zu einem gemeinsamen Zustand aufheben.

Der Multi-Master-Betrieb erzeugte Konflikte aus seiner Stärke heraus. Mehrere Master konnten Änderungen annehmen, ohne vorher miteinander zu sprechen. Das erhielt lokale Verfügbarkeit, ermöglichte aber zwei gültige Änderungen an denselben Verzeichnisdaten. Beim späteren Abgleich musste eine deterministische Entscheidung fallen.

„Zuletzt angekommen gewinnt“ war dafür keine stabile Grundlage. Replikate können dieselben Änderungen in unterschiedlicher Reihenfolge empfangen. Wählt jedes seine letzte Ankunft, können sie verschiedene Sieger behalten. MM7 verlangte daher, dass Konfliktauflösung zur Sicherung der Konvergenz nicht von geordneter Ankunft abhängt. Zufälliges Netzwerktiming durfte keine dauerhafte Autorität vergeben.

Das RFC entschied sich nicht für eine bestimmte logische Uhr, Zeitstempelregel oder Serverpriorität. Es schrieb eine grundlegendere Eigenschaft fest: Unabhängige Replikate mussten im unterstützten Modell trotz verschiedener Empfangsfolgen zum selben Ergebnis gelangen können. Technische Freiheit blieb bestehen, aber keine Freiheit, Korrektheit auf eine unkontrollierbare Reihenfolge zu stützen.

MM5 fügte die entscheidende zweite Pflicht hinzu. Multi-Master-Replikation sollte keine Information verlieren. Führte die Konfliktauflösung dennoch dazu, dass Verzeichnisinformation aus dem konvergierten Live-Zustand verschwand, musste der Prozess diese Information speichern, den Administrator über Konflikt und Verlust informieren und eine mögliche administrative Korrektur anbieten.

Das bedeutete nicht, beide unvereinbaren Werte als aktuell stehen zu lassen. Dann wäre die Entscheidung nur an jeden Client weitergereicht worden. Die Anforderung trennte vielmehr den einheitlichen Betriebszustand von einer Evidenzebene. Dort blieb erhalten, was die automatische Regel verdrängt hatte, damit ein Mensch die Wahl prüfen und gegebenenfalls ändern konnte.

Damit reicht visuelle Gleichheit nicht als Integritätsbeweis. Zehn identische Replikate zeigen, dass ein gemeinsamer Wert verteilt wurde. Sie zeigen nicht, ob der richtige Wert gewann, ob die Alternative abrufbar ist oder ob eine verantwortliche Person benachrichtigt wurde. Eine grüne Konvergenzanzeige misst den sichtbaren Zustand, nicht die Verantwortbarkeit seines Zustandekommens.

M12 setzte eine Grenze gegen Wiederholung. Eine mehrfach empfangene Aktualisierung durfte kein anderes Ergebnis erzeugen als ihr einmaliger Empfang. Eine Verbindung kann nach Anwendung, aber vor Bestätigung abbrechen. Der Lieferant sendet erneut, weil er den Zustand nicht kennt. Ohne Idempotenz würde Wiederherstellung selbst zur Datenverfälschung.

P6 erhielt die Atomarität von LDAP-Operationen. Teile einer Operation durften durch den Transport nicht getrennt sichtbar werden. Zwei vollständige atomare Operationen konnten dennoch miteinander kollidieren. Atomarität verhindert zerrissene Änderungen; sie wählt nicht zwischen zwei vollständigen Absichten.

Ein Initiierungskonflikt war ein eigenes Problem. Wenn mehrere Master gleichzeitig einen Zyklus mit demselben Replikat starten wollten, verlangte MM4 automatische Auflösung oder Vermeidung. Ein beschäftigter Consumer, Verbindungsverlust und Neuplanung betreffen die Sitzung. Widersprechende Datenwerte betreffen die inhaltliche Entscheidung. Beide brauchen verschiedene Nachweise.

Verwaltbarkeit war Bestandteil der Interoperabilität. AM2 verlangte von jedem Replikat eine Audit-Historie der Server, mit denen es Daten ausgetauscht hatte. AM4 und AM5 sahen Vergleich und Reparatur zweier Replikate ohne neuen Zyklus vor. Ein leeres Replikat sollte durch ein vollständiges Update initialisiert werden können. Abstimmung musste beobachtbar und steuerbar bleiben.

Obwohl allgemeine Ankunftsreihenfolge keinen Sieger bestimmen durfte, blieben kausale Folgen wichtig. AM6 verlangte, die Abfolge zwischen Zugriffskontrollinformation und den von ihr geregelten Daten zu erhalten. Trifft der Datensatz vor seiner Schutzregel ein, kann vorübergehend eine andere Sicherheitsbedeutung entstehen. Zufällige Reihenfolge und explizite Abhängigkeit waren nicht dasselbe.

Schemaabweichungen mussten behandelt und gemeldet werden. Replikation umfasste Schemadefinitionen, Attributnamen und -werte, Zugriffskontroll-, Wissens- und Namensrauminformation. DSA-spezifische Betriebsattribute waren als solche ausgeschlossen. Teilreplikate waren zulässig, aber ihre Zonen, Einträge und Attribute mussten in der Vereinbarung klar abgegrenzt sein.

Bei der Sicherheit blieben Authentisierung, Autorisierung, Integrität und Vertraulichkeit getrennt. Gegenseitige Authentisierung, gegenseitige Autorisierungsprüfung und geschützter Transfer sollten unterstützt werden. Das Dokument verlangte auch anonyme Replikationssitzungen. Es erklärte sie nicht für gleich vertrauenswürdig, sondern machte unterschiedliche Richtlinienzustände darstellbar.

Spätere LDAP-RFCs liefern Chronologie, keinen pauschalen Implementierungsnachweis. RFC 4510, RFC 4511 und RFC 4512 ordneten die technische LDAP-Spezifikation neu. RFC 4533 definierte Inhaltssynchronisation, RFC 5805 später Transaktionen. Daraus folgt nicht, dass sämtliche Multi-Master-Anforderungen von RFC 3384 vollständig umgesetzt wurden.

Das unmittelbar benachbarte RFC 3383 regelte eine andere Kollisionsfläche. Es ordnete Registrierungsverfahren für LDAP-Erweiterungskennungen. RFC 3384 behandelte dagegen legitime Zustandsänderungen, die zeitlich kollidierten. Das eine steuerte den Eintritt von Namen in gemeinsamen Raum; das andere erhielt Beweise über verdrängte Zustände.

Lu Hengs Perspektive einer minimalen Anfangsspezifikation erklärt, warum ein Anforderungstext ohne Einheitsalgorithmus wirksam sein konnte. Er konnte unzulässige Schäden festlegen — Ankunftsautorität, stillen Verlust, fehlenden Einspruch — und spätere lokale Entscheidungen über das Verfahren offenlassen. Offenheit des Mechanismus war keine Offenheit des Schadens.

Die Perspektive der Realitätsebenen trennt angenommene Schreiboperation, transportiertes Update, erkannten Konflikt, sichtbaren Sieger, gespeicherten Verlierer, Administratorwarnung und menschliche Revision. „Konvergiert“ beschreibt nur einen Abschnitt dieser Kette. Wer daraus die Richtigkeit der ganzen Entscheidung ableitet, lässt eine technische Messung unberechtigt für Governance sprechen.

Die bleibende Lehre von RFC 3384 lautet daher, einer zu sauberen Konvergenz zu misstrauen. Ein verteiltes System kann eine einzige Antwort schaffen, indem es die Grundlage ihrer Anfechtung löscht. Die Erhaltung des unterlegenen Werts machte aus stiller Überschreibung eine prüfbare Entscheidung. Replikate durften sich einigen, ohne ihre frühere Uneinigkeit zu verleugnen.

Quellen