Der Generator für die standortübergreifende Replikationstopologie (Inter-Site Topology Generator, kurz ISTG), der, unabhängig von der Anzahl an Domänen und Verzeichnispartitionen, nur einmal pro AD-Standort existiert, ist eine Komponente des Knowledge Consistency Checker, kurz KCC. Der ISTG ist für die Berechnung der standortübergreifenden Replikationstopologie und für das Erstellen von eingehenden Replikationsverbindungen auf Bridgeheadserver (BHS) zuständig. Der ISTG ist in jedem AD-Standort auch dafür verantwortlich, automatisch einen BHS für jede Verzeichnispartition sowie für jedes Replikationstransportprotokoll an einem AD-Standort zu ermitteln. Der DC, der die Rolle des ISTG innehat, muss nicht unbedingt auch ein BHS sein!
Der BHS dient im Hinblick auf die AD-Replikation mit BHS aus anderen AD-Standorten als Brückenkopf und somit als Anlaufstelle, über den Replizierungsinformationen mit anderen AD-Standorten ausgetauscht werden. Der BHS ist der Einzige, der für die AD-Standort zu -Standort Replikation zuständig ist. Das bedeutet, über den BHS und nur über ihn, läuft die AD-Replikation zwischen den AD-Standorten (Inter-Site) ab! Dazu sammeln die BHS alle getätigten AD-Änderungen die auf allen DCs eines AD-Standorts stattgefunden haben, um diese dann zu anderen BHS aus anderen AD-Standorten zu replizieren. Deshalb erhält ein BHS an einem AD-Standort bevorzugt als erster die Replikationsdaten.
Der BHS ist dabei ausschließlich für die Verzeichnispartitionen autorisierend und repliziert auch nur die, die der BHS selbst in seiner Verzeichnisdatenbank (NTDS.dit) hält (einschließlich der Verzeichnispartitionen für den globalen Katalog). Jede Verzeichnispartition, die ein BHS eines AD-Standorts nicht innehat, benötigt einen weiteren BHS, der die entsprechende Verzeichnispartition in seiner Verzeichnisdatenbank gespeichert hat. Unter anderem können deshalb an einem AD-Standort mehrere BHS existieren. Ein BHS kann mehrere Verzeichnispartitionen über dasselbe Replikationstransportprotokoll oder auch über beide Replikationstransportprotokolle verwalten. Die AD-Replikation findet aber standortintern und standortübergreifend standardmäßig über das RPC über IP Protokoll statt. Die AD-Replikation könnte jedoch auch mit dem SMTP-Protokoll durchgeführt werden, allerdings ist das nur eingeschränkt möglich. Denn die Domänenpartition kann by Design nicht über das SMTP-Protokoll repliziert werden und es ist ein höherer Aufwand notwendig, um das entsprechend zu konfigurieren (eine Zertifizierungsstelle muss vorhanden sein).
Des Weiteren ist der ISTG für das Erstellen von eingehenden Verbindungsobjekten zwischen den BHS zuständig. Da die standortübergreifende AD-Replikation ausschließlich zwischen den BHS konfiguriert wird, werden im Gegensatz zu der standortinternen (Intra-Site) AD-Replikation, keine redundanten Verbindungsobjekte erstellt. Es werden lediglich weitere Verbindungsobjekte mit BHS in mehreren AD-Standorten erstellt, wenn es in der Standortverknüpfung (Site-Link) so konfiguriert wurde.
Einen Bridgeheadserver konfigurieren
Es gibt seit Windows 2000 mehrere Möglichkeiten einen DC als BHS für das IP- und SMTP-Protokoll zu bestimmen. Diese wären:
- Die automatische Auswahl des BHS wird dem ISTG überlassen. Standardmäßig bestimmt der ISTG eigenständig den DC, der als BHS in einem AD-Standort tätig sein soll. Es ist kein manuelles Eingreifen erforderlich. Fällt der aktuelle BHS eines AD-Standorts aus, wählt beim nächsten KCC-Lauf (standardmäßig nach maximal 15 Minuten) der ISTG automatisch und eigenständig, ohne das Zutun des Administrators, einen anderen DC am gleichen AD-Standort als BHS aus. Dabei wird der DC, der die niedrigste objectGUID am AD-Standort hat, zum BHS ausgewählt.
- Der Administrator kann aber auch manuell einen DC als bevorzugten BHS festlegen. Das kann beispielsweise dann von Interesse sein, wenn zwischen den AD-Standorten eine Firewall steht und nur gezielt einem bestimmten DC die standortübergreifende AD-Replikation erlaubt werden soll. Ein weiterer Anwendungsfall wäre zum Beispiel, wenn die meisten DCs an einem AD-Standort auf veralteter Hardware laufen und nur ein bestimmter DC, der auf aktueller Hardware läuft, soll als BHS bestimmt werden. Denn der BHS muss mehr Replikationsverkehr verarbeiten (insbesondere in größeren AD Umgebungen), als alle anderen DCs am selben AD-Standort.
Wird manuell ein DC an einem AD-Standort explizit als BHS für ein oder beide Replikationstransportprotokolle konfiguriert, bedeutet das bei einem Ausfall dieses BHS, dass der Administrator manuell einen anderen DC zum BHS deklarieren muss, damit die AD-Replikation weiterhin durchgeführt werden kann. Denn nur wenn ein vom ISTG bestimmter BHS ausfällt, wird automatisch ein anderer DC als BHS bestimmt. Deshalb sollte man wenn möglich, entweder keinen BHS manuell bestimmen und dem ISTG die automatische Auswahl des BHS überlassen oder wenn man schon manuell die BHS bestimmen möchte, sollten idealerweise mehrere (mindestens immer zwei) DCs als BHS bestimmt werden.
In einer Gesamtstruktur mit mehreren Domänen sollte stets der globale Katalog (GC) an einem AD-Standort der bevorzugte BHS sein. Andernfalls wird das mit der FehlerID 1567 im Eventlog protokolliert. Wenn in einem Multi-Domain Forest an einem AD-Standort ein GC existiert, und sich nicht zusätzlich an demselben AD-Standort mindestens ein DC aus allen anderen AD-Domänen existiert, muss der GC zwingend ein BHS sein.
Es können vom Administrator mehrere DCs am gleichen AD-Standort als bevorzugte BHS bestimmt werden. Jedoch wählt der ISTG je nach Umgebung, nur aus den manuell bestimmten BHS einen oder mehrere BHS pro AD Standort aus. Fällt ein BHS aus, wählt der ISTG wieder automatisch von den anderen manuell bestimmten DCs einen BHS aus.
Wenn zwischen zwei DCs, die sich an verschiedenen AD-Standorten befinden, manuell ein Verbindungsobjekt erstellt wird, werden diese beiden DCs ebenfalls zu BHS.
Möchte man einen DC oder mehrere DCs als bevorzugten BHS konfigurieren, so kann man das in der MMC Active Directory-Standorte und -Dienste durchführen. Dazu wählt man aus einem AD-Standort den entsprechenden DC aus und wählt im Kontextmenü zuerst die Eigenschaften aus. Danach wählt man im Reiter Allgemein aus dem Feld Transporte für die standortübergreifende Datenübermittlung das entsprechende Replikationstransportprotokoll, entweder IP oder SMTP aus und fügt es in das Feld Server ist ein bevorzugter Bridgeheadserver für folgende Transporte hinzu. Damit wird der DC zum manuell bestimmten bevorzugten BHS.
Ist ein vom ISTG bestimmter BHS ausgefallen und möchte man bis zum nächsten KCC-Lauf nicht warten (max. 15 Minuten), kann man in der Kommandozeile mit Repadmin /KCC die Replikationstopologie manuell neu berechnen lassen und somit den ISTG dazu zwingen, einen neuen BHS zu bestimmen. Die Replikationstopologie kann man auch in der grafischen Oberfläche, in der MMC Active Directory-Standorte und –Dienste neu berechnen und somit einen neuen BHS vom ISTG bestimmen lassen. Dazu muss man mit einem Rechtsklick auf das NTDS Settings Objekt eines bestehenden DCs, im Kontextmenü unter Alle Aufgaben die Option Replikationstopologie überprüfen auswählen. Beide Vorgehensweisen fordern den KCC dazu auf, die Replikationstopologie zu überprüfen und bei etwaigen Veränderungen, diese anzupassen. Fällt dem ISTG bei einem KCC-Lauf auf, dass der BHS eines AD-Standorts nicht mehr existiert, bestimmt er einen anderen DC (falls ein weiterer DC an diesem AD-Standort existiert) an diesem AD-Standort zu einem BHS.
In der AD-PowerShell lässt sich manuell ein DC ebenfalls als einen bevorzugten BHS konfigurieren.
Der Befehl für das Bestimmen eines BHS für das IP-Protokoll lautet:
Set-ADObject -Identity „CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne“ -Add @{ bridgeheadTransportList=”CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Root-Domäne“ }
Wird ein DC manuell, für ein oder beide Replikationstransportprotokolle zu einem bevorzugten BHS bestimmt, passiert im Hintergrund folgendes:
- Im mehrwertigen Forward-Link Attribut bridgeheadTransportList, das sich in den Eigenschaften des DC-Objekts befindet, wird der Distinguished Name (DN) des entsprechenden Replikationstransportprotokolls eingetragen. Also z.B. CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuation,DC=Root-Domäne.
- Auf der gegenüberliegenden Seite wird im mehrwertigen Back-Link Attribut bridgeheadServerListBL, das sich in den Eigenschaften des Replikationstransportprotokoll-Containers (in der MMC dssite.msc unter Sites – Inter-Site Transports – IP/SMTP) befindet, der DN des bestimmten BHS eingetragen. Beispielsweise: CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Wird ein BHS vom ISTG bestimmt, enthalten die Attribute keinen Wert!
Bei jedem Durchlauf des ISTG überprüft dieser das Attribut bridgeheadTransportList. Ist in dem Attribut der DN eines Replikationstransportprotokolls eingetragen, wird dieser DC vom KCC als der bevorzugte BHS für das eingetragene Replikationstransportprotokoll verwendet.
Im Übrigen kann man sich alle aktuellen BHS in der Kommandozeile, mit dem Schweizer Messer Werkzeug für die AD-Replikation REPADMIN folgendermaßen anzeigen lassen: Repadmin /bridgeheads
Die Auswahl und die Lastverteilung des BHS
Windows 2000
Unter Windows 2000 kann es nur einen einzigen BHS pro AD-Standort geben! Die Auswahl des BHS ändert sich unter Windows 2000 nur, wenn der bisher ausgewählte BHS nicht mehr verfügbar ist. Das Problem mit dem BHS unter Windows 2000 ist, dass der BHS in der Zentrale (Hub) schnell zu einem Engpass werden kann, wenn die AD Standorttopologie nach der Hub-and-Spoke Topologie aufgebaut wurde und viele Außenstellen (Spokes) existieren. Denn alle BHS aus allen Außenstellen führen die standortübergreifende AD-Replikation stets nur mit dem einen BHS in der Zentrale durch. Kommen weitere DCs in der Zentrale hinzu, werden diese von den BHS in den Außenstellen nicht berücksichtigt! Es existiert also weder eine Skalierung, noch eine Lastverteilung!
Windows Server 2003
Ab Windows Server 2003 wurde das Problem mit dem einzelnen BHS pro AD-Standort behoben. Von nun an kann jeder DC an einem AD-Standort zeitgleich ein BHS sein. Es können also mehrere BHS pro AD-Standort zeitgleich existieren. Wurden mehrere DCs an einem AD-Standort manuell als BHS bestimmt, beschränken sich die möglichen BHS eines AD-Standorts auf diese DCs. Somit wurde eigentlich in Bezug auf die Skalierbarkeit sowie Lastverteilung Rechnung getragen. Man muss lediglich beim manuellen bestimmen von BHS Vorsicht walten lassen. Denn BHS werden pro Verzeichnispartition und pro Replikationstransportprotokoll bestimmt. Wird beispielsweise an einem AD-Standort kein BHS für die Schemapartition bestimmt, wird diese Verzeichnispartition (auf Englisch Naming Context, kurz NC) zu diesem AD-Standort niemals repliziert.
Diese neue Funktion der Lastverteilung hat jedoch einen gravierenden Nachteil. Denn haben sich in einer Hub-and-Spoke Topologie die BHS in den Außenstellen die Replikationstopologie mit einem BHS aus der Zentrale aufgebaut, überprüfen die BHS in den Außenstellen die Replikationstopologie nicht erneut, wenn weitere BHS Kandidaten in Form von zusätzlichen DCs in der Zentrale installiert werden. Sogar wenn mehrere DCs in der Zentrale manuell als bevorzugte BHS bestimmt werden, führen die BHS in den Außenstellen die AD-Replikation weiterhin mit dem bereits ausgewählten BHS in der Zentrale durch. Die neu hinzugefügten DCs in der Zentrale werden von den BHS in den Außenstellen einfach ignoriert.
Microsoft hat dieses Fehlverhalten erkannt. Leider erst, als Windows Server 2003 RTM wurde. Somit blieb keine Zeit mehr das im Quellcode des Serverbetriebssystems zu überarbeiten. Stattdessen wurde ein Tool entwickelt, um dieses Verhalten zu korrigieren. Das Tool heist Active Directory Load Balancer, kurz adlb.exe, und befindet sich im “Windows Server 2003 Active Directory Branch Office Guide”. Führt man das Tool jedes Mal aus, nachdem ein neuer DC in der Zentrale (Hub) hinzugefügt wurde, wird unter Berücksichtigung der neuen DCs die Replikationstopologie neu berechnet und möglicherweise weitere BHS an einem AD-Standort bestimmt. Bedauerlich dabei ist, dass man das Tool jedes Mal manuell ausführen muss, nach dem ein neuer DC hinzugefügt wurde.
Das Tool selbst und weitere Informationen dazu gibt es hier:
Windows Server 2003 Active Directory Branch Office Guide
Windows Server 2008
Unter Windows Server 2008 wurde die automatische Auswahl eines BHS verbessert, leider wieder einmal mehr halbherzig. Denn unter Windows Server 2008 nutzen lediglich Read-Only Domänencontroller (RODCs) die automatische Auswahl eines BHS. Beschreibbare DCs (RWDC) dagegen verhalten sich weiterhin wie unter Windows Server 2003, was die automatische Auswahl eines BHS anbetrifft. Das bedeutet also, dass ein RODC aus einer Außenstelle die neu hinzugefügten DCs in der Zentrale als BHS berücksichtigt, ein beschreibbarer Windows Server 2008 DC jedoch nicht. Für RODCs besteht nicht die Notwendigkeit, das zusätzliche Werkzeug adlb.exe auszuführen, denn die automatische BHS Lastverteilung ist bei RODCs standardmäßig aktiviert. Doch auf beschreibbaren Windows Server 2008 DCs muss in Bezug auf die BHS Lastverteilung, weiterhin das Tool adlb.exe ausgeführt werden, damit neue DCs als mögliche BHS berücksichtigt werden.
Möchte man die automatische Lastverteilung auf RODCs deaktivieren, zum Beispiel weil sich eine Firewall zwischen dem RODC und einem beschreibbaren DC befindet und der RODC stets die AD Aktualisierungen immer nur von einem bestimmten beschreibbaren DC erhalten soll, so kann man das mit diesem Registryeintrag, der standardmäßig nicht existiert:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Random BH Loadbalancing Allowed
1 = Aktiviert (standardmäßig)
0 = Deaktiviert
Review Bridgehead Server Load-Balancing Improvements with Windows Server 2008 RODCs
Die verbesserte Lastverteilung der BHS unter Windows Server 2008 R2
Ab Windows Server 2008 R2 wurde die BHS Lastverteilung zusätzlich zu RODCs, für beschreibbare DCs eingeführt. RODCs und vor allem beschreibbare DCs verteilen nun Replikationsverbindungen und die standortübergreifende Replikationslast gleichmäßig zwischen allen BHS, die an einem AD-Standort zur Verfügung stehen. Kommen zum Beispiel in einer Hub-and-Spoke Topologie weitere DCs in der Zentrale (Hub) und somit potentiell neue BHS dazu, berechnen Read-Only- und beschreibbare DCs aus den Außenstellen die Replikationstopologie neu. Die Replikationslast und Replikationsverbindungen werden dann stets gleichmäßig über alle DCs in der Zentrale verteilt.
Insbesondere in größeren AD Umgebungen profitiert man von dieser Verbesserung und deshalb sollten bei einer Domänenaktualisierung auf mindestens Windows Server 2008 R2, stets die DCs in der Zentrale als erste aktualisiert werden, um von der BHS Lastverteilung zu profitieren.
Es gibt aber bei dem verbesserten Auswahlverfahren eines BHS unter Windows Server 2008 R2 folgende Einschränkungen:
- Die BHS Lastverteilung funktioniert erst, wenn sich DCs mindestens in zwei AD-Standorten (logischerweise) befinden.
- Existiert eine „Full-Mesh“ AD-Standorttopologie (jeder AD-Standort repliziert mit jedem anderen), mit denselben Kosten in allen Standortverknüpfungen, kann keine Lastverteilung durchgeführt werden. Die BHS Lastverteilung findet immer zwischen zwei AD-Standorten statt.
- Wenn der KCC zum gleichen Zeitpunkt simultan auf allen BHS in den Außenstellen läuft, wird in allen eingehenden Replikationsverbindungen derselbe BHS aus der Zentrale verwendet. Erst wenn der KCC auf den BHS zwischen den Außenstellen, mindestens eine Sekunde versetzt läuft, findet die BHS Lastverteilung statt!
Weitere Informationen:
AD-PowerShell Befehle
Die Active Directory Verbindungsobjekte
Bridgehead Server Selection
How Active Directory Replication Topology Works
Use ADLB from the Windows Server 2003 Branch Office Guide to Rebalance Connections Between Writeable Domain Controllers in the Hub
The Role of the Inter-Site Topology Generator in Active Directory Replication
Description of Bridgehead Servers in Windows 2000
Comments are closed, but trackbacks and pingbacks are open.