Tipps und Strategien zur Fehlersuche in VMware vSphere

Ob man sich dabei am ISO/OSI-Modell mit seinen 7 Schichten oder dem Internet/DOD-Schichten­modell mit 4 Ebenen orientiert, ist gar nicht so entscheidend. Wichtig ist aber in jedem Fall beurteilen zu können, ob bei der Ursachen­forschung eine Top-Down-, Devide and Conquer- oder Bottom-Up-Analyse sinnvoller ist.

Reagiert beispiels­weise ein Web-Server nicht auf Anfragen auf Port 443, lässt sich aber per Ping erreichen (ICMP-Protokoll), dann braucht man den Fehler in Kenntnis des OSI-Modells nicht im Layer-2, etwa bei der Switch-Konfiguration zu suchen.

Schichten einer virtuellen Infrastruktur

Ähnlich verhält es sich in einer Virtua­lisierungs­infrastrukrur wie VMware vSphere. Hier können wir die vier funk­tionalen Ebenen physische Hardware, ESXi-Host, virtuelle Maschine und Anwendung bzw. Guest OS unterscheiden, wie folgende Abbildung zeigt.

Symptomatik

Die größte Schwierigkeit besteht nun darin, ein auftretendes Symptom einer Ursache zuzuordnen. Aufgrund der oben skizzierten Funktions­ebenen lässt sich diese nämlich nicht auf dem ersten Blick eindeutig ausmachen. Daher ist eine stringente Methodologie unbedingt einzuhalten. Eine solche könnte so aussehen:

• Definieren des Problems
• Identifizieren der Ursache
• Lösung implementieren

Problem-Arten

Probleme wiederum lassen sich grob klassifizieren. Typische System­probleme sind etwa

• Konfigurationsfehler
• Ressourcen-Engpässe
• Software-Bugs
• Defekte Hardware
• Netzwerk-Attacken

System­probleme können sich auf zahlreiche Aspekte auswirken, wie die Verwend­barkeit, Korrektheit, Zuver­lässigkeit oder die Performance. Dabei ist es aber leider häufig auf dem ersten Blick so, dass die Symptome das Problem selbst zu sein scheinen. Daher ist das Sammeln von Symptomen immer der erste Schritt zur Problem­behandlung.

Dabei ist zu beachten

• Eine einzige Ursache wird von den Benutzern möglicher­weise in Form mehrerer Symptome gemeldet.
• Die Unter­scheidung zwischen Symptomen und den Haupt­ursache eines Problems ist oft nicht einfach, aber zwingend erforderlich.

Dazu zwei Beispiele:

Symptom	Mögliche Ursache(n)	Wahre Wurzel des Problems
Nutzer kann sich nicht per vSphere Client zu vCenter verbinden	vCenter-Server-Dienst (vpxd) läuft nicht Netzwerkpfad zur vCenter-Appliance ist nicht verfügbar	vCenter-Appliance-Datenbank defekt Der Router, der für die Bereitstellung der Route zwischen dem User-Desktop und dem vCenter-Server verantwortlich ist, ist ausgefallen oder defekt
Eine oder mehrere LUNs auf dem Storage-Array sind auf einem bestimmten ESXi-Host nicht sichtbar	Pfad-Fehler zwischen ESXi-Host und Storage-Array Die LUNs sind nicht sichtbar, weil sie auf dem betreffenden Host nicht korrekt präsentiert werden	Das Netzwerk bzw. der bevorzugte Pfad zwischen ESXi-Host und Storage-Array ist ausgefallen und kein redundanter Pfad verfügbar Am Storage-Array liegt ein Konfigurations­fehler vor, der durch eine kürzlich erfolgte Konfigurations­änderung auf dem Array verursacht wurde.

Fehleranalyse

Ein erster Schritt zur systematischen Fehlersuche besteht dann darin, so viele Informationen wie möglich einzusammeln, die mit dem Problem potenziell im Zusammenhang stehen. Dazu ist es nützlich, sich folgende Fragen zu stellen.

• Kann das Problem reproduziert werden?
• Was ist der Reichweite des Problems? Tangiert es nur ein Objekt oder eventuelle mehrere?
• Bis wann hat das System vorher einwand­frei funktioniert? Falls ja, gab es Änderungen an der Umgebung oder der Konfiguration?
• Handelt es sich um ein bekanntes Problem? Hierzu ist es wichtig, Release Notes, Dokumen­tationen oder die Knowledge Base zu konsultieren. Meist reicht es auch schon, die Fehler­meldung (möglichst auf Englisch) in Google zu suchen.

Darüber hinaus muss man lernen, Fehler- und Diagnose­meldungen in der GUI oder in Log-Files richtig zu interpretieren.

Scheitert beispiels­weise ein vMotion-Vorgang wie in der folgenden Abbildung, dann kann man schon durch aufmerksames Lesen der Fehler­meldung darauf schließen, dass das vMotion-Netzwerk falsch konfiguriert ist. Quell- und Ziel-Host können nämlich nicht über das vMotion-Netzwerk kommunizieren.

Forscht man im Event-Browser des vSphere-Clients etwas tiefer, findet man schnell das folgende zugeordnete Event:

Demnach funken die vMotion-Kernel-Adapter für Quell- und Ziel-Host offenbar nicht im gleichen Subnet (10.0.1.x/ 10.0.8.x), womit keine gültige Route zustande kommt. Einer von beiden muss also umkon­figuriert werden.

Beispiel für Top-Down-Analyse

Spielen wir nun ein Beispiel durch, wie man sich per Top-Down-Analyse zum so genannten Root-Cause vorarbeitet. Angenommen eine virtuelle Maschine antwortet nicht mehr. Wie lässt sich dieses Symptom sinnvoll je einer der vier Ebenen zuordnen?

Das Problem wurde/wird durch eine Opera­tion an/mit der virtu­ellen Maschine verur­sacht, etwa eine vMotion oder einen Snap­shot. Falsch konfi­gurierte Ressource-Steuerung durch Shares oder Limits auf VM-Ebene sor­gen dafür, dass sie zu wenige Ressour­cen er­hält, um zu ant­worten. Es sind nicht mehr aus­reichend Host-Ressourcen wie CPU oder Memory ver­fügbar. Teile der der physi­schen Res­sourcen sind nicht ver­fügbar.

Lösung

Zur Lösung des Problems muss wie beschrieben der Root-Cause, also die wahre Ursache sicher identifiziert werden. Hat man die Ursache ermittelt, muss man die Auswirkungen des Problems auf die bestehenden Betriebs­abläufe bewerten.

Ist die Auswirkung hoch, muss das Problem sofort gelöst werden. Ist die Auswirkung moderat, kann man das Problem beseitigen, wenn das zum gegenwärtigen Zeitpunkt möglich ist. Ansonsten verschiebt man die Lösung auf das nächste Wartungs­fenster, genau wie bei Problemen mit geringen Auswirkungen auf die Betriebsabläufe.

Klassifizierung von Problemen durch VMware

In Bezug auf eine vSphere-Umgebung klassifiziert VMware mögliche Lösungen und deren Auswirkungen wie folgt:

• Eine kurzfristige Lösung ist ein Workaround, der es erlaubt, den Betrieb weiter laufen zu lassen.
• Eine langfristige Lösung würde dann eine Rekonfiguration innerhalb des nächsten Wartungsfensters erfordern.

Dabei muss man die Auswirkung der Lösung auf den laufenden Betrieb im Rahmen der Wirkungs­analyse beurteilen.