Schlagwort: failover

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

HA failover und STP

Eine Verfahrensweise, die ich mir bei Wartungen an ESX Clustern zu eigen gemacht habe, ist HA zu deaktivieren. Insbesondere dann, wenn es sich um Wartungen an der Netzinfrastruktur handelt. Warum eigentlich? HA ist inzwischen ein robuster Dienst und die Netzinfrastruktur sollte ohnehin redundant ausgelegt sein. Die Erfahrung zeigte allerdings, dass trotz aller Redundanz, Arbeiten an der Netzinfrastruktur immer wieder zu unerwünschten Failover Aktionen des HA führten. Dabei versucht z.B. ein Host (vergeblich), die laufenden VMs eines anderen zu starten. „HA failover und STP“ weiterlesen

Veröffentlicht am

vSphere5: Priorisierte I/O Pfade

Im Fall eines Pfadverlustes wählt normalerweise das Path-Selection-Plugin (VMW_PSP_MRU) zufällig einen der verbleibenden Pfade als Alternative. Im VMware vSphere Blog erschien kürzlich ein Artikel, der die Methode der Pfad-Priorisierung unter vSphere5 beschreibt und den VMware KB-Artikel etwas erweitert ausführt. Im Blogartikel wird noch die alte Syntax (4.x) der vSphereCLI verwendet, diese funktioniert nicht mehr bei einem ESXi5.0.0. Aus diesem Grund habe ich unten die aktuelle Syntax angegeben, die auch im KB Artikel genannt wird.

Im Kern geht es darum, daß es drei Kategorien für Pfade gibt:

  • ACTIVE
  • ACTIVE_UO  (active, unoptimized)
  • STANDBY

Die Auswahlreihenfolge ist Active > Active_UO > Standby. Gleichwertige Pfade der selben Kategorie werden weiterhin von VMW_PSP_MRU zufällig ausgewählt. Die Defaulteinstellung der Priorität ist bei allen Pfaden “0” und unterscheidet sich damit nicht vom Verhalten früherer vSphere Versionen.

Wie setzt man die Priorität?

Mittels vSphereCLI können die Einstellungen ausgelesen und neu gesetzt werden. Eine Konfiguration über die GUI ist derzeit nicht möglich.

Achtung! Keine ESXCLI 4.0 Kommandos an einen ESXi 5.0.0 Server absenden!

Die aktuelle Version gibt es bei VMware.

Im folgenden ist [connection] die Verbindungsdaten zum ESXi Server:

--server myserver.domain.com --user root --password mypassword

<vmhba pathname> könnte z.B. so aussehen: vmhba3:C0:T0:L0

# esxcli [connection] storage nmp psp generic pathconfig get -p <vmhba pathname>
# esxcli [connection] storage nmp psp generic pathconfig set -p <vmhba pathname> -c rank=<rank Number>

Alternativ kann der Pfad auch über die NAA-ID (Network Addressing Authority identifier) bestimmt werden.

# esxcli [connection] storage nmp psp generic deviceconfig get --device=<naa.xxx>

Die so eingestellte Priorität des Pfades bleibt auch nach einem Neustart des Hosts erhalten.