Active Directory Replication: speed up!
Update vom 03.04.2025: Ich habe ein PowerShell-Skript nachgereicht, welches die notwendigen Anpassungen durchführt.
Update vom 30.04.2025: Nüsse!
Ich schätze [Beleg erforderlich] Kommentare zu meinen Blog-Beiträgen sehr und interagiere [Beleg erforderlich] mit diesen gerne [Beleg erforderlich], wenn es einen fachlichen Bezug dazu gibt.
Im akutellen Fall (siehe oben) geht es im wesentlichen um die Frage:
Q: „Wie schnell kann ein Active Directory Replizieren?“
A: „schnell, sehr schnell, wenn man die ursprünglichen Latenzen zugrunde legt.“
Latenzen bei der Replikation von Active Directory out of the box:
- Intra-Site-Replikation: 15 Sekunden + 3 Sekunden*
- Inter-Site-Replikation: alle 15 Minuten
*die 3 Sekunden werden für jeden weiteren Replikationspartner angehängt. Je mehr Replikationspartner, desto länger** dauert es
**maximal 9 Sekunden Latenz, da der KCC eine Maschentopologie rechnen wird.
Intra-Site-Replikation
Die Intra-Site-Replikation betrifft den Datenabgleich der Active Directory Datenbank innerhalb einer Active Directory Site.
Innerhalb einer AD-Site gelten folgene Regelwerke:
- Change notification: RWDCs benachrichtigen einander per change notification über getätigte oder empfangene Änderungen
- No compression: RWDCs komprimieren den Datenverkehr vor dem Abgleich nicht
- Any-to-any: jeder RWDC darf mit jedem anderen RWDC der gleichen Site replizieren
- cyclic replication: es wird gemäß Zeitplan regelmäßig ein Datenabgleich durchgeführt
Inter-Site-Replication
Die Inter-Site-Replikation betrifft den Datenabgleich der Active Directory Datenbank zwischen Active Directory Sites.
Zwischen AD-Sites gelten folgene Regelwerke:
- Scheduled replication: es wird streng nach Zeitplan repliziert
- compression: das zu replizierende Datenvolumen wird zuvor komprimiert um Bandbreite zu sparen
- Bridge-Head-Servers: es kann über einen Standort hinweg nur per Bridge-Head-Server repliziert werden.
Intra-Site-Replikation-Latenzen
Die Latenzen der Intra-Site-Replikation werden von zwei Attributen pro Partiton gesteuert:
- msDS-Replication-Notify-First-DSA-Delay („<not set>“ = Default = 15 Sekunden)
- msDS-Replication-Notify-Subsequent-DSA-Delay („<not set>“ = Default = 3 Sekunden)
Diese beiden Attribute definieren die Latenz in Sekunden, wobei „<not set>“ dem Default entspricht.
Inter-Site-Replikation-Latenzen:
Die Latenzen zwischen den Sites werden über das Zeitfenster und einen Takt des Site-Links definiert, wobei Microsoft hier zwei Attribute verwendet
- replInterval (Takt in Minuten)
- schedule („<not set>“ = Default = 24 Stunden am Tag, 7 Tage die Woche)
Topologie entscheidet die Geschwindigkeit
Die Topologie des Active Directory entscheidet über die grundlegene Verzögerung bei der AD-Replikation.
Jedoch: fast egal wie man es baut, es ist sehr, sehr langsam!
Topologie
Die Active Directory Topologie besteht im wesentlichen aus den Sites, welche durch Site-Links miteinander verbunden sind.
Wenn man die Topologie dokumentieren möchte, so konnte man auf ADTD zurück greifen, welches ein Plug-in für Microsoft Visio ist.
Leider und aus meiner Sicht aus unerfindlichen Gründen ist das Tool nicht mehr verfügbar, gut dass ich noch eine Kopie davon habe.
Nichts desto trotz zeichnet ADTD einem die Verbindungen, die der KCC gerechnet hat, welche zwischen RWDCs laufen.
Default Replication – Zeitbeispiel
Nehmen wir doch mal an, dass in den Vereinigten Staaten von Amerika (das ist die Site „US“) ein Objekt im Active Directory angelegt wird.
Die Topologie besagt, dass die Site wie ein Lindwurm miteinander verbunden sind:
US (Vereinigte Staaten von Amerika) ↔ UK (Großbritannien) ↔ DE (Deutschland) ↔ FR (Frankreich) ↔ ES (Spanien)
Q: Wie lange dauert es, bis ein AD-Objekt in Spanien (Site „ES“) ankommt?
A: 1 Stunde, 1 Minute und 27 Sekunden (im schlimmsten Fall)
Wieso?
- Site US: 15 Sekunden (Replikation von US-DC01 auf US-DC02)
- Site UK: 15 Minuten (Site-Link zwischen US und UK)
- Site UK: 21 Sekunden (drei Hops gem. KCC-Regel)
- Site DE: 15 Minuten (Site-Link zwischen UK und DE)
- Site DE: 21 Sekunden (drei Hops gem. KCC-Regel)
- Site FR: 15 Minuten (Site-Link zwischen DE und FR)
- Site FR: 15 Sekunden (Replikation von CDD1 zu CDD2)
- Site ES: 15 Minuten (Site-Link zwischen FR und ES)
- Site ES: 15 Sekunden (Replikation zwischen Baztan-DC und Bera-DC)
Schneller, schneller!
Das ist viel, viel zu langsam. Bis zu einer Stunde Latenz um ein AD-Objekt oder eine AD-Änderung, macht ja keinen Unterschied, über fünf Sites zu replizieren.
Wir haben zwei Ansatzpunkte:
- Die Intra-Site-Replikation muss schneller werden und
- Die Inter-Site-Replikation muss schneller werden.
Intra-Site-Replikation: Latenz von maximal 1 Sekunde pro Intervall!
Die Intra-Site-Replikation wird von zwei Attributen beeinfluss, die pro Partition hinterlegt sind:
- msDS-Replication-Notify-First-DSA-Delay und
- msDS-Replication-Notify-Subsequent-DSA-Delay
Beide Attribute über den Domain Naming Master und pro Partition auf „1“ setzen, fertig.
Kein Reboot, kein Neustart der Dienste, einfach eintragen.
Inter-Site-Replikation: Latenz von maximal 1 Sekunde!
Die Inter-Site-Replikation wird von drei Attributen beeinfluss, wovon zwei pro Site-Link hinterlegt sind und eines pro Site-NTDS-Settings:
- options (Site-Link + Site-NTDS-Settings)
- replInterval
Pro Site-Link:
- options auf „7“: das entspricht Change notification + reziproke Replikation + keine Kompression des Datenverkehrs
- change notification: die Bridge-Head-Server schicken sich über die Site-Links hinweg Änderungsbenachrichtigungen. Dadurch verkürzt sich das Intervall von 15 Minuten auf 1 Sekunde!
- reziproke Replikation: wenn ein Bridge-Head-Server eine change notification sendet, holt er auch gleich die Änderungen, die beim Replikationspartner vorliegen. Das ist nun sogar schneller als im Standort!
- disable compressions: wenn die Bandbreite (=> 128 kbit/s (!)) keine Rolle mehr spielt, dann auf die CPU-Zeit für die Kompression des Datenverkehrs verzichtet werden.
- replInterval auf „1“: das kann nur über den Attributeditor gesetzt werden, da die DLL von der dssite.msc keine Integer kleiner als 15 akzeptiert. Es wird nun ein Mal pro Minute repliziert, ob Änderungen vorliegen oder nicht.
Pro Site-NTDS-Settings
Die NTDS-Site-Settings sollten noch im Attribut options auf 1536 gesetzt werden. Das entspricht nämlich der Bitmaske bestehend aus:
- 512: SHE (NTDSSETTINGS_OPT_IS_SCHEDULE_HASHING_ENABLED, 0x00000200): Allow the KCC to use hashing when creating a replication schedule.
Bedeutet, dass pro Verbindungsobjekt ein eigener Zeitplan gerechnet wird. Dieses unterstützt die Lastverteilung bei Bridge-Head-Servern. - 1024: RSE (NTDSSETTINGS_OPT_IS_REDUNDANT_SERVER_TOPOLOGY_ENABLED, 0x00000400): Create static failover connections.
Bedeutet, dass bei Bridge-Head-Servern immer zwei eingehende Verbindungsobjekte gerechnet werden. Das erhöht die Ausfallsicherheit.
Dadurch werden die Verbindungen zwischen den Standorten redundant gerechnet und belastbarer.
I am Active Directory, I am speed!
Was bringen diese Änderungen? Geschwindigkeit (wer hätte das gedacht)!
Ein Testobjekt wird, analog zum obigen Beispiel, in einer Site angelegt, die ganz am Anfang des Lindwurms ist. Dann messen wir doch mal die Zeit, bis das Objekt „verdaut“ wurde und am anderen Ende des Lindwurms wieder raus kommt.
17 Sekunden!
Vorher waren es 20 Minuten und 36 Sekunden.
In meinen Schulungsunterlagen resümiere ich wie folgt:
KA-CHOW!
PowerShell-Skript zur Vereinfachnung
Hier das angefragte PowerShell-Skript zur vereinfachten Anwendung der schnellen Replikation.
# building variables
$configuration = (Get-ADRootDSE).configurationNamingContext
$RIDMaster = (Get-ADForest).DomainNamingMaster
$ADParitions = (Get-ADObject -Filter { objectclass -eq 'crossRef' } -SearchBase $("CN=Partitions," + $configuration)).DistinguishedName
$SiteLinks = (Get-ADObject -Filter { objectclass -eq 'sitelink' } -SearchBase $("CN=IP,CN=Inter-Site Transports,CN=Sites," + $configuration)).DistinguishedName
$NTDSSiteSettings = (Get-ADObject -Filter { objectclass -eq 'NTDSSiteSettings' } -SearchBase $("CN=Sites," + $configuration)).DistinguishedName
$Attrib1 = 'msDS-Replication-Notify-First-DSA-Delay'
$Attrib2 = 'msDS-Replication-Notify-Subsequent-DSA-Delay'
$Attrib3 = 'options'
$Attrib4 = 'replInterval'
#performing changes
## intra site replication
$ADParitions.ForEach{ Set-ADObject -Identity $_ -Replace @{ $Attrib1=1; $Attrib2=1 } -Server $RIDMaster }
## inter site replication
$SiteLinks.ForEach{ Set-ADObject -Identity $_ -Replace @{ $Attrib3=7; $Attrib4=1 } }
$NTDSSiteSettings.ForEach{ Set-ADObject -Identity $_ -Replace @{ $Attrib3=1536 } }ComputerLogbuch der IQunit, Sternzeit -297672.4105783867, Captian Handl
Der Vertrieb geht mir auf die Nüsse, im dem er die „call to action“ in meine Artikeln vermisst.
Kenne ich nicht. Ich kenne „call of duty“ oder „ports of call„.
„Call to action“ heißt, ich soll Werbung für den Kurs machen, in dem man die obige Angelgenheit vermittelt bekommt.
Bitteschön: Essential Active Directory 2025; das wäre das Kapitel „Advanced Site Management“