Grundlegende DFS-R Überwachung mit HausmittelnTeil 2 - Die Health Reports, Propagation Tests und Backlogs

Teil 1 - Die Ereignisprotokolle

Autor: olc, MCSEboard.de

 

In den meisten Unternehmen spielen heute nicht nur Daten von Content Management Systemen, Datenbanken oder ähnlichem eine große Rolle, sondern auch die auf Dateiservern lagernden und bearbeiteten Dateien, so etwa von Tabellenkalkulationsprogrammen, Textdokumente oder Präsentationen. Diese bilden oftmals die Grundlage der Arbeit in der Verwaltung, der Produktion als auch im Management – ein Verlust dieser Daten kommt dem Einreichen eines Insolvenzantrages gleich.

Um so erstaunlicher ist es dementsprechend, immer wieder zu sehen, daß der Überwachung von DFS-R Systemen in einigen Unternehmen (größere als auch kleinere) kaum eine Bedeutung zukommt. Erst im Fehlerfall wird dann festgestellt, daß vielleicht schon eine lange Zeit Daten verloren gingen oder schlichtweg gar nicht repliziert wurden. Ist dann die Topologie beispielsweise so aufgebaut, daß an den Außenstandorten die Daten nicht gesichert werden, sondern im zentralen Datacenter, kommt es zwangsläufig beim Ausfall eines Servers am Außenstandort zum Datenverlust, wenn die Replikation nicht korrekt durchlief.

Ausgewachsene Überwachungsprogramme wie z.B. Microsoft Operation Manager bzw. System Center Operation Manager [4] oder ähnliche Produkte bringen Management Packs mit, die die auch die Überwachung  des DFS-R Dienstes sehr übersichtlich und einfach machen. Da solche Produkte jedoch recht teuer sind und sich daher nicht jedes Unternehmen für eine solche Lösung entscheiden kann, muß man sich über Alternativen Gedanken machen.

Obwohl es im Grunde kaum erwähnenswert scheint, daß man zur Überwachung von Diensten und Applikationen die Windows Ereignisprotokolle nutzen sollte, wird von dieser Möglichkeit in der Praxis oft kaum Gebrauch bemacht. Eine regelmäßige Kontrolle der Event Logs kann jedoch den Unterschied zwischen funktionierender DFS-R Replikation und Datenverlust bedeuten.

DFS-R bringt ein eigenes Event Log mit dem Namen „DFS Replication“ mit, daß bedeutet man kann dieses auch recht komfortabel einzeln auswerten. Wie auch bei anderen Ereignisprotokollen spielen im Normalfall die "Warnungen" oder Fehler im Gegensatz zu "Informationen" eine übergeordnete Rolle, jedoch ist es bei DFS-R in einigen Situationen durchaus empfehlenswert, ab und an auch ein Auge auf die Informationsmeldungen zu werfen. Dies wird im Laufe des HowTos noch einmal angesprochen.

Grundsätzlich macht es Sinn, die Warnungen und Fehler z.B. täglich zu exportieren und zu prüfen. Da es sich hierbei um ein „einsammeln“ der Daten handelt, können beliebige Werkzeuge dafür genutzt werden, so z.B. VBScripts, die PowerShell oder aber auch Kommandozeilenprogramm wie PsLogList [5]. Die Logik in den jeweiligen Scripts ist recht einfach: Je nachdem, ob die DFS-R Systeme in einer eigenen Active Directory OU liegen, ob Sie ein einheitliches, eindeutiges Namensschema besitzen oder aber die Beschreibung im Computerobjekt eine eindeutige ist, kann über eine Abfrage der Systeme über diese Merkmale eine Serverliste erstellt werden. Diese Server werden dann über die Scripte abgefragt und die Ereignisse in eine Datei oder Datenbank geschrieben.

Ein sehr einfaches Beispiel mit PsLogList könnte also wie folgt aussehen (Pfade zu den Objekten oder eigene LDAP Filter sind selbständig anzupassen, die Programme PsLogList und DSQUERY müssen vorhanden sein):

C:\> FOR /F „tokens=2 delims==,“ %i in (‘dsquery computer “OU=DFSR,OU=Servers,DC=domain,DC=tld”’) do PsLogList \\%i –f WE “DFS Replication” > “\\server\share\DFSR_events.txt”


Das Ergebnis kann dann in etwa so aussehen:

C:\>psloglist \\DBW2K3R201 -f we "DFS Replication"

PsLoglist v2.64 - local and remote event log viewer
Copyright (C) 2000-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

DFS Replication log on \\DBW2K3R201:
[018] DFSR
   Type:     WARNING
   Computer: DBW2K3R201
   Time:     8/23/2008 11:29:32 AM   ID:       4102
