Michael Schroeder - ElasticSky

17. Mai 202215. März 2024

vCenter Server 7.0 Update 3e verfügbar

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.

15. April 202217. Mai 2022

Zu Gast beim Deutschen VMware Podcast

Ich wurde kürzlich als Gast zum Deutschen VMware Podcast eingeladen, der von Björn Brundert (VMware) moderiert wird. Gemeinsam mit beiden anderen Gästen Raiko Mesterheide (VMware) und Patrick Häfner (VMUG Stuttgart) sprechen wir über die VMUG und die vCommunity.

Den aktuellen Podcast zur 21. Episode mit dem Titel “VMware User Group und vCommunity” findet Ihr auf der Homepage.

Ihr findet den Podcast auch auf Spotify, Google Podcast oder iTunes.

11. April 20226. Juli 2022

Ein tieferer Einblick in vSAN-Striping

Dieser Artikel geht zurück auf Fragen, die immer wieder von meinen Studenten in vSAN-Kursen gestellt werden. Das Thema Striping klingt zunächst sehr einfach, aber es stellt sich als durchaus komplex heraus, sobald man von den einfachen Standardbeispielen abweicht. Wir beleuchten das Striping Verhalten von vSAN-Objekten bei Spiegelung, Erasure-Coding und bei großen Objekten. Wir zeigen auch das unterschiedliche Striping Verhalten vor der Version vSAN 7 Update 1 und danach.

Was ist Striping?

Striping bezeichnet ganz allgemein eine Technik, bei der logisch sequentielle Daten derart segmentiert werden sodass aufeinanderfolgende Segmente auf verschiedenen physischen Speichergeräten abgelegt werden. Striping schafft keine Redundanz. Das Gegenteil ist der Fall. Im klassischen Storage bereich wird Striping auch als RAID 0 beszeichnet (Merkhilfe: RAID 0 -> null Sicherheit). Durch die Verteilung der Segmente auf mehrere Geräte, auf die parallel zugegriffen werden kann, wird der Gesamtdatendurchsatz erhöht und die Latenz reduziert.

Die Stripe-Size oder Stripe Width bezeichnet dabei die Anzahl der Segmente, in die ein Objekt aufgeteilt wird.

Bei einer Stripe Width von 2 wird ein Objekt von beispielsweise 100 GB in zwei Komponenten zu je 50 GB segmentiert und auf zwei Datenträger verteilt. Dies entspricht einem RAID 0.

14. März 202214. März 2022

vSAN Cluster Live-Migration in ein neues vCenter

Was kann man tun, wenn die produktive vCenter Server Appliance beschädigt ist und man einen vSAN-Cluster auf eine neue vCenter Appliance übertragen muss?

Im heutigen Beitrag werde ich zeigen, wie man einen laufenden vSAN-Cluster unter vollen Segeln von einer vCenter-Instanz auf ein neues vCenter übertragen kann.

Bei jedem der mit vSAN arbeitet, wird sich bei diesem Gedanken ein flaues Gefühl in der Magengegend verbreiten. Warum sollte man so etwas tun? Wäre es nicht besser, den Cluster komplett in den Wartungsmodus zu fahren? – Prinzipiell, ja. In der Praxis treffen wir aber immer wieder auf Einschränkungen, die in absehbarer Zeit kein Wartungsfenster erlauben.

Normalerweise sind vCenter Server Appliances robuste und wartungsarme Einheiten. Entweder sie funktionieren, oder sie sind völlig zerstört. In letzterem Fall könnte eine neue Appliance bereitgestellt und vom Backup ein Konfiguration-Restore eingespielt werden. Nichts davon traf auf ein kürzlich durchgeführtes Projekt zu. Die VCSA 6.7 funktionierte noch halbwegs, jedoch waren wichtige vSAN-Funktionalitäten im UI nicht mehr verfügbar. Eine erste Idee, das Problem mit einem Upgrade auf vCenter v7 und somit auf eine neue Appliance zu beseitigen scheiterte. Auch eine Cross-vCenter Migration der VMs (XVM) auf einen neuen vSAN-Cluster war nicht möglich, da erstens dieses Feature erst mit Version 7.0 Update 1c integriert wurde und zweitens auch nur zwei neue Ersatzhosts zur Verfügung standen. Zu wenig für einen neuen vSAN-Cluster. Zu allem Überfluss war auch der Quellcluster an seiner Kapazitätsgrenze.

Es gab nur einen Ausweg: Den Cluster stabilisieren und unter voller Last auf ein neues vCenter übertragen.

Zu diesem Thema gibt es einen alten, aber immer noch wertvollen Beitrag von William Lam. Damit, und mit dem VMware KB 2151610 Artikel konnte ich eine Strategie entwickeln, die ich hier skizzieren möchte.

Das Verfahren funktioniert, da ein vSAN-Cluster nach Einrichtung und Konfiguration autonom vom vCenter arbeiten kann. Das vCenter wird lediglich für Monitoring und Konfigurationsänderungen benötigt.