Teil 1 - Die EreignisprotokolleGrundlegende DFS-R Überwachung mit HausmittelnTeil 3 - Bestandsanalyse und Performanceauswertung

Teil 2 - Die Health Reports, Propagation Tests und Backlogs

Autor: olc, MCSEboard.de

 

Health Reports

Die Health Reports wurden im ersten Teil des DFS-R HowTos [3] schon angesprochen, daher folgen an dieser Stelle nur einige wenige Hinweise dazu.

Die Health Reports sind im Bereich DFS-R wirklich gut zu nutzen und sehr wertvoll in Ihren Informationen. Man kann diese automatisch mittels „dfsradmin health new“ (plus einige Parameter) über die Kommandozeile oder aber über die DFS MMC erzeugen.
Warum die Health Reports über „dfradmin“ und nicht über „dfsrdiag“ aufgerufen werden, bleibt ein ungelöstes Rätsel. ;-)
Liest man die DFS-R Daten z.B. in eine Excel Liste ein und übergibt die Servernamen und Replikationsgruppen / -verzeichnisse darüber per Script an die „dfsradmin“ Kommandozeile, kann man auch hier automatisiert einen regelmäßigen Export gewährleisten, der dann jedoch auch geprüft werden muß. In den Reporten stehe eine Menge nützlicher Informationen, aus denen sich auch Basislinien des DFS-R Betriebs erstellen lassen. Optionen wie „Count the replicated files and and their sizes on each member“ können eine hohe Last verursachen und sollten daher nur bei Bedarf ausgewählt werden.

Die wirklich interessante Option der Health Reports sind in größeren Umgebungen jedoch natürlich nicht die einzeln auszuwertenden HTML Reports, sondern die ebenfalls erzeugten XML-Dateien. Diese liegen im gleichen Verzeichnis, in dem auch die HTML Dateien abgelegt werden. Die XML-Dateien können mit einem beliebigen XML-Parser etwa in Datenbanken eingelesen werden oder direkt über eine Programm-„intelligenz“ ausgewertet werden. So lassen sich die Basislinien über einen sehr langen Zeitraum aufbauen (je länger der Zeitraum, um so besser lassen sich auch „Ausreißer“ feststellen) und eine automatisierte Auswertung bewerkstelligen.

Propagation Tests

Angelehnt daran lassen sich weiterhin sogenannte „Propagation Tests“ durchführen. Diese waren unter FRS als „Canary Tests“ bekannt, was auf eine alte (nicht gerade vogelfreundliche) Methode zum Prüfen des Sauerstoffgehalts im Bergbau zurückgeht. [8]  Im Grunde geht es dabei unter DFS-R darum, eine Datei im entsprechenden Replikationsordner abzulegen und dann zu prüfen, ob diese Datei auf allen Replikationspartner ankommt und in welcher Zeit. Ein Propagation Test läßt sich über die folgenden Kommandozeile aufrufen (Parameter sind je nach Umgebung anzupassen):

C:\> dfsrdiag propagationtest /RGName:test1 /RFName:test1 /TestFileName:TEST.XML

Nach etwas Wartezeit kann man nun mittels...

C:\> dfsrdiag propagationreport /RGName:test1 /RFName:test1 /TestFileName:TEST.XML /ReportFileName:C:\TEMP\PropagationReport.xml

...die Reportgenerierung anstoßen und neben der Zusammenfassung in der Kommandozeile die Datei PropagationReport.xml auswerten. Auch dies kann automatisiert erfolgen, wenn ein entsprechender XML-Parser zur Verfügung steht. Hierzu kann man übrigens auch die PowerShell verwenden [9].

C:\> dfsrdiag propagationreport /RGNAME:test1 /RFNAME:test1 /Reportfilename:C:\TEMP\Report.xml /TestFileName:TEST.XML

PROCESSING MEMBER DBW2K3R201 [1 OUT OF 2]

PROCESSING MEMBER DMW2K3R201 [2 OUT OF 2]

Total number of members            : 2
Number of disabled members         : 0
Number of unsubscribed members     : 0
Number of invalid AD member objects: 0
Test file access failures          : 0
WMI access failures                : 0
ID record search failures          : 0
Test file mismatches               : 0
Members with valid test file       : 2


Operation Succeeded

Hier zur Ansicht die Datei im Pfad  C:\TEMP\PropagationReport.xml: (Klick öffnet die Datei als einfachen Text)

Die Propagation Dateien / Verzeichnisse sollten nach Möglichkeit nach Abschluß des Tests wieder entfernt werden, was sich durch die folgende Kommandozeile erreichen läßt:

C:\> dfsrdiag propagationtest /RGName:test1 /RFName:test1 /TestFileName:TEST.XML /Cleanup

Backlogs

Als weitere Möglichkeit zur Überwachung des DFS-R Status’ als auch Basislinienerstellung steht die Überprüfung der sogenannten Backlogs zur Verfügung. Die Backlogs sind - einfach gesprochen - die Dateien, die zum jeweiligen Zeitpunkt auf Abarbeitung, also auf die Replikation warten. Je nach Umgebung kann das Backlog sehr klein sein (wenn nicht gar gleich „0“) oder aber recht groß. In jedem Fall sind Backlogs vorhanden, sollte der Schedule nicht 24 Stunden geöffnet sein und in der Zwischenzeit Daten geändert werden.

