Ich werde auf der diesjährigen VMware Explore in Barcelona einen Vortrag zur Migration eines vSAN-Clusters halten. Es geht hierbei nicht nur um die technische Umsetzung, sondern vielmehr um den Weg der Entscheidungsfindung. Wenn Plan A nicht funktioniert sollte man einen Plan B bereit haben. Oder – wie in meinem Praxisbeispiel – einen Plan C und letztlich einen Plan D.
Der einfache Weg muss nicht immer der beste sein und auch eine wenig attraktive Alternative kann schließlich zum Erfolg führen.
CODE1405BCN
Der Vortrag ist imVMware Explore Content Catalog unter der Nummer 1405 gelistet.
Mit Einführung von vSphere 7.0 Update 1 erschienen in vSphere-Clustern erstmals die vSphere Cluster Services VMs (vCLS). Damit wurden Cluster Funktionen wie z.B. Distributed Resource Scheduler (DRS) und andere erstmals unabhängig von der Verfügbarkeit der vCenter Server Appliance (VCSA). Letztere stellt im Cluster immer noch einen Single-Point-of-Failure dar. Durch Auslagerung der DRS Funktion in die redundanten vCLS Maschinen wurde ein höheres Maß an Resilienz erreicht.
Retreat Mode
Der vSphere-Administrator hat nur wenig Einfluss auf die Bereitstellung dieser VMs. Gelegentlich ist es jedoch notwendig, diese VMs von einem Datastore zu entfernen wenn dieser beispielsweise in den Wartungsmodus versetzt werden soll. Dafür gibt es eine Prozedur, um den Cluster in den sogenannten Retreat-Mode zu setzen. Dabei werden temporäre erweiterte Einstellungen gesetzt, die zur Löschung der vCLS VMs durch den Cluster führen.
Laut Prozedur von VMware muss für die Aktivierung des Retreat Modes die Domain ID ermittelt werden. Die Domain ID ist der numerische Wert zwischen ‘domain-c’ und dem folgenden Doppelpunkt. Im Beispiel aus meinem Labor ist es der Wert 8, aber die Zahl kann durchaus auch vierstellig sein.
Die Domain ID muss dann in den Advanced Settings des vCenters übergeben werden.
config.vcls.clusters.domain-c8.enabled = false
Korrekte Settings für den Retreat Mode.
Admin Fehler beim Retreat Mode
Nach Aktivierung des Retreat-Modes auf einem vSAN-Cluster hatten Administratoren sämtliche Privilegien auf alle Objekte im vSphere-Client verloren.
Eine Überprüfung der Dienste zeigte, dass der vCenter Server Daemon (vpxd) nicht gestartet war.
In den letzten Jahren haben wir einen deutlichen Trend zur Einführung von Cloud-Strategien auf Kundenseite festgestellt. Einige setzen bereits auf eine Multi-Cloud-Strategie, um den größtmöglichen Nutzen aus verschiedenen Angeboten zu ziehen. Wir dürfen jedoch nicht vergessen, dass die Infrastruktur vor Ort – die so genannte private Cloud – immer noch die häufigste Art der virtuellen Infrastruktur ist. Das ist nicht verwunderlich, denn die Infrastruktur vor Ort hat zweifellos eine Reihe von Vorteilen. Das sind nicht nur Aspekte des Datenschutzes, der Datensicherheit und der Datensouveränität. Es sind auch Leistungsaspekte wie geringe Latenzen, die Kunden davon abhalten, spezielle Arbeitslasten in die (public) Cloud zu migrieren.
Andererseits haben Cloud-Angebote auch ein paar Vorteile. Dazu gehören die flexible Nutzung, die minimale Wartung, die eingebaute Ausfallsicherheit, die Agilität für Entwickler und die Möglichkeit, das System von überall aus zu verwalten.
Um die Lücke zwischen lokalen Anforderungen und Cloud-basierten Möglichkeiten zu schließen, hat VMware auf der VMworld 2021 das Projekt Arctic angekündigt. Vorteile der Cloud für lokale Workloads nutzbar machen.
VMware hat einen Patch Update 3e für vCenter bereitgestellt. Dies ist ein Wartungsupdate und bringt in erster Linie Updates für vSphere mit Tanzu. Es gibt dazu eigene Release Notes für vSphere with Tanzu.
Neue Funktionen
Unterstützung von Network Security Policies für VMs, die über den VM-Operator-Service bereitgestellt werden – Sicherheitsrichtlinien auf NSX-T können über Security Gruppen auf der Grundlage von Tags erstellt werden. Es ist jetzt möglich, NSX-T-basierte Sicherheitsrichtlinien zu erstellen und sie auf VMs anzuwenden, die über VM-Operator auf der Grundlage von NSX-T-Tags bereitgestellt werden.
Unterstützung für Kubernetes 1.22 im Supervisor Cluster – In dieser Version wird die Unterstützung für Kubernetes 1.22 hinzugefügt und die Unterstützung für Kubernetes 1.19 eingestellt. Die unterstützten Versionen von Kubernetes in dieser Version sind 1.22, 1.21 und 1.20. Supervisor-Cluster, die auf Kubernetes Version 1.19 laufen, werden automatisch auf Version 1.20 aktualisiert, um sicherzustellen, dass alle Ihre Supervisor-Cluster auf den unterstützten Kubernetes-Versionen laufen.
Zur Beachtung beim Update
Wenn das vCenter von einer Version vor v7.0 U3c aktualisiert wird und im Supervisor Cluster eine Kubernetes Version 1.19 läuft, gehen die tkg-controller-manager-Pods in einen CrashLoopBackOff-Zustand über, wodurch die Guest-Cluster nicht mehr verwaltbar sind. Ein Workaround hierfür ist in KB 88443 beschrieben.
Test K8s Version
Zur Sicherheit sollte vor dem Update die Kubernetes Version in der Supervisor Control Plane überprüft werden.
Menu > Workload Management > Subervisor Clusters
Im Bild oben ist die Version der Supervisor Control Plane bereits auf Version v1.21.
Update
Vor dem Update sollte unbedingt eine Sicherung der vCenter Konfiguration erstellt werden! Optional ist auch ein Snapshot hilfreich, da hiermit im Falle eines Scheiterns schnell der Ausgangzustand wiederhergestellt werden kann.
Das Update kann entweder im VAMI oder auf der Shell ausgeführt werden. Die Abbildung unten gibt einen Überblick der neuen Pakete.
Nach dem Update steht eine neue Kubernetes Version für die Supervisor Control Plane zur Verfügung.
