the Sky is the Limit
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.
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.
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.
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.
„vSAN Cluster Live-Migration in ein neues vCenter“ weiterlesen
vSphere 7.0 Update 3 erschien ursprünglich am 5. Oktober 2021. Schon kurz nach Veröffentlichung gab es gehäuft Problemmeldungen von Kundenseite, so dass am 18. November 2021 alle ESXi Versionen 7.0 U3a, U3b, U3c, sowie vCenter 7.0 U3b aus dem Downloadbereich von VMware zurückgezogen wurden. VMware erklärt im KB 86191 Details zur Problematik.
Hauptproblem waren die doppelten Treiber i40en und i40enu für Intel 10 GBit NICs X710 und X722 im System. Eine Überprüfung auf der CLI liefert schnell ein Ergebnis. Hier darf nur ein Resultat zurückkommen.
esxcli software vib list | grep -i i40
Hosts mit beiden Treibern werden potenziell HA Probleme haben mit dem Update auf U3c, sowie Probleme mit NSX.
Am 27. Januar 2022 ( 28.1.2022 CET) wurde das neue Update 3c veröffentlicht und steht zum Download bereit. Neben der Beseitigung der Probleme aus früheren Update 3 Versionen (KB 86191) steht vor allem der Fix für die Apache Log4j Lücke (VMSA-2021-0028.10) im Vordergrund.
Alle Anwender und Kunden, die früh eines der zurückgezogenen Updates 3 installiert hatten, wird dringend ein Update auf Version U3c empfohlen.
„VMware vSphere 7.0 U3c erschienen“ weiterlesen