Wieder ist eine Dienstleistung abgeschlossen. Das Problem wurde gefunden und der Kunde ist glücklich. Für den Kunden war es ein längerer Leidensweg, da die Probleme schon eine geraume Weile zwischen dem Lieferanten der Software, dem Server Betreiber, den Anwendungsbetreuern und den Netzwerkverantwortlichen verschoben wurde. Da die Umgebung auch keine simple Client zu "Single Server" Anwendung war, sondern deutlich komplexer, wählten wir den Weg des Ausschlussverfahrens. Komplex daran war: ESX Server auf 2 Blade Systemen, mit jeweils 2 virtuellen Servern und mehreren einzelnen verteilten Anwendungsdiensten. Das Ganze in einem MS Cluster, der aus VM Sicht und MS Clustersicht beliebig verteilt werden konnte. Natürlich alles doppelt redundant angeschlossen.
Wir setzten GeNiEnd2End Application ein, um die sporadischen von den Anwendern beschriebenen Probleme sichtbar zu machen. Des Weiteren nutzen wir GeNiEnd2End Network, um die Netzwerk Infrastruktur aus Sicht der Ende-zu-Ende Qualität zu betrachten.
Wie meistens üblich, ist es selten ein einziges großes Problem, sondern es sind viele kleine Probleme, die ein Problem groß werden lassen.
So stellte sich heraus, dass die Anwendung in der Tat sporadisch deutlich längere Transaktionszeiten aufwies. Aber auch das Netzwerk war nicht fehlerfrei. Die zentrale WAN Strecke wies Paketverluste auf. Außerdem kam die gemessene Anwendungstransaktion ins Stocken, weil lokale sowie remote angebundene Arbeitsplätze durch nur 1-2 verlorene Pakete statt einer Sekunde 2,5 Sekunden brauchten.
Die WAN Strecke wurde durch neue Router getuned, was zu einer deutlichen Verbesserung der nutzbaren Bandbreite, aber auch zum Wegfall aller Paketverluste führte.
Um die Ursache und den Ort der Paketverluste im LAN weiter einzuschränken wurde GeNiEnd2End Multitrace eingesetzt. Damit war es nun sehr einfach möglich eine 3 Punkt Zangenmessung auszuführen und eine Problem-Transaktion zu untersuchen. Die Zangenmessung wurde auf dem VM Gast, am Serverswitch via SPAN und am Client aufgesetzt. Die Untersuchung ergab, dass die Pakete zwischen Serverswitch und VM Gast verloren gingen.
Diese Verluste wurden auch durch die Messung mit GeNiEnd2End Network bestätigt. Hier waren ebenfalls Paketverluste über den ganzen Zeitraum der Messung zwischen Serverswitch und vServer messbar.
Es folgten nun einige Versuche der Serverleute das Problem weiter einzugrenzen. Die Kontrolle oblag jetzt nur noch GeNiEnd2End Network und GeNiEnd2End Application – durch diese Tools erhielten wir eine Analyse mit nur minimalen Aufwand im einstelligen Minutenbereich! Alle Änderungen, z.B. vMotion nutzen, um das andere Blade zu testen oder Switch innerhalb des MS Clusters, brachten leider keinen Erfolg.
Letztendlich gelang eine Besserung durch den Tausch der virtuellen Netzwerkkarte innerhalb des VM Gastes.
Die Messungen zeigten nun, dass durch diese Änderung keine Verluste von Paketen innerhalb der VM mehr auftraten.
Somit wurde dieses Problem mit vergleichbar wenig Aufwand identifiziert und schlussendlich in der richtigen Abteilung behoben.