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.

„vSAN Cluster Live-Migration in ein neues vCenter“ weiterlesen

Belegte vSAN Disks im ESXi Host freigeben (unclaim)

Bei Experimenten mit der neuesten ESXi / vSAN Beta trat ein Problem auf. Ich war gerade dabei, eine vCenter Server Appliance (VCSA) auf einen einzelnen ESXi Host auszurollen, der dann mit anderen Hosts einen neuen vSAN (beta) Cluster bilden sollte. Bei der Basiskonfiguration der VCSA (Phase 2) stürzte der Assistent ab. (Muss ich erwähnen, dass es ein DNS Problem war?) 🙂

Dieser Teil der vCenter / vSAN Installation ist heikel. Geht hier etwas schief, bedeutet das in der Regel “Game Over”. Man darf das ganze nochmal von vorne beginnen. Wenn man dann den Installer erneut startet (und das DNS Problem inzwischen hoffentlich beseitigt hat) wird man wahrscheinlich keine Speichermedien im Host sehen. Ganz offensichtlich sind diese noch im Host eingebaut und verfügbar, jedoch wurden diese beim ersten Installationsversuch von vSAN beansprucht und formatiert. Bei einer Neuinstallation dürfen die Spechergeräte jedoch weder vSAN, noch VMFS Dateisysteme enthalten. Falls doch, werden diese ignoriert und nicht angezeigt.

Wie kann man die Disks wieder freigeben?

Im Prinzip kann man Diskgroups im vCenter entfernen. Leider haben zu diesem Zeitpungt noch kein vCenter. Also ein Henne-Ei Problem. Aber wir haben einen Host, eine Shell und ESXCLI. Wir müssen dazu SSH auf dem Host aktivieren und eine Verbindung aufbauen (z.B. mit Putty).

„Belegte vSAN Disks im ESXi Host freigeben (unclaim)“ weiterlesen

Mikro-Tipp: esxcli Kommandoliste

Es sind gelegentlich die einfachen Dinge, die einem das Leben erleichtern. Kürzlich war ich auf der Suche nach einer Übersicht der verfügbaren esxcli Kommandos. Dafür gibt es erfreulicherweise auch einen esxcli Befehl. Die komplette Liste aller esxcli Kommandos kann man sich ausgeben lassen mit:

esxcli esxcli command list

HBA Driver und Firmware Version ermitteln

Vor Upgradevorgängen ist es ratsam, einen Blick in die VMware HCL zu werfen und Hostsystem und IO-Devices auf Kompatibilität zu prüfen. Hierbei ist das Zusammenspiel von Treiberversion, Firmware und VMware ESXi Version entscheidend. Auch kleinere Updates können mit dem Verlust der HCL Kompatibilität einhergehen. Ein System, das bei Installation noch HCL-konform war, muss es nach dem dritten Update nicht mehr zwingend sein. Durch Updates aktualisierte Treiber können möglicherweise eine höhere Firmware erfordern.

Nun kann man sich glücklich schätzen, wenn man eine Software im Einsatz hat, die einem die mühevolle Suche abnimmt. Runecast Analyzer leistet hier sehr gute Dienste und zeigt auf einen Blick bestehende Inkompatibilitäten. Darüber hinaus kann man ein Upgrade zu einer beliebigen vSphere-Version simulieren und den HCL-Status ermitteln.

Leider haben viele Kunden keine derartige Software im Einsatz und so muss man auf die Bordmittel der ESXi Shell zurückgreifen. Dafür muss SSH auf den Hosts aktiviert werden. Entweder über den vSphere-Client, oder sehr schnell und elegant über ein PowerCLI Kommando.

„HBA Driver und Firmware Version ermitteln“ weiterlesen