Harmonie zwischen DFSR und Backup Software ?

Servus, ich möchte heute ein bißchen Licht darauf werfen, was passiert, wenn Daten gesichert werden, die via DFSR repliziert werden.

Eines der klassischen Szenarien, für die DFSR gedacht ist, ist ja: Wir haben viele Außenstellen und eine Zentrale. In den Außenstellen gibt es Server, auf denen den Benutzern Daten lokal zur Verfügung gestellt werden. Um nun nicht in jeder Außenstelle ein eigenes Backup, eine eigene Datensicherung machen zu müssen, mit dem damit verbundenen Aufwand, werden die Daten in die Zentrale repliziert und dort zentral gesichert.

Wenn man die Daten nun noch auf beiden Servern (Außenstelle und Zentrale) via DFSN veröffentlicht, hat man außerdem noch zusätzliche Fehlertoleranz gewonnen.

Aber das nur am Rande … obwohl das evtl. eigene Betrachtungen wert wäre.

Wenn nun die Datensicherung losläuft, während Dateien repliziert werden, könnte dies zu Inkonsistenzen führen, je nachdem, in welchem Stadium die Dateien gerade vom Backup erfaßt werden. Um dies zu verhindern, stoppt DFSR die Replikation, wenn eine Dateisicherung beginnt.

In den Ereignisprotokollen sieht man das entsprechend an Ereignissen wie:

ESENT 100 – 103, die protokollieren, daß die DFSR Datenbank bzw. einzelne DFSR-Datenbankinstanzen angehalten und wieder gestartet werden.

Im Ereignisprotokoll von DFSR sieht man z.B.

Event ID : 4008

Source : DFSR

Type : Information

Generated : 01.08.2008 09:01:08

Machine : FS01

Message : The DFS Replication service stopped replication on the replicated folder at local path E:\DATEN\GRUPPE\folder1.

…

 

Wenn zu diesem Zeitpunkt das Zeitfenster für die DFS-Replikation offen ist, kann es aber auch sein, daß wir auf dem Replikationspartner (z.B. in der Außenstelle, wenn ich mich auf das Beispiel oben beziehe) eine Warnung bekommen, weil er nicht replizieren kann, weil die Replikation auf dem Server in der Zentrale angehalten ist:

Event ID : 5014

Source : DFSR

Type : Warning

Generated : 03.08.2008 16:00:46

Machine : FS02

Message : The DFS Replication service is stopping communication with partner FS01 for replication group RG1 due to an error. The service will retry the connection periodically.

Additional Information:

Error: 9033 (Die Anforderung wurde durch Herunterfahren abgebrochen.)

 

Wenn einen diese Einträge im Ereignisprotokoll stören, ist es günstiger, die Datensicherung auf einen Zeitpunkt außerhalb eines Replikationszeitfensters zu legen.

 

Daneben gibt es auch Backup-Software, die gar nicht damit zurechtkommt, wenn Dateien mit DFSR repliziert werden sollen, und hier scheint es nötig zu sein, den DFSR Dienst zu beenden, bevor die Datensicherung von Dateien in Verzeichnissen, die mit DFSR repliziert werden, anfängt.

Dafür kann man sich zwar theoretisch ein Skript basteln, das erst den Dienst beendet, dann das Backup startet und nach einer gewissen Zeit dann den Dienst wieder startet, aber aus der Sicht der Replikationsleistung ist das keine gute Idee, weil DFSR anschließend wieder komplett die Konsistenz überprüfen muß usw.

Eine Backup-Software (z.B. NTBackup), der es reicht, wenn der Dienst die Replikation anhält, ist hier deutlich effektiver.

Warum hebe ich die Variante, die ein Beenden des DFSR Dienstes erfordert, so hervor ?

Das Stoppen des Dienstes hat verschiedene Auswirkungen, die die Leistung der Replikation und evtl. auch die Auslastung der involvierten Server beeinträchtigen können.

Wenn der Dienst längere Zeit gestoppt war, kann es z.B. zu einem sogenannten Journal Wrap kommen.

Das NTFS Journal oder auch USN Journal – beide Namen sind gängig – protokolliert alle Änderungen auf einem NTFS Volume mit. Das hat zunächst nichts mit DFSR zu tun. Aber DFSR nutzt dieses Journal, um festzustellen, ob eine Datei oder ein Verzeichnis in seinem „Hoheitsbereich“ geändert wurde.

Dieses Journal ist zyklisch, d.h. es wächst bis zu einer bestimmten Größe und ab dann werden bei allen weiteren Änderungen jeweils die ältesten Einträge überschrieben. Die Standardgröße ist 512MB bei den aktuellen Betriebssystemen.

Wenn DFSR nun, bevor der Dienst gestoppt wurde, noch den Eintrag N registriert hat, nach dem Neustart aber den Eintrag N+1 nicht mehr im NTFS Journal findet, weil er in der Zwischenzeit bereits überschrieben wurde, dann ist das ein Journal Wrap. Die DFS-Replikation kann nun die Konsistenz der Daten nicht mehr sicherstellen ohne Überprüfung. Das ist zwar nicht mehr so teuer wie noch zu FRS Zeiten – auch FRS hat das USN Journal bereits für den gleichen Zweck verwendet, die Konsistenz konnte aber nur mit einem manuellen Eingriff wiederhergestellt werden –, aber es erfordert im Minimum den Abgleich der Metadaten aller bereits existierenden Dateien. D.h. alle vorhandenen Dateien und Verzeichnisse erhalten eine Markierung „journalWrap“ in der DFSR Datenbank und die in der Datenbank hinterlegten Metadaten werden mit den Metadaten verglichen, die nun für die tatsächlichen Dateien im Dateisystem erstellt werden. Wenn bei einer Datei bzw. einem Verzeichnis ein Unterschied festgestellt wird, wird die Datenbank aktualisiert und die Änderung rausrepliziert (außer auf einem der Partner gibt es eine aktuellere Änderung, dann würde eine Konfliktlösung erfolgen). Anschließend wird die Markierung entfernt. So werden nacheinander alle Dateien / Verzeichnisse abgearbeitet. Je nach Anzahl und Größe der Dateien kann das recht aufwendig sein.

Dateien / Verzeichnisse, die während dieser Überprüfung neu erstellt werden bzw. schon nicht mehr markiert sind und lokal geändert werden, replizieren (auch während für andere Dateien / Verzeichnisse die Überprüfung noch läuft) ganz normal.

Soweit zum Journal Wrap.

Wenn man den DFSR Dienst stoppt, aus welchem Grund auch immer, muß man sich darüber im klaren sein, daß das alle Replikationsgruppen und alle Replicated Folder auf diesem Server betrifft - nicht eine Gruppe oder ein Verzeichnis oder eine Platte sondern ALLE.

Ein weiterer Effekt eines Neustarts des Dienstes ist, daß auf dem Server alle Leistungsindikatoren (Performance Counter) von DFSR zurückgesetzt werden, so daß alle Überwachungsprodukte, die darauf basieren und keine eigene Historie mitprotokollieren, wieder auf „0“ sind.

Alle diese Punkte sprechen dagegen, daß man den Dienst häufig neu startet, insbesondere bei größeren Datenmengen. Und sie sprechen dafür – um auf den Ausgangspunkt zurückzukommen :-) – ein Backup zu verwenden, das nicht das Beenden des DFSR Dienstes erfordert.

 

Gruß

Barbara