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

Upgrade ESXi 6.5 mit Fujitsu Custom Image

Konflikt mit VIB

Host Upgrade mit angepassten ESXi Images (sog. Custom Images) bieten ein erweitetes Angebot an Treibern und Hardware-spezifischen Agenten. Somit werden etwa Treiber bereitgestellt, die im VMware Standard („Vanilla“) Image nicht vorhanden sind, oder ein erweitetes Monitoring der Hardware mit Agenten ist möglich. Führt man Upgrades von Customized Installationen durch, kommt es immer wieder zu Konflikten mit existierenden Paketen. Ein bekanntes Beispiel aus der Vergangenheit war der LSI-Provider in Fujitsu-Images beim Upgrade auf Version 5.1 oder der Tod durch Upgrade auf Version ESXi 6.0 mit Fujitsu Custom Images. Die Hall of Shame ließe sich beliebig erweitern. Auch andere OEM Hersteller sind hier nicht beser. „Upgrade ESXi 6.5 mit Fujitsu Custom Image“ weiterlesen