Das „Wer mit wem“ in der Active Directory-(intra-site) Replikation

Die Active Directory-Replikation ist für viele Administratoren ein Buch mit sieben Siegeln. Gerade wenn mehrere Standorte und mehrere Domänen in die Replikation einer Gesamtstruktur verwickelt sind, kann man schnell einmal den Überblick verlieren. Im Folgenden werden wir anhand von ein paar einfachen Diagrammen sehen, wie der Knowledge Consistency Checker (KCC)-Dienst von Active Directory seine Replikationstopologie(n) aufbaut und wie Daten letztlich verteilt werden.

Als generelle Grundsätze lässt sich aber jetzt schon einmal festhalten:

• Jeder Namenskontext (NC) benötigt eine seperate „Replikationskette“.
•  Schema- und Konfigurationspartition werden stets zusammen repliziert.
• Alle NCs können bidirektional repliziert werden (Ausnahme: GC).

Wir werden in diesem Artikel in einem kleinen Rahmen beginnen und  nur einen einzigen Standort für unsere Replikation verwenden.

Das erste Beispiel zeigt den Einzelstandort mit drei Domänencontrollern aus einer Domäne contoso.com. Die Domänencontroller replizieren einen gemeinsamen Domänen-Namenskontext (contoso.com) sowie die unternehmensweiten Namenskontexte des Schemas und der Konfiguration:

Szenario: 1 Standort mit einer Domäne

In diesem Szenario haben wir einen Replikationsring aus drei Domänencontrollern. Da alle Domänencontroller, die an der Replikation beteiligt sind, dieselben Namenskontexte besitzen und diese auch replizieren wollen, muss der KCC nur eine Topologie erstellen. Mit den Verbindungen zwischen den Domänencontrollern werden alle drei NCs repliziert.

Anders sieht es aus, wenn eine zweite Domäne für den gleichen Forest in den Standort eingefügt wird:

Szenario: 1 Standort mit 2 Domänen

Aus einer einzigen Schleife mit drei Domänencontrollern sind nun drei verschiedene Replikationskontexte entstanden. Die grünen, durchgezogenen Pfeile beschreiben die Replikation der Domäne contoso.com, die wir aus dem ersten Beispiel kennengelernt haben. Der rote, durchgezogene Pfeil beschreibt die Replikation der Domänenpartition fabrikam.com, dem Domänen-NC der roten Domänencontroller. Die gepunkt- und gestrichelte Linie ist Replikation des Schemas und der Konfiguration, die sich beide Domänen teilen, da sie in der selben Gesamtstruktur liegen.

Nun fehlt uns allerdings noch ein wichtiger Bestandteil eines Verzeichnisses mit mehreren Domänen in einem gemeinsamen Forest: der Globale Katalog. Globale Kataloge halten, neben ihren eigenen Domänen-NCs, read-only Kopien alle weiteren Domänen-NCs aus der Gesamtstruktur. Um an diese fremden NCs zu kommen, wird eine eigene, weitere Replikationskette erstellt. Wir machen die beiden mit (GC) markierten Domänencontroller, jeweils einen DC aus den Domänen contoso.com und fabrikam.com, zu Globalen Katalogen:

2 Domänen in einem Standort mit den Verbindungen für die GC-Replikation

Allmählich scheint das Beispiel wild auszusehen – doch wir lassen uns davon nicht abschrecken: wie gehabt, kennzeichnen die durchgezogenen Pfeile die Replikation von Domänen-NCs. Die gestrichelt und gepunkteten Pfeile markieren die Replikation des Schemas und der Konfiguration. Neu hinzugekommen sind die Globalen Kataloge. Da Globale Kataloge nur „Read-Only“ Kopien fremder Domänen-NCs erhalten, wird die Replikation der nur-lese NCs mit einem einseitigen, gestrichelten Pfeil dargestellt. Einseitig deshalb, weil Globale Kataloge keine Änderungen für nur-lese NCs entgegennehmen und die fremden NCs schon gar nicht aktualisieren. Abhängig davon, für welche Verbindungen sich der KCC entscheidet, kann es passieren, dass die beiden GCs untereinander nur-lese-NCs austauschen (wie im Bild gezeigt). Globale Kataloge können ihre fremden Domänen-NCs entweder von anderen GCs erhalten oder Domänencontroller der jeweiligen, fremden Domäne kontaktieren.

Um das „wer mit wem“ noch auf die Spitze zu treiben und ehrgeizigen Lesern ein noch komplexeres Beispiel zu bieten, hier die Einführung einer dritten Domäne in blauer Markierung, tailspintoys.com:

Der Standort mit 3 Domänen und Globalen Katalogen

GC rot und blau tauschen mehrere NCs miteinander aus. Da beide eine read-only Kopie der grünen Domänenpartition haben, können sie den grünen NC in beide Richtungen replizieren. Sie nehmen für diesen NC zwar keine Änderungen entgegen, bekommen aber Änderungen von grünen DCs mitgeteilt. Abhängig davon, wer eine Änderung zuerst erhalten hat, kann der Partner-GC davon unterrichtet werden. Natürlich tauschen die beiden GCs auch die eigenen Domänen-NCs sowie das Schema und die Konfiguration aus.

Das hier vorgestellte Replikationsschema ist nur ein Beispiel. Wenn der KCC sich dafür entscheidet, den blauen und grünen GC miteinander replizieren zu lassen, können ähnlichen Verbindungen wie zwischen GC blau und GC rot kreiert werden und so ein Replikationsring aus den drei GCs entstehen.

Nähere Informationen zum KCC und zur Replikation:

http://www.faq-o-matic.net/2006/04/26/active-directory-replikation/