The DFS Replication service initialized the replicated folder at local path C:\DFSShares\test1
and is waiting to perform initial replication. The replicated folder will remain in this state until 
it has received replicated data, directly or indirectly, from the designated primary member.

  Additional Information:
  Replicated Folder Name: test1
  Replicated Folder ID: 7736410A-B3F9-463C-A3DE-BDE585472D1F
  Replication Group Name: test1
  Replication Group ID: 02BEAE0E-D464-431B-94E5-F0DC9743B00D
  Member ID: AC250AF1-9D1E-42A4-BB87-713B92E34181

[001] DFSR
   Type:     WARNING
   Computer: DBW2K3R201
   Time:     8/21/2008 11:02:14 AM   ID:       4102
The DFS Replication service initialized the replicated folder at local path C:\DFSShares\test
and is waiting to perform initial replication. The replicated folder will remain in this state until 
it has received replicated data, directly or indirectly,from the designated primary member.

Eine regelmäßige Überprüfung dieser Daten kann Probleme frühzeitig aufzeigen. Wird zum Beispiel in einer Replikationsgruppe recht häufig das Staging Verzeichnis aufgeräumt (Event ID 4202), so ist dies im Normalfall ein Indiz dafür, daß dieses schlichtweg zu klein ist und vergrößert werden sollte. Hierbei wird oftmals unterschätzt, daß durch wiederholtes Staging Folder Cleanup bzw. dessen Folgen nicht nur die Replikationsperformance sinken kann, sondern daß auch das System mehr belastet wird, da das Staging ein recht aufwändiger (und damit „teurer“) Prozess für CPU und unter Umständen auch die Festplatte / das HDD Array ist.

Problematisch dabei ist jedoch, daß die Logs nur in bestimmten Zeitintervallen gezogen werden. Einige Fehler sind jedoch zeitkritisch, so daß Sie einer besonderen Beobachtung unterliegen sollten. Zwei Beispiele dazu.
Eines der am häufigsten genutzten DFS-R Szenarien ist die Bearbeitung von Daten in Außenstellen und die zentrale Sicherung dieser Daten an einem Datacenter Standort. Wendet man in einem solchen Szenario ein wenig Logik an, sollten beispielsweise die folgenden zwei Ereignisse einer besonderen Überwachung unterliegen:

  1. Konflikte dürfen im Normalfall (außer bei einer Rücksicherung, das ist jedoch ein „Spezialfall“) niemals auf Servern der Außenstelle geloggt werden. Da nur in den Außenstellen Daten geändert werden sollen, nicht jedoch im Datacenter, kann man die Außenstellen auf Konfliktereignisse überprüfen. Eine Bearbeitung der gleichen Daten an mehreren Standorten gleichzeitig ist grundsätzlich nicht zu empfehlen und wird daher hier aus der Überlegung ausgeschlossen. Somit wäre also die Überlegung, Ereignisse mit der Event ID 4412 auf dem Außenstellenserver sofort melden zu lassen (übrigens ist diese Meldung nur eine „Informational“ Meldung, keine Warnung oder Fehler, s.o.).

  2. Eine weitere kritische Event ID ist die Meldung 2102 (Warnung) bzw. 2106 (Information). Diese zeigen an, daß nach einem Datenbankproblem die DFS-R Datenbank neu initialisiert wurde. Soweit erst einmal kein Problem, jedoch bedeutet dies, daß nun eine Initialreplikation für alle Replikationsgruppen des Volumes erfolgt, auf dem die Datenbank neu erstellt wurde. Werden diese Meldungen also auf einem Außenstellenserver geloggt, könnte als Event Trigger beispielsweise sofort der DFS-R Dienst auf diesem Server beendet werden, eine Nachricht an die Administratoren gehen, so daß Maßnahmen eingeleitet werden. Tritt das Event allerdings auf dem Backup System auf, wird in den meisten Fällen keine direkte Aktion notwendig sein – obwohl natürlich eine Ursachenanalyse erfolgen sollte.

Eine sofortige Benachrichtigung oder Aktion kann man unter Windows Server 2003 etwa mit dem Programm „Eventtrigger“ [6] erzeugen oder aber unter Windows Server 2008 recht komfortabel über die Aufgabenplanung. [7]

Diese beiden Beispiele zeigen, daß man die Logik, die in professionellen Überwachungsprodukten steckt, selbst entwickeln muß. Mit etwas Zeit in der Planung und einem ganzheitlichen Ansatz läßt sich hier jedoch ein recht umfangreiches Regelwerk definieren, welches dann per Script automatisiert angewendet werden kann.

 

© MCSEboard.de, olc

Grundlegende DFS-R Überwachung mit HausmittelnTeil 2 - Die Health Reports, Propagation Tests und Backlogs