Dateireplikation unter Server 2008 - suche gute Strategie

[DeathAndPain2 10]

Wir führen eine Reihe neuer Windows Server 2008-Server in verschiedenen Sites ein. Dabei wollen wir ein Intranet aufziehen. Dieses wird auf einem Server gepflegt und soll regelmäßig auf die anderen Server repliziert werden, damit die verschiedenen Sites die Intranetseiten stets von ihrem lokalen Server abrufen können.

 

Der Forest ist zwar vom Typ "Windows Server 2008", also ohne Kompatibilitätseinschränkungen zu früheren Versionen, aber wir wollen unseren Verzeichnisbaum nicht virtualisieren. Daher habe ich bisher kein DFS installiert. Jetzt überlege ich, welcher Weg der günstigste für die automatische Replikation der Intranetseiten ist. Ich sehe mehrere Wege:

• Man könnte doch DFS installieren, nur wegen der Replikation. Aber macht das nur für diesen Zweck Sinn? Und kann ich trotzdem verhindern, daß meine Dateipfade zu einem großen, virtuellen Baum zusammengeführt werden? Bislang habe ich keinerlei Erfahrung mit DFS, weswegen die Frage etwas dämlich klingen mag.
   
  
• Man könnte die "Windows Server 2003 File Services" installieren und dann den darin enthaltenen File Replication Service nutzen. Aber macht es Sinn, die Windows Server 2003 File Services zu installieren, wenn wir keine Windows Server 2003 haben? Sollte man dann nicht lieber auf Mechanismen setzen, die für Windows Server 2008 typisch sind?
   
  
• Man könnte händisch was basteln, indem man Robocopy als Task einplant. Funktioniert sicherlich; die Idee wirkt aber nicht allzu professionell auf mich.
   
  
• Vielleicht funktioniert das alte Dateireplikationskonzept von NT 4.0 ja auch noch unter Server 2008? So haben wir es in der Vergangenheit gemacht. Aber ist das auch noch ein Modell für die Zukunft?
  

Bitte um Rat.

[olc 18]

Hi,

 

wie immer zu Beginn die Bitte, zwischen DFS-N und DFS-R zu unterscheiden. ;)

 

Man könnte doch DFS installieren, nur wegen der Replikation. Aber macht das nur für diesen Zweck Sinn? Und kann ich trotzdem verhindern, daß meine Dateipfade zu einem großen, virtuellen Baum zusammengeführt werden? Bislang habe ich keinerlei Erfahrung mit DFS, weswegen die Frage etwas dämlich klingen mag.

 

Klingt überhaupt nicht dämlich - wer nicht fragt, ist dämlich. ;)

 

Es kann durchaus Sinn machen, kommt ein wenig auf die Eckdaten an. Grundsätzlich sind DFS-N und DFS-R zwei vollkommen unterschiedliche Techniken, die sich nicht bedingen. Du kannst also theoretisch Daten mittels DFS-R replizieren, ohne Sie überhaupt freizugeben oder in einem Namespace zu veröffentlichen.

 

Dabei solltest Du jedoch in diesem konkreten Fall unter anderem im Auge behalten, daß einige Webapplikationen die Dateien sperren, die sie gerade ausliefern. Damit bekommst Du unter Umständne bei DFS-R Probleme - denn diese Dateien können nicht repliziert werden und verzögern unter ungünstigen Umständen die gesamte Replikation. Hier heißt es also: Vorher evaluieren und testen.

 

[*] Man könnte die "Windows Server 2003 File Services" installieren und dann den darin enthaltenen File Replication Service nutzen. Aber macht es Sinn, die Windows Server 2003 File Services zu installieren, wenn wir keine Windows Server 2003 haben? Sollte man dann nicht lieber auf Mechanismen setzen, die für Windows Server 2008 typisch sind?

 

