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.
Achtung! Diese Methode birgt Risiken und erfordert gründliche Vorbereitung. Wer hier zweifelt, sollte unbedingt den VMware Support kontaktieren.
Phase 1 – Cluster in Ordnung bringen
Man könnte diese Phase auch als “Leichen aus dem Keller bergen” bezeichnen. Vorraussetzung ist ein in sich stabiler und regelgerecht konfigurierter vSAN-Cluster. Auch wenn die vCenter-Instanz fehlerhaft oder beschädigt ist, so müssen alle Knoten sauber miteinander kommunizieren. Sämtliche Objekt-Synchronisierungen im Hintergrund müssen beendet sein.
Im vorliegenden Fall konnte mit dem vSphere-Client keine zuverlässige Aussage getroffen werden, daher musste die Diagnose auf die CLI verlegt werden.
esxcli vsan network list
Obiger Befehl listet alle Kerneladapter, die für den vSAN-Traffic zuständig sind.
Zum Test der vSAN Netzwerkverbindung verwenden wir den unten aufgeführten Befehl. Anzugeben ist der vSAN-Kernelport (hier vmk1) und die vSAN-Kernelport-IP des Ziehlhosts (hier als x.x.x.x dargestellt).
esxcli network diag ping -I vmk1 -H x.x.x.x
Als Alternative kann man auch ein einfaches vmkping Kommando verwenden.
vmkping -I vmk1 x.x.x.x
Es ist notwendig, den Kontakt zu allen benachbarten Hosts im Cluster zu testen.
Abschließender Check
esxcli vsan cluster get
Es ist wichtig, hier die Anzahl der Cluster Member zu notieren.
esxcli vsan health cluster list
Der ursprünglich überlastete Cluster konnte durch Bereitstellung zweier weiterer Hosts in einen stabilen Zustand (green) gebracht werden. Er ist nun in einem stabilen Zustand und die Übertragung der Hosts kann beginnen.
Phase 2 – Vorbereitung des Ziel-vCenters
Das Ziel-vCenter muss mindestens dem Buildlevel des Quell-vCenters entsprechen oder höher.
- alle Lizenzen für vCenter, vSAN und vSphere im neuen vCenter registrieren
- Verbindung zum Active-Directory herstellen, falls dies zuvor auch der Fall war
- Datacenter Objekt erzeugen
- Cluster Objekt erzeugen und vSAN aktivieren
- Optional HA, DRS (manuell, oder halbautomatisch) aktivieren
- Deduplication und Compression analog zu den Quelleinstellungen konfigurieren
Falls auf der Quellseite Encryption aktiviert war, so muss auch das Ziel-vCenter mit dem KMS verbunden werden und ein Trust mit der identischen Cluster-ID hergestellt werden.
Manchmal ist in der GUI nicht klar erkennbar, welche Cluster-Features aktiviert sind. In meinem beschriebenen Fall waren die Parameter im vSphere-Client nicht auslesbar. Auch hier müssen wir die CLI befragen. Der Code unten ist ein einzeiliger Befehl.
esxcli vsan storage list | grep -i 'Device\|Is ssd\|Is Capacity Tier\|DEDUPLICATION\|COMPRESSION\|In CMMDS\|ENCRYPTION:' |sed 'N;N;N;N;;N;N;s/\n//g' | sort -k9;Das obige Kommando liefert auf der CLI eine Tabelle mit aktiven, oder inaktiven Cluster-Eigenschften wie Deduplizierung und Kompression oder Verschlüsselung.
Phase 3 – Übertragung der Storage Policies und vDS-Einstellungen
Export der Storage policies
Prüfung der verwendeten Policies
Im vSAN Cluster kann es ein Vielzahl an Storage Policies geben. Interessant sind jedoch nur die tatsächlich aktiv verwendeten.
esxcli vsan debug object list | grep spbmProfileId | sort | uniq
Es werden nur Policies zurückgegeben, die mindestes einmal auf ein Objekt angewendet wurden.
Mit PowerCLI können alle Policies exportiert werden.
Get-SpbmStoragePolicy | Export-SpbmStoragePolicy -FilePath C:\temp\
Das Kommando exportiert alle Storage-Policies als einzelne XML Dateien, die den Namen der Policy tragen. Z.B. SP-ErasureCoding-R5.xml.
Import der Storage-Policies
Mit PowerCLI eine Verbindung zum Ziel-vCenter herstellen und die lokal gespeichert Policy (XML) importieren.
Import-SpbmStoragePolicy -Name "MyPolicy" -FilePath C:\temp\MyPolicy.xml
Nach der Übertragung der Storage-Policies müssen nun auch die Distributed-vSwitches exportiert und am Ziel importiert werden.
Export der vDS
Wir exportieren die Einstellungen der vDistributed-Switches (vDS) vom Quellcluster.
Networking > vDS wählen > Settings > Export Configuration
Die Switchkonfiguration wird als ZIP Archiv auf den Client geladen.
Import der vDS
Im Ziel vCenter das Datacenter auswählen > Distributed Switch > Import Distributed Switch. Wir übergeben die zuvor exportierte ZIP-Datei. Beim Import-Dialog nicht die Option “Preserve original distributed switch port group identifiers” wählen.
Phase 4 – Transfer der Hosts
Die Übertragung der Host zum neuen vCenter erfolgt einzeln. Damit der vSAN-Cluster dabei erhalten bleibt, müssen wir ihn in einen geschützten Modus bringen. ClusterMemberListUpdates vom vCenter werden fortan ignoriert. D.h. kein Host verlässt den Cluster und kein Host kommt hinzu. Das ist ein kritischer Punkt, denn wir werden nacheinander Hosts aus dem Quell-vCenter entfernen. Das führt unter normalen Bedingungen zu Member-List-Updates durch das vCenter an die verbleibenden Hosts und würde unseren Cluster zerteilen. Daher weisen wir die Hosts an, diese Member List Updates vom vCenter zu ignorieren.
Dazu führt man entweder auf jedem Host das unten dargestellte Kommando aus, oder aktiviert es zentral im Cluster über PowerCLI.
esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates
Alternative über PowerCLI. Der Name des vSAN-Clusters muss entsprechend angepasst werden (hier: vSAN-Cluster).
Foreach ($vmhost in (Get-Cluster -Name vSAN-Cluster | Get-VMHost)) { $vmhost | Get-AdvancedSetting -Name "VSAN.IgnoreClusterMemberListUpdates" | Set-AdvancedSetting -Value 1 -Confirm:$false }Bei erfolgreicher Ausführung liefert das PowerCLI-Kommando pro Host eine Resultatzeile zurück.
Bevor wir mit dem Transfer beginnen, sollte DRS im Quell-Cluster auf halbautomatisch, oder manuell gestellt werden.
Ein letzter Kontrollblick auf den Gesundheitszustand des Clusters schadet hier nicht und auch ein lückenloses Backup muss vorhanden sein. Schließlich migrieren wir einen vSAN-Cluster unter vollen Segeln. Auch bei sorgfältigster Planung gilt:
“The force of shit happens will be with you, always”.
Obi vSAN Kenobi
Host übertragen
Die nun folgende Prozedur wird nacheinander mit jedem Host durchgeführt. Die Prozedur ist mit Start und Ende markiert.
Start der Prozedur
Wir trennen den ersten Host vom vCenter (disconnect), quittieren die Warnung und entfernen nach Abschluss des Tasks den Host aus der Konfiguration (Remove from Inventory).
Im Ziel-vCenter selektieren wir das Datacenter (nicht den vSAN-Cluster!) und fügen dort den Host hinzu (add Host).
- FQDN des Hosts angeben
- root Passwort des Hosts eingeben
- Zertifikatswarnung akzeptieren
- Details zum Host kontrollieren
- Lizenz zuweisen. Der Host bringt in der Regel seine ursprüngliche Lizenz mit. Diese kann zugeteilt werden.
- Lockdown Mode konfigurieren (disable)
- Datacenter als VM-Ziel wählen
- Zusammenfassung lesen
- Finish
Der Host befindet sich nach Abschluss der Aktion außerhalb des neuen vSAN-Clusters. Wir ziehen ihn nun mit der Maus in das vSAN-Clusterobjekt. Dieser Zwischenschritt ist notwendig, da ein direkter Import in den vSAN-Cluster einen Wartungsmodus auf dem Host auslösen würde. Das darf natürlich nicht passieren, da wir aktive VMs auf dem Host betreiben. Mit der Verschiebeaktion wird jedoch kein Wartungsmodus ausgelöst.
An dieser Stelle empfiehlt sich ein Check der vSAN Netzverbindung zu allen Hosts im alten vCenter.
vmkping -I vmk1 x.x.x.x
Hier ist der vSAN-Kernelport anzupassen und als Zieladresse die IP-Adresse eines vSAN-Kernelports der anderen Cluster-Mitglieder zu wählen.
Host dem vDS zufügen
Die Netzkommunikation funktioniert weiterhin, obwohl der vDS im neuen vCenter noch leer ist. Das liegt daran, dass jeder Distributed-vSwitch “verborgene” Standard-vSwitches auf jedem Host erzeugt. Diese wandern mit dem Host und bleiben aktiv. Damit wir die vDS Eigenschften des Hosts zukünftig administrieren und monitoren können, fügen wir ihn dem importierten vDS hinzu.
- Netzwerk > vDS markieren
- Add and manage Hosts
- Migrierten Host wählen
- Uplinks definieren (wie zuvor)
- Kernelports den Portgruppen zuordnen (vSAN, vMotion, Provosioning, etc)
- VM-Netze zuordnen (falls zutreffend)
- Übersicht kontrollieren
- Finish
Ende der Prozedur
Wir wiederholen diese Prozedur mit jedem Host bis sich alle im neuen vSAN-Cluster befinden.
Sobald der Transfer aller Hosts abgeschlossen ist, können wir den geschützten Modus verlassen, den wir zu Anfang aktiviert hatten. Dies kann entweder einzeln auf allen Hosts durchgeführt werden, oder zentral über PowerCLI.
esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates
Der alternative PowerCLI Befehl ist praktisch der gleiche wie zu Beginn. Nur dass hier das Value auf 0 gesetzt wird (= deaktiviert). Auch der vSAN-Clustername muss entsprechend angepasst werden.
Foreach ($vmhost in (Get-Cluster -Name vSAN-Cluster | Get-VMHost)) { $vmhost | Get-AdvancedSetting -Name "VSAN.IgnoreClusterMemberListUpdates" | Set-AdvancedSetting -Value 0 -Confirm:$false }Nach Abschluss der Aktion finden sich auf allen Hosts zwei gleichnamige vDS. Einer trägt die Hosts und Portgruppen, der andere ist ein Relikt aus dem Transfer und kann gelöscht werden.
Fazit
Alle Hosts wurden auf das neue vCenter übertragen. Dabei waren alle VMs durchgehend verfügbar.
Es ist wichtig, neben Plan A auch einen tragfähigen Plan B (und vielleicht auch einen Plan C) in der Hinterhand zu haben. Veränderte Bedingungen oder versteckte Einschränkungen können einen Strategiewechsel erfordern. Ist man schon gezwungen, den Königsweg zu verlassen, so gibt ein bereits ausgearbeiteter alternativer Ansatz zusätzliche Sicherheit.