Nach einem gescheiterten Firmwareupgrade auf den Intel x722 NICs kam der betroffene Host ohne seine 10 Gbit Kerneladapter (vSAN-Network) hoch. Alle Versuche der Wiederherstellung scheiterten und ich musste den Server zu Supermicro einschicken. Klassischer Fall von “bricked device“. Nach Update so funktional wie ein Ziegelstein. Normalerweise wäre das in einem 4-Knoten Cluster keine große Sache. Da aber die Management Adapter funktional waren und die vSAN-Netzwerk Adapter nicht, kam es wohl im Cluster zu Störungen und alle Objekte wurden auf den drei verbleibenden Hosts als “invalid” deklariert.
Ich war zu sehr mit Projektarbeit beschäftigt und hatte ohnehin keine Zeit für Experimente im Lab, also wartete ich bis der 4. Host aus der Reparatur zurück kam. Letzte Woche wurde er endlich geliefert. Sofort baute ich Bootmedium, Cache- und Capacity-Disks wieder ein. Ich prüfte die MAC Adressen und Einstellungen. Alles sah gut aus. Sogar die Firmware war auf neuestem Stand. Nachdem ich den wiedervereinigten Cluster gestartet hatte, blieben die Objekte jedoch weiterhin im Status “invalid”.
Zeit für Troubleshooting
Zuerst startete ich SSH auf allen Hosts. Es gibt zwar einen cleveren powerCLI Befehl der das cluster-weit erledigt, aber ich hatte ja kein vCenter (invalid). Also blieb nur der Hostclient.
Auf der Shell des reparierten Hosts prüfte ich die vSAN-Netzwerk Verbindungen zu allen anderen Hosts im Cluster. Das unten dargestellte Kommando pingt beispielsweise vom Interface vmk1 (vSAN) zur IP 10.0.100.11 (vSAN Kernelport esx01).
vmkping -I vmk1 10.0.100.11
Ich erhielt Antworten aller Kernelports aller Hosts. Ein physische Störung im vSAN Netzwerk konnte also ausgeschlossen werden.
Als nächstes müssen wir herausfinden, ob der vSAN-Cluster intakt ist und ob sich alle Mitglieder kennen. Vielleicht liegt eine Netzwerk Partition vor, infolge dessen die Unicast-Agenten auf jedem Host nicht mit allen Hosts im Cluster kommunizieren können. Um das herauszufinden benötigen wir zwei Informationen von jedem Host:
- IP Adresse und Name des vSAN Kernelports
- Host UUID
Kernelport Details
Mir ist bekannt, dass der Kernelport vmk1 heißt. Für den Fall dass man das nicht weiss, kann man es mit folgendem Kommando herausfinden.
# esxcli vsan network list
Sucht im Resultat nach dem Parameter VmkNic Name. Das ist der vSAN Kerneladapter (in meinem Fall vmk1). Mit dieser Info können wir die IP Adresse des Kerneladapters finden. Passt das grep Kommando im Befehl unten an Euren Kernelport an.
root@esx01:~] esxcli network ip interface ipv4 get | grep vmk1
vmk1 10.0.100.11 255.255.255.0 10.0.100.255 STATIC 0.0.0.0 false
Host UUID
Wir haben jetzt den Namen des Kernelports und seine IP Adresse. Jetzt fehlt uns noch die UUID des Hosts.
[root@esx01:~] cmmds-tool whoami
5eaf1b92-7d12-9f3e-556f-002590bc4d64
Notiert diese Info in einer Tabelle oder einem Textfile und wiederholt den Vorgang auf allen Hosts. Danach prüfen wir die Einstellungen des Unicast-Agents auf allen Hosts.
[root@esx01:~] esxcli vsan cluster unicastagent list
NodeUuid IsWitness Supports Unicast IP Address Port Iface Name Cert Thumbprint SubClusterUuid
------------------------------------ --------- ---------------- ----------- ----- ---------- ----------------------------------------------------------- --------------
5eaf1c30-73d8-2368-ad23-002590bb2ed0 0 true 10.0.100.13 12321 0F:0D:99:30:76:C7:02:87:09:18:EB:C3:12:F7:75:23:99:88:8E:96
5eaf1c66-12d7-3de4-1310-002590bb3008 0 true 10.0.100.14 12321 01:89:11:C0:5A:FF:C4:41:E8:E9:E1:25:2C:E2:93:46:FC:32:3F:11
5eaf1c43-e997-774a-9bb4-002590bc4cdc 0 true 10.0.100.12 12321 4B:5D:A1:88:C9:56:32:9E:03:F5:DD:5E:4D:82:0D:FC:F6:44:6D:42Die erste Spalte zeigt die Liste aller UUIDs aller Hosts im Cluster mit Ausnahme des Hosts von dem das Kommando abgesetzt wurde. Im Beispiel oben wurde das Kommando auf esx01 abgesetzt und ich erhielt die UUIDs der Hosts esx03 (Zeile1), esx04 (Zeile2) und esx03 (Zeile3). Das ist gut. Der Unicast-Agent von esx01 hat alle drei weiteren Hosts gelistet.
Wiederholt diese Abfrage auf allen Hosts.
Sollten sich hier unvollständige Listen ergeben, so kann man die Einstellungen manuell auf der CLI setzen. Hierzu sind die Vorgaben aus KB2150303 einzuhalten.
Ich konnte bestätigen, dass alle Einstellungen der Unicast-Agents im Cluster korrekt waren. Dennoch wurden immer noch sämtliche Objekte als “invalid” deklariert.
vSAN Cluster Einstellungen abrufen
Bisher konnten wir zeigen, dass mit den Unicast-Agenten alles in Ordnung ist. Im nächsten Schritt sammeln wir weitere Informationen.
[root@esx01:~] esxcli vsan cluster get Cluster Information Enabled: true Current Local Time: 2020-09-17T10:36:03Z Local Node UUID: 5eaf1b92-7d12-9f3e-556f-002590bc4d64 Local Node Type: NORMAL Local Node State: AGENT Local Node Health State: HEALTHY Sub-Cluster Master UUID: 5eaf1c30-73d8-2368-ad23-002590bb2ed0 Sub-Cluster Backup UUID: 5eaf1c66-12d7-3de4-1310-002590bb3008 Sub-Cluster UUID: 527a6824-b9bf-a7ad-36f4-8a2cd78b9685 Sub-Cluster Membership Entry Revision: 3 Sub-Cluster Member Count: 4 Sub-Cluster Member UUIDs: 5eaf1c30-73d8-2368-ad23-002590bb2ed0, 5eaf1c66-12d7-3de4-1310-002590bb3008, 5eaf1b92-7d12-9f3e-556f-002590bc4d64, 5eaf1c43-e997-774a-9bb4-002590bc4cdc Sub-Cluster Member HostNames: esx03.lab.local, esx04.lab.local, esx01.lab.local, esx02.lab.local Sub-Cluster Membership UUID: 2534635f-f8c8-760f-a3b1-002590bb2ed0 Unicast Mode Enabled: true Maintenance Mode State: ON Config Generation: d89f0896-2f64-4ebb-8232-de45a28b6392 37 2020-08-14T19:22:44.617
Der Befehlt liefert erweiterte Informationen über den Host und den vSAN-Cluster. An dieser Stelle ein kleiner Exkurs: Es gibt drei Arten von Knoten in einem vSAN Cluster: Master, Backup und Agent. Es gibt genau einen Master-Host im Cluster. Er empfängt die Updates der Clustering Services (CMMDS) anderer Hosts. Dann gibt es genau einen Backup-Host. Er hat eine Kopie der Cluster Service Informationen und wird die Master Rolle übernehmen, falls der Master nicht mehr erreichbar sein sollte. Alle anderen Hosts haben die Agenten-Rolle. Sie können Backup-Node werden, wenn der Backup-Node zur Master-Rolle wechselt. Exkurs Ende.
Wie man im Ergebnis oben sehen kann ist esx01 ein Agent-Node. Es gibt 4 Knoten im Cluster und der lokale Knoten ist im Status “healthy”. Die UUID und Hostnamen aller Member sind korrekt. Ähnliche Resultate auch auf esx02, esx03 und esx04.
[root@esx02:~] esxcli vsan cluster get Cluster Information Enabled: true Current Local Time: 2020-09-17T10:35:46Z Local Node UUID: 5eaf1c43-e997-774a-9bb4-002590bc4cdc Local Node Type: NORMAL Local Node State: AGENT Local Node Health State: HEALTHY Sub-Cluster Master UUID: 5eaf1c30-73d8-2368-ad23-002590bb2ed0 Sub-Cluster Backup UUID: 5eaf1c66-12d7-3de4-1310-002590bb3008 Sub-Cluster UUID: 527a6824-b9bf-a7ad-36f4-8a2cd78b9685 Sub-Cluster Membership Entry Revision: 3 Sub-Cluster Member Count: 4 Sub-Cluster Member UUIDs: 5eaf1c30-73d8-2368-ad23-002590bb2ed0, 5eaf1c66-12d7-3de4-1310-002590bb3008, 5eaf1b92-7d12-9f3e-556f-002590bc4d64, 5eaf1c43-e997-774a-9bb4-002590bc4cdc Sub-Cluster Member HostNames: esx03.lab.local, esx04.lab.local, esx01.lab.local, esx02.lab.local Sub-Cluster Membership UUID: 2534635f-f8c8-760f-a3b1-002590bb2ed0 Unicast Mode Enabled: true Maintenance Mode State: ON Config Generation: d89f0896-2f64-4ebb-8232-de45a28b6392 37 2020-08-14T19:22:44.634
Esx02 ist auch ein Agent-Node. Alle anderen Hosts sind korrekt registriert.
[root@esx03:~] esxcli vsan cluster get
Cluster Information
Enabled: true
Current Local Time: 2020-09-17T10:35:16Z
Local Node UUID: 5eaf1c30-73d8-2368-ad23-002590bb2ed0
Local Node Type: NORMAL
Local Node State: MASTER
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 5eaf1c30-73d8-2368-ad23-002590bb2ed0
Sub-Cluster Backup UUID: 5eaf1c66-12d7-3de4-1310-002590bb3008
Sub-Cluster UUID: 527a6824-b9bf-a7ad-36f4-8a2cd78b9685
Sub-Cluster Membership Entry Revision: 3
Sub-Cluster Member Count: 4
Sub-Cluster Member UUIDs: 5eaf1c30-73d8-2368-ad23-002590bb2ed0, 5eaf1c66-12d7-3de4-1310-002590bb3008, 5eaf1b92-7d12-9f3e-556f-002590bc4d64, 5eaf1c43-e997-774a-9bb4-002590bc4cdc
Sub-Cluster Member HostNames: esx03.lab.local, esx04.lab.local, esx01.lab.local, esx02.lab.local
Sub-Cluster Membership UUID: 2534635f-f8c8-760f-a3b1-002590bb2ed0
Unicast Mode Enabled: true
Maintenance Mode State: ON
Config Generation: d89f0896-2f64-4ebb-8232-de45a28b6392 37 2020-08-14T19:22:44.597
Esx03 hat die Master-Rolle. Alle anderen Hosts sind registriert.
[root@esx04:~] esxcli vsan cluster get
Cluster Information
Enabled: true
Current Local Time: 2020-09-17T10:34:36Z
Local Node UUID: 5eaf1c66-12d7-3de4-1310-002590bb3008
Local Node Type: NORMAL
Local Node State: BACKUP
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 5eaf1c30-73d8-2368-ad23-002590bb2ed0
Sub-Cluster Backup UUID: 5eaf1c66-12d7-3de4-1310-002590bb3008
Sub-Cluster UUID: 527a6824-b9bf-a7ad-36f4-8a2cd78b9685
Sub-Cluster Membership Entry Revision: 3
Sub-Cluster Member Count: 4
Sub-Cluster Member UUIDs: 5eaf1c30-73d8-2368-ad23-002590bb2ed0, 5eaf1c66-12d7-3de4-1310-002590bb3008, 5eaf1b92-7d12-9f3e-556f-002590bc4d64, 5eaf1c43-e997-774a-9bb4-002590bc4cdc
Sub-Cluster Member HostNames: esx03.lab.local, esx04.lab.local, esx01.lab.local, esx02.lab.local
Sub-Cluster Membership UUID: 2534635f-f8c8-760f-a3b1-002590bb2ed0
Unicast Mode Enabled: true
Maintenance Mode State: ON
Config Generation: d89f0896-2f64-4ebb-8232-de45a28b6392 37 2020-08-14T19:22:44.677
Esx04 ist der Backup-Node. Alle anderen Hosts sind registriert.
Am Ende ist die Lösung ganz einfach
Der Cluster sieht in allen Prüfungen korrekt und gesund aus. Dennoch haben wir immer noch keinen Zugriff auf die Objekte, die alle als “invalid” deklariert sind. Eine Kleinigkeit hatte ich aber bisher übersehen. Kurz bevor ich das (gescheiterte) Firmware-Update einspielte, hatte ich den gesamten Cluster in de Wartungsmodus versetzt. Selbst nachdem ich den reparierten Host esx04 wieder dem Cluster hinzugefügt hatte, verblieben die Hosts im Wartungsmodus. Man sieht das in der vorletzten Zeile der oben dargestellten Resultate. Dort steht Maintenance Mode State: ON.
Den Wartungsmodus kann man mittels Hostclient oder SSH Shell beenden.
esxcli system maintenanceMode set --enable false
Ich beendete den Wartungsmodus auf allen Hosts und innerhalb von Sekunden waren alle Objekte wieder im Status “healthy”. Zugegeben, das hätte ich auch einfacher haben können, aber es war eine gute Übung in Troubleshooting. Und das ist es, worum es im Lab geht.
Not because they are easy, but because they are hard.
John F. Kennedy, 1962