Neues vCSA-Setup beachten
Die vCenter Server Appliance (vCSA) wird nach wie vor als OVA-Datei bereitgestellt, die bei Verwenden des Setup-Szenarios "Sehr klein" eine virtuelle Maschine mit 8 GByte RAM und 125 GByte Festplattenplatz, einschließlich eingebetteter vPostgres-Datenbank und eingebetteten Platform Services Controller (bei Thin Provisioning) ausrollt.
Im Vergleich zu VCSA 5.5 hat sich allerdings am Deployment-Prozess, sowie bei der Konfiguration und Administration einiges geändert. Ersterer wurde mit dem Bereitstellungprozess der Windows-Variante vereinheitlich mit der Konsequenz, dass man nicht mehr die OVA-Datei importiert, sondern lediglich nach dem Einbinden des ISOs auf dem Bereitstellungs-Host die Datei "setup.html" ausführt. Das Setup initiiert den Browser-basierten Upgrade-/Migrationsprozess, der im Installationsverlauf mit Hilfe eines Assistenten die gesamte Konfiguration der neuen vCSA erfragt.
Dies ist ein bedeutender Unterschied zur Vorgängerversion 5.5, welche lediglich als OVA ausgerollt und anschließend in einem eigenen Webinterface auf dem HTTPS-Port 5480 eingerichtet wurde.
Upgrade-Schema festlegen
Ausgangspunkt der Upgrade-Prozedur ist eine Bereitstellungsmaschine mit aktuellem Browser und installiertem "VMware Client Integration Plugin-6.0.0 (CIP). Dessen Installation wird automatisch eingeleitet, startet man "vcsa-setup.html" im zuvor von VMwares Downloadcenter heruntergeladenen und eingebundenem ISO "VMware-VCSA-all-6.0.0-2656757.iso". Das CIP-Plugin befindet sich im Unterverzeichnis vcsa, genau wie die eigentliche OVA-Datei der virtuellen Appliance, die allerdings mangels Datei-Endung nicht sofort zu erkennen ist.
Entscheidet man sich nach dem Installieren des CIP mit "Upgrade durchführen" für den "vCenter Upgrade Manager", möchte der zunächst wissen, ob das Upgrade von vCenter 5.1 U3 oder 5.5 erfolgen soll.
VMware nennt den Vorgang zwar "Upgrade", faktisch handelt es sich aber um eine Migration, in deren Verlauf der Upgrade Manager eine neue VM erzeugt. Dabei werden die Netzwerkeinstellungen samt Datenbank mit dem kompletten Inventar, sowie die aktuellen Leistungsdaten zwischengespeichert. Danach schaltet der Migrationsprozess die alte VM ab sowie die neue VM ein und importiert dann sämtliche Daten über ein temporär eingerichtetes Netzwerk.
Foto: Thomas Drilling
Foto: Thomas Drilling
Hat der Assistent die Angaben validiert, bestätigt man das Zertifikat und legt einen Namen für die neue Appliance fest. Darüber hinaus muss der Anwender das Betriebssystemkennwort des Linux-Root-Accounts der auf Suse Linux Enterprise (SLE) basierenden Appliance vergeben.
Angaben zur Quell-VCSA konfigurieren
Im entscheidenden Schritt "Verbindung herstellen mit Quell-Appliance" ist zuerst die Version der Quell-VCSA anzugeben, die auf die neue Version 6 migriert werden soll, zum Beispiel 5.5. Es folgen die Zugangsdaten (Name, Benutzername und Kennwort) des vCenter Administrators.
Foto: Thomas Drilling
Achtung: Dies kann entweder der vCenter-Administrator der lokalen Single-Sign-On-Datenbank (SSO) sein (Administrator@vsphere.local) oder ein Windows-Administrator-Konto im Active Directory, wenn das vCenter Mitglied einer Windows Domäne ist. Zusätzlich benötigt der Assistent das root-Kennwort (Linux) der "alten" Appliance, unter anderem, um Zugang zur Datenbank zu erlangen.
Danach gibt der Nutzer einen temporären Export-Folder an oder übernimmt den unterbreiteten Vorschlag und aktiviert bei Bedarf die Option, auch die aktuellen Leistungsdaten und sonstige Verlaufsdaten zu exportieren.
Quell-ESXI-Host definieren
Im Bereich "Quell-ESXi-Host" sind dann Benutzername und Kennwort des ESXi-Hosts angeben, auf dem die Quell-Appliance läuft. Die Angaben müssen von Assistenten erfolgreich validiert werden können. So sollte sich zum Beispiel der vCenter-Hostname in einer vSphere-Umgebung via DNS auflösen lassen.
War die Validierung erfolgreich, weist der Assistent darauf hin, dass Port 22 im Verlauf des Upgrade-Vorgangs zum Übertragen von Daten über ssh verwendet wird, was gegebenenfalls beim Betrieb einer Firewall zwischen beiden Maschinen zu bedenken ist. Der sshd wird dazu automatisch gestartet.
Im Folgeschritt gibt man noch die Appliance-Größe passend zur Größe der geplanten Umgebung an, die von der Größe und Anzahl der einzurichtenden virtuellen Discs beziehungsweise VMDK-Dateien,sowie die Größe der vPostgres-Datenbank abhängen. Danach ist ein Datastore für die virtuelle Appliance auszuwählen. Wer möchte, kann die Bereitstellung mittels Thin Provisioning beschleunigen.
Temporäres Netzwerk einrichten
Schließlich ist das temporäre Netzwerk für das Übertragen der Einstellungen von der Quell- zur Ziel-Appliance zu konfigurieren, wobei die Netzwerkadresse nicht mit der des (noch aktuellen) Quellsystems kollidieren darf. Am schnellsten führt hier DHCP zum Ziel.
Nach Fertigstellung der Migration übernimmt die neue Appliance die Netzwerkidentität und braucht die temporären Einstellungen nicht mehr. Mit dem Bestätigen der Zusammenfassung kümmert sich der Assistent um alles Weitere. Nach dem Importieren der OVA-Datei startet dieser das Einrichten der Ziel-VM, Migrieren der Daten und kümmert sich um das Abschalten der alten Appliance. Zusätzlich übernimmt die Appliance die Kontrolle über sämtliche benötigten Services wie zum Beispiel den PSC, SSO, Inventory, Web-Client und so weiter.
Finale Fertigstellung kontrollieren
Bei Erfolg kann man sich wahlweise an der neu gestalteten Portalseite oder direkt am Web-Client (9443), sowie via Konsole (gegebenenfalls auch bei SSH) an der vCenter 6 Appliance-Shell anmelden.
Foto: Thomas Drilling
Der Konsole-Login erlaubt unter anderem das Auflisten sämtlicher API-Befehle und Plugins, zum Beispiel mit "help api list" beziehungsweise "help pi list". Um auf die BASH der Appliance zu gelangen genügt dann das Eingeben von
shell.set --enabled True
gefolgt
shell
Foto: Thomas Drilling
Damit ist die das Upgrade der Virtual Center Server Appliance auf Version 6 abgeschlossen. (hal)