Zieht man nun zu festgelegten Zeitpunkten die Backlogs für die Replikationsordner und Replikationsgruppen, bekommt man über einen längeren Zeitraum einen sehr guten Überblick über das Replikationsgeschehen. Auch hier gilt: Je länger Daten im „Normalzustand“ gesammelt werden und damit zur Analyse zur Verfügung stehen, um so besser lassen sich Probleme feststellen. Es ist hier sinnvoll, am Tag mehr als einmal die Backlogs auszuwerten. Mindestens 1x während der Hauptbetriebszeit und 1x in der Nacht bzw. Nebenbetriebszeit sollten die Backlogs ausgegeben werden. In Internationalen Unternehmen sind die Grenzen natürlich nicht fest zu ziehen, jedoch lassen sich auch hier definierte Intervalle setzen.

Die Backlogs lassen sich beispielsweise über das folgende Kommando anzeigen (Parameter sind selbständig anzupassen oder wie oben angemerkt über ein Script zu generieren):

C:\> dfsrdiag backlog /RGName:test1 /RFName:test1 /SMem:DMW2K3R201 /RMem:DBW2K3R201

Die Ausgabe sieht dann in etwa wie folgt aus, wobei im Grunde der 1. Zeile der Ausgabe die meiste Bedeutung zukommt, da hier die Anzahl der Backlogs aufgeführt ist. Ggf. kann man hier nur die Anzahl ausfiltern, ohne die Dateiliste zu speichern.

C:>dfsrdiag backlog /RGName:test1 /RFName:test1 /SMem:DMW2K3R201 /RMem:DBW2K3R201

Member  Backlog File Count: 110
Backlog File Names (first 100 files)
     1. File name: dfsrtest1.txt
     2. File name: dfsrtest2.txt
[…]
     99. File name: dfsrtest99.txt
     100. File name: dfsrtest100.txt

Operation Succeeded

Interessant wird es übrigens, wenn man der Kommandozeile den Parameter „/v“ hinzufügt:

C:\> dfsrdiag backlog /RGName:test1 /RFName:test1 /SMem:DMW2K3R201 /RMem:DBW2K3R201 /v
[INFO] Computer Name: dmw2k3r201
[INFO] Computer DNS: dmw2k3r201.forest1.test
[INFO] Domain Name: forest1
[INFO] Domain DNS: forest1.test
[INFO] Site Name: Munich
[INFO] Computer Name: dbw2k3r201
[INFO] Computer DNS: dbw2k3r201.forest1.test
[INFO] Domain Name: forest1
[INFO] Domain DNS: forest1.test
[INFO] Site Name: Berlin
[INFO] Connected to WMI services on computer: dbw2k3r201.forest1.test
[INFO] Issuing query: SELECT * FROM DfsrReplicationGroupConfig WHERE Replication GroupName="test1"
[INFO] Found DfsrReplicationGroupConfig object, guid: 02BEAE0E-D464-431B-94E5-F0DC9743B00D
[INFO] Issuing query: SELECT * FROM DfsrReplicatedFolderConfig WHERE ReplicationGroupGuid=
"02BEAE0E-D464-431B-94E5-F0DC9743B00D" AND ReplicatedFolderName="test1"
[INFO] Found DfsrReplicatedFolderConfig object, guid: 7736410A-B3F9-463C-A3DE-BDE585472D1F
[INFO] Object Path: DfsrReplicatedFolderInfo.ReplicatedFolderGuid="7736410A-B3F9-463C-A3DE-BDE585472D1F"
[INFO] Invoke GetVersionVector() method on dbw2k3r201.forest1.test
[INFO] Connected to WMI services on computer: dmw2k3r201.forest1.test
[INFO] Invoke GetOutboundBacklogFileCount() method on dmw2k3r201.forest1.test
[INFO] Invoke GetOutboundBacklogFileIdRecords() method on dmw2k3r201.forest1.test

Member  Backlog File Count: 110
Backlog File Names (first 100 files)
     1. File name: dfsrtest1.txt
     2. File name: dfsrtest2.txt
[…]
     99. File name: dfsrtest99.txt
     100. File name: dfsrtest100.txt

[INFO] Execution Time: 0 seconds
Operation Succeeded

Es wird hierbei deutlich, daß sich alle relevanten DFS-R Informationen aus der DFS-R Datenbank über WMIC auslesen lassen. Hierzu folgen später in diesem HowTo noch ein paar Informationen.

Steigen die Backlogs nun im Vergleich zur Basislinie enorm an, kann dies entweder an beabsichtigten größeren Änderungen liegen (z.B. dem Ändern von NTFS ACLs auf Verzeichnissen und Dateien) oder aber auf ein Problem hindeuten. Hier sollte man im Auge behalten, wie sich die Backlogs entwickeln und ggf. Maßnahmen zur Problemeingrenzung bzw. Fehlerbehebung einleiten.

Prüft man die Health Reports, die Propagation Tests und die Entwicklung der Backlogs regelmäßig, bekommt man einen guten Überblick über den DFS-R Status. Weiterhin lassen sich die Basislinien sehr genau auswerten, was neben der konkreten Fehleranalyse auch eine Trendanalyse ermöglicht, etwa wie sich das Replikationsaufkommen im Laufe der Zeit verändert oder wie der zukünftige Speicherausbau / WAN-Ausbau geplant werden muß.

 

© MCSEboard.de, olc

Teil 1 - Die EreignisprotokolleGrundlegende DFS-R Überwachung mit HausmittelnTeil 3 - Bestandsanalyse und Performanceauswertung