Logo faq-o-matic.net
Logo faq-o-matic.net

Replikation: Standorte & Standortverknüpfungsbrücken

von veröffentlicht am15. Februar 2005, 15:30 Uhr Kurzlink und Zitatlink einblenden
Kategorie Kategorie: Active Directory, AD: Replikation, Design   Translate with Google Translate Translate EN   Die angezeigte Seite drucken
Zuletzt aktualisiert: 26. September 2013

In diesem Artikel:

  • Kostendefinitionen bei der Active Directory Replikation (wann und warum).
  • Hintergründe einer Standortverknüpfungsbrücke (wofür).

Für geografische Standorte des Active Directory, bei denen die Domänencontroller über WAN (auch ggf. über mehrere Router hinweg) miteinander kommunizieren, richtet man Active-Directory-Standorte und damit verknüpfte Subnetze im Tool "Active Directory-Standorte und Dienste" ein. Für die grundsätzliche Funktionalität der Replikation genügt eine einzige Standortverknüpfung (SiteLink), in der alle Active-Directory-Standorte aufgeführt sind.
Mehrere Standortverknüpfungen werden erstellt, wenn man Einfluss auf die Replikation in Form von Zeitplanung, Replikationsintervall und Richtung der Replikation (Kosten) nehmen will.

Als erstes  Beispiel dazu eine Firma mit Zentrale und zwei Niederlassungen:

                        Zentrale
                       |            |
                   NL-A          NL-B

Die beiden Niederlassungen sind nur mit der Zentrale direkt verbunden. Zwischen beiden Niederlassungen gibt es keine direkte WAN-Verbindung. Direkte Kommunikation zwischen A und B ist über die Zentrale hinweg jedoch möglich, da dort die Router entsprechend konfiguriert sind.
Hier definiert man drei Standorte und die passenden Subnetze jedes Standortes. Um die Replikationsfunktionalität zu gewährleisten, genügt eine einzige Standortverknüpfung (DefaultIPSiteLink), in der alle drei Standorte enthalten sind. Eine Kostendefinition ist hier nutzlos, da es nur eine einzige Standortverknüpfung gibt. Eine Definition von zwei Standortverknüpfungen, wo in einer die Standorte Zentrale-A und in der anderen die Standorte Zentrale-B verknüpft sind, ist hier wenig sinnvoll.

Anders sieht es aus, wenn zusätzliche WAN-Verbindungen existieren:

                       Zentrale
                      |            |
                  NL-A  ——  NL-B

In diesem Beispiel ist NL-A zusätzlich direkt mit NL-B verbunden. Das WAN ist wiederum vollständig durchgeroutet. Auch zwecks Fehlertoleranz; falls eine Leitung ausfallen sollte, kann die Replikation immer noch über die andere Verbindung durchgeführt werden.
Auch hier genügt eine einzige Standortverknüpfung (DefaultIPSiteLink), die alle drei Standorte beinhaltet. In diesem Fall kann jedoch kein Einfluss darauf genommen werden, in welche Richtung bzw. über welche WAN-Verbindung die Replikation stattfindet. Um dies zu erreichen, muss die Definition von drei Standortverknüpfungen und eine dortige Kostendefinition gemacht werden.
Wenn beispielsweise zwischen Zentrale und den Niederlassungen 2 MBit Bandbreite vorliegen und zwischen A und B 128 KBit, möchte man vielleicht wegen der höheren Bandbreite die Replikation zwischen A und B grundsätzlich über die Zentrale hinweg laufen haben. Daher definiert man für diesen Wunsch drei Standortverknüpfungen (SiteLinks) mit an diesen dann konfigurierten, unterschiedlichen Kostenfaktoren. Beispiel:

  • SiteLink: A-B, Kosten 50
  • SiteLink: Zentrale-A, Kosten 10
  • SiteLink: Zentrale-B, Kosten 10.

Die Kosten von A nach B über die Zentrale hinweg betragen dann insgesamt 20, dies sind weniger als die 50 zwischen A und B direkt. Daher wird die Replikation zwischen A und B über die Zentrale hinweg stattfinden.

Zuletzt ein Szenario für eine Standortverknüpfungsbrücke:

                       Zentrale
                     |      |      | 
                  NL-A  NL-B  NL-C

Die Niederlassungen können sich gegenseitig nicht direkt erreichen, zwischen Ihnen existiert keine direkte Verbindung. Und auch über die Zentrale hinweg funktioniert keine direkte Kommunikation zwischen den Niederlassungen. Das WAN ist also nicht komplett durchgeroutet. Systeme der Zentrale erreichen alle drei Niederlassungen, Systeme in den Niederlassungen können jedoch nur die Zentrale erreichen und sonst nicht weiter. Dies ist das technische Szenario für eine Standortverknüpfungsbrücke (SiteLinkBridge).
In diesem Fall definiert man vier Standorte (Zentrale, A, B, C) mit ihren dazugehörenden Subnetzen und drei Standortverknüpfungen (SiteLinks) mit jeweils zwei darin befindlichen, verbundenen Standorten.
SiteLinks: 

  • Zentrale-A
  • Zentrale-B
  • Zentrale-C

Da die Server der drei Niederlassungen sich gegenseitig nicht direkt erreichen können (kein vollständig durchgeroutetes Netz), leistet jetzt eine Standortverknüpfungsbrücke (SiteLinkBridge), in welche nun die drei SiteLinks aufgenommen werden, hier Hilfestellung. Die Replikationsdaten werden über die Bridge schneller an die Server in den Niederlassungen weiterverbreitet. Eine Kostendefinition ist hier wieder nutzlos, denn es gibt immer nur eine Verbindung zwischen jeweiliger Quelle und Ziel der Replikation.

Auch ohne Definition einer SiteLinkBridge würde die Replikation funktionieren, nur wäre möglicherweise deren Latenzzeit zu hoch (abhängig von Intervall und Zeitplan an den SiteLinks) und hierdurch die nahe Konvergenz der Daten nicht mehr gewährleistet.

Dazu obiges Beispiel ohne SiteLinkBridge (bei Standardeinstellungen der SiteLinks):
Auf dem DC in NL-B wird ein User angelegt. Nach drei Stunden (Standard-Replikationsintervall) erfährt davon der DC in der Zentrale. Gerade vorher hat der DC in NL-A sich mit der Zentrale repliziert. Nun wird der DC in NL-A erst in weiteren drei Stunden von dem neuen User etwas mitbekommen (macht 6 Stunden Zeitunterschied in der Konvergenz der Daten).

Beispiel mit SiteLinkBridge (bei Standardeinstellungen der SiteLinks):
Durch die Bridge wird der DC in NL-A jetzt auch gleich die Änderung auf dem DC der NL-B erfahren und erhält über die Bridge hinweg die Information der Datenbankänderung auf dem DC der NL-B genauso schnell, wie der DC in der Zentrale.
Als Eselsbrücke könnte man Standortverknüpfungsbrücken auch als eine Art 'Routing' für die Replikationsdaten bezeichnen.

© 2005-2017 bei faq-o-matic.net. Alle Rechte an den Texten liegen bei deren Autorinnen und Autoren.

Jede Wiederveröffentlichung der Texte oder von Auszügen daraus - egal ob kommerziell oder nicht - bedarf der ausdrücklichen Genehmigung durch die jeweiligen Urheberinnen oder Urheber.

Das Impressum findet sich unter: http://www.faq-o-matic.net/impressum/

Danke, dass du faq-o-matic.net nutzt. Du hast ein einfaches Blog sehr glücklich gemacht!