Autor: Michael Schroeder

Veröffentlicht am

vSAN Cluster Objekte als invalid deklariert

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.

„vSAN Cluster Objekte als invalid deklariert“ weiterlesen
Veröffentlicht am

VMware Cloud Foundation 4.1 angekündigt

Gemeinsam mit vSphere7 und vSAN7 erschien im März dieses Jahres VMware Cloud Foundation (VCF) 4.0 mit Tanzu. Nun hat VMware zusammen mit vSphere 7.0 Update1 und vSAN 7 U1 VMware Cloud Foundation 4.1 angekündigt, das auf einigen der neuen Funktionen von vSAN aufbaut.

Was ist neu?

  • vSAN Data Persistence Platform – Dies ist ein wichtiger Schritt für Hersteller virtueller Appliances und Container Lösungen, die auf vSAN respektive VCF ausgeführt werden sollen. Nicht alle Container Workloads sind statuslos (stateless). Einige von ihnen wie zum Beispiel Objectstorage oder NoSQL sind stateful applications. Bisher waren eigene Replikationsmechanismen in der Anwendung notwendig. Mit vSAN Persistence Platform wird den Anbieitern ermöglicht, direkt die Hochverfügbarkeit von vSAN zu nutzen. Erste Anbieter zind beispielsweise MinIO, DataStax, Dell EMC ObjectScale oder Cloudian.
  • VMware Cloud Foundation Remote Clusters – Ein Feature, das auf vSAN HCI Mesh aufbaut. Damit können vSAN Datastores anderer Cluster eingebunden werden. Dies ist inbesondere für Remotestandorte interessant.
  • vVols in der Workload Domain – Damit können Workload Domains nicht mehr nur auf vSAN Datatores aufgesetzt werden, sondern auch auf klassischer Storage mit vVol Funktion. Als Protokolle werden FC, iSCSI und NFS unterstützt.
  • Automatisierte Bereitstellung der vRealize Suite 8.1 – Der vRealize Suite Life Cycle Manager (vRSLCM) interagiert nun mit dem SDDC Manager. Somit können alle vRealize Produkte vom vRSLCM installiert und aktualisiert werden.
  • Neuerungen und Bugfixes im SDDC Manager
  • VMware Skyline Support für VCF

Das Update wird wahrscheinlich Anfang Oktober zur VMworld oder kurz danach verfügbar sein.

Veröffentlicht am

Update Problem VCSA 7 – vCenter Server not operational

Beim Update (Patch) einer vCenter Server Appliance (VCSA) kann es zu Störungen kommen, oder das Update wird vor dem Start abgebrochen. Versucht man dann erneut das Update einzuspielen, so kann es zu der unten dargestellten Fehlermeldung kommen.

Update Installation failed. VCenter Server is not operational.

Im Management Interface der VCSA (VAMI) lässt sich kein Problem erkennen. Alle Dienste sind aktiv und der Status ist grün. Das Problem bleibt auch nach einem Neustart der Appliance bestehen. Die Ursache liegt in einem zuvor abgebrochenen oder gescheiterten Updateversuch. Dabei wird im Dateisystem der Appliance ein File zurückgelassen, das wir zunächst entfernen müssen.

Dazu starten wir eine SSH Sitzung auf die vCenter Server Appliance.

# cd /etc/applmgmt/appliance

Im dortigen Verzeichnis findet sich eine Datei software_update_state.conf, welche üblicherweise nur während eines Updatevorganges vorhanden ist. Wir können uns den Inhalt näher anschauen.

# cat software_update_state.conf
{
"state": "INSTALL_FAILED",
"version": "7.0.0.10700",
"latest_query_time": "2020-09-17T11:42:37Z"
}

Man sieht den Vermerk in der Datei, dass zuvor ein Update gescheiter war. Die Datei wird vor einem neuen Versuch nicht bereinigt, daher müssen wir das selbst übernehmen.

# rm software_update_state.conf

Danach kann das Update regulär neu gestartet werden und läuft problemlos durch.

Veröffentlicht am

VCF 4.0.1 VxRail Cluster mit mehr als einem dvSwitch für Overlay Traffic verwenden

Der SDDC-Manager ist die zentrale Instanz zur Verwaltung von vCloud Foundation (VCF). Man kann damit Workload Domains (WLD) hinzufügen, Cluster importieren, oder Kubernetes Namespaces definieren. Für jede Aufgabe gibt es einen graphischen Workflow im SDDC-Manager.

Derzeit ist es in Version VCF 4.0.1 jedoch nicht möglich, Cluster mit mehr als zwei Uplinks und mehr als einem dvSwitch zu einer WLD hinzuzufügen.

Was tun?

Die Lösung ist innerhalb des SDDC-Managers bereits vorbereitet.

„VCF 4.0.1 VxRail Cluster mit mehr als einem dvSwitch für Overlay Traffic verwenden“ weiterlesen