ESXi Host Recovery mit Hindernissen

Verbindung mit EVC Cluster scheitert nach ESXi Host Restore

Der Austausch von defekten ESXi Bootmedien wurde inzwischen leider zur Routine. Der Gund sind Flashmedien von schlechter Qualität und daher kurzer Lebensdauer. Man muss hier allerdings fairerweise anfügen, daß einige Kunden günstige USB-Sticks als Bootmedium verwenden. Im Homelab ist das praktisch, im Produktivcluster eine schlechte Idee.

Die übliche Prozedur dafür ist recht einfach:

  • Host Konfiguration exportieren
  • Host räumen und herunterfahren
  • Neues Bootmedium vorbereiten mit einem ISO, das den selben oder einen niedrigeren Patchlevel hat, als die ursprüngliche Installation.
  • Frisch installierten Host booten
  • IP Adresse (temporär) vergeben, falls kein DHCP Server erreichbar ist
  • Hostkonfiguration wiederherstellen
  • Mit Cluster verbinden
  • Fehlende Patches nachinstallieren

So weit, so gut. Aber letzte Woche wurde die Routineaufgabe zur Herausforderung.

„ESXi Host Recovery mit Hindernissen“ weiterlesen

Automatische Segmentierung von VDI Endgeräten

Automatische VLAN Zuordnung und Verwendung eines DHCP Relays

Software Defined Datacenter (SDDC) ermöglichen uns, sehr viele Komponenten innerhalb der Software-Schicht des Hypervisors zu halten. An irgendeinem Punkt muss diese Schicht jedoch verlassen werden, um mit dem Endnutzer in Kontakt zu kommen. Dafür verwendet man üblicherweise Zero- oder Thin-Clients als VDI-Endgeräte. Diese Geräte an sich benötigen eine IP Adresse und müssen im LAN erreichbar sein.

Ich zeige hier ein Beispiel auf, wie Endgeräte automatisch in ein eigenes VLAN und Subnetz separiert werden und dabei dennoch vom zentralen DHCP-Server bedient werden können.

„Automatische Segmentierung von VDI Endgeräten“ weiterlesen

Troubleshooting bei vmnic Störungen

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?

„Troubleshooting bei vmnic Störungen“ weiterlesen

ESX physische Uplinks gegen Pfadausfall sichern (Teil 2)

Was ist beacon probing?

In meinem kürzlich veröffentlichten Blog-Artikel “ESX physische Uplinks gegen Pfadausfall sichern“, habe ich “Link State Tracking ” diskutiert. Eine Methode mit der man den LAN Datenverkehr gegen physische Ausfälle härten kann. Heute möchte ich eine andere Methode der Ausfallsicherung beschreiben, mit der man Uplinks identifizieren kann, die entweder fehlerhaft oder isoliert sind.

Gründe für solche Fehler können zum Beispiel Treiber / Firmware Unverträglichkeiten sein, oder schlicht ein defektes Kabel auf dem Weg zum Coreswitch.

Beacon probing

Beacon probing ist ein Mechanismus, bei welchem der ESX Host im Sekundenabstand Pakete über alle Uplink Ports sendet und kontrolliert, auf welchen anderen Uplink Ports diese empfangen werden. Beacon bedeutet “Leuchtfeuer” und ist eine treffende Bezeichnung. Jeder Uplink sendet Leuchtfeuer aus und empfängt die Signale der anderen Uplinks.

„ESX physische Uplinks gegen Pfadausfall sichern (Teil 2)“ weiterlesen