Google Cloud fornisce strumenti, prodotti, indicazioni e servizi professionali per eseguire la migrazione delle macchine virtuali (VM) insieme ai relativi dati da Amazon Elastic Compute Cloud (Amazon EC2) a Compute Engine. Questo documento descrive come progettare, implementare e convalidare un piano per la migrazione da Amazon EC2 a Compute Engine.
La discussione in questo documento è rivolta agli amministratori cloud che vogliono dettagli su come pianificare e implementare una procedura di migrazione. È inoltre destinato ai responsabili delle decisioni che stanno valutando l'opportunità di eseguire la migrazione e che vogliono esplorare come potrebbe essere la migrazione.
Questo documento fa parte di una serie in più parti sulla migrazione da AWS a Google Cloud che include i seguenti documenti:
- Inizia
- Esegui la migrazione da Amazon EC2 a Compute Engine (questo documento)
- Esegui la migrazione da Amazon S3 a Cloud Storage
- Migrazione da Amazon EKS a Google Kubernetes Engine
- Esegui la migrazione da Amazon RDS e Amazon Aurora per MySQL a Cloud SQL per MySQL
- Esegui la migrazione da Amazon RDS e Amazon Aurora per PostgreSQL a Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL
- Esegui la migrazione da Amazon RDS per SQL Server a Cloud SQL per SQL Server
- Esegui la migrazione da AWS Lambda a Cloud Run
Per questa migrazione a Google Cloud, ti consigliamo di seguire il framework di migrazione descritto in Migrazione a Google Cloud: Guida introduttiva.
Il seguente diagramma illustra il percorso del tuo viaggio di migrazione.
Potresti eseguire la migrazione dall'ambiente di origine a Google Cloud in una serie di iterazioni. Ad esempio, potresti eseguire la migrazione di alcuni workload prima e di altri in un secondo momento. Per ogni iterazione di migrazione separata, segui le fasi del framework di migrazione generale:
- Valuta e scopri i tuoi workload e i tuoi dati.
- Pianifica e crea una base su Google Cloud.
- Esegui la migrazione dei carichi di lavoro e dei dati a Google Cloud.
- Ottimizza il tuo ambiente Google Cloud .
Per maggiori informazioni sulle fasi di questo framework, consulta la pagina Eseguire la migrazione a Google Cloud: guida introduttiva.
Per progettare un piano di migrazione efficace, ti consigliamo di convalidare ogni passaggio del piano e di assicurarti di avere una strategia di rollback. Per convalidare il piano di migrazione, consulta la pagina Eseguire la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.
Valuta l'ambiente di origine
Nella fase di valutazione, determini i requisiti e le dipendenze per migrare l'ambiente di origine a Google Cloud.
La fase di valutazione è fondamentale per il successo della migrazione. Devi acquisire una conoscenza approfondita dei carichi di lavoro di cui vuoi eseguire la migrazione, dei loro requisiti, delle loro dipendenze e del tuo ambiente attuale. Devi comprendere il tuo punto di partenza per pianificare ed eseguire correttamente una Google Cloud migrazione.
La fase di valutazione è costituita dalle seguenti attività:
- Crea un inventario completo dei tuoi workload.
- Catalogare i carichi di lavoro in base alle loro proprietà e dipendenze.
- Forma e istruisci i tuoi team su Google Cloud.
- Crea esperimenti e proof of concept su Google Cloud.
- Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
- Scegli la strategia di migrazione per i tuoi workload.
- Scegli gli strumenti di migrazione.
- Definisci il piano di migrazione e le tempistiche.
- Convalida il piano di migrazione.
Per saperne di più sulla fase di valutazione e su queste attività, vedi Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute in questo documento.
Crea un inventario delle istanze Amazon EC2
Per definire l'ambito della migrazione, crea un inventario delle tue istanze Amazon EC2. Puoi quindi utilizzare l'inventario per valutare i processi di deployment e operativi per il deployment dei carichi di lavoro su queste istanze.
Per creare l'inventario delle tue istanze Amazon EC2, ti consigliamo di utilizzare Migration Center, la piattaforma unificata diGoogle Cloudche ti consente di accelerare il percorso verso il cloud end-to-end dall'ambiente attuale a Google Cloud. Migration Center ti consente di eseguire un rilevamento dell'inventario su AWS.
I dati forniti da Migration Center e dall'interfaccia a riga di comando del client predittivo di Migration Center potrebbero non acquisire completamente le dimensioni che ti interessano. In questo caso, puoi integrare questi dati con i risultati di altri meccanismi di raccolta dei dati che crei in base alle API AWS, agli strumenti per sviluppatori AWS e all'interfaccia a riga di comando AWS.
Oltre ai dati ottenuti da Migration Center e dall'interfaccia a riga di comando del client predittivo di Migration Center, considera i seguenti punti dati per ogni istanza Amazon EC2 di cui vuoi eseguire la migrazione:
- Regione e zona di deployment.
- Tipo e dimensioni dell'istanza.
- L'Amazon Machine Image (AMI) da cui viene avviata l'istanza.
- Il nome host dell'istanza e il modo in cui altre istanze e altri carichi di lavoro utilizzano questo nome host per comunicare con l'istanza.
- I tag dell'istanza, nonché i metadati e i dati utente.
- Il tipo di virtualizzazione dell'istanza.
- L'opzione di acquisto dell'istanza, ad esempio l'acquisto on demand o spot.
- Modalità di archiviazione dei dati dell'istanza, ad esempio l'utilizzo di archivi istanza e volumi Amazon EBS.
- La configurazione della tenancy dell'istanza.
- Indica se l'istanza si trova in un gruppo di posizionamento specifico.
- Indica se l'istanza si trova in un gruppo di scalabilità automatica specifico.
- I gruppi di sicurezza a cui appartiene l'istanza.
- Qualsiasi configurazione di AWS Network Firewall che coinvolge l'istanza.
- Se i carichi di lavoro eseguiti sull'istanza sono protetti da AWS Shield e AWS WAF.
- Se controlli lo stato del processore della tua istanza e in che modo i carichi di lavoro eseguiti sull'istanza dipendono dallo stato del processore.
- La configurazione dello scheduler I/O dell'istanza.
- Come esponi i carichi di lavoro eseguiti sull'istanza ai client eseguiti nel tuo ambiente AWS (ad esempio altri carichi di lavoro) e ai client esterni.
Valuta i processi di deployment e operativi
È importante avere una chiara comprensione del funzionamento dei processi di deployment e operativi. Questi processi sono una parte fondamentale delle pratiche che preparano e mantengono il tuo ambiente di produzione e i workload che vengono eseguiti al suo interno.
I processi di deployment e operativi potrebbero creare gli artefatti necessari per il funzionamento dei tuoi workload. Pertanto, devi raccogliere informazioni su ogni tipo di artefatto. Ad esempio, un artefatto può essere un pacchetto del sistema operativo, un pacchetto di deployment dell'applicazione, un'immagine del sistema operativo, un'immagine container o qualcos'altro.
Oltre al tipo di artefatto, considera come completare le seguenti attività:
- Sviluppa i tuoi carichi di lavoro. Valuta i processi che i team di sviluppo hanno in atto per creare i tuoi carichi di lavoro. Ad esempio, in che modo i tuoi team di sviluppo progettano, codificano e testano i tuoi carichi di lavoro?
- Genera gli artefatti di cui esegui il deployment nell'ambiente di origine. Per eseguire il deployment dei tuoi workload nell'ambiente di origine, potresti generare artefatti di cui è possibile eseguire il deployment, come immagini container o immagini del sistema operativo, oppure potresti personalizzare artefatti esistenti, come immagini del sistema operativo di terze parti installando e configurando il software. La raccolta di informazioni su come generi questi artefatti ti aiuta a assicurarti che siano adatti al deployment in Google Cloud.
Archivia gli artefatti. Se produci artefatti che archivi in un registro degli artefatti nell'ambiente di origine, devi renderli disponibili nell'ambiente Google Cloud . Puoi farlo utilizzando strategie come le seguenti:
- Stabilisci un canale di comunicazione tra gli ambienti: rendi gli artefatti nell'ambiente di origine raggiungibili dall'ambienteGoogle Cloud di destinazione.
- Esegui il refactoring del processo di creazione degli artefatti: completa un refactoring secondario dell'ambiente di origine in modo da poter archiviare gli artefatti sia nell'ambiente di origine sia in quello di destinazione. Questo approccio supporta la migrazione creando un'infrastruttura come un repository di artefatti prima di dover implementare i processi di creazione degli artefatti nell'ambiente di destinazione. Google CloudPuoi implementare questo approccio direttamente oppure puoi basarti sull'approccio precedente di stabilire prima un canale di comunicazione.
La disponibilità degli artefatti sia nell'ambiente di origine sia in quello di destinazione ti consente di concentrarti sulla migrazione senza dover implementare processi di compilazione degli artefatti nell'ambiente di destinazione Google Cloud nell'ambito della migrazione.
Scansiona e firma il codice. Nell'ambito dei processi di creazione degli artefatti, potresti utilizzare la scansione del codice per proteggerti da vulnerabilità comuni e dall'esposizione involontaria della rete, nonché la firma del codice per assicurarti che nei tuoi ambienti venga eseguito solo codice attendibile.
Esegui il deployment degli artefatti nell'ambiente di origine. Dopo aver generato gli artefatti di cui è possibile eseguire il deployment, potresti eseguirne il deployment nell'ambiente di origine. Ti consigliamo di valutare ogni processo di deployment. L'analisi aiuta a garantire che i processi di deployment siano compatibili con Google Cloud. Ti aiuta anche a comprendere l'impegno necessario per eventualmente eseguire il refactoring dei processi. Ad esempio, se i processi di deployment funzionano solo con l'ambiente di origine, potresti doverli refactorizzare per indirizzarli all'ambiente Google Cloud .
Inserisci la configurazione di runtime. Potresti inserire la configurazione di runtime per cluster, ambienti di runtime o deployment di workload specifici. La configurazione potrebbe inizializzare variabili di ambiente e altri valori di configurazione come secret, credenziali e chiavi. Per contribuire a garantire che i processi di inserimento della configurazione di runtime funzionino su Google Cloud, ti consigliamo di valutare come configuri i workload eseguiti nell'ambiente di origine.
Logging, monitoraggio e profilazione. Valuta i processi di logging, monitoraggio e profilazione che hai implementato per monitorare l'integrità del tuo ambiente di origine, le metriche di interesse e il modo in cui utilizzi i dati forniti da questi processi.
Autenticazione. Valuta l'autenticazione rispetto all'ambiente di origine.
Esegui il provisioning e la configurazione delle risorse. Per preparare l'ambiente di origine, potresti aver progettato e implementato processi che eseguono il provisioning e la configurazione delle risorse. Ad esempio, potresti utilizzare Terraform insieme a strumenti di gestione della configurazione per eseguire il provisioning e configurare le risorse nell'ambiente di origine.
Pianificare e creare le basi
Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione dell'infrastruttura per svolgere le seguenti operazioni:
- Supporta i tuoi carichi di lavoro nel tuo ambiente Google Cloud .
- Collega l'ambiente di origine e l'ambiente Google Cloud per completare la migrazione.
La fase di pianificazione e creazione è composta dalle seguenti attività:
- Crea una gerarchia delle risorse.
- Configura Identity and Access Management (IAM) di Google Cloud.
- Configura la fatturazione.
- Configura la connettività di rete.
- Rafforza la tua sicurezza.
- Configura logging, monitoraggio e avvisi.
Per maggiori informazioni su ciascuna di queste attività, consulta la sezione Eseguire la migrazione a Google Cloud: pianificare e creare le basi.
Migrazione dei carichi di lavoro
Per eseguire la migrazione dei tuoi carichi di lavoro da Amazon EC2 a Compute Engine, devi procedere nel seguente modo:
- Migra le VM da Amazon EC2 a Compute Engine.
- Esegui la migrazione dei dischi VM a Persistent Disk.
- Esporre ai client i carichi di lavoro eseguiti su Compute Engine.
- Rimodella i processi di deployment e operativi per scegliere come target Google Cloud anziché Amazon EC2.
Le sezioni seguenti forniscono dettagli su ciascuna di queste attività.
Migrazione delle VM su Compute Engine
Per eseguire la migrazione delle VM da Amazon EC2 a Compute Engine, ti consigliamo di utilizzare Migrate to Virtual Machines, un servizio completamente gestito. Per maggiori informazioni, consulta la pagina Percorso di migrazione con Migrate to VMs.
Nell'ambito della migrazione, Migrate for VMs esegue la migrazione delle istanze Amazon EC2 nel loro stato attuale, a parte le modifiche alla configurazione richieste. Se le tue istanze Amazon EC2 eseguono AMI Amazon EC2 personalizzate, Migrate for VMs esegue la migrazione di queste personalizzazioni alle istanze Compute Engine. Tuttavia, se vuoi rendere riproducibile la tua infrastruttura, potresti dover applicare personalizzazioni equivalenti creando immagini del sistema operativo Compute Engine nell'ambito dei processi di deployment e operativi, come spiegato più avanti in questo documento.
Esegui la migrazione dei dischi VM a Persistent Disk
Puoi anche utilizzare Migrate to VMs per eseguire la migrazione dei dischi dalle VM Amazon EC2 di origine a Persistent Disk, con interruzioni minime dei carichi di lavoro in esecuzione sulle VM Amazon EC2. Per ulteriori informazioni, consulta Eseguire la migrazione dei dischi VM e collegarli a una nuova VM.
Ad esempio, puoi eseguire la migrazione di un disco di dati collegato a una VM Amazon EC2 a Persistent Disk e collegarlo a una nuova VM Compute Engine.
Esporre i carichi di lavoro eseguiti su Compute Engine
Dopo aver eseguito la migrazione delle istanze Amazon EC2 alle istanze Compute Engine, potrebbe essere necessario eseguire il provisioning e configurare l'ambiente Google Cloudper esporre i carichi di lavoro ai client.
Google Cloud offre servizi e prodotti sicuri e affidabili per esporre i tuoi carichi di lavoro ai clienti. Per i carichi di lavoro eseguiti sulle istanze Compute Engine, configura le risorse per le seguenti categorie:
- Firewall
- Bilanciamento del carico del traffico
- Nomi, zone e record DNS
- Protezione DDoS e web application firewall
Per ciascuna di queste categorie, puoi iniziare implementando una configurazione di base simile a quella che hai utilizzato per configurare i servizi e le risorse AWS nella categoria equivalente. Puoi quindi iterare la configurazione e utilizzare funzionalità aggiuntive fornite dai servizi Google Cloud .
Le sezioni seguenti spiegano come eseguire il provisioning e configurare le risorseGoogle Cloud in queste categorie e come vengono mappate alle risorse AWS in categorie simili.
Firewall
Se hai configurato i gruppi di sicurezza AWS e le policy e le regole di AWS Network Firewall, puoi configurare le policy e le regole di Cloud Next Generation Firewall. Puoi anche eseguire il provisioning delle regole dei controlli di servizio VPC per regolare il traffico di rete all'interno del VPC. Puoi utilizzare i Controlli di servizio VPC per controllare il traffico in uscita dalle istanze Compute Engine e per contribuire a mitigare il rischio di esfiltrazione di dati.
Se utilizzi protocolli di accesso remoto come SSH o RDP per connetterti alle tue VM Amazon EC2, puoi rimuovere l'indirizzo IP pubblico della VM e connetterti alla VM da remoto con Identity-Aware Proxy (IAP). L'inoltro TCP di IAP consente di stabilire un tunnel criptato. Puoi utilizzare il tunnel per inoltrare SSH, RDP e altro traffico internet alle VM senza assegnare indirizzi IP pubblici alle VM. Poiché le connessioni dal servizio IAP hanno origine da un intervallo di indirizzi IP pubblici riservati, devi creare regole firewall VPC corrispondenti. Se hai VM basate su Windows e hai attivato Windows Firewall, verifica che Windows Firewall non sia configurato per bloccare le connessioni RDP da IAP. Per saperne di più, vedi Risoluzione dei problemi relativi a RDP.
Bilanciamento del carico del traffico
Se hai configurato Elastic Load Balancing (ELB) nel tuo ambiente AWS, puoi configurare Cloud Load Balancing per distribuire il traffico di rete e migliorare la scalabilità dei carichi di lavoro in Google Cloud. Cloud Load Balancing supporta diversi prodotti di bilanciamento del carico globali e regionali che funzionano a diversi livelli del modello OSI, ad esempio a livello di trasporto e applicazione. Puoi scegliere un prodotto di bilanciamento del carico adatto ai requisiti dei tuoi carichi di lavoro.
Cloud Load Balancing supporta anche la configurazione di Transport Layer Security (TLS) per criptare il traffico di rete. Quando configuri TLS per Cloud Load Balancing, puoi utilizzare certificati TLS autogestiti o gestiti da Google, a seconda dei tuoi requisiti.
Nomi, zone e record DNS
Se utilizzi Amazon Route 53 nel tuo ambiente AWS, puoi utilizzare quanto segue in Google Cloud:
- Cloud Domains per registrare i tuoi domini DNS.
- Cloud DNS per gestire le zone DNS pubbliche e private e i record DNS.
Ad esempio, se hai registrato un dominio utilizzando Amazon Route 53, puoi trasferire la registrazione del dominio a Cloud Domains. Allo stesso modo, se hai configurato zone DNS pubbliche e private utilizzando Amazon Route 53, puoi migrare questa configurazione a Cloud DNS.
Protezione DDoS e web application firewall
Se hai configurato AWS Shield e AWS WAF nel tuo ambiente AWS, puoi utilizzare Google Cloud Armor per proteggere i tuoi Google Cloud carichi di lavoro dagli attacchi DDoS e dagli exploit comuni.
Riorganizzare i processi di deployment e operativi
Dopo aver eseguito il refactoring dei carichi di lavoro, esegui il refactoring dei processi di deployment e operativi per:
- Esegui il provisioning e la configurazione delle risorse nel tuo Google Cloud ambiente anziché eseguire il provisioning delle risorse nell'ambiente di origine.
- Crea e configura i carichi di lavoro e implementali in Google Cloud anziché nell'ambiente di origine.
Hai raccolto informazioni su questi processi durante la fase di valutazione precedente.
Il tipo di refactoring da considerare per questi processi dipende da come li hai progettati e implementati. Il refactoring dipende anche dallo stato finale che vuoi ottenere per ogni processo. Ad esempio, prendi in considerazione quanto segue:
- Potresti aver implementato questi processi nell'ambiente di origine e intendi progettare e implementare processi simili in Google Cloud. Ad esempio, puoi eseguire il refactoring di questi processi per utilizzare Cloud Build, Cloud Deploy e Infrastructure Manager.
- Potresti aver implementato questi processi in un altro ambiente di terze parti al di fuori dell'ambiente di origine. In questo caso, devi eseguire il refactoring di questi processi per scegliere come target l'ambiente Google Cloud anziché l'ambiente di origine.
- Una combinazione degli approcci precedenti.
Il refactoring dei processi di deployment e operativi può essere complesso e richiedere uno sforzo significativo. Se provi a eseguire queste attività nell'ambito della migrazione del workload, quest'ultima può diventare più complessa ed esporti a rischi. Dopo aver valutato i processi di deployment e operativi, probabilmente hai una comprensione della loro progettazione e complessità. Se stimi che sia necessario un impegno notevole per eseguire il refactoring dei processi di deployment e operativi, ti consigliamo di prendere in considerazione il refactoring di questi processi nell'ambito di un progetto separato e dedicato.
Per saperne di più su come progettare e implementare le procedure di deployment su Google Cloud, consulta:
- Esegui la migrazione a Google Cloud: esegui il deployment dei tuoi carichi di lavoro
- Esegui la migrazione a Google Cloud: esegui la migrazione dai deployment manuali a quelli automatizzati e containerizzati
Questo documento si concentra sui processi di deployment che producono gli artefatti da eseguire il deployment e li esegue nell'ambiente di runtime di destinazione. La strategia di refactoring dipende molto dalla complessità di questi processi. Il seguente elenco descrive una possibile strategia di refactoring generale:
- Esegui il provisioning dei repository di artefatti su Google Cloud. Ad esempio, puoi utilizzare Artifact Registry per archiviare gli artefatti e creare dipendenze.
- Esegui il refactoring dei processi di build per archiviare gli artefatti sia nell'ambiente di origine sia in Artifact Registry.
- Esegui il refactoring dei processi di deployment per eseguire il deployment dei carichi di lavoro nell'ambiente di destinazione.Google Cloud Ad esempio, puoi iniziare eseguendo il deployment di un piccolo sottoinsieme dei tuoi carichi di lavoro in Google Cloud, utilizzando gli artefatti archiviati in Artifact Registry. Poi, aumenti gradualmente il numero di carichi di lavoro di cui è stato eseguito il deployment in Google Cloud, finché tutti i carichi di lavoro da migrare non vengono eseguiti su Google Cloud.
- Esegui il refactoring dei processi di build per archiviare gli artefatti solo in Artifact Registry.
- Se necessario, esegui la migrazione delle versioni precedenti degli artefatti da distribuire dai repository nell'ambiente di origine ad Artifact Registry. Ad esempio, puoi copiare le immagini container in Artifact Registry.
- Ritira i repository nell'ambiente di origine quando non ti servono più.
Per facilitare i rollback dovuti a problemi imprevisti durante la migrazione, puoi archiviare le immagini container sia nei repository di artefatti attuali in Google Cloud mentre la migrazione a Google Cloud è in corso. Infine, nell'ambito del ritiro dell'ambiente di origine, puoi eseguire il refactoring dei processi di creazione delle immagini container per archiviare gli artefatti solo in Google Cloud .
Sebbene non sia fondamentale per il successo di una migrazione, potresti dover eseguire la migrazione delle versioni precedenti degli artefatti dall'ambiente di origine ai repository di artefatti su Google Cloud. Ad esempio, per supportare il rollback dei workload a punti temporali arbitrari, potrebbe essere necessario migrare le versioni precedenti degli artefatti in Artifact Registry. Per maggiori informazioni, vedi Eseguire la migrazione delle immagini da un registro di terze parti.
Se utilizzi Artifact Registry per archiviare gli artefatti, ti consigliamo di configurare i controlli per proteggere i repository di artefatti, come icontrollo dell'accessolo dell'accesso, la prevenzione dellesfiltrazione di datiti,analisi delle vulnerabilitàtà e l'autorizzazione binaria. Per saperne di più, consulta Controllare l'accesso e proteggere gli artefatti.
Ottimizzare l' Google Cloud ambiente
L'ottimizzazione è l'ultima fase della migrazione. In questa fase, esegui l'iterazione delle attività di ottimizzazione finché l'ambiente di destinazione non soddisfa i requisiti di ottimizzazione. I passaggi di ogni iterazione sono i seguenti:
- Valuta l'ambiente, i team e il ciclo di ottimizzazione attuali.
- Stabilisci i requisiti e gli obiettivi di ottimizzazione.
- Ottimizza il tuo ambiente e i tuoi team.
- Ottimizza il ciclo di ottimizzazione.
Ripeti questa sequenza finché non hai raggiunto gli obiettivi di ottimizzazione.
Per ulteriori informazioni sull'ottimizzazione dell'ambiente Google Cloud , vedi Migrazione a Google Cloud: ottimizza il tuo ambiente e Google Cloud Well-Architected Framework: ottimizzazione delle prestazioni.
Passaggi successivi
- Scopri di più su altri percorsi di migrazione Google Cloud da AWS.
- Scopri come confrontare i servizi AWS e Azure con Google Cloud.
- Scopri quando trovare assistenza per le migrazioni.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.
Collaboratori
Autore: Marco Ferrari | Cloud Solutions Architect