Tags: vCenter, Migration, vSphere
Ein Upgrade auf vCSA 6.7 erfolgt über den Assistenten des Installers, und zwar durch die Migration auf eine neue Appliance. Dieser Vorgang unterscheidet sich von der Neuinstallation in einigen wichtigen Punkten. Zuvor muss man jedoch einige Voraussetzungen beim Quell- und Zielsystem sowie beim Netzwerk 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 herunterzuladen.
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 Festplattenspeicher vorhanden sein, um die Daten für das Upgrade auswählen können.
Ist auf dem Quellsystem ein externer vSphere Update Manager (VUM) konfiguriert, dann muss der Migration Assistant auf der VUM-Quellmaschine ausgeführt werden. Details dazu, wie dieser Assistent vor dem Upgrade manuell heruntergeladen 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 Mindestspeichergröß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 Zusammenhang 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 Mindestanforderungen an Soft- und Hardware einige Voraussetzungen zu beachten. So muss man beispielsweise überprüfen, ob sich der ESXi-Zielhost nicht im Sperr- oder Wartungsmodus befindet. Außerdem darf der Ziel-ESXi nicht Teil eines vollautomatisierten DRS-Clusters sein.
Schließlich gilt es noch einige Voraussetzungen 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 Netzwerkeinstellungen der Appliance eine statische IP-Adresse und einen FQDN als Systemnamen 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 Standardsicherheitsrichtlinie Änderungen an MAC-Adressen ablehnt.
Schließlich ist es vor dem Start des Migrationsassistenten empfehlenswert, 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 selbstverstä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 Konfiguration der Appliance über die Management Shell zu sichern.
Ablauf des Upgrades
Der Upgrade-Prozess gliedert sich wie die Neuinstallation in zwei Phasen, wobei der Assistent zunächst einer Verbindung zur Quell-Appliance konfiguriert.
Im Unterschied zur Phase 1 bei der Neubereitstellung konfiguriert der Assistent die neue Appliance zunächst mit temporären Netzwerkeinstellungen.
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 Bereitstellungstyp 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-Installationsprogramm 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 Neuinstallation 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 Netzwerkeinstellungen, bis die Datenübertragung abgeschlossen 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 versehentlich 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-Installationsprogramm 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 Voraussetzungen soweit erfüllt, dann steht der Fertigstellung 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-Replikationstopologie 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-Replikationsknoten hinzugekommen 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 nachfolgende Knoten, abhängig vom Bereitstellungsziel (für ESXi oder vCenter).
Täglich Know-how für IT-Pros mit unserem Newsletter
Seine Themenschwerpunkte sind Virtualisierung und Cloud Computing, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zertifizierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas ist außerdem zertifizierter AWS Solutions Architect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Administrator.
Thomas führt aktuell jeden zweiten Montag einen 4-tägigen Grundlagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Informationen und Anmeldung über sein AWS-Blog.
Ähnliche Beiträge
- Upgrade auf vCenter 7: Vorbereitungen treffen und mit der Quell-VM verbinden
- Update auf vCenter 7 Appliance: Voraussetzungen und Einschränkungen
- Cross-vCenter und Long-Distance vMotion in VMware vSphere
- VMware bringt vSphere 6.5 Update 2, Support für Embedded Linked Mode
- VMware vCenter auf vCSA migrieren: Support für Server 2012 R2
Weitere Links