Autor: Michael Schroeder

Veröffentlicht am

Buchprojekt: vSphere 7 – Das umfassende Handbuch

Ich hatte das besondere Vergnügen, in den vergangenen Monaten an einem Buchprojekt als Co-Autor mitzuwirken. Es trägt den Titel „VMware vSphere 7 – Das umfassende Handbuch“ und wird im November im Rheinwerk-Verlag erscheinen. Es ist die inzwischen 6. aktualisierte und erweiterte Auflage dieser Serie.

Dieses Buch deckt ein breites Spektrum von vSphere 7 ab. Von der grundlegenden Architektur über die Einrichtung bis hin zum Betrieb, was gemeinhin auch als day-2-Operations bezeichnet wird. Es hilft Anfängern und fortgeschrittenen IT-Administratoren, die Prinzipien von vSphere, Netzwerkvirtualisierung mit NSX-T, vSAN, Container-Workloads, VMware Cloud Foundation, Hybrid-Cloud und SDDC zu verstehen.

Meine Beiträge sind die komplett neu geschriebenen Kapitel Monitoring und vSAN. Beim Kapitel Monitoring geht es darum, dem Administrator einen Überblick über die integrierten Monitoring-Werkzeuge zu geben und wie diese anzuwenden und zu interpretieren sind. Darüber hinaus werden auch Hilfsmittel von VMware und Drittherstellern vorgestellt. Das Kapitel vSAN erläutert den fundamentalen Aufbau dieser Storage Virtualisierung und erklärt die Besonderheiten eines vSAN-Clusters im Vergleich zu herkömmlichen Storage Lösungen.

Es war mir eine Freude mit einem Team aus Experten an diesem Buch mitzuwirken.

Veröffentlicht am

vSphere with Kubernetes

Was ist neu in v7U1?

In Kürze wird Update1 für vSphere 7 veröffentlicht werden. Den Anwendern eröffnet sich damit die Möglichkeit Kubernetes nativ auf vSphere zu betreiben. Dies war bislang nur Anwendern vorbehalten, die VMware Cloud Foundation 4 (VCF) im Datacenter betrieben haben. Ab vSphere7 Update1 wird es zwei Arten von Kubernetes auf vSphere geben:

  • VCF mit Tanzu
  • vSphere mit Tanzu

VCF bietet das komplette Portfolio, hat aber engere Grenzen. VCF fordert beispielsweise vSAN als Storage und NSX-T im Network Stack. NSX-T bietet Loadbalancer Funktion sowohl für den Supervisor Cluster als auch für Tanzu Kuberneted Grid (TKG). Darüber hinaus stellt es Overlay Netzwerke für PodVMs bereit. Dies sind Container Pods die mittels Micro-VMs direkt auf dem Hypervisor laufen.

Im Gegensatz dazu ist vSphere mit Tanzu etwas freier. Es gibt keine Vorgaben bezüglich Storage und auch NSX-T ist optional. Das Netzwerk kann mit normalen virtuellen Distributed Switches (vDS) abgebildet werden. Als Loadbalancer für Supervisor Control Plane API und TKG Cluster API kann der HA-Proxy verwendet werden. Diese Freiheit kommt jedoch mit Einschänkungen in der Funktion einher. Ohne NSX-T können keine PodVMs betrieben werden. Abhängig von PodVMs ist beispielsweise auch die Harbor Image Registry. Harbor kann also unter vSphere mit Tanzu nur genutzt werden wenn NSX-T vorhanden ist.

VCF mit TanzuvSphere mit Tanzu
NSX-Terforderlichoptional, vDS
vSANerforderlichoptional
PodVMsjanur mit NSX-T
Harbor Registryjanur mit PodVM, NSX-T
LoadbalancerNSX-THA-Proxy
CNICalicoAntrea o. Calico
Overlay NWNSX-T–

Tanzu Editions

Künftig wird es 4 Varianten von vSphere with Tanzu geben:

  • Tanzu Basic – Betrieb einfacher Kubernetes-Cluster in vSphere. Erhältlich als Lizenzbundle mit vSphere7 EnterprisePlus
  • Tanzu Standard – Wie Tanzu Basic jedoch mit Multi Cloud Support. Addon Lizenz für vSphere7 oder VCF.
  • Tanzu Advanced – Wird zu einem späteren Zeitpunkt erhältlich.
  • Tanzu Enterprise – Wird zu einem späteren Zeitpunkt erhältlich.

Links

vSphere Blog – What’s New with VMware vSphere 7 Update 1

vSphere Blog – Announcing VMware vSphere with Tanzu

Cormac Hogan – Getting started with vSphere with Tanzu

VMware Tanzu – Simplify Your Approach to Application Modernization with 4 Simple Editions for the Tanzu Portfolio

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