vCenter Server Appliance (vCSA) auf Version 6.7 aktualisieren

Ein Upgrade auf vCSA 6.7 erfolgt über den Assi­stenten des Installers, und zwar durch die Migration auf eine neue Appliance. Dieser Vor­gang unter­scheidet sich von der Neu­instal­lation in einigen wich­tigen Punkten. Zuvor muss man jedoch einige Voraus­setzungen beim Quell- und Ziel­system sowie beim Netz­werk schaffen.

Werfen wir zunächst einen Blick auf das Quellsystem, also den Host oder den Cluster, auf dem die bestehende Appliance läuft. Befindet sich der Host in einem DRS-Cluster, dann muss DRS für die Dauer der Migration auf manuell gesetzt werden, damit VMs wie die Quell-Applicance nicht im Verlauf des Upgrades verschoben werden.

Voraussetzungen beim Quellsystem

Ferner muss auf der "alten" Appliance Port 22 (SSH) geöffnet sein, da beim Upgrade eine eingehende SSH-Verbindung aufgebaut wird, um die exportierten Daten herunter­zuladen.

Zusätzlich muss auch der Port 443 auf dem ESXi-Quellhost geöffnet sein, denn zu ihm wird beim Upgrade-Vorgang eine HTTPS-Verbindung aufgebaut, um zu überprüfen, ob die Appliance bereit für das Upgrade ist. Zudem muss ausreichend freier Festplatten­speicher vorhanden sein, um die Daten für das Upgrade auswählen können.

Ist auf dem Quell­system ein externer vSphere Update Manager (VUM) konfiguriert, dann muss der Migration Assistant auf der VUM-Quell­maschine aus­geführt werden. Details dazu, wie dieser Assistent vor dem Upgrade manuell herunter­geladen und gestartet wird, finden sich in der VMware-Dokumentation.

Auch bezüglich der Datenbank gilt es aufzupassen: Die Anwender können nämlich Daten von einer externen Datenbank der vorhandenen vCenter Server Appliance in eine eingebettete PostgreSQL-Datenbank von vCSA 6.7 übertragen. Das gilt übrigens nur für vCSA 5.5 oder 6.0, welche alternativ zur internen vPostgreSQL auch eine externe Oracle-Datenbank unterstützten. Die Versionen 6.5 und 6.7 verwenden ausschließlich eine eingebettete Datenbank.

Dabei richtet sich die Mindest­speicher­größe für die neue Appliance nach dem Umfang der externen Datenbank, was auch erklärt, warum man während der Bereitstellung für den Speicher verschiedene Größen wählen kann. Weitere Informationen zur Support-Matrix und den zulässigen Upgrade-Pfaden im Zusammen­hang mit einer externen Datenbank finden sich in der Dokumentation.

Eine externe Datenbank sollte man vor dem Upgrade in jedem Fall sichern. Im Verlauf des Upgrades kann es nämlich zu Problemen mit der Datenbank kommen.

Voraussetzungen für Zielsystem und Netzwerk

Auch für das Zielsystem gilt es neben den üblichen Mindest­anfor­derungen an Soft- und Hardware einige Voraus­setzungen zu beachten. So muss man beispiels­weise überprüfen, ob sich der ESXi-Zielhost nicht im Sperr- oder Wartungs­modus befindet. Außerdem darf der Ziel-ESXi nicht Teil eines voll­automa­tisierten DRS-Clusters sein.

Schließlich gilt es noch einige Voraus­setzungen beim verwendeten Netzwerk zu beachten. So muss die neue Appliance eine Verbindung zum ESXi-Quellhost oder dem vCenter Server herstellen können, auf dem sich die alte Appliance befindet.

Möchte man in den temporären Netzwerk­einstellungen der Appliance eine statische IP-Adresse und einen FQDN als System­namen zuweisen, dann müssen die Forward- und Reverse-DNS-Datensätze für diese IP-Adresse konfiguriert werden. Alternativ kann man auch die temporäre IP-Adresse über DHCP zuweisen lassen.

Auch dazu muss der ESXi-Host, auf dem die neue Appliance bereitgestellt wird, im selben Netzwerk sein wie der ESXi-Host, auf dem die vorhandene vCenter Server Appliance läuft. Er muss also mit mindestens einem Netzwerk verbunden sein, das mit einer Portgruppe verknüpft ist, die Änderungen an MAC-Adressen akzeptiert.

Die zugehörige Portgruppen-Eigenschaft heißt MAC-Adressänderungen und findet sich im Abschnitt Sicherheit des betreffenden vSwitches oder der Portgruppe, von dem diese Einstellungen geerbt wurden. Dies ist vor allem bei einem Distributed vSwitch wichtig, dessen Standard­sicherheits­richtlinie Änderungen an MAC-Adressen ablehnt.

Schließlich ist es vor dem Start des Migrations­assistenten empfehlens­wert, einen Snapshot der vorhandenen Appliance anzulegen für den Fall, dass es während des Upgrades zu einem Fehler kommt.

Aktualisiert man ein vCenter Server Appliance mit einem externen Platform Services Controller (PSC), dann sollte man selbst­verständlich auch diesen vorab per Snapshot sichern.

Immer eine gute Idee ist es auch, die von VMware mit Version 6.5 eingeführte Option zu nutzen, die Konfi­guration der Appliance über die Management Shell zu sichern.

Ablauf des Upgrades

