Teil 5 - Zugelassene DateitypenWeiterführende DFS-R Konfiguration unter Windows Server 2003 R2Teil 7 - Schlusswort, Quellen und Links

Teil 6 - Diagnoseberichte

Autor: olc, MCSEboard.de

 

Microsoft verfolgt seit geraumer Zeit die Strategie des Einsatzes von Diagnoseberichten (je nach Produkt auch „Health Reports“ oder „Best Practice Analyzer“) in diversen Produkten und Produktlinien.

Diese Berichte sind sehr strukturiert und stellen neben den Konfigurationsdaten der Systeme bzw. Dienste mögliche Probleme oder Fehler dar und geben Hinweise zur Lösung dieser Probleme. Oftmals werden diese Programmroutinen sogar Online-Updates unterzogen, so dass bei neu bekannt gewordenen Problemen oder neuen Patches die Diagnoseberichte neue Informationen anzeigen und somit immer aktuell sind.

In immer komplexer werdenden Systemumgebungen wird den Administratoren so ein Werkzeug an die Hand gegeben, mit dem sie sich nicht nur einen gut strukturierten Überklick über ihr System verschaffen können, sondern auch neue „Problemdefinitionen“ aktualisiert auf den Schirm bekommen.
Des Weiteren geben die Diagnoseberichte Hilfestellung zur Problemlösung, sollte auf den Systemen aktuell ein Fehler festgestellt werden.

Die DFS-R Diagnoseberichte (Health Reports) sind eine gute Möglichkeit, viele interessante und auch für den DFS-R Betrieb relevante Daten darzustellen und dem Administrator eine Übersicht zu geben, was in seiner DFS-R Umgebung passiert.

Eine gute Vorgehensweise zur Sicherstellung der Funktionsfähigkeit der DFS-R Umgebung ist es, die Health Reports beispielsweise mittels dfsradmin täglich automatisch generieren zu lassen und diese dann etwa auf einem Netzlaufwerk ablegen zu lassen oder aber per E-Mail zuzustellen. Für eine Zustellung per E-Mail ist jedoch (derzeit) eine Drittapplikation notwendig. Ab Windows Server 2008 wird es dafür voraussichtlich integrierte Varianten geben.

Beispielhaft schauen wir uns einen Health Report einer Replikationsgruppe namens „B-B_Marketing“ an. Es werden einige Daten nur kurz angesprochen, das Prinzip hinter den Reports sollte jedoch klar werden.

In Abbildung 09 ist der geöffnete Health Report zu sehen. Im oberen Bereich sind die Eckdaten der Replikationsgruppe zusammengefasst, so der Name der Replikationsgruppe, das Referenzmitglied etc. Weiterhin gibt es eine Übersicht über die Effizienz der Replikation, d.h. um wie viel Prozent der zu replizierenden Datenmasse konnte DFS-R den Replikationsverkehr verringern. Das bedeutet, dass unter Zuhilfenahme von RDC nicht alle Daten übertragen werden mussten, sondern nur die Deltas und dass die Daten außerdem gepackt übertragen wurden. Somit ist in dem Beispiel eine Einsparung von über 77% der Daten erreicht worden.

Im nächsten Teil des Reports „FEHLER“ werden mögliche Fehler bzw. Fehlerquellen aufgeführt.
In dem Beispiel ist ein Patch auf beiden Servern nicht installiert und auf einem Server startet der DFS-R Dienst sehr häufig neu. Hier sollte also überprüft werden, was die Ursache dafür ist.

Thema Patches
Microsoft stellt auf einer Webseite [8] Informationen zu alten und neuen DFS-R relevanten Hotfixes zur Verfügung. Es ist dringend anzuraten diese Hotfixes bzw. neue Hotfixes ebenfalls zeitnah zu installieren. In der Praxis zeigt sich erfahrungsgemäß, dass viele DFS-R Fehler durch die Installation der Hotfixes behoben werden bzw. vor neuen Problemen schützen. Wichtig dabei ist alle Server auf dem gleichen Patchlevel zu halten, also nach Möglichkeit nicht nur ein paar DFS-R Server mit Patches zu versorgen und andere nicht.

In der nächsten Sektion des Berichtes „WARNUNGEN“ sind die nicht ganz so kritischen Probleme oder Hinweise aufgeführt. Auch hier sollte sichergestellt werden, dass die Daten überprüft und gegebenenfalls in Ordnung gebracht werden.

In unserem Beispiel sind Daten der Initialreplikation noch immer auf dem „Slave-Server“ vorhanden, die Speicherplatz rauben. Es sollten in diesem Fall jedoch nicht nur die Daten gelöscht werden – vorher sollte überprüft werden, ob diese Daten nicht fälschlicherweise in der Verzeichnissen lagen bzw. ob diese Daten unter Umständen noch benötigt werden. Andernfalls löscht man diese leichtfertig und stellt erst später den Datenverlust fest.

Mit Bezug auf die oben erwähnte wichtige Quota Grenze ist diese Warnung in keinem Fall zu ignorieren. Ist eine Menge Speicher durch die Daten belegt, könnte die Festplattenkapazität unter Umständen nicht ausreichen und somit irgendwann die Festplatten vollaufen. Das führt unter ungünstigen Umständen zu massiven Produktionsstörungen und sollte daher von vornherein vermieden werden…

Die „Fehler“ und „Warnungen“ sind im HTML-Report Links, d.h. sie können angeklickt werden. In diesem Fall öffnet sich direkt der untere Teil des Health Reports und man springt direkt zur Problembeschreibung - ein sehr praktisches Feature.

Abb. 09
Abb. 10

Schaut man nun in die Fehlerdetails (siehe Abb. 10), erhält man zusätzliche Informationen zu den gemeldeten Fehlern und Warnungen. Diese sind in vielen Fällen mit Online Ressourcen verknüpft, so dass man direkt zu weiteren Informationen im (Microsoft) Web gelangt.
In unserem Beispiel kann man den Link anklicken, um direkt zum KB-Artikel und damit zum Download des fehlenden RPC-Patches zu gelangen.

Abb. 11

Eine gute Zusammenfassung und Übersicht der Replikationsdaten bieten die „INFORMATIONEN“ des Health Reports, die die in Abbildung 11 nur auszugsweise angezeigt werden. Man erhält einen Überblick über die Laufzeit des Replikationsdienstes, über die Einsparungen bei der Datenübertragung und über die Festplattenkapazität etc.
Wichtig hierbei ist, dass die Daten zur Anzahl der Dateien im jeweiligen Replikationsordner nur angezeigt werden, wenn man beim Erstellen des Reports in den Optionen mit angibt, dass die Daten gezählt werden sollen. Hier sollte man Vorsicht walten lassen – bei einigen Terabyte an Daten innerhalb der Ordner kann das schnell zu einer starken Auslastung der Server kommen und einige Zeit dauern.

Die angezeigten und errechneten Daten werden allerdings bei einem Neustart des DFS-R Dienstes auf „NULL“ zurückgesetzt. D.h. man bekommt unter Umständen auf zwei Replikationspartnern bezüglich einer Replikationsgruppe unterschiedliche Daten. Hier sollte man prüfen, welche Daten aktueller sind, um nicht unnötig verwirrt zu werden.

 

© MCSEboard.de, olc

Teil 5 - Zugelassene DateitypenWeiterführende DFS-R Konfiguration unter Windows Server 2003 R2Teil 7 - Schlusswort, Quellen und Links