Klingt hart - aber das wäre eine wirklich dumme Idee. ;) FRS ist bei weitem fehleranfälliger und vor allen Dingen nicht so skalierbar wie DFS-R. Da es unter Windows Server 2008 bezüglich DFS-R auch noch einige Verbesserungen im Vergleich zu Windows Server 2003 R2 gab (siehe The Storage Team at Microsoft - File Cabinet Blog : What’s new in Windows Serverâ„¢ 2008), solltest Du die FRS Variante von vornherein ausschließen. ;)

 

[*] Man könnte händisch was basteln, indem man Robocopy als Task einplant. Funktioniert sicherlich; die Idee wirkt aber nicht allzu professionell auf mich.

 

Je nach Umgebung kann das sinnvoll sein oder nicht. Wenn Du nur etwas "pushen" willst, kann robocopy o.ä. durchaus Sinn machen. Du profitierst dann jedoch von vielen Features nicht, z.B. der Delta-Replikation, Conflict-Detection, Bandbreiteneinsparungen durch Kompression, etc. pp.

Es gibt sicherlich noch andere Tools (wie RSYNC), jedoch sind die meist nicht so leistungsfähig wie DFS-R. Es ist halt die Frage, was genau Du machen willst. Vielleicht reichen sie auch aus.

 

[*] Vielleicht funktioniert das alte Dateireplikationskonzept von NT 4.0 ja auch noch unter Server 2008? So haben wir es in der Vergangenheit gemacht. Aber ist das auch noch ein Modell für die Zukunft?

 

Was genau meinst Du damit?

 

Aber mal ehrlich - wann kam Windows NT auf den Markt? Vor 10 Jahren ca., wenn ich mich nicht irre. Ohne das jetzt übertreiben zu wollen - aber 10 Jahre sind in der IT mittlerweile ein Zeitalter, daher kann ich mir kaum vorstellen, daß etwas in diese Richtung Sinn machen würde. :)

 

Bei Interesse: Windows Server How-To Guides: Planung, Installation und Konfiguration des Distributed File System (DFS) unter Windows Server 2003 R2 - ServerHowTo.de

Windows Server How-To Guides: Weiterführende DFS-R Konfiguration unter Windows Server 2003 R2 - ServerHowTo.de

 

Die meisten Aspekte der HowTos sind auch noch unter Windows Server 2008 relevant. Die Änderungen dazu findest Du im oben genannten Blog Eintrag.

 

Viele Grüße

olc

[DeathAndPain2 10]

Erst mal vielen Dank für die Tipps.

 

Was genau meinst Du damit?

Na ja, schon NT 4.0 hatte eine Dateireplikation eingebaut. Sie war allerdings kompliziert zum Laufen zu bringen, und extrem fehleranfällig (sobald eine Datei durch irgendwen geöffnet war, kam die ganze Replikation ins Stocken). Wenn ich richtig informiert bin, dann hat diese Empfindlichkeit Microsoft dazu veranlaßt, ROBOCOPY überhaupt erst zu entwickeln.

 

Für unser Intranet hat die NT4-Dateireplikation aber ausgereicht. Bei einem Intranet, in dem alle paar Tage mal ein neuer Eintrag auftaucht, stört es nicht weiter, wenn die Replikation erst 4 Stunden später klappt, weil sie bei allen vorhergehenden Versuchen auf die Nase gefallen ist und das Ereignislog zugespammt hat.

 

Wie dem auch sein mag, ich habe jetzt also DFS-R eingerichtet. Zwischen den beiden Domänencontrollern unseres Stammsitzes klappt das auch wunderbar. Aber nun habe ich auch einen Domänencontroller in die Replikation eingebunden, der zwar zu derselben Domäne gehört, aber in einer anderen Site steht. Doch die Replikationseinstellung, die ich im Haupthaus vorgenommen habe, hat diesen Server auch Stunden später noch nicht erreicht (trotz 24/7-Schedule) - er kennt noch nicht einmal die Replikationsgruppe, obwohl er RODC derselben Domäne ist. Was kann man da tun? Die Fernleitung steht jedenfalls einwandfrei.

[olc 18]

Hi,

 

was sagt denn ein "repadmin /replsum". Siehst Du Fehler in der Replikation zu diesem DC?

 

