Sie möchten Legacy-Anwendungen auf End-of-Life-Betriebssystemen in die Google Cloud verlagern? Dann ist dieser Beitrag genau richtig. Wir zeigen Ihnen, welche Optionen es gibt, um virtuelle Maschinen mit EOL-Betriebssystem in Google Compute Engine zu importieren.
Legacy-Anwendungen am Ende ihres Lebenszyklus – wie sieht die Realität aus?
Bei DoiT International begegnen uns Kunden in den unterschiedlichsten Phasen ihrer Cloud-Reise. Manche sind bereits cloud-native unterwegs und haben kaum technische Schulden, andere schleppen aus den verschiedensten Gründen Legacy-Anwendungen mit. Einige bemühen sich, diese aktuell zu halten – andere landen genau im Szenario dieses Artikels: ungeliebte Legacy-Anwendungen, die auf End-of-Life-Betriebssystemen (EOL) laufen. Wenn Sie solche Anwendungen in die Google Cloud verlagern möchten, ist dieser Artikel für Sie gedacht. Sie erfahren, welche Optionen Ihnen offenstehen – und treffen damit hoffentlich die richtige Entscheidung für Ihre workloads.
Anlass für den Artikel war die Beobachtung, dass mehrere Kunden Google Cloud VMware Engine (GCVE) ins Auge fassten, um ihre Legacy-Anwendungen in der Google Cloud zu betreiben. Da unter der Haube VMware steckt, ist GCVE durchaus eine gute Möglichkeit, bestimmte VMs zu betreiben – auch solche mit EOL-Betriebssystemen. Der Haken: GCVE skaliert für kleinere workloads nicht gut nach unten und ist nur dann kosteneffizient, wenn Sie die Ressourcen in der kleinstmöglichen Konfiguration auch wirklich auslasten.
GCVE ist also durchaus eine Option, um Legacy-Anwendungen in der Google Cloud zu betreiben – meine erste Wahl wäre es allerdings nur, wenn Ihre workloads diese Größenordnung tatsächlich erfordern. Dazu später mehr.
Ich habe untersucht, warum Kunden zu dem Schluss kamen, sie bräuchten GCVE für ihre Legacy-EOL-Anwendungen, und bin auf einige Stolpersteine gestoßen:
Zunächst sah ich Kunden, die versuchten, neue virtuelle Maschinen aus EOL-Betriebssystemen wie Centos 6 zu erstellen. Sie werden schnell feststellen, dass das entsprechende Image nicht mehr in Googles öffentlich verfügbaren Images aufgeführt ist. Okay – wie geht es weiter?
Der nächste Schritt war der Versuch, die Importfunktion von Google Compute Engine zu nutzen, mit der sich VM-Images ad hoc importieren lassen. Man würde erwarten, dass das auch mit älteren OS-Versionen funktioniert. Doch beim Versuch, ein EOL-OS – in diesem Beispiel Centos 6 – zu importieren, gab es ernüchternde Nachrichten:
$ gcloud compute instances import centos-6 --source-uri=gs://eol-migration1322/centos6 --zone=us-central1-a
WARNING: Importing OVF. This may take 40 minutes for smaller OVFs and up to a couple of hours for larger OVFs.
Created [https://cloudbuild.googleapis.com/v1/projects/johnd-test-01/locations/us-central1/builds/0e67bbb8-3389-4a34-adae-5f5566732085].
Logs are available at [https://console.cloud.google.com/cloud-build/builds;region=us-central1/0e67bbb8-3389-4a34-adae-5f5566732085?project=306419495665].
starting build "0e67bbb8-3389-4a34-adae-5f5566732085"
[import-ovf]: 2022-07-05T21:25:20Z Starting OVF import workflow.
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6.ovf
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6-disk1.vmdk
[import-ovf]: 2022-07-05T21:25:21Z Didn't find valid OS info in OVF descriptor. OS will be detected from boot disk.
[import-ovf]: 2022-07-05T21:25:21Z Will create instance of `g1-small` machine type.
[import-disk-1]: 2022-07-05T21:25:22Z Inspecting the image file...
[import-disk-1]: 2022-07-05T21:28:26Z Inspecting disk for OS and bootloader
[import-disk-1]: 2022-07-05T21:30:05Z Inspection result=os_release:{cli_formatted:"centos-6" distro:"centos" major_version:"6" minor_version:"10" architecture:X64 distro_id:CENTOS} elapsed_time_ms:98933 os_count:1
[import-ovf]: 2022-07-05T21:30:06Z Cleaning up.
[import-ovf]: 2022-07-05T21:30:06Z os `centos-6` is invalid. Allowed values: [centos-7 centos-8 debian-10 debian-11 debian-8 debian-9 opensuse-15 rhel-6 rhel-6-byol rhel-7 rhel-7-byol rhel-8 rhel-8-byol rocky-8 sles-12 sles-12-byol sles-15 sles-15-byol sles-sap-12 sles-sap-12-byol sles-sap-15 sles-sap-15-byol ubuntu-1404 ubuntu-1604 ubuntu-1804 ubuntu-2004 windows-10-x64-byol windows-10-x86-byol windows-2008r2 windows-2008r2-byol windows-2012 windows-2012-byol windows-2012r2 windows-2012r2-byol windows-2016 windows-2016-byol windows-2019 windows-2019-byol windows-2022 windows-2022-byol windows-7-x64-byol windows-7-x86-byol windows-8-x64-byol windows-8-x86-byol]
ERROR
ERROR: build step 0 "us-central1-docker.pkg.dev/compute-image-tools/wrappers/gce_ovf_import:release" failed: step exited with non-zero status: 1
ERROR: (gcloud.compute.instances.import) build 0e67bbb8-3389-4a34-adae-5f5566732085 completed with status "FAILURE"Der Image-Import unterstützt also nur ausgewählte Betriebssysteme und Versionen – Centos 6 gehört nicht dazu. Egal, ob über die Google Cloud Console oder die Kommandozeile: Das Ergebnis bleibt dasselbe. Damit fällt die bequeme Variante, die Disk-Images direkt in Google Compute Engine (GCE) zu importieren, schon einmal flach.
An dieser Stelle stößt vielleicht jemand auf GCVE und stellt fest, dass sich dort weiterhin alles betreiben lässt, was VMware unterstützt. Ein Cluster wird hochgefahren und konfiguriert, VMs werden importiert – genau wie on-prem. Erledigt, super! Oder etwa doch nicht?
Aktueller Stand: Google-Cloud-Support für EOL-OS-Images
Ein Großteil der Google-Supportdokumentation zu EOL-Betriebssystemen rät dazu, das EOL-Betriebssystem zunächst zu aktualisieren. Das ist sicherlich Best Practice, aber nicht für jeden umsetzbar. Vielleicht stehen die ursprünglichen Entwickler der Anwendung nicht mehr zur Verfügung, es bestehen Abhängigkeiten zu bestimmten Bibliotheken oder es fehlen schlicht die Ressourcen, um die Anwendung zu aktualisieren.
Optionen, um EOL-OS-VMs nach GCE zu importieren
Hier sind die verfügbaren Optionen – ohne bestimmte Reihenfolge. Jede hat ihre Vor- und Nachteile.
Option 1: Legacy-Anwendung mit einem deprecated öffentlichen GCE-Image neu installieren
Wie eingangs erwähnt, sehe ich immer wieder Kunden, die zunächst keine nativen Google-Cloud-Images finden. Tatsächlich sind sie weiterhin verfügbar – nur eben nicht ohne Weiteres sichtbar. In der Supportdokumentation zu EOL-Images habe ich gesehen, dass diese Images verfügbar, aber als deprecated markiert sind. Hier finden Sie eine Beispieldokumentation für Centos 6.
In der Google Cloud GCE Console gibt es unter "Images" einen Schalter, der deprecated Images einblendet. Aktivieren Sie ihn – und voilà, eine Liste sämtlicher älterer GCE-Images erscheint:
Filtern Sie nach dem, was Sie suchen – in meinem Fall Centos-6-Images –, wählen Sie das gewünschte Image aus, und erstellen Sie daraus eine GCE-Instanz.
Über die Kommandozeile erreichen Sie dasselbe mit:
gcloud compute images list --show-deprecated
Der Vorteil dieser Option: Sie erhalten ein originales Google-Image, in dem Google-Tools wie der os-agent und alle für den Betrieb auf Compute Engine nötigen OS-Anpassungen bereits enthalten sind. Wenn sich Ihre Anwendung leicht neu installieren lässt und Sie nur wenige Instanzen migrieren müssen, kann das durchaus attraktiv sein.
Option 2: Bestehendes VM-Image manuell in ein GCE-kompatibles Format konvertieren und importieren
Google bietet Supportdokumentation zum manuellen Importieren von Images sowie zum anschließenden Anpassen der importierten Images, damit sie in GCE reibungslos funktionieren. Dieser Weg eignet sich, wenn Sie maßgeschneiderte VM-Appliances oder nur eine kleine Zahl von Servern mit einzelnen Volumes nach GCE migrieren möchten. Da der Prozess manuell abläuft, ist er fehleranfällig.
Die grundlegenden Schritte – fortgeführt am Centos-6-Beispiel – sehen so aus:
Planen Sie Ihren Weg. Sie benötigen Speicherplatz für ein aus Ihrer Quellumgebung exportiertes Image sowie eine Möglichkeit, das Image zu booten, um Änderungen vorzunehmen, und es danach in ein GCE-kompatibles Format zu konvertieren. Achten Sie auf ausreichend Festplattenplatz für das Image, das komprimierte Image und etwas Reserve, damit es nicht zu Out-of-Space-Fehlern kommt.
Erstellen Sie eine Kopie des Images, booten Sie es in der Quellumgebung und nehmen Sie vor der Konvertierung die nötigen OS-Anpassungen vor, etwa:
Bearbeiten Sie die Linux-Boot-Konfigurationsdatei – in unserem Beispiel /etc/grub.conf – und entfernen Sie die Zeile, die das Boot-Splashimage konfiguriert. Entfernen Sie außerdem die Kernel-Parameter rhgb und quiet. Fügen Sie console=ttyS0,38400n8d zu den Kernel-Parametern hinzu.
Stellen Sie sicher, dass Sie sich über die Konsole mit Benutzername und Passwort anmelden können. Das ist nützlich, falls das Netzwerkinterface nach dem Boot in GCE Probleme bereitet.
Hinterlegen Sie zur Sicherheit auch einen SSH-Schlüssel für den Zugriff auf das Image.
Prüfen Sie, ob Ihre Centos-Repos noch funktionieren. In meinem Fall musste ich sie auf vault.centos.org umstellen.
Aktualisieren Sie die Standardkonfiguration des Netzwerkinterfaces. Bei centos-6 war das /etc/sysconfig/network-scripts/ifcfg-eth0. Entfernen Sie die Zeilen HW_ADDR und UUID und ergänzen Sie ONBOOT=yes sowie MTU=1460.
Entfernen Sie VMware- oder andere Hypervisor-Tools.
Kopieren Sie das Image an einen Ort, an dem Sie die nächsten Schritte ausführen können.
Konvertieren Sie das Image in ein von GCE akzeptiertes Format.
Am einfachsten ließ sich das Image in meinen Tests mit dem Tool qemu-img konvertieren. Installieren Sie qemu.
In diesem Beispiel nehme ich eine VMware-.vmdk-Datei und konvertiere sie ins Raw-Format, das GCE benötigt:
qemu-img convert -f vmdk -O raw PATH/TO/VM.VMDK PATH/TO/disk.raw
Nachdem die .VMDK-Datei in .raw konvertiert ist, muss sie im oldgnu-Format getart werden:
tar –format=oldgnu -Sczf compressed-image.tar.gz disk.raw- Laden Sie die Datei compressed-image.tar.gz in einen Google-Cloud-Storage-(GCS-)Bucket hoch:
gsutil cp compressed-image.tar.gz gs://BUCKET\_NAMEErstellen Sie schließlich das GCE-Image:
gcloud compute images create IMAGE_NAME --source-uri \ gs://BUCKET_NAME/compressed-image.tar.gz
Erstellen Sie aus dem resultierenden Image eine VM, installieren Sie den Google os-agent und nehmen Sie alle erforderlichen Anpassungen vor.
Erstellen Sie aus dem in Schritt 3e entstandenen Image eine VM.
gcloud compute instances create VM_NAME --zone ZONE --image IMAGE_NAME
Melden Sie sich am Image über den in Schritt 2c hinterlegten SSH-Schlüssel an.
Falls die Anmeldung nicht klappt, wurde beim Boot vermutlich ein neues Netzwerkinterface erkannt. Melden Sie sich über die serielle Konsole mit Benutzername/Passwort an und passen Sie die Netzwerkkonfiguration entsprechend an.
Nach erfolgreicher Anmeldung installieren Sie den Google os-agent.
Wenn Ihnen diese Anweisungen zu aufwendig erscheinen, ist die nächste Option vielleicht besser geeignet. Ich empfehle Ihnen ausdrücklich, die Google-Supportdokumentation zum manuellen Importieren von Images sowie zum Anpassen importierter Images vollständig zu lesen. Oben habe ich die wichtigsten Schritte und einige der Stolperfallen festgehalten. Es gibt diverse Anforderungen und Einschränkungen – ein Blick in die Dokumentation lohnt sich.
Option 3: Migrate to Virtual Machines nutzen, wenn mehrere VMs nach GCE wandern sollen
Migrate to Virtual Machines (früher Migrate for GCE) ist ein Migrationswerkzeug, das speziell für das Lift-and-Shift von On-Prem-Servern nach GCE entwickelt wurde. Die aktuelle Version konzentriert sich auf VMware-Migrationen. Wenn Ihre Legacy-Anwendungen bereits auf VMware laufen, könnte das die beste Option für Sie sein. Die Nutzung erfordert etwas Setup-Aufwand – ist der einmal erledigt, lässt sich eine große Zahl virtueller Maschinen einfach, zuverlässig und mit minimaler Downtime migrieren.
Migrate to Virtual Machines arbeitet über eine Migrations-Appliance, die in Ihrer bestehenden VMware-Umgebung installiert wird. Diese Migrate Appliance verbindet die Google Cloud mit Ihrem On-Prem-vSphere, sodass Migrate to Virtual Machines die vSphere-Umgebung einsehen, zu migrierende VMs auswählen, die Datenreplikation einrichten und anschließend Cloning für Tests bzw. Cutovers verwalten kann, sobald Sie bereit sind, Ihre Anwendungen in die Google Cloud zu verlagern.
Für die meisten Anwender dürfte das die attraktivste Option sein. Anders als der manuelle Importprozess aus Option 2 automatisiert sie viele Schritte und migriert Images aus meiner Erfahrung zuverlässig. Wenn Sie mehr als nur eine Handvoll Server verschieben müssen, ist das der schnellste Weg. Migrate to Virtual Machines unterstützt zahlreiche aktuelle und ältere Betriebssysteme.
Migrate to Virtual Machines benötigt einen Migrate-Connector, der direkt mit den Google-APIs kommunizieren kann – sei es über das Internet oder über eine private Verbindung zwischen Ihrer VMware-Umgebung und der Google Cloud. Diese Supportseite stellt Ihnen die Optionen vor.
Die grundlegenden Schritte zur Nutzung von Migrate to Virtual Machines:
- Voraussetzungen einrichten – etwa die zugehörigen Google-Cloud-APIs aktivieren und festlegen, welche Projekte und IAM-Berechtigungen genutzt werden.
- Migrate-Connector in Ihrer bestehenden VMware-Umgebung installieren, konfigurieren und registrieren
- VM-Migration starten. Der Migrationsprozess gliedert sich in folgende Schritte:
- VMs in Migrate to Virtual Machines onboarden.
- Replikation für ausgewählte oder alle VMs starten. Die Replikation kann erfolgen, während Ihre Quell-VMs weiterlaufen.
- Details der Ziel-VMs festlegen, etwa VM-Instanztypen, Netzwerkkonfiguration usw.
- Optional können Sie die Migration über die Klonfunktion testen. Ich empfehle, das in einer isolierten Zielumgebung zu tun. Ihre Quell-Images laufen weiterhin in VMware.
- Cutover. Dabei wird die Quell-VM heruntergefahren, eine letzte Replikation durchgeführt und anschließend die Ziel-VM provisioniert. Dieser Schritt verursacht Downtime. Bei meinen Test-Images lagen rund 15 Minuten zwischen dem Herunterfahren des Quell-Images und dem Hochfahren der neuen Instanz in der Google Cloud. Den größten Anteil macht die Image-Verarbeitung aus, daher kann die Image-Größe diese Dauer beeinflussen.
- Aufräumen.
Option 4: Google Cloud VMware Engine für umfangreiche oder zahlreiche Legacy-Anwendungen
Google Cloud VMware Engine ist häufig der Einstiegspunkt, weil die anderen Optionen nicht so prominent beworben werden. GCVE ist ein hervorragendes Produkt für die richtigen Use Cases – der Betrieb einer kleinen Zahl virtueller Maschinen auf einem GCVE-Cluster kann allerdings teuer werden.
Die Mindestkonfiguration für GCVE ist ein 3-Node-Cluster. Jeder Node ist eine ve1-standard-72-Instanz mit 72 hyperthreaded Cores (36 physisch), 768 GB RAM und über 20 TB SSD. Zum On-Demand-Preis kostet jeder Node 9,29 USD pro Stunde, der kleinste Cluster mit drei Nodes kommt damit auf 20.345,10 USD pro Monat. Mit 1- und 3-Jahres-Commitments lässt sich dieser Preis deutlich senken.
Google bietet zwar auch eine 1-Node-Konfiguration an, was Preis und Ressourcen etwas reduziert, beschränkt diese aber auf 60 Tage, da sie hauptsächlich für PoC-Zwecke gedacht ist. Bitte betreiben Sie darauf keine Produktiv-workloads.
GCVE bleibt eine sinnvolle Option für End-of-Life-Legacy-Anwendungen – vorausgesetzt, die Ressourcenanforderungen rechtfertigen es, Ihre workloads bringen Lizenzen mit, die in der Cloud schwierig sind (Windows Server, Oracle usw.), oder Sie setzen bereits stark auf VMware on-prem und wollen das für bestimmte workloads beibehalten, etwa um Investitionen in Tooling oder Betrieb zu schützen.
Bonus-Option 5: Mit Migrate to Containers bestimmte Legacy-Anwendungen containerisieren
Googles Migrate to Containers kann für bestimmte workloads eine Option sein. Wenn Sie bereits mit Containern vertraut sind und nicht noch mehr GCE-VMs betreiben möchten, ist Migrate to Containers womöglich die richtige Wahl. Das Tool analysiert Ihre workloads und erzeugt – sofern sie für eine Containerisierung geeignet sind – einen Container Ihres VM-basierten workloads, der auf Plattformen wie Google Kubernetes Engine und Cloud Run läuft.
Ein Vorbehalt: Nicht alle workloads eignen sich für die Konvertierung. Google nennt Beispiele für workloads, die gut geeignet sind, sowie für solche, die nicht passen. Auch ein Analyse-Tool hilft bei der Einschätzung. Mitunter sind Anpassungen nötig. Mehrere aktuelle und ältere Betriebssysteme werden unterstützt.
Was passt am besten zu Ihrer ungeliebten Legacy-Anwendung?
Auf Basis meiner Erfahrungen mit Kunden halte ich Migrate to Virtual Machines insgesamt für die beste Lösung. Sie bietet eine ausgewogene Mischung aus Aufwand, Automatisierung, Zuverlässigkeit und minimaler Downtime für stateful workloads.
Wenn Sie nur 1–2 Images zu migrieren haben, kann es weniger Aufwand sein, Ihre App auf einem deprecated Google-Cloud-Image neu zu installieren oder eine manuelle Konvertierung durchzuführen. Für stateful workloads, die kaum Downtime tolerieren, sind diese Optionen allerdings nicht ideal.
Wenn Sie bereits containerisierte Apps betreiben, bereit sind, Ihre workloads bei Bedarf anzupassen, und keine zusätzlichen virtuellen Maschinen einführen möchten, kann Migrate to Containers eine spannende Option sein. Der Nachteil: Nicht alle workloads eignen sich, und Ihre Anwendungen brauchen unter Umständen Anpassungen.
Bei großem Umfang – insbesondere mit bestehenden VMware-Umgebungen, deren Lizenzen in der Cloud Probleme bereiten könnten – erlaubt GCVE schließlich, bestimmte Lizenzvereinbarungen zu erhalten, unter denen einige workloads in GCE nicht wirtschaftlich betrieben werden können, und vorhandene Skills und Tools weiter zu nutzen. Für nur wenige kleine Anwendungen ist GCVE allerdings in der Regel keine kosteneffiziente Lösung.