DFSR – Rettung, wenn die Datenbank des “primären” Servers kaputt geht

Hi,

dieser Beitrag ist eine Ergänzung zu folgendem KB Artikel, der die Wiederherstellung ohne allzu viele Details beschreibt:

961879    How to recover from a DFSR database crash on designated primary member
https://support.microsoft.com/default.aspx?scid=kb;EN-US;961879

 

Hier möchte ich Schritt für Schritt das Vorgehen beschreiben.

Die Ausgangslage ist:

Die Replikation geht nicht, und wir sehen Event ID 2104 auf dem Server, den wir während der initialen Replikation als primären Server festgelegt hatten.

Protokollname: DFS Replication
Quelle: DFSR
Datum: 06.06.2010 17:10:41

Ereignis-ID: 2104
Ebene: Fehler Computer: serverA.contoso.com
Beschreibung:
Der DFS-Replikationsdienst konnte nach einem internen Datenbankfehler auf Volume "H:" nicht wiederhergestellt werden. Replikation wurde für alle replizierten Ordner auf diesem Volume beendet.
Weitere Informationen:
Fehler: 9209 (The database resource was not found (-1601))
Volume: 78E9B886-1234-4321-5678-00215AF4AA38
Datenbank: H:\System Volume Information\DFSR
Ereignis-XML:
…

Da es pro Laufwerk (Volume) eine Datenbank gibt, sind alle replizierten Ordner auf diesem Laufwerk betroffen. I.a. würde man beim manuellen Wiederherstellen einer Datenbank z.B. die kaputte Datenbank löschen. Dann würde DFSR beim Neuaufbau der Datenbank (nicht-autoritativ) mit einem beliebigen Partner replizieren und sich von dort den aktuellen Datenstand holen – mit der Folge, daß alle Dateien, die auf unserem betroffenen Server (ich nenne ihn in Zukunft serverA) anders sind als auf den übrigen Servern, im Verzeichnis Conflict & Deleted landen und Dateien, die es nur auf serverA gibt, im PreExisting Verzeichnis.

Das möchten wir in unserem Szenarium vermeiden, weil z.B.

• wir uns noch in der initialen Replikation befinden mit serverA als gewähltem primären Server oder
• die Benutzer diesen Server zum Arbeiten verwenden, d.h. hier alle Änderungen passieren, während die übrigen Mitglieder der Replikationsgruppe eigentlich nur Empfänger sind.

Um eine solche nicht-autoritative Wiederherstellung zu vermeiden, dienen diese Schritte:

Schritt 1: Alle Mitglieder der Replizierten Ordner Deaktivieren

Klingt zunächst einfach, und ist es in vielen Fällen auch.

• D.h. in den meisten Fällen öffnet man die DFS Konsole geht auf die Replikationsgruppe, die betroffen ist,
• wählt den Replizierten Ordner
• und macht dann einen Rechtsklick auf jedes Mitglied und wählt im Kontext-Menu jeweils “Deaktivieren” (engl. “Disable”).

Anders verhält es sich, wenn zusammen mit dem Replizierten Ordner der Inhalt auch im Namespace (Namensraum) veröffentlicht wurde oder wenn im Namespace ein Ordner mit Ordnerzielen (folder mit folder targets) eingerichtet wurde und im Knoten “Namespace dann gesagt wurde, daß die Inhalte repliziert werden sollen.

Wenn man dann diesen erwähnten Rechtsklick macht, resultiert das in:

D.h. es wird nicht nur die Mitgliedschaft im Replizierten Ordner deaktiviert, sondern der Ordner wird auch aus dem Namespace entfernt.

Wenn auf dem Ordner Benutzer arbeiten, ist er dann über den DFSN-Namen plötzlich nicht mehr erreichbar. Daher ist das unter Umständen nicht wünschenswert.

Ähnlich sieht es aus im Namespace-Knoten. Auch dort sind beide Bereiche beim Deaktivieren der Replikation betroffen, sofern beides miteinander angelegt wurde.

 

Was nun ? Wie können wir verhindern, daß gleichzeitig mit der Replikation auch die Verfügbarkeit für die Benutzer unterbrochen wird ?

