Fehlfunktionen sind schlimmer als Ausfälle
Redundanz ist elementar wichtig in virtuellen Umgebungen. Wenn eine Komponente ausfällt, muss eine zweite einspringen und die Funktion übernehmen. Aber was passiert, wenn eine Komponente nicht gänzlich ausfällt, sondern nur nicht mehr richtig funktioniert? In diesem Fall läßt sich die Störung nur schwer erkennen.
Ich wurde kürzlich von einem Freund alarmiert, als er plötzlich den Zugriff auf alle Freigaben seines (virtuellen) Fileservers verlor. Ich verband mich mit einer Service Workstation und begann mit dem Troubleshooting. Dies sind die ersten Diagnose-Ergebnisse:
- Der Fileserver reagierte nicht auf ping
- Ping zum Gateway funktionierte
- DNS Auflösung zu den virtuellen Domaincontrollern funktionierte
- Eine Browser-Session zu vCenter scheiterte und die vCenter Appliance antwortete nicht auf ping.
Es handelte sich hier um einen kleinen 2-Knoten Cluster auf vSphere 6.5 U2. Vielleicht war ein ESX ausgefallen? Aber dann hätte HA alle betroffenen VMs auf dem verbleibenden Host neu starten müssen. Und das war offensichtlich nicht der Fall. Ich schickte ping Anfragen an beide ESXi Hosts und erhielt von beiden Antwort. Nein, das sah nicht nach einem Host Crash aus.
Als nächstes verband ich mich mittels Hostclient direkt zu den ESXi Hosts. Alle VMs waren aktiv. Ich öffnete eine vSphere-Konsole zur Fileserver VM, konnte mich aber nicht mit Domänen-Login anmelden. Mit einem lokalem Konto funktionierte es. Der Fileserver sah von innen gesund aus munter aus und alle Freigaben waren vorhanden.
Spätestens jetzt wurde klar, dass es sich um ein Netzwerk Problem handeln musste. Jedoch waren alle Uplinks aktiv und verbunden. Wo ist also das Problem?
Ich fand eine VM, welche auf ping reagierte und Verbindung zum Internet hatte und sich auf dem selben Host befand wie Fileserver und vCenter. Ich öffnete eine RDP Sitzung zu dieser VM und konnte von dort alle anderen VMs des Hosts über ping erreichen. Sogar der Webclient von vCenter war erreichbar. Jetzt wurde das Bild klarer. Einer der physischen Uplinks musste ein Problem haben. Nur welcher?
ESXTOP ist Dein Freund
Der Uplink vmnic0 wurde für das Management Netzwerk (PG0) verwendet. Die Uplinks vmnic1 und vmnic2 nur als Standby. Die Portgruppe VM-Network (PG1) verwendete vmnic1 und vmnic2 als aktive Ports, vmnic0 nur als Standby.
Um herauszufinden, welche VM welchem Uplink zugeteilt ist, kann man das Tool esxtop auf der Shell verwenden. Dazu öffnet man eine SSH-Verbindung und gibt esxtop ein. Nachdem das Tool gestartet wurde, wechselt man mit der Taste “n” in die Netzwerk-Ansicht.
Etwa die Hälfte der VMs verwendeten vmnic1 und die andere Hälfte vmnic2. Es stellte sich sehr schnell heraus, dass alle VMs auf vmnic2 keinerlei Verbindungsprobleme hatten, während VMs auf vmnic1 von der Außenwelt abgeschnitten waren.
Solange aber vmnic1 im Status “Verbunden” bzw. “up” ist, werden VMs keinen Netzwerk Failover zu einem anderen Uplink machen. Ich deaktivierte also den physischen Switchport, mit dem vmnic1 verbunden war. Sofort wechselten alle VMs zu vmnic2 und alles funktioniette wieder normal.
Gegenmaßnahmen
Die Fehlererkennung auf dem vSwitch war eingestellt auf “Link Status” bzw. “link state only”. Das ist eine einfache und unkomplizierte Methode, um den physischen Uplink zu überwachen. Es sagt aber nichts über den logischen Verbindungsstatus aus. Eine Unterbrechung kann möglicherweise weiter Stromabwärts im LAN auftreten. Zum Beispiel durch einen Linkverlust zwischen zwei Switches. Dadurch bleibt der Linkststus aktiv, kann aber keine Daten weiterleiten.
Nur den Linkstatus zu überwachen ist in manchen Fällen nicht hinreichend. In jüngster Vergangenheit hatte ich mehr als einmal Probleme mit gestörten NIC Ports, deren Status als “aktiv” angezeigt wurde.
In zweien meiner kürzlich veröffentlichten Blogartikel “ESX physische Uplinks gegen Pfadausfall sichern” und “ESX physische Uplinks gegen Pfadausfall sichern (Teil 2)” diskutiere ich Methoden, um den vSphere Netzwerkverkehr gegen weiter entfernte physische Ausfälle zu härten.