End2End Service

Dies ist eine Ideen-Seite und noch kein realisiertes Skript

Immer wieder werden ich mit Problemen bezüglich Performance konfrontiert, die sich mit Stichproben einer Messung nicht erfassen lassen. Selbst langlaufende regelmäßige Messungen von Performancedaten  bewegen sich fast immer im Bereich von Minuten. Die Auflösung ist für kurze aber störende Ausfälle nicht fein genug. Diese Lücke soll dieser Dienst schließen.

Problemstellung

Server stellen Dienste bereit und Netzwerke transportieren die Daten. Auf der einen Seite liefen die Daten also auf müssenspeichern und werden über das "Storage-Netzwerk" zur Verarbeitung übertragen und dann über das "Daten-Netzwerk" zum Verbraucher. Das ganze muss möglichst verzögerungsfrei erfolgen. Die meisten Firmen müssen dazu z.B. die "Queue-Länge" von Festplatten oder die Auslastung ihres Netzwerks per SNMP. Wenn die Queue-Länge kurz oder das Ethernet wenig belastet erscheint, wird davon ausgegangen, dass auch die Latenzzeit gering ist. Die Latenzzeit selbst lässt sich von "außen" aber nur sehr schwer müssen. Welche Software schaut denn "Permanent" und in "Echtzeit" auf dem Netzwerk sich schon die Pakete an und sucht die Antwort darauf um dann die Laufzeit bzw. Verzögerungen zu ermitteln?. Die Applikation selbst wäre der beste Platz solche Messwerte zu erfassen und bereit zu stellen. Leider passiert das in den seltensten Fällen. Oder die Daten sind bereitgestellten Daten sind oft nur eine Momentaufnahme zum Zeitpunkt der Messung. Exchange z.B. generiert zumindest in einigen schweren Problemfällen eine Eventlogmeldung, dass eine Disk zu langsam war.

Ich hatte mal Support Case, wo die Mitarbeiter sich über eine Sanduhr im Windows Explorer beschwert haben und letztlich ein Dauertest mit End2End-File eine veraltete FirmWare auf einer Festplatte im SAN als Ursache einkreisen konnte.

Durch die Virtualisierung (HyperV, VMWare, Xen) wird das Feld nicht einfacher, da damit Netzwerklink und Storage-Anbindung nicht mehr dediziert für den Server bereit stehe, sondern meist gemeinsam genutzt werden. Die Performance eines Servers hängt damit auch von den IO-Anforderungen der benachbarten Systeme ab, die ebenfalls stark schwanken können. Natürlich bieten auch die VM-Hosts entsprechende Messwerte an. Oft hat der Betreiber des Gast-Systems aber keinen Zugriff darauf oder die Messwerte des Hosts sind ebenfalls nur Mittelwerte über längere Zeiträume.

Lösungsansatz

Auf den anderen Seiten zum Thema Ende2Ende Monitoring (End2End-File, End2End Mailbox, End2End-Ping) habe ich schon den Sachverhalte ausführlicher beschrieben und auch kleine Tools für den "AdHoc"-Einsatz bereit gestellt. Aber für den Dauerbetrieb muss es natürlich ein Dienst sein.

Die Lösung sollte folgende Anforderungen erfüllen:

  • Single-EXE kein Installer
    Die Lösung ist so einfach, dass Sie eigentlich nicht noch mit einem MSI-Overhead versehen werden muss. Ein Admin sollte es schon selbst schaffen, eine EXE auf eine System zu starten oder mit einem Parameter dann auch zu installieren.
  • Interaktiv oder als Windows Service
    Die EXE sollte man einfach interaktiv starten können und eine Hilfe ausgeben. Wenn ich Sie als Dienst installieren möchte, dann wären die üblichen Parameter "-install" und "-uninstall" angesagt. Die Angabe von "-verbose" oder "-debug" würde eine detaillierte Ausgabe erzwingen. Ansonsten sollte der Dienst den Start und die Alarme auf der Console protokollieren
  • DEBUG-Interface
    Mit dem Sysinternals-Tool "DebugView" kann man die Windows Debug Schnittstelle öffnen. Das Programm könnte also detailliertere Meldungen einfach dorthin senden.
  • Netzwerk-IO: ICMP Ping zum Gateway
    Ohne Konfiguration kennt das Programm keine Gegenstellen und es gibt auch nur wenige ECHO-Gegenstellen. Das Programm sollte daher das lokale Default-Gateway, welches ja in der Regel schnell angebunden ist, einfach per ICMP-Ping ansprechen. Einen 100Byte-Ping alle 0,1Sek sollte nicht viel mehr als 1kBit/Sec erzeugen und weder den Host noch den Router überfordern.
  • Disk-IO: kleine Testdateien schreiben und lesen
    Dann sollte das Programm alle lokalen Partitionen ermitteln und auf jeder eine kleine Datei anlegen, die es permanent schreibt und liest. Ich denk da z.B. an eine 100 Byte Datei, die 10mal/Sek (synchron, also ohne Cache) geschrieben und gelesen wird. Eine Dauerlast von 100KBit sollte ein Storage-System nicht stören und selbst mit einer SSD wären das das weniger als 100MB/Tag und sollte also die Lebensdauer einer SSD im Serverbetrieb nicht extrem verzögern. Wobei ich hier nun außer acht gelassen habe, dass Systeme auf der einen Seite dennoch mit einem "Cache" arbeiten und je nach Blocksize mehr Daten real geschrieben werden. Zudem darf sich das Programm nicht auf "Laufwerksbuchstaben" beschränken, da es dann die Mountpoints übersehen würde.
  • Messen von Mittelwerte und Extremwerte
    Das Programm sollte für Netzwerk und Disk die Laufzeiten und Varianzen (Jitter) müssen und dazu Mittelwerte mitführen, z.B. anhand der letzten 10 Messungen. Immer wenn ein einzelner Weg z.B. 10mal so lange braucht als der Mittelwert, wäre dies eine aktive Meldung. Es geht hier wirklich nur um die Erkennung von solchen Peaks, die mit dem klassischen Monitoring nicht erkannt werden. Wenn sich der Mittelwert über Stunden hinweg verschiebt, dann sollte dies auch ein klassischen Monitoring auslesen können.
  • Meldungen im Eventlog
    Auf der Windows Plattform wäre ein Eventlog-Eintrag der passende Ort um die Überschreitung einer Grenze zu melden. Dort sollte sich der Dienst idealerweise ein eigenes Eventlog anlegen und dort Start, Beendigung, regelmäßige Lebenszeichen und natürlich Alarme melden.
  • Performance Counter
    Zusätzlich sollte das Programm die Messwerte natürlich auch selbst als Performance Counter bereit stellen, so dass ein klassisches Monitoring ebenfalls die Daten auswerten kann. Hier wäre dann natürlich der jeweilige aktuelle Mittelwert aber auch die Maximalwert der letzten 5 Minuten und die Anzahl der Alarme in den letzten 5 Minuten interessant. 5 Minuten ist meist das Intervall von klassischen Überwachungslösungen zur Auswertung. Zudem sollte jeweils ein "Total-Counter" vorhanden sein, da viele Produkte den Messwert aus der Differenz zwischen zwei Messungen (Messwert und Zeit) errechnen können.