Die Lösung ist DFSRAdmin.

Mit dem Kommandozeilen-Tool können wir die Replikation unterbrechen, ohne die Verfügbarkeit in DFSN zu beenden. Das Kommando sieht so aus:

dfsradmin membership set /RFName:Test-RG-RF /RGName:Test-RG
/MemName:opa\win2008x64DC2 /MembershipEnabled:false

Das Kommando so ausgeführt, bringt diese Meldung:

Mit dieser Variante wird die Mitgliedschaft nicht deaktiviert. Wir erhalten nur diese Warnung.

Beim zweiten Mal ist der Parameter “/force” hinzugefügt, und damit ignoriert DFSR die Warnung und deaktiviert die Mitgliedschaft wie gewünscht, ohne den Server aus dem Namespace zu entfernen.

Wie können wir kontrollieren, daß das Deaktivieren erfolgreich ist ?

Event ID 4008
(englischer Text: “The DFS Replication service stopped replication on the replicated folder at local path %2. ”)

gefolgt von Event ID 4114
(englischer Text: “The replicated folder at local path %2 has been disabled. The replicated folder will not participate in replication until it is enabled. All data in the replicated folder will be treated as pre-existing data when this replicated folder is enabled. ”)

sind hier unsere Helfer.

Protokollname: DFS Replication
Quelle: DFSR
Datum: 12.07.2010 16:55:56

Ereignis-ID: 4008
Ebene: Informationen Computer: serverX.contoso.com
Beschreibung:
Der DFS-Replikationsdienst hat die Replikation für den replizierten Ordner unter dem lokalen Pfad "C:\DFSR\Test-RG\Test-RG-RF" beendet.
Weitere Informationen:
Name des replizierten Ordners: Test-RG-RF
ID des replizierten Ordners: F9806275-1234-5678-4321-BAAB4931DEFF
Replikationsgruppenname: Test-RG
Replikationsgruppen-ID: 9E9CC571-1234-5678-4321-FBBC976BFCAE
Mitglieds-ID: 7368C484-1234-5678-4321-D782F9DAB6E1
Ereignis-XML:
…

 

Protokollname: DFS Replication
Quelle: DFSR
Datum: 12.07.2010 17:00:56
Ereignis-ID: 4114
Ebene: Informationen Computer: serverX.contoso.com
Beschreibung:
Der replizierte Ordner unter dem lokalen Pfad "C:\DFSR\Test-RG\Test-RG-RF" wurde deaktiviert. Der replizierte Ordner nimmt nicht an der Replikation teil, bis er aktiviert wird. Alle Daten im replizierten Ordner werden bei seiner Aktivierung als bereits vorhandene Daten behandelt.
Weitere Informationen:
Name des replizierten Ordners: Test-RG-RF
ID des replizierten Ordners: F9806275-EBAF-42E3-904D-BAAB4931DEFF
Replikationsgruppenname: Test-RG
Replikationsgruppen-ID: 9E9CC571-4307-49B3-9A72-FBBC976BFCAE
Mitglieds-ID: 7368C484-4089-4AAF-A25E-D782F9DAB6E1
Ereignis-XML:
…

 

Zwischenschritt - immer bei Änderungen an der Konfiguration:  AD Replikation

 Nun ist es wichtig, daß alle DCs (Domänenkontroller) und alle beteiligten DFSR-Server die Änderungen mitbekommen, bevor wir weitermachen. Sonst kann es auch passieren, daß wir die Events, wie z.B. oben Event ID 4008 und Event ID 4114 vergeblich suchen.

Also heißt es entweder einen Replikationszyklus des AD (Active Directory) + 1 POLL-Zyklus von DFSR abwarten oder Replikation und POLL forcieren mit

• repadmin /syncall /force
• DFSRDiag POLLAD /MEM:<MEMBER>

Die AD Replikation innerhalb einer Site (intra-site) erfolgt innerhalb weniger Sekunden, repadmin brauchen wir also nur für DCs in anderen AD Standorten (= Sites).