P.S.: Vielleicht würde es eher Sinn machen, hierfür einen anderen Thread zu öffnen. Ist schließlich ein anderes Thema. :)

 

Viele Grüße

olc

[DeathAndPain2 10]

Naja, das Problem scheint ja (fast) gelöst, denn nachdem jetzt eine Nacht vergangen ist, stelle ich fest, daß der Ordnerinhalt korrekt auf alle Server repliziert wurde. Was mich aber wundert, ist die Tatsache, daß auf den Zielservern die Replikationsgruppe im DFS-Manager trotzdem nicht vorhanden ist - obwohl diese Server auch DCs derselben Domäne sind! Sollte die Replikationsgruppe selbst nicht auch auf alle beteiligten Server repliziert werden, damit man sie dort einsehen kann? Oder ist das normal, daß man die Replikationsgruppe nur im Quellserver einsehen und pflegen kann?

[olc 18]

Hallo,

 

nein, das ist nicht normal. Obwohl ich im Moment nicht weiß, wie es mit einem RODC aussieht. Kann mir jedoch nicht vorstellen, daß es dort Unterschiede geben sollte - letztlich verbindet sich die GUI ggf. mit einem schreibbaren DC.

 

Kannst Du über dfsradmin / dfsrdiag die Replikationsgruppen auslesen oder werden Dir diese auch dort nicht angezeigt?

 

Es handelt sich bei dem "Problemserver" um einen 2008er RODC, ja?

Habe gerade keine DFS-MMC vor mir, aber bei den Namespaces kann man nicht angezeigte Namespaces per Rechtsklick hinzufügen. Habe soetwas bei Replikationsgruppen zwar noch nie machen müssen, aber vielleicht gibt es diese Option auch im DFS-R Node?

 

Vielleicht kannst Du ja meine Nachfrage nach der "repadmin" Befehlsausgabe auch noch beantworten. ;)

 

Gruß olc

[DeathAndPain2 10]

Obwohl ich im Moment nicht weiß, wie es mit einem RODC aussieht. Kann mir jedoch nicht vorstellen, daß es dort Unterschiede geben sollte - letztlich verbindet sich die GUI ggf. mit einem schreibbaren DC.

Ist bei beiden DC-Sorten aufgetreten.

 

Habe gerade keine DFS-MMC vor mir, aber bei den Namespaces kann man nicht angezeigte Namespaces per Rechtsklick hinzufügen. Habe soetwas bei Replikationsgruppen zwar noch nie machen müssen, aber vielleicht gibt es diese Option auch im DFS-R Node?

Das ist wohl die Lösung, ja. An der rechten Seite ist mir ein Link "Add Replication Groups to Display" aufgefallen. Damit konnte ich auf den betroffenen DCs die Replikationsgruppe einblenden. Wundert mich zwar etwas, daß er das nicht von alleine macht, aber ist egal.

 

Vielleicht kannst Du ja meine Nachfrage nach der "repadmin" Befehlsausgabe auch noch beantworten.

 

 

Was heißt eigentlich "largest delta"? Das zu replizierende Verzeichnis ist knapp 1 GB groß, und in der Replikationstopologie habe ich 256kbps eingestellt. Da kann er doch niemals die Erstreplikation in 4 Minuten schaffen?!

 

Wie ist das eigentlich: Nutzt er ausgehend vom Quellserver insgesamt die 256kbps für alle Zielserver, oder genehmigt er sich 256kpbs pro Zielserver, so daß an der Anbindung des Quellservers ein viel höheres Datenaufkommen entsteht?

 

Und eine Frage habe ich noch: Ich habe bei der Anlage der Replikation die 1:n-Topologie gewählt, die Windows für Publishingzwecke vorgeschlagen hat, denn wir haben ja einen Quellserver, dessen Inhalt auf mehrere Zielserver verteilt werden soll. Trotzdem hat der Wizard aber alle Connections symmetrisch angelegt. Es gibt also pro Zielserver eine Connection vom Quellserver zum Zielserver und eine in umgekehrter Richtung. Haben diese Rückverbindungen eine Daseinsberechtigung? Ich will ja nicht Änderungen, die auf den Zielservern stattfinden (bzw. niemals stattfinden werden), auf den Quellserver zurückreplizieren. Braucht er die Rückverbindungen für Statusmeldungen oder ähnliches, oder sollte ich sie löschen?

