VMware vSAN 6.x auf 7.0 (Update 1) aktualisieren

    Erfolgreiches Update auf vSAN 7.0Nachdem Virtual SAN 7 einige interessante neue Features bietet, wird man mit dem Umstieg auf vSphere 7 auch vSAN auf den neuesten Stand bringen. Dies erfordert die Aktuali­sierung des Fest­platten­formates. Zusätz­lich sollte man eine vorhan­dene Witness-Appliance durch eine kom­patible Ver­sion er­setzen.

    Das Aktualisieren einer vSAN-Umgebung von der Version 6.x auf 7.0 (U1) besteht in einer einfachen vSphere-Umgebung mit einem einzelnen vCenter und einigen ESXi-Hosts aus folgenden Schritten:

    Für das Aktualisieren der ESXi-Hosts stehen mehrere Verfahren zur Auswahl. Da es aber hier um ein Upgrade im Kontext eines vSAN-Szenarios geht, ziehe ich die vCenter-basierende Host-Aktualisierung mit VUM vor, weil ich für das Aufsetzen von Tanzu NSX-T benötige und dieses derzeit noch nicht mit vLCM Cluster-Images kompatibel ist.

    Ist der Host-Cluster mit einer passenden vSAN-Lizenz lizensiert und wurden alle Hosts erfolgreich auf Version 7 aktualisiert, dann kann man sich zwar bei markiertem Cluster im Tab Konfigurieren unter Lizenzierung => vSAN-Cluster die zugewiesene Lizenz anzeigen lassen.

    Das Update auf vSphere 7 bringt die vSAN-Cluster-Lizenz auch auf den neuesten Stand. Weitere Aktionen sind aber noch nötig.

    Das bedeutet aber nicht, dass das vSAN-Upgrade durch das Aktualisieren der Hosts bereits abgeschlossen ist. Wie ein Blick in Überwachen unter vSAN => Skyline-Integrität offenbart, ist das Datenträger­format von vSAN noch auf dem alten Stand.

    Die Skyline-Integrität weist auf das veraltete Festplattenformat hin.

    Der Abbildung zufolge ist die Festplatten­version im vSAN noch auf 10 und nicht auf 11. Ein Klick auf den Info-Tab liefert nähere Informationen.

    Dieser Sachverhalt zeigt sich auch, wenn man bei markiertem vSAN-Cluster unter dem Tab Konfigurieren auf vSAN => Festplatten­verwaltung klickt. Hier kann man mit Hilfe der gleich­namigen Schaltfläche die Festplatten­version aktualisieren oder eine Vorabprüfung veranlassen.

    Die Festplattenverwaltung zeigt auch das Format v10 an und erlaubt das Update auf v11.

    Das Upgrade des Festplatten­formats kann man nun durch einen Klick auf Aktualisieren einleiten. Aber Achtung: Dazu muss sichergestellt sein, dass dafür genügend Speicher­kapazität vorhanden ist.

    Ist der freie Platz auf den Festplatten­gruppen (ohne die zu konvertierenden Festplatten­gruppen) geringer ist als die verbrauchte Kapazität der größten Festplatten­gruppe, dann muss man Verringerte Redundanz zulassen als Daten­migrations­option auswählen.

    Bei knappem Speicherplatz sollte man die Option "Verringerte Redundanz zulassen" aktivieren.

    Außerdem ist es wichtig, dass beim Upgrade des Festplatten­formats kein Host mehr im Wartungs­modus ist, weil er dann ja keinen Speicher mehr zum Cluster beiträgt und sich so die Cluster-Kapazität automatisch reduziert.

    Startet man die Aktualisierung, dann weist der Assistent drauf hin, dass ein Upgrade des vSAN-Festplatten­formats viel Zeit in Anspruch nimmt. Sobald es aktualisiert wurde, ist eine Wieder­her­stellung der Software auf den Hosts oder das Hinzufügen älterer ESXi-Versionen zum Cluster nicht mehr möglich.

    Anschließend muss man nur unter Überwachen bei vSAN => Skyline-Integrität die Integrität wieder­herstellen, indem man auf den Link Objekte sofort reparieren klickt.

    Integrität der vSAN-Objekte wiederherstellen

    Diesen Vorgang muss man so sooft wiederholen, bis der Zähler bei Objektzählung auf Null steht. In unserem 2-Knoten-Cluster müssen wir das recht häufig tun, doch je größer die Anzahl physischer Hosts, desto schneller ist das vSAN wieder integer.

    Wir klicken jetzt erneut auf Festplatten­format aktualisieren und beobachten den Prozess in der Ereignis­anzeige.

    Konvertierung des Festplattenformats in der Ereignisanzeige verfolgen

    Wie erwähnt kann der Vorgang recht lange dauern.

    Update des Zeugen-Hosts

    Bei einem weiteren Punkt ist Vorsicht geboten: In einem 2-Knoten-Cluster muss auch der Witness-Host aktualisiert werden, und zwar vor dem Festplatten­format. In unserem Beispiel befindet sich der Zeuge noch auf Version 6.7.

    Er trägt zwar nicht zur Cluster-Kapazität bei, würde sich aber nicht mehr als Witness im vSAN-7-Cluster mit Festplatten­version 11 verwenden lassen.

    ESXi-Version des Zeugenknotens anzeigen

    Da es sich hierbei um einen ganz gewöhnlichen, wenn auch virtuellen, ESXi-Hosts handelt, könnte man diesen tatsächlich mit VUM aktualisieren. Komfortabler und schneller ist es aber meist, die Witness-Appliance in Version 7 neu bereit­zustellen und anschließend in der Fault-Domain-Konfi­guration zu ersetzen.

    Die 7er Version der Appliance gibt es zum Download bei VMware. Nachdem wir das OVA in unsere Inhaltsbibliothek importiert haben, könnten wir von dort aus im Menü Aktionen => Neue VM über diese Vorlage die neue Appliance einfach bereitstellen.

    Neue Witness-Appliance als OVA importieren

    Das Formular des Assistenten ist schnell ausgefüllt. Ich habe das Vorgehen bereits in diesem Artikel erklärt.

    Einstellungen für die neue Witness-Appliance beim Import konfigurieren

    Danach muss man den von der Witness-VM bereit­gestellten Zeugen als Host zu vCenter hinzufügen, allerdings nicht zum vSAN-Cluster.

    Neue Witness-Appliance als Host zu vCenter hinzufügen

    Zum Austauschen des Witness-Hosts navigiert man bei markierten Cluster im Tab Konfigurieren zu vSAN => Fehlerdomänen und klickt recht oben auf Zeugenhost ändern.

    Neuen Zeugenhost in der Fehlerdomäne konfigurieren

    Sofern auf dem hier angegebenen Witness-Host ein vSAN-Kernel-Adapter existiert, wird er auch als kompatibel markiert. Nach kurzer Zeit sollte der Wechsel erfolgreich abgeschlossen sein. Der alte Witness kann jetzt entsorgt werden.

    Keine Kommentare