Das “polling” also das Ziehen von Konfigurationsinformationen aus dem AD führt DFSR standardmäßig, wenn sich nichts ändert, einmal pro Stunde durch. Sobald DFSR bemerkt, daß sich etwas ändert, wechselt es in einen 5min Rhythmus, solange bis sich wieder nichts mehr ändert.

Diesen Zwischenschritt brauchen wir immer, wenn wir an der DFSR Konfiguration etwas ändern, da alle diese Änderungen im AD gespeichert werden, also z.B. eine Mitgliedschaft aktivieren oder deaktivieren, Mitglieder hinzufügen oder entfernen oder auch an der Topologie etwas ändern.

So, damit ist das Deaktivieren abgeschlossen.

 

Schritt 3: Replikation auf dem gewählten primären Mitglied aktivieren

Nun geht’s weiter mit dem “Neuaufbau”.

Ich empfehle, daß beim Neuaufbau nun ein Replizierter Ordner nach dem anderen komplett aktiviert wird, damit immer nur eine initiale Replikation zur Zeit läuft.

Als erstes muß nun der Server aktiviert werden, der der “primäre” Server ist, also serverA.

Also gehen wir wieder in die DFS Verwaltung und dort in den Replizierten Ordner, für den wir die Mitgliedschaft der Server aktivieren wollen. Rechte Maustaste auf den ausgewählten primären Server und im Kontextmenu “Aktivieren”.

Ergebnis:

a) klappt wunderbar    oder

b)

Ursache: Wie vorher beim Deaktivieren liegt es daran, daß der Ordner gleichzeitig im Namensraum veröffentlicht ist. Und auch hier ist die Lösung wieder die Kommandozeile:

dfsradmin membership set /RFName:Test-RG-RF /RGName:Test-RG
/MemName:opa\win2008x64DC2 /MembershipEnabled:true /force

Analog zum Deaktivieren benötigen wir auch hier den Parameter “/force”, damit trotz Namespace-Verknüpfung die Mitgliedschaft im Replizierten Ordner wieder aktiviert wird.

Wichtig ist, daß hier nun im Eventlog das Event ID 4112
(englischer Text: "This member is the designated primary member for this replicated folder.")

zu sehen ist:

Protokollname: DFS Replication
Quelle: DFSR
Datum: 28.06.2010 13:38:55

Ereignis-ID: 4112
Ebene: Informationen Computer: serverA.contoso.com
Beschreibung:
Der DFS-Replikationsdienst hat den replizierten Ordner unter dem lokalen Pfad "C:\DFSR\Test-RG" initialisiert. Dieses Mitglied ist das zugeordnete primäre Mitglied für diesen replizierten Ordner.
Weitere Informationen:
Name des replizierten Ordners: Test-RG-RF
ID des replizierten Ordners: F9806275-EBAF-42E3-904D-BAAB4931DEFF
Replikationsgruppenname: Test-RG
Replikationsgruppen-ID: 9E9CC571-4307-49B3-9A72-FBBC976BFCAE
Mitglieds-ID: 52F77E37-F0BD-4F7C-A9D0-A2FC7D5E9426
Ereignis-XML:
…

 

Dieses Event sagt uns, daß dieser Server nun als “primär” für die weitere (erneute) initiale Replikation festgelegt ist. Das ist wichtig, damit DFSR dann weiß, wer der Herr und wer der Knecht ist (für die initiale Replikation). Denn während DFSR im allgemeinen Betrieb ein sogenanntes “multi-master replication” System ist, gewinnt bei der initialen Replikation der “Master” alle Replikationskonflikte und nur die Dateien landen im aktiven Datensatz, die auch dieser Server kennt. Wenn es auf den übrigen Servern Dateien gibt, die der “Master” gar nicht kennt, dann landen diese Dateien im “PreExisting” Verzeichnis, von wo man sie dann manuell in den aktiven Datensatz übertragen muß, wenn die Benutzer sie weiterhin verwenden können sollen.

 

Schritt 4: Replikation der übrigen Mitglieder aktivieren

Der vierte Schritt ist kurz gesagt, kann aber lange dauern.

