Autor: Michael Schroeder

Veröffentlicht am

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

Veröffentlicht am

Problem mit Emulex OneConnect OCe14000 NIC LoM

Troubleshooting mit Treiber, Firmware und ESXi Versionen

Hardware Ausfälle sind in vSphere Clustern in der Regel keine große Sache. Nahezu jede Komponente ist redundant ausgelegt und bei Ausfall springt ein Ersatz ein. Schwieriger wird es, wenn eine Komponente nicht komplett ausfällt, sondern Fehlfunktionen zeigt. Ein so genannter Zombie ist viel kritischer, als ein Ausfall. Die Ersatzkomponente wird unter Umständen nicht einspringen, so lange noch irgendwelche Lebenszeichen von der gestörten Komponente kommen.

Ein solches Szenario erlebte ich bei dem geplanten Neustart eines Top-of-Rack (ToR) Switches. Der angeschlossene 10 Gbit Port eines ESXi Servers wurde nachhaltig gestört, aber er ist nicht ausgefallen.

Die aktiven Link-LEDs trotz entferntem Kabel sind ein untrügliches Kennzeichen, dass hier etwas nicht in Ordnung ist.

„Problem mit Emulex OneConnect OCe14000 NIC LoM“ weiterlesen

Veröffentlicht am

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

Veröffentlicht am

VMs ohne Tag emitteln

Backup-Tag SLA überprüfen

VMware Tags bieten vielseitige Möglichkeiten, VMs dynamisch anhand ihrer Tags zu gruppieren. Ein Anwendungsfalls sind die Verwendung von Backup-Tags, um Backup-SLA zu gewährleisten. In meinem Fall gibt es eine Kategorie mit Namen „Backup“ und darunter mehrere SLA-Tags für wöchentliche, oder tägliche Backups.

Oneliner

Mittels PowerCLI lässt sich schnell ermitteln, welche VM keinen Tag gesetzt hat.

connect-viserver myVC
get-vm | ?{ (get-tagassignment $_) -eq $null}

Diese Abfrage ist aber noch nicht hinreichend. Sie ermittelt nur, welche VMs KEINE Tags haben. Ich möchte jedoch erfahren, welche VMs keine Tags der Kategorie „Backup“ haben. Wir müssen dazu unsere Abfrage etwas anpassen.

get-vm | ?{ (get-tagassignment $_ -category Backup) -eq $null}

Die Kategorie „Backup“ ist mit der jeweilig verwendeten Namensgebung anzupassen.