[olc 18]

Hi,

 

Das ist wohl die Lösung, ja. An der rechten Seite ist mir ein Link "Add Replication Groups to Display" aufgefallen. Damit konnte ich auf den betroffenen DCs die Replikationsgruppe einblenden. Wundert mich zwar etwas, daß er das nicht von alleine macht, aber ist egal.

 

Wundert mich ebenfalls. Aber gut, hauptsache es wird angezeigt.

 

 

Was heißt eigentlich "largest delta"?

 

Zeit seit der letzten AD(!) Replikation.

 

Das zu replizierende Verzeichnis ist knapp 1 GB groß, und in der Replikationstopologie habe ich 256kbps eingestellt. Da kann er doch niemals die Erstreplikation in 4 Minuten schaffen?!

 

Das Repadmin Kommando hat nichts mit der DFS-R Replikation zu tun (bzw. nur indirekt), es geht ausschließlich um AD-Replikation. Damit DFS-R die Konfigurationsdaten bekommt, muß die AD-Replikation zum Standort stehen. Daher meine Nachfrage und dieser Befehl.

 

Wie ist das eigentlich: Nutzt er ausgehend vom Quellserver insgesamt die 256kbps für alle Zielserver, oder genehmigt er sich 256kpbs pro Zielserver, so daß an der Anbindung des Quellservers ein viel höheres Datenaufkommen entsteht?

 

Gute Frage. :D Habe ich mich ehrlich gesagt noch nie gefragt. Da Du den Wert jedoch auf Replikationsgruppen festlegen kannst würde ich auf "insgesamt pro Replikationsgruppe" tippen. Schau ich mir einmal genauer an, wenn ich etwas Zeit habe. Interessante Sache eigentlich...

 

Es wird grundsätzlich nicht wirklich eine Bandbreiteneinschränkung vorgenommen, sondern ein Mittelwert errechnet und die Replikation ein- und wieder ausgesetzt um den Mittelwert zu erreichen. D.h. die Datenübertragung läuft bei Bandbreiteneinschränkung in (sehr kurzen) "Intervallen" und nicht mit Bandbreitenkontrolle à la QOS.

 

Und eine Frage habe ich noch: Ich habe bei der Anlage der Replikation die 1:n-Topologie gewählt, die Windows für Publishingzwecke vorgeschlagen hat, denn wir haben ja einen Quellserver, dessen Inhalt auf mehrere Zielserver verteilt werden soll. Trotzdem hat der Wizard aber alle Connections symmetrisch angelegt. Es gibt also pro Zielserver eine Connection vom Quellserver zum Zielserver und eine in umgekehrter Richtung. Haben diese Rückverbindungen eine Daseinsberechtigung? Ich will ja nicht Änderungen, die auf den Zielservern stattfinden (bzw. niemals stattfinden werden), auf den Quellserver zurückreplizieren. Braucht er die Rückverbindungen für Statusmeldungen oder ähnliches, oder sollte ich sie löschen?

 

Auf gar keinen Fall solltest Du die Connection Objects in eine Richtung deaktivieren. Da gibt es große Probleme und ist mittlerweile von MS nicht mehr supportet, siehe

 

Is it possible to configure one-way replication with DFS Replication?

Microsoft does not support creating a one-way replication connection with DFS Replication. Doing so can cause numerous problems including health check topology errors, staging issues, and problems with the DFS Replication database. A better solution is to simulate a one-way connection by using the following list:

 

• Train administrators to make changes only on the server(s) that you want to designate as primary servers. Then let the changes replicate to the destination servers.

 

• Configure the share permissions on the destination servers so that end users do not have Write permissions. If no changes are allowed on the branch servers, then there is nothing to replicate back, simulating a one-way connection and keeping WAN utilization low.

 

Viele Grüße

olc