Analog zu Schritt drei werden nun nach und nach die übrigen Server wieder aktiviert.

Je nachdem wie lange die Replikation schon nicht mehr lief und wie hoch die Änderungsrate ist, sind die Datenbestände auf den einzelnen Servern mehr oder weniger auseinandergedriftet, und dementsprechend kann diese erneute Erstreplikation mehr oder weniger lange dauern.

Der Beginn der initialen Replikation wird auf diesen Servern durch Event ID 4102
(englischer Text: “The DFS Replication service initialized the replicated folder at local path %2 and is waiting to perform initial replication.”)

gekennzeichnet, das Ende durch Event ID 4104.
(englischer Text: "The DFS Replication service successfully finished initial replication on the replicated folder...")

Protokollname: DFS Replication
Quelle: DFSR
Datum: 12.07.2010 17:11:38

Ereignis-ID: 4102
Ebene: Warnung Computer: serverB.Contoso.com
Beschreibung:
Der DFS-Replikationsdienst hat den replizierten Ordner unter dem lokalen Pfad "C:\DFSR\Test-RG\Test-RG-RF" initialisiert und ist für die erste Replikation bereit. Der replizierte Ordner verbleibt in diesem Zustand, bis er replizierte Daten direkt oder indirekt vom zugewiesenen primären Mitglied empfangen hat.
Weitere Informationen:
Name des replizierten Ordners: Test-RG-RF
ID des replizierten Ordners: F9806275-EBAF-42E3-904D-BAAB4931DEFF
Replikationsgruppenname: Test-RG
Replikationsgruppen-ID: 9E9CC571-4307-49B3-9A72-FBBC976BFCAE
Mitglieds-ID: 7368C484-4089-4AAF-A25E-D782F9DAB6E1
Ereignis-XML:
…

Protokollname: DFS Replication
Quelle: DFSR
Datum: 12.07.2010 17:11:38

Ereignis-ID: 4104
Ebene: Informationen Computer: serverB.contoso.com
Beschreibung:
Der DFS-Replikationsdienst hat die erste Replikation für den replizierten Ordner unter dem lokalen Pfad "C:\DFSR\Test-RG\Test-RG-RF" erfolgreich abgeschlossen.

Alle bereits vorhandenen lokalen Inhalte in diesem replizierten Ordner, die nicht auf dem primären Mitglied für Test-RG-RF vorhanden sind, wurden in den ausgeblendeten Systemordner 'DFSRPrivate\PreExisting' unterhalb des replizierten Ordnerstamms verschoben.

Inhalte im Ordner 'DFSRPrivate\PreExisting' werden nicht auf andere Mitglieder der Replikationsgruppe repliziert und vom DFS-Replikationsdienst bei automatischen Bereinigungen nicht gelöscht. Wenn Sie die Replikation dieser Inhalte auf andere Mitglieder wünschen, verschieben Sie die Inhalte in die replizierten Ordner außerhalb des Ordners 'DFSRPrivate'.
Weitere Informationen:
Name des replizierten Ordners: Test-RG-RF
ID des replizierten Ordners: F9806275-1234-5678-4321-BAAB4931DEFF
Replikationsgruppenname: Test-RG
Replikationsgruppen-ID: 9E9CC571-1234-5678-4321-FBBC976BFCAE
Mitglieds-ID: 7368C484-1234-5678-4321-D782F9DAB6E1
Ereignis-XML:
…

Soweit die Schritt für Schritt Beschreibung, wie wir nach einem Datenbank Crash geordnet die Replikation wieder einrichten können.

 

 

Da das Vorgehen etwas einfacher ist (aber nicht nur deshalb), wenn keine Verknüpfung zwischen Namespace- und Replikationskonfiguration besteht, empfehle ich stets den Namespace im Knoten “Namespace” zu administrieren und die Replikation im Knoten “Replikation” der DFS Verwaltungskonsole. DFSN und DFSR sind jeweils eigene Technologien, die nichts miteinander zu tun haben, außer den ersten drei Buchstaben ihres Kürzels und die Verwaltungskonsole. Daher empfehle ich, sie getrennt zu administrieren.

Gruß

Barbara