Se desidera spostare applicazioni legacy con sistemi operativi end-of-life su Google Cloud, questo articolo fa per Lei. Esploriamo le opzioni per importare le macchine virtuali con sistemi operativi EOL su Google Compute Engine
La realtà delle applicazioni legacy end-of-life
In DoiT International incontriamo clienti in fasi diverse del percorso verso il cloud. Alcuni sono già cloud-native e non hanno ancora accumulato molto debito tecnico, mentre altri si portano dietro applicazioni legacy mantenute per ragioni differenti. Alcuni cercano di tenere aggiornate le loro applicazioni legacy, altri finiscono per essere il tema di questo articolo: ospitare applicazioni legacy dimenticate su sistemi operativi end-of-life (EOL). Se ha applicazioni di questo tipo e desidera spostarle su Google Cloud, questo articolo fa al caso Suo. Scoprirà le opzioni a Sua disposizione, che si spera La aiutino a prendere le decisioni giuste per i Suoi workloads.
L’ispirazione per questo articolo è nata osservando alcuni clienti che valutavano Google Cloud VMware Engine (GCVE) per eseguire le proprie applicazioni legacy su Google Cloud. Essendo VMware sotto il cofano, GCVE è un ottimo modo per eseguire determinate VM, comprese quelle con sistemi operativi EOL. Il problema di GCVE è che non scala bene verso il basso per workloads più contenuti, ed è un’opzione conveniente solo se si sfruttano le risorse nella configurazione minima disponibile.
Sebbene GCVE sia senza dubbio un’opzione per eseguire le Sue applicazioni legacy su Google Cloud, non lo consiglierei come prima scelta a meno che i Suoi workloads non richiedano quel tipo di scala. Ne riparleremo più avanti.
Ho indagato sul perché alcuni clienti concludessero di aver bisogno di GCVE per eseguire le proprie applicazioni legacy EOL e ho individuato alcuni ostacoli:
Innanzitutto, ho visto clienti tentare di creare nuove macchine virtuali da sistemi operativi EOL, come Centos 6. Si scopre subito che l’immagine non è più presente nell’elenco delle immagini pubbliche di Google. E adesso?
Il passo successivo era provare la funzionalità di import di Google Compute Engine, che esegue importazioni ad-hoc di immagini di VM. Ci si aspetterebbe che funzioni con le versioni precedenti dei sistemi operativi, ma quando ho provato a importare un OS EOL — Centos 6 in questo esempio — ho ricevuto una brutta notizia:
$ 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"Quindi l’opzione di import delle immagini supporta solo alcuni sistemi operativi e versioni — Centos-6 non è tra questi. Che lo si faccia dalla console di Google Cloud o dalla riga di comando, il risultato è lo stesso. Questo chiude la porta all’opzione "bottone facile" di importare le immagini disco direttamente in Google Compute Engine (GCE).
A questo punto qualcuno potrebbe scoprire GCVE e accorgersi che esegue ancora qualsiasi cosa VMware sia in grado di eseguire. Si avvia e si configura un cluster, le VM vengono importate — proprio come on-prem. Lavoro fatto, fantastico! O forse no?
Lo stato attuale del supporto di Google Cloud per le immagini OS EOL
Gran parte della documentazione di supporto di Google relativa ai sistemi operativi EOL si concentra sulla raccomandazione di aggiornare prima il sistema operativo EOL. Questa è certamente una best practice, ma non tutti possono farlo. Gli sviluppatori dell’applicazione potrebbero non essere più disponibili, oppure potrebbero esistere dipendenze da determinate librerie o, semplicemente, mancare le risorse per aggiornare l’applicazione.
Opzioni per importare le Sue macchine virtuali con OS EOL in GCE
Ecco le opzioni disponibili, in ordine sparso. Ognuna ha i suoi pro e i suoi contro.
Opzione 1: Reinstallare l’applicazione legacy utilizzando un’immagine pubblica GCE deprecata
Come accennato in precedenza, ho visto clienti che, provando a usare immagini native di Google Cloud, inizialmente non ne trovavano nessuna. Si scopre che Google ha mantenuto disponibili le immagini, semplicemente non in modo facilmente visibile. Leggendo parte della documentazione di supporto per le immagini EOL, ho scoperto che le immagini sono disponibili ma contrassegnate come deprecate. Ecco un esempio di documentazione per Centos 6.
Dalla console GCE di Google Cloud, sotto Immagini, un interruttore mostra le immagini deprecate. Lo attivi e voilà, appare l’elenco di tutte le immagini GCE passate:
Filtri ciò che sta cercando — nel mio caso, le immagini Centos 6 — selezioni l’immagine che desidera utilizzare e potrà creare un’istanza GCE da quell’immagine.
Da riga di comando, può ottenere lo stesso risultato con:
gcloud compute images list --show-deprecated
Il vantaggio di questa opzione è che dispone di un’immagine Google originale con strumenti Google come l’os-agent e con tutte le modifiche a livello di OS già apportate per il funzionamento su Compute Engine. Se la Sua applicazione è facile da reinstallare e ha un numero ridotto di istanze da spostare, questa opzione può essere interessante.
Opzione 2: Convertire manualmente l’immagine VM esistente in un formato compatibile con GCE e importarla manualmente
Google fornisce documentazione di supporto per importare manualmente le immagini e quindi apportare gli aggiustamenti per le immagini importate in modo che funzionino correttamente all’interno di GCE. Questo processo può essere utile se ha appliance VM personalizzate o solo un piccolo numero di server con singoli volumi da migrare a GCE. Il processo è manuale, quindi introduce un potenziale margine di errore.
I passaggi di base di questo processo, proseguendo con l’esempio Centos 6, sono i seguenti:
Pianifichi il percorso. Avrà bisogno di archiviare un’immagine esportata dal Suo ambiente di origine e di un modo per avviarla per apportarvi modifiche e poi convertirla in un formato compatibile con GCE. Si assicuri di avere spazio su disco sufficiente per ospitare l’immagine, l’immagine compressa e un po’ di spazio extra, in modo da non incorrere in errori di spazio esaurito.
Crei una copia dell’immagine, la avvii nell’ambiente di origine e apporti le modifiche necessarie all’OS prima della conversione, ad esempio:
Modifichi il file di configurazione di boot di linux, /etc/grub.conf nel nostro esempio, e rimuova la riga che configura la spashimage di boot. Rimuova anche i parametri kernel rhgb e quiet. Aggiunga console=ttyS0,38400n8d ai parametri kernel.
Verifichi di poter accedere via console con username e password. Può tornare utile in caso di problemi con l’interfaccia di rete una volta avviata in GCE.
Si assicuri inoltre di avere una chiave ssh per accedere all’immagine, per ogni evenienza.
Verifichi che i Suoi repository Centos funzionino ancora. Nel mio caso ho dovuto aggiornare i repository Centos a vault.centos.org.
Aggiorni la configurazione dell’interfaccia di rete predefinita. Per centos-6, era /etc/sysconfig/network-scripts/ifcfg-eth0. Rimuova le righe HW_ADDR e UUID e aggiunga al file ONBOOT=yes e MTU=1460.
Rimuova VMware o gli strumenti di altri hypervisor.
Copi l’immagine in un luogo dove poter eseguire i passaggi successivi.
Converta l’immagine in un formato accettato da GCE.
Il modo più semplice che ho trovato per convertire un’immagine è stato utilizzare l’utility qemu-img. Installi qemu.
In questo esempio, prendo un file VMware .vmdk e lo converto in formato raw, che è quello richiesto da GCE:
qemu-img convert -f vmdk -O raw PATH/TO/VM.VMDK PATH/TO/disk.raw
Ora che il file .VMDK è stato convertito in .raw, deve essere compresso con tar in formato oldgnu:
tar –format=oldgnu -Sczf compressed-image.tar.gz disk.raw- Carichi il file compressed-image.tar.gz in un bucket Google Cloud Storage (GCS):
gsutil cp compressed-image.tar.gz gs://BUCKET\_NAMEInfine, crei l’immagine GCE:
gcloud compute images create IMAGE_NAME --source-uri \ gs://BUCKET_NAME/compressed-image.tar.gz
Crei una VM dall’immagine risultante, installi l’os-agent di Google e apporti le eventuali modifiche necessarie.
Crei una VM dall’immagine risultante dal Passaggio 3e.
gcloud compute instances create VM_NAME --zone ZONE --image IMAGE_NAME
Acceda all’immagine tramite la chiave ssh suggerita al passaggio 2c.
Se non riesce ad accedere alla Sua istanza, è probabile che all’avvio sia stata rilevata una nuova interfaccia di rete. Acceda all’istanza tramite la console seriale con username/password e corregga l’interfaccia di rete in base a quella rilevata.
Una volta effettuato l’accesso, installi l’os-agent di Google.
Se le istruzioni qui sopra Le sembrano eccessive, forse l’opzione successiva fa per Lei. Le consiglio di leggere la documentazione di supporto Google per importare manualmente le immagini e per apportare gli aggiustamenti per le immagini importate. Ho riportato sopra i passaggi essenziali e alcune delle problematiche incontrate. Esistono diversi requisiti e limitazioni, quindi La invito a consultarli.
Opzione 3: Utilizzare Migrate to Virtual Machines se ha più VM da portare in GCE
Migrate to Virtual Machines (in precedenza Migrate for GCE) è uno strumento di migrazione progettato per il lift and shift di server on-prem verso GCE. L’ultima versione di Migrate to Virtual Machines è focalizzata sulle migrazioni VMware. Se le Sue applicazioni legacy sono già in esecuzione su VMware, questa potrebbe essere l’opzione migliore. Utilizzare Migrate to Virtual Machines comporta un piccolo lavoro di setup, ma una volta completato è possibile migrare un gran numero di macchine virtuali in modo semplice, affidabile e con un downtime minimo.
Migrate to Virtual Machines funziona installando un’appliance di migrazione nel Suo ambiente VMware esistente. Questa appliance fa da interfaccia tra Google Cloud e il Suo vSphere on-prem, permettendo a Migrate to Virtual Machines di visualizzare l’ambiente vSphere, selezionare le VM da migrare, impostare la replica dei dati e gestire la clonazione per i test o il cutover quando è pronto a spostare le applicazioni su Google Cloud.
Penso che questa opzione sarà la più interessante per la maggior parte degli utenti. A differenza del processo di import manuale dell’opzione 2, automatizza molti dei passaggi e, dalla mia esperienza, migra le immagini in modo affidabile. Se ha più di qualche server da spostare, sarà il modo più rapido. Migrate to Virtual Machines supporta diversi sistemi operativi attuali e legacy.
Migrate to Virtual Machines richiede che il migrate connector possa comunicare direttamente con le API Google, sia tramite internet sia tramite qualsiasi connettività privata Lei abbia tra l’ambiente VMware e Google Cloud. Questa pagina di supporto illustra le opzioni disponibili.
I passaggi di base per utilizzare Migrate to Virtual Machines sono:
- Configurare i prerequisiti, ad esempio abilitare le API Google Cloud associate e decidere quali progetti e quali permessi IAM utilizzare.
- Installare, configurare e registrare il migrate connector nel Suo ambiente VMware esistente
- Avviare la migrazione delle VM. Il processo di migrazione può essere suddiviso nei seguenti passaggi:
- Onboarding delle VM in Migrate to Virtual Machines.
- Avvio della replica per VM selezionate o per tutte le VM. La replica può essere effettuata mentre le VM di origine sono ancora in esecuzione.
- Configurazione dei dettagli delle VM target, ad esempio scegliendo i tipi di istanza, la configurazione di rete, ecc.
- Facoltativamente, può testare una migrazione tramite la funzione di clonazione. Consiglio di farlo con un ambiente target isolato. Le immagini di origine continueranno a funzionare in VMware.
- Cutover. Verrà spenta la VM di origine, eseguita una replica finale e quindi provisionate le VM target. Questa fase comporta downtime. Per le immagini con cui ho fatto i test, ho riscontrato circa 15 minuti di downtime tra lo spegnimento dell’immagine di origine e l’avvio della nuova istanza su Google Cloud. La maggior parte del downtime è dovuta all’elaborazione dell’immagine, quindi le dimensioni dell’immagine possono far variare questo tempo.
- Pulizia.
Opzione 4: Utilizzare Google Cloud VMware Engine per ospitare applicazioni legacy di grandi dimensioni o numerose
Utilizzare Google Cloud VMware Engine è il punto di partenza per la maggior parte delle persone, perché le altre opzioni non sono ben pubblicizzate. GCVE è un ottimo prodotto se utilizzato per i casi d’uso giusti, ma eseguire un piccolo numero di macchine virtuali su un cluster GCVE può diventare costoso.
La configurazione minima di GCVE è un cluster a 3 nodi. Ogni nodo è un’istanza ve1-standard-72, ovvero 72 core hyperthreaded (36 fisici), 768 GB di RAM e oltre 20 TB di SSD. Ogni nodo, al prezzo On-Demand, costa $9,29/h per nodo, quindi il cluster minimo da 3 nodi avrà un costo di $20.345,10 al mese. I commitments a 1 anno e a 3 anni possono ridurre sensibilmente questo prezzo.
Google offre anche una configurazione a 1 nodo, che riduce un po’ il prezzo e le risorse, ma Google limita le configurazioni a 1 nodo a un periodo di 60 giorni, poiché sono pensate principalmente per uso PoC. Si raccomanda di non eseguire i workloads di produzione su questa configurazione.
GCVE rimane un’opzione valida per eseguire applicazioni legacy end-of-life se i requisiti di risorse lo richiedono, se i Suoi workloads hanno licenze meno compatibili con il Cloud (Windows Server, Oracle, ecc.) o se sfrutta già intensamente VMware on-prem e desidera continuare a utilizzarlo per determinati workloads, mantenendo gli investimenti su strumenti od operations.
Opzione bonus 5: Utilizzare lo strumento Migrate to Containers per containerizzare alcune applicazioni legacy
Utilizzare lo strumento Migrate to Containers di Google Cloud potrebbe essere un’opzione per certi workloads. Se è già a Suo agio con l’esecuzione di container e non desidera aggiungere altre macchine virtuali GCE, Migrate to Containers può essere un’opzione interessante. Migrate for Containers analizza i Suoi workloads e, se idonei alla containerizzazione, produce un container del Suo workload basato su VM da utilizzare su piattaforme come Google Kubernetes Engine e Cloud Run.
Un’avvertenza con questo metodo è che non tutti i workloads sono adatti alla conversione. Google fornisce esempi di workloads che sono una buona scelta e di quelli che non lo sono. Anche uno strumento di analisi può aiutare a determinarlo. Potrebbero essere necessarie anche alcune modifiche. Sono supportati diversi sistemi operativi attuali e legacy.
Qual è la soluzione migliore per la Sua applicazione legacy dimenticata?
Sulla base di ciò che ho osservato presso i clienti, ritengo che Migrate to Virtual Machines sia la soluzione complessiva migliore, offrendo un buon equilibrio tra impegno richiesto, automazione, affidabilità e minimo downtime per i workloads stateful.
Se ha 1-2 immagini da gestire, reinstallare la Sua app su un’immagine Google Cloud deprecata o effettuare una conversione manuale può richiedere meno sforzo per avviare una macchina virtuale su GCE. Queste opzioni non sono però ideali per migrare workloads stateful che non tollerano molto downtime.
Se sta già eseguendo app containerizzate, è disposto ad apportare alcune modifiche ai Suoi workloads se necessario e non desidera introdurre macchine virtuali nel Suo stack, Migrate to Containers potrebbe essere un’opzione interessante. Lo svantaggio è che non tutti i workloads sono adatti a questo processo e le Sue applicazioni potrebbero richiedere alcune modifiche per funzionare.
Infine, se ha esigenze su larga scala, soprattutto con ambienti VMware esistenti che potrebbero presentare complessità di licensing nel cloud, GCVE Le consente di preservare alcuni dei Suoi accordi di licenza esistenti che non permettono di eseguire economicamente alcuni workloads su GCE, oltre a sfruttare competenze e strumenti che probabilmente già possiede. Detto ciò, GCVE generalmente non è una soluzione economicamente vantaggiosa per poche piccole applicazioni.