All diese Funktionen können komplett ohne weitergehende Konfiguration genutzt werden, d.h. einfach Programm starten oder als Dienst installieren und warten. Im Eventlog sollte sich dann die Werte und Alarme zeigen.

Mittelfristig wäre es natürlich schon interessant, wenn dieser Dienst speziell im Bereich "Netzwerk" noch mehr Funktionen bereit stellen kann. Aktuell testet er ja nur den LAN-Link bis zum nächsten Gateway. Interessant wäre schon die Konfiguration von anderen Gegenstellen, um die Laufzeit von Paketen dorthin zu erkennen. Dazu wäre aber ein Wechsel von ICMP z.B. auf UDP wünschenswert um z.B. auch QoS-Tags zu nutzen. Dann reichen aber vermutlich Eventlogs und Performance Counter nicht mehr aus. Denkbar wäre z.B.

  • Zentrale Konfiguration
    Über eine DNS Abfrage nach z.B.: "end2end.<dns-domain>" könnte das Programm ermitteln, dass es einen zentralen Service gibt, der Anweisungen verteilt
  • Aufträge per und HTTP-GET
    Wenn der Name per DNS erreichbar ist, könnte das Skript sich per HTTPGET von diesem System einfach die Konfiguration als XML-Datei ziehen, in der z.B. drin steht, welche Tests gegen welche Gegenstelle ausgeführt werden sollen. Natürlich sollte das Programm dieses Befehle nicht endlos abarbeiten, sondern z.B. alle 10 Sek immer wieder nachfragen, ob diese noch aktuell sind und bei Nichterreichbarkeit des Dienstes wieder auf den einfachen Mode zurückfallen. Das kann durchaus als "Sicherung" verstanden werden, z.B. wenn konfigurierte Tests die Bandbreite überlastet, dass dieser Zustand nicht eine Anpassung der Konfiguration verhindert.
  • Status und Rückmeldung
    Wenn es schon einen zentralen "Controller" gibt, der regelmäßig gefragt wird, dann könnte das Programm auch gleich die Ergebnisse zurück senden, z.B. im Rahmen des HTTP-GET.

Dann fehlt "nur" noch eine Ablage der Daten in einer Datenbank, die grafische Aufbereitung der Ergebnisse und eine grafische Konfiguration der Aufträge. Denkbar wäre natürlich auch die Bereitstellung dieser Funktion als "Cloud Service", d.h. der Controller und die Auswertung erfolgen in der Cloud und die lokalen Programme prüfen intern die Verbindungen. Die Abfrage könnte dann z.B. per MAC-Adresse als "ID" und dem Servernamen als Kennwort erfolgen, wenn man nicht gleich eine Benutzerverwaltung einbauen möchte. Sicher fehlt noch einiges mehr, um eine ganze Menge von Studenten und Praktikanten zu beschäftigen.

Auswertung

Wenn wir aber erst mal bei der Basisfunktion bleiben, dann generiert das Programm im Fehlerfall natürlich Eventlog-Einträge und erweitert die Windows Performance Counter um die gemessenen Werte. Diese Daten können lokal auf dem "verdächtigen" Server im Rahmen der Fehlersuche direkt eingelesen und ausgewertet werden. Im ersten Schritt sehe ich den Einsatz dieses Programms auch wirklich auf dieser Ebene einer Stichpunktsucher oder als weitere Quelle, um, ein vorhandenes Management mit zusätzlichen Daten zu erweitern.

Weitere Links