Tipps und Strategien zur Fehlersuche in VMware vSphere

    Problem - Analyse -LösungBei der Fehler­suche in kom­plexen IT-Infra­strukturen muss man sich unab­hängig von Art, Tools-Chain und Her­steller eine strin­gente Methodik ange­wöhnen, um sich nicht zu ver­zetteln. Dazu zählen Top-Down- und Bottom-Up-Ana­lysen. Wie das in einer vSphere-Umgebung aus­sehen könnte, zeigt dieser Beitrag.

    Nahezu alle IT-Infra­strukturen lassen sich in ver­schiedene Abstraktions­ebenen zerlegen. Selbst wenn man sich nur auf einer davon bewegt, wie etwa dem zugrunde­liegenden Netzwerk, lässt sich dieses in weitere Schichten aufteilen, deren Kenntnis im Rahmen des ISO/OSI-Modells auch bei der Fehlersuche hilft.

    Beispiel für ein Netzwerkproblem

    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.

    Schichten einer virtuellen Infrastruktur und mögliche Analyseansätze

    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.

    Fehler bei vMotion durch Netzwerkkonfiguration

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

    Eintrag zu vMotion-Fehler in der Logfile

    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?

    Top-Down-Fehlersuche in VMware vSphere

    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.

    Keine Kommentare