Teil 2 - Intra-Site-Replication

Autor: olc, MCSEboard.de

Bei der Intra-Site-Replication bildet der KCC automatisch Connection Objects zwischen jeweils 2 DCs der gleichen Site. Es wird, wie oben kurz erwähnt, für jeden der beiden DCs jeweils ein Inbound Connection Object erstellt. Ein Beispiel für den Schedule eines Intra-Site Connection Objects ist in Abbildung 2 zu sehen.

: Abb. 2

Es ist in Abbildung 2 zu erkennen, daß von Montag bis Sonntag durchgängig die Replikation möglich ist, jedoch nur ein Mal die Stunde.
Administratoren, die sich mit der Intra-Site-Replication schon einmal zu tun hatten, wissen, daß dies nicht so recht stimmen kann: Unter Windows Server 2003 werden „change notifications“ verwendet, sobald Änderungen auf einem Replikationspartner vorgenommen wurden (siehe [2]).

Somit wird, ist der Domänenfunktionsmodus Windows Server 2003, im Normalfall eine Benachrichtigung innerhalb von 15 Sekunden nach einer Änderung versendet, bei dringenden Änderungen (z.B: dem Sperren eines Accounts) sogar sofort. Es kann also nicht nur einmal die Stunde zu einer Replikation kommen.

Was bedeutet also der Schedule auf dem Connection Object?

Es kann durchaus vorkommen, daß eine change notification bei der Übertragung „verloren geht“, so z.B. bei Netzwerkproblemen oder ähnlichem. In diesem Fall würde kein Abruf der Änderungen des erfolgen, da der Ziel DC nichts von den Änderungen mitbekommen würde und sie somit nicht anfordern könnte. Genau aus diesem Grund wird standardmäßig einmal die Stunde von dem DC, der die jeweilige Inbound Connection hält, eine PULL-Replikation zu seinem Replikationspartner erfolgen. D.h. bekommt DC A eine knappe Stunde lang keine change notifications des DC B, für den er eine Inbound Connection eingerichtet hat, wird DC A per PULL-Verfahren etwaige Änderungen vom DC B anfordern. Hierdurch wird sichergestellt, daß auch bei Verlust der Änderungsbenachrichtigungen alle Änderungen des Replikationspartners auch tatsächlich bei DC A ankommen.

: Abb. 3

Der Intervall dieses Schedules wird auf den NTDS Settings der entsprechenden Site festgelegt. Der KCC wird bei der Erzeugung der Connection Objects das dort als Template hinterlegte Intervall heranziehen, um den Schedule für das neu erzeugte Connection Object festzulegen. Vergleicht man also die beiden Schedules, den des Connection Objects und den des NTDS Settings Objekts, wird man die gleiche Konfiguration vorfinden (siehe Abbildung 3).

Ändert man dieses Intervall auf dem NTDS Setting Objekt der entsprechenden Site, wird auch der Schedule aller automatisch generierten Connection Objects geändert, sobald der KCC seine Topologieüberprüfung durchläuft. Standardmäßig ist das alle 15 Minuten der Fall. Forcieren kann man diesen Durchlauf z.B. bei Tests mittels

repadmin /kcc

oder in in der „Standorten und Dienste“ MMC auf dem NTDS Settings Objekt des entsprechenden Server über einen Rechtsklick >> Alle Aufgaben >> Replikationstopologie überprüfen.

Im Normalfall sollte jedoch das Verändern des Schedules für die Intra-Site-Replication nur sehr selten notwendig sein. Kommt es zu Problemen bei der Übertragung der Änderungsbenachrichtigungen, sollte man eher das zugrunde liegende Problem lösen als den „erzwungenen“ Replikationsintervall zu verkleinern.

Zu beachten gilt bei einer Veränderung der Templates, daß dies einen Einfluß auf alle darunterliegenden automatisch erzeugten Connection Objects hat.