Der Upgrade-Prozess gliedert sich wie die Neu­installation in zwei Phasen, wobei der Assistent zunächst einer Verbindung zur Quell-Appliance konfiguriert.

Im Unterschied zur Phase 1 bei der Neu­bereit­stellung konfiguriert der Assistent die neue Appliance zunächst mit temporären Netzwerk­einstellungen.

Hierbei spricht dann, wie oben erwähnt, nichts gegen das Verwenden von DHCP und den Verzicht auf einen FQDN.

In dieser Phase wird das vCSA mittels OVA-Datei auf dem Zielserver mit demselben Bereit­stellungstyp eingerichtet wie die Quell-Appliance, außerdem werden die vom Nutzer angegebenen Appliance-Einstellungen berücksichtigt.

Alternativ zur Durchführung der ersten Upgrade-Phase mit dem GUI-Installations­programm kann man die OVA-Datei für die neue vCenter bzw. PSC-Appliance einfach mit dem vSphere Web Client oder dem VMware Host Client importieren.

Die Konfiguration des Phase 1 ist damit abgeschlossen und dem Bereitstellen des OVAs mit eingebettetem PSC steht nicht mehr im Weg.

Phase 2 des Uprades auf vCSA 6.7

Während die Phase 2 bei einer Neu­installation im Wesentlichen die SSO-Konfiguration am Platform Services Controller abschließt, wählt der Admin in Phase 2 des Upgrade-Assistenten die Daten aus, die von der alten auf die neue Appliance übertragen werden sollen.

Die neue VM verwendet die temporären Netzwerk­einstellungen, bis die Daten­übertragung abge­schlossen ist. Danach übernimmt sie die Konfiguration der alten vCSA. In dieser Phase starten zudem die Dienste der neuen Appliance und die alte vCSA wird ausgeschaltet. Phase 1 leitet übrigens automatisch in Phase 2 über.

Sollte man dabei zu lange gewartet haben, so dass die Session terminiert wurde, muss man sich innerhalb des Assistenten erneut mit dem root-Passwort an der Appliance anmelden.

Hat man ver­sehentlich den Assistenten beendet, muss man sich lediglich wieder mit der Management Shell der neuen Appliance auf Port 5480 verbinden und wird dann automatisch wieder zum GUI-Installations­programm der Phase 2 geführt.

Auf diesem Weg würde man übrigens hier einsteigen, wenn man die Phase 1 nicht mit Hilfe des Assistenten, sondern durch direktes Einspielen des OVA für die Ziel-Appliance erledigt hat. In diesem Fall würde man hier auf Set up klicken.

Vor dem eigentlichen Upgrade, also dem Übertragen der Daten, führt der Assistent eine Reihe von Prüfungen durch. Wenn es gut läuft, präsentiert der Upgrade-Check lediglich eine Reihe von Warnungen (gelb). Den Hinweis auf ein ggf. zu deaktivierendes DRS im Automatic Mode hatten wir schon erläutert.

Ferner weist der Assistent darauf hin, dass einige externe vCenter-Erweiterungen wie das vCOPS-Plugin nun nicht mehr funktionieren, und dass vorhandene Dateien, die vCenter 6.7 nicht mehr verwendet, beim Upgrade ebenfalls verworfen werden.

Der Upgrade-Check würde im Übrigen auch erkennen, wenn sich Quell- und Ziel-Appliance nicht im gleichen Subnet befänden. Sind alle Voraus­setzungen soweit erfüllt, dann steht der Fertig­stellung nichts im Wege und man kann im nächsten Schritt die Upgrade-Daten auswählen, die man übernehmen möchte:

• Nur Konfiguration
• Konfiguration und Verlaufsdaten
• Konfiguration und Verlaufsdaten (inklusive Leistungsmetriken).

Der Installer gibt dabei auch die geschätzte Upgrade-Zeit an, während der vCenter nicht verfügbar sein wird, wenn man nur die Konfiguration einschließt. Ferner kann und muss man ein Export directory festlegen, sofern die Root-Partition der Source-Maschine weniger als 4GB freien Disk-Speicher hat. Wenn auch das passt, kann das Upgrade fertiggestellt werden.

Vorgehen bei komplexeren Umgebungen

Weitere Informationen hierzu, sowie zum Upgrade komplexerer Architekturen mit externen Platform Service Controllern sowie zur Migration von einer Windows-vCenter-Version 6.7 finden sich VMware-Whitepaper vCenter Server-Upgrade - VMware vSphere 6.7.

So ist etwa bei einer Bereitstellung von mehr als zwei Knoten zu beachten, dass VMware in seiner Anleitung empfiehlt, eine Ring-Replikations­topologie zwischen den PSC-Knoten zu erstellen, egal ob diese extern oder eingebetteten sind.

Schaut man sich zudem die JSON-Templates für die CLI-basierte Bereitstellung an, dann wird man feststellen, dass im ISO-Image der Version 6.7 unter \vcsa-cli-installer\templates\install zwei neue Vorlagen für die Bereitstellung der zweiten oder weiteren eingebetteten vCSA-Replikations­knoten hinzuge­kommen sind, und zwar je eine für ESXi und vCenter Server.

Man verwendet also eine der beiden ersten Vorlagen für die Bereitstellung des ersten Knotens und dann eine der beiden weiteren Vorlagen für nach­folgende Knoten, abhängig vom Bereitstellungs­ziel (für ESXi oder vCenter).