Text, Bildergalerie und Video: Das VMware vCenter Upgrade Schritt für Schritt von der vCenter-Version 6.5 zur Version 6.7

VMware hat Ende April mit „vSphere 6.7“ ein überraschend umfassendes Minor-Release seiner Servervirtualisierungsplattform eingeführt. Dieses umfasst nicht nur den Hypervisor, sondern das gesamte Produktökosystem samt neuer Versionen von „vCenter“, „Operations Manager“, „vSAN“ und „Loginsight“. Dieser Beitrag befasst sich mit dem Upgrade-Pfaden von „vSphere 6.5“, insbesondere für die „vCenter-Appliance“ (VCSA).

Anbieter zum Thema

VMware Global Inc Zweigndl. Deutschland

Dell GmbH

Fujitsu Technology Solutions GmbH

Nachdem wir im letzten Teil unserer „vSphere-Webcast“-Serie vorrangig einen Blick auf die neuen Features für Hypervisor und vCenter geworfen und die Neuinstallation einer vCenter Appliance 6.7 illustriert haben, geht es diesmal um das Thema Upgrade.

Text und Video zu vSphere 6.7 und den Updates 1 plus 2

Die Funktionen in vSphere 6.7 taugen zum Antörnen

Back-portiert im Minor-Release 6.7

VMware bringt Update 2 für vSphere 6.5

In freier Wildbahn werden sich die weitaus meisten Unternehmen eher mit dem Upgrade- oder Migrationsthema auseinandersetzen, als mit einer kompletten Neuinstallation ihrer Virtualisierungslandschaft. Grundsätzlich muss man beim Upgrade-Thema vier Komponenten auseinanderhalten beziehungsweise getrennt behandeln:

• vCenter-Server

• ESXi-Hosts (Hypervisor)

• virtuelle Maschinen

• VMware-Solutions

Letztere sind Zusatzkomponenten wie etwa „vRealize Operations Manager“ oder „vRealize LogInsight“. Die einzelnen Teilaufgaben sollten auch in dieser Reihenfolge behandelt werden. Prinzipiell gibt die VMware Interoperabilitätsmatrix über mögliche Upgrade und Migrationspfade Auskunft.

Wie man ein Upgrade plant und durchführt ist ebenfalls grundsätzlich nicht schwierig und mit den zahlreichen hervorragenden Informationen im „VMware Upgrade Center“ gut planbar. Auch dieses empfiehlt die Upgrade-Reihenfolge vCenter->ESXi->VMs->Solutions, wobei es im Einzelfall von der konkreten Situation abhängt, wie komplex sich der Upgrade-Vorgang gestaltet.

Herausforderung Multi-Site

Kompliziert wird es vor allem dann, wenn Single-Sign-On in mehreren verlinkten vCenter-Anwendungen, möglicherweise noch Multi-Site mit unterschiedlichen Betriebssystemen zum Einsatz kommt. Dies ist ja auch einer der wichtigsten Gründe, eine vCenter-Version 6.5 U2 oder 6.7 auf Basis der Appliance anzustreben. Die Appliance bietet schon seit der Version 6.0 dank des ausgelagerten „Platform Service Controller“ einen deutlich einfacher konfigurierbaren „Advanced Linked-Mode“ (ALM) und damit eine bessere SSO-Konfiguration. Großen Anteil daran hat ebenso wie an der mit vSphere 6.5 eingeführten „vCenter-HA“-Funktion die eingebettete „vPostgres“-Datenbank.

Ebenfalls einem geplanten Upgrade förderlich ist die ab Version 6.5 nur in der Appliance enthaltene Backup-Funktion. Neu in Version 6.7 ist die noch einmal deutlich vereinfachte SSO-Konfiguration auf Basis eines vereinfachten Multi-Site-Deployment-Modes auch mit eingebetteten Platform-Service-Controllern.

Grundsätzlich ist für Unternehmen daher anzustreben, bestehende „Windows-vCenter“ los zu werden, da diese nicht nur das Deployment in Multi-Site-Setups, sondern auch das Datenbank-Backup erschweren oder allgemein keine eingebaute Backup-Funktion bieten und ab Version 7 von VMware nicht mehr unterstützt werden. Auch die HA-Funktion fehlt der Windows-Version gänzlich. Wer bereits auf VCSA-Level operiert, sollte zumindest ein Upgrade von Version 6.0 auf 6.5 oder 7 anstreben.

Für beide Funktionen bietet der „vCenter-Deployment-Assistent“ ab Version 6.5 eine eingebaute Menü-Optionen im grafischen Installer für Migration (von Windows auf Linux/Appliance) oder „Migration“ von Version 5.5 oder 6.0 auf 6.5 oder 6.5 auf 6.7.

Doppelter Boden

Grundsätzlich ist es für jede Art von Update/Upgrade unabdingbar, alle im Unternehmen verfügbaren Backup-, Failover und Sicherheitsinstrumente im Kontext des jeweiligen Produktes zu nutzen. Für den ESXi-Host sorgt VMware hierbei bereits selbst, da das Standard-ESXi-FAT-Partitionslayout mit seinen 7 Partitionen stets zwei Systempartitionen vom Typ „linuNative“ von 250 MB für die Installationspakete (VIBs) bereit hält, von denen jeweils eine (Partition Nr. 5 im Dateisystem unter /bootbank gemountet) das jeweils aktuelle System und die „andere“ (Partition Nr. 6 im Dateisystem unter /altbootbank gemountet) enthält.

Sollte also im Verlauf der Installation etwas schieflaufen, würde ESXi einen Fallback auf die alte Version durchführen. Es ist aber trotzdem ratsam, auch die Host-Konfiguration zu sichern. Besonders komfortabel gelingt das vom vCenter aus mit Hilfe des Features Host-Profile, aber auch die Kommandozeile oder PowerCLI bietet dazu Gelegenheit. Da das ESXI-Upgrade hier nicht Thema ist, verweisen wie auf die einschlägigen Suchmaschinen.

Das Sichern bestehender VMs über ein dazu geeignetes Backup-Programm solle ohnehin eine Selbstverständlichkeit sein, ebenso wie die Tatsache, dass VMs nicht auf einen lokalen Host-Storage, sondern einen Shared-Storage gehören, der vom Upgrade-Prozess normalerweise nicht betroffen ist. Wird NFS /NAS als Shared Storage verwendet, lassen sich VMs zusätzlich noch über das Dateisystem wegsichern.

Trotzdem ist es im Verlauf der ESXi-Installation ratsam, etwaige lokal angebundene VMFS-Partitionen beziehungsweise deren Speicher-Controller abzuziehen oder die Verbindung zum SAN zu kappen, um bei einem Upgrade nicht versehentlich die falsche Partition zu überschreiben. Unglücklich wäre es auch, die Host-Konfiguration mit den korrekten Einstellungen für die Speicheradapter und Netzwerkadapter im Verlauf des Upgrades zu verlieren. Dann müsste man den Host erst mühevoll händisch soweit konfigurieren, bis er wieder an seinen Speicher kommt.

Das vCenter Backup

Was ein vor dem Upgrade ebenfalls sehr empfehlenswertes Backup des vCenter angeht, gibt es - nicht zuletzt durch Einführung der Appliance und insbesondere der Version 6.0 - inzwischen zahlreiche Möglichkeiten. Vom Upgrade „on the fly“ ohne Downtime mit automatischen Failover in einem Setup mit hochverfügbarem vCenter (vCenter HA oder eigene Lösung) bis zur manuellen Sicherung der VCSA-VM, der unterliegenden Datenbank und der vCenter-Konfiguration Vieles möglich.

Das Sichern der VCSA-VM kann zum Beispiel im Rahmen des oben erwähnten normalen VM-Backup-Zyklus sozusagen außerhalb des normalen Schedule erfolgen. Mit der mit Version 6.5 der Appliance eingeführten Backup- und Wiederherstellungs-Funktion, welches über das VAMI-Interface auf Port 5480 erreichbar ist, lassen sich zudem Konfiguration und Daten der vCenter-Appliance per FTPS/FTPS oder HTTP/HTTPS s sichern, einschließlich der Einstellungen der integrierten Dienste „Auto Deploy“ und „Update Manager“.

Alternativ kann das Feature auch über die APIs durch externe Tools angesteuert werden. Jedes Backup enthält eine Reihe von Dateien, die via HTTP(S), SFTP oder SCP auf ein Ziel-Storage-System übertragen werden. Für eine Wiederherstellung klickt man im UI-Installer des gemounteten ISOs auf das „Restore“-Menü.

Die VCSA-Migration

Im gleichen Menü verbergen sich auch die Funktionen für das Neuaufsetzen der VCSA, wie im letzten Teil dieser Serie gezeigt sowie für die Migration und ein Upgrade der VCSA auf Version 6.7. Der Menü-Eintrag „Migrate“ bezieht sich dabei auf eine Migration eines Windows vCenter 6.0 oder 6.5 auf die Appliance in Version 6.7. Die Migration ist nur für die Richtung von Windows zu Linux gedacht. Das sich hinter dem Feature verbergende Migrations-Tool gab es zwar auch früher schon, allerdings nur als separates Tool, welches aber lediglich den Sprung von vSphere 5.5 auf 6.0 beherrscht.

Mit der im Installer der Versionen 6.5 und 6.7 integrierten Version gelingt auch eine Migration auf die neuste Version. Das Migrations-Feature setzt voraus, das VCSA-6.7-ISO zunächst auf dem Windows-vCenter-Quellsystem zu mounten und dort aus dem Unterverzeichnis „migration-asssitant“ das Tool „VMware-Migration-Asssitant.exe“ zu starten. Es führt einen Pre-Migration-Check durch und nimmt anschließend Verbindung mit dem auf dem Staging-Host noch einmal gestarteten Migration-Tool auf, das letztendlich das Ziel-System generiert.

Erst dann lässt sich der Punkt „Migrate“ auch tatsächlich auswählen. Das Quell-System überträgt dabei unter anderem auch Migrations-Logs an die Ziel-VCSA.

Das VCSA-Upgrade

Etwas anders funktioniert das Upgrade-Feature. Dieses bezieht sich auf eine bestehende VCSA-Version 6.0 oder 6.5. Das Upgrade sieht zwar das Deployment einer komplett neuen VCSA-VM 6.7 vor, diese erhält aber im Verlauf der Migration eine identische Konfiguration einschließlich der Netzwerkdaten der Ursprungs-Appliance sowie den aktuellen Datenbestand der unterliegenden vPostgres-Datenbank.

Dabei wird das Zielsystem im Verlauf des Vorgangs eine temporäre IP-Konfiguration verwenden und das Quellsystem im Anschluss an eine erfolgreiche Migration abschalten. Hinsichtlich der Konfiguration bleibt sie jedoch unverändert, so dass bei einem problematischen Verlauf des Vorgangs jederzeit ein Rollback möglich ist. Vor dem Start des Upgrade-Vorgangs sollte man sich aber unbedingt mit dem https://kb.vmware.com/s/article/54008 VMware-Best-Practises für das vCenter-Upgrade auf Version 6.7 beschäftigen.

Folgende Bilder-Galerie illustriert die notwendigen Schritte in Anlehnung an die in unserem letzten Beitrag bereits gezeigte Neuinstallation. Das anschließende Video zeigt den kompletten Vorgang:

Bilder-Galerie

Bildergalerie

Bildergalerie mit 14 Bildern

Das Video im Youtube-Kanal von DataCenter-Insider

(ID:45401272)