Replikation

In der Standort-internen Replikation erfolgt diese unkomprimiert, da davon ausgegangen wird, dass die Controller "schnell" miteinander verbunden sind. im Unterschied dazu wird für die Standort-übergreifende Repllikation komprimiert, was einerseits geringeren Bandbreitenbedarf, andererseits mehr Rechenlast (ver/entpacken) an den jeweiligen Servern zur Folge hat.

Ablauf einer Replikation

Jeder DC eines Standortes wird durch ein Serverobjekt repräsentiert. Jedes Serverobjekt wiederum besitzt ein untergeordnetes Objekt, welches den replizierenden DC des Standortes darstellt, das "NTDS-Einstellungsobjekt". Das NTDS-Einstellungsobjekt verfügt über ein Verbindungsoblekt, in welchem die Attribute einer Replikationsverbindung zwische zwei DCs gespeichert sind.

Ein Dienst namens Konsistenzprüfung (Knowledge Consistency Checker, KCC) erstellt automatisch die für die Replikation zwischen DCs erforderlichen Strukturen aus den Verbindungsoblekten. Dies kann natürlich auch manuell geschehen.

Die KCC erstellt verschiedene Replikationstopologien für standortinterne und ~externe Replikation. Diese Topologien werden durch die Konsistenzprüfung automatisch aktualisiert, wenn zB DCs hinzugefügt, entfernt oder zwischen Standorten verschoben werden

Replikationstransporte

Zur Replikation stehen zwei Mechanismen zur Verfügung, RPC (RemoteProcedureCall) und SMTP (Simple Mail Transfer Protokoll)

RPC wird für interne Replikationen verwendet, da es sich dabei um ein mit den meisten Netzwerktypen kompatibles Standardprotokoll ist. Es setzt allerdings auch permanente Verbindungen zwischen den DDc voraus

Im Unterschied dazu wird SMTP für die Replikation zwischen Standorten, die nicht permanent verbunden sind. Allerdings werden mit SMTP keine Domänenpartitionsinformationen repliziert (was wiederum kein Problem ist, da damit ohnehin nut zwischen Standorten einer Domain repliziert wird). Also ist SMTP eigentlich nur für die Replikation des Schemas und des Globalen Kataloges nützlich

Standortverknüpfungen

Die Standortverknüpfung ist ein AD-Objekt. Durch sie werden die Verknüpfungen, welche aus der tatsächlichen physischen Verbindung und dem Standortverknüpfungsobjekt besteht, zwischen Standorten geregelt und so die Replikation ermöglicht. Das Standortverknüpfungsobjekt bestimmt dabei das Protokoll, welches zur Replikation verwendet wird (IP/SMTP), und steuert den Zeitpunkt der Replikation

Per default sind Standortsverknüpfungen transitiv, was auch so bleiben sollte. Es gibt eigentlich nur drei Gründe, diese Transitivität zu unterbrechen:

1. es wird vollständige Kontrolle über das Replikationsmuster benötigt
2. es muss verhindert werden, dass ein bestimmter Replikationspfad verwendet wird
3. das Netzwerk ist nicht vollständig geroutet bzw. Firewalls blockieren die direkte Replikation zwischen den Standorten

Standortverknüpfungskosten

Per Voreinstellung werden jeder Standortverbindung die Kosten 100 zugewiesen. Die von Microsoft empfohlenen Kosten gemäß Bandbreite finden sich in der Tabelle:

Bandbreite KBit/s	Standortverknüpfungskosten
9.6	1042
19.2	798
38.4	644
56	586
64	567
128	486
256	425
512	378
1024	340
2048	309
4096	283

Zu beachten ist, dass Kosten addiert werden, d.h. der weg über zwei 4MBit-Standortverbindungen [Umweg via einem weiteren Standort] ist teurer als eine direkte Standortverbindung via 128KBit

Bridgeheadserver

Nach der Erstellung der Standortverknüpfungen weist die Konsistenzprüfung für jede Domäne am Standort einem oder mehreren DCs die Rolle des Bridgeheadservers zu. Nur diese Server kommunizieren mit den anderen Standorten, und das zu den festgelegten Zeiten.

Die Replikationsverbindungen werden wahllos auf alle verfügbaren Brückenkopfserver verteilt, sodass eine Art Lastenausgleich passiert. Diese "Lastverteilung" findet nur statt, wenn neue Verbindungsobjekte erstellt werden. Allerdings beinhaltet das w2k3-Resource.Kit das Tool ADLB (AD-Load Balancing), mit dem derartige Lastverteilungen zu jeder anderen Zeit durchgeführt werden können