End2End File

Der Auslöser zu diesem Skript war ein älterer Supportfall, bei der ein Kunde sich über "Sanduhren" beim Explorer und beim Speichern von Dateien auf einem Server beschwert hat. Die klassische Kontrolle des Dateiservers mittels Perfmon und anderen lokalen Test (DT Performance Messung etc.) hat insofern nicht geholfen, da die kritischen Kennzahlen alle in Ordnung waren.

Also war eine aktive Langzeitmessung gefragt, bei der permanent eine kleine Grundlast aufgelegt wurde. Und tatsächlich konnte alle 6h eine Unterbrechung von 30Sek gemessen werden, während der aber kein Performance Counter angeschlagen hat. Mit dem Skript wurden dann mehrere Server als Quelle und mehrere Disks als Ziel ausgemessen und so eine bestimmter SAN-Storage isoliert. SAN-Controller und SAN-Switches, Virenscanner, Betriebssystemversionen, Treiber etc. wurden so ausgeschlossen. Letztlich konnte der SAN Storage-Hersteller dann herausfinden, dass wohl eine Festplatte im SAN eine alte Firmware hatte und damit einen Teilbus, damals noch SCSI, alle 6h mit einem Reset für 30 Sekunden blockiert hat. Nach dem Firmware-Update dieser Disk waren die Probleme weg.

Was kann ich müssen und analysieren ?

End2End-File arbeitet anders und versucht gar nicht erst die maximale Leistung eines Systems zu ermitteln, sondern beaufschlagt das System mit einer definierbaren "Grundlast", und ermittelt die Zeiten hierfür. Es ist damit also sehr einfach möglich, von einem Client über das LAN oder lokal auf dem Server permanent eine kleine konstante Last auf dem Server anzulegen und "Aussetzer" zu ermitteln. Bislang hat das Skript mit geholfen bei ...

  • ... SAN-Problemen
    Bei einem Kunden haben sich Anwender über "Stockungen" bei der Arbeit mit "Dateiservern" beschwert. Nachdem Performance-Tests nur maximale Leistung gezeigt haben und das Netzwerk scheinbar "sauber" blieb, konnte mit end2end-file nachgewiesen werden, das immer regelmäßig die Performance für einige Sekunden "0" war. parallel aufgezeichnete Performance Counter und Queues unter Windows haben aber auch hier keinen Engpass angezeigt.
    Nachdem das Skript dann "lokal" auf dem Server gegen die lokalen Disks gefahren wurde, konnte belegt werden, dass auch hier die "Aussetzer" auf den SAN-Disks, aber nicht den lokalen Disks vorlagen. Insofern waren Netzwerk und "Serverdienst" rehabilitiert. Die Gegenprobe auf allen Servern zeigt, dass alle Server am gleichen Storage-Node das Problem hatten. Bei den anderen Servern ist es nur noch nie aufgefallen. Letztlich konnte mit dem Storage-Anbieter eine alte BIOS- Version auf einer Festplatte im SAN ausgemacht werden, die wohl den SCSI-Bus per Reset quasi "angehalten" hat.
    End2End-File hat nach der Korrektur dann auch keine "Aussetzer" mehr gezeigt.
  • WAN-Links
    Immer mehr "Kunden" zentralisieren ihre Exchange Umgebungen. Damit wird die WAN-Bandbreite natürlich wichtig. Eine kleine "Grundlast" von wenigen Prozent der nutzbaren Bandbreite kann mit end2end-file generiert und die Verzögerungen gemessen werden. Dies ist natürlich nicht für den "Dauereinsatz" vorgesehen, aber kann doch kurzfristige Überlastungen melden oder aufzeichnen, um späteren Beschwerden nachzugehen. Besser wäre es hier natürlich per SNMP die einzelnen Schnittstellen der WAN-Verbindung zu überwachen. Aber oftmals lässt der Provider dies nicht zu und bei einem VPN über das Internet können die beiden VPN-Tore nicht viel über die Gesamtperformance anzeigen. Ein einem Fall hat end2end-File sogar wunderbar gezeigt, wie WAN-Optimierer wie Riverbed oder Cisco WAAS-Systeme arbeiten. Dies war auch der Grund, warum Version 1.1 nicht mehr nur liest, sondern auch schreibt.

Es sind also manchmal die einfachen Skripte, die einem bei der Fehlersuche voran bringen.

So funktioniert das Skript

Dazu schreibt End2End-File eine bestimmte konfigurierbare Anzahl an Bytes auf die angegeben Datei (Local oder Netzwerk) und misst die Zeit hierfür. Danach pausiert das Skript für eine ebenfalls einstellbare Zeit um dann den Prozess zu wiederholen. Die Zeitdauer für das Schreiben wird zu einem Mittelwert verrechnet und wenn eine bestimmte ebenfalls konfigurierbare Abweichung vorhanden ist, wird ein Alarm (z.B. im Eventlog) generiert. Zudem werden alle Messwerte in einer CSV-Datei mit protokolliert.

Dieses Skript hat mir schon gute Dienste getan, wenn die Umgebung eigentlich ohne Fehler läuft aber manchmal Verzögerungen zu beobachten sind und Performancecounter oder SNMP-Werte der Switches zu ungenau waren oder nicht zur Verfügung standen.

Die Standardwerte sind wie folgt im Skript definiert. Sie können alle Werte im Skript ändern oder per Kommandozeile überschreiben.

  • Testfilename = ".\end2end-file.tmp"
    Dies ist der Dateiname und Pfad, welcher beschrieben wird.
  • Reportfilename= ".\end2end-file.csv"
    Ausgabe der aktuellen Messwerte als CSV-Datei
  • IdleTime = 100
    Ruhezeit zwischen zwei Schreibvorgängen in Millisekunden
  • Buffersize = 1024
    Größe des zu schreibenden Buffers in Bytes
  • Alarmdelta = 1000
    Maximale Abweichung des Messwerts vom Mittelwert in ms

Mit diesen Werte schreibt das Skript also alle 100ms eine 1KB-Datei. Wenn man die Zeit für das Schreiben als gering ansetzt, dann produziert dieses Skript maximal 10kbyte oder 100kbit/Sek. Ziel des Skript es ja nicht die maximale Leistung zu ermitteln, sondern die Kontinuität. Es liegt an ihnen, die Werte anzupassen. Eine höhere Belastung können Sie durch einen größeren Buffer als auch durch kürzere Pausenzeiten erreichen.

Download und Anwendung

Ursprünglich entstand das Skript als VBScript. Mittlerweile habe ich auf PowerShellumgestellt, die aber von der Funktion her identisch sind. Sie können die Skripte ja vergleichen. Gerade die Verarbeitung von Kommandozeilenparametern ist denkbar einfacher. Auch die Event-Log Ausgabe.

tools/end2end/end2end-file.1.5.ps1.txt

Ich kann zwar das Skript kostenfrei zum Download anbieten, allerdings müssen Sie schon selbst überlegen, von welchen Systemen aus auf welche andere Systeme Sie einen Test laufen lassen wollen und wie Sie die Daten am Ende auswerten und interpretieren. Das Skript misst einfach nur.

Das Skript beschreibt permanent eine 10 Kilobyte Datei und misst die hierfür benötigte Zeit. Um den Server nicht zu überlasten, wird dann eine kurze Pause (100ms) eingelegt, so dass dieses Skript eine Dauerlast von ca. 100kByte/Sek = 1 Megabit produziert. Dies sollte einen aktuellen Server nicht beeinträchtigen. Die benötigte Zeit wird gespeichert und gemittelt, so dass ein "Durchschnitt" vorhanden ist. Weicht ein Zugriff nun sehr stark davon ab, wird die erkannt und eine Meldung hinterlassen.

end2end File

Die Funktion des Skripts ist eigentlich ganz einfach. Um jedoch den Netzwerkzugriff zu testen, muss es auf einem Client oder anderen Server gestartet werden. Soll dies nicht interaktiv erfolgen, muss das Skript mit SRVANY, dem Windows Taskplaner oder anderen Tools als "Dienst" implementiert werden.

Achtung
Um in das Eventlog zu schreiben, muss das PowerShell-Skript als Administrator laufen oder Sie vergeben explizit die Berechtigungen. Solche Dinge übernimmt bei Programmen in der Regel die Setup-Routine.

Weitere Links