Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Migrazione con AWS Application Migration Service
La maggior parte delle lift-and-shift migrazioni di grandi dimensioni da utilizzare. AWS AWS Application Migration Service
Questo metodo di replica a livello di blocco non supporta lo storage collegato alla rete (NAS), le unità condivise come le condivisioni Network File System (NFS) o le condivisioni Common Internet File System (CIFS) /Server Message Block (SMB). Supporta solo lo storage a livello di blocco collegato direttamente al sistema migrato al momento della migrazione. (Per ulteriori informazioni, consulta le domande frequenti sul servizio di migrazione delle applicazioni sul supporto SAN/NAS.) Ciò limita l'applicabilità della replica tramite Application Migration Service per la maggior parte dei sistemi cluster, poiché la maggior parte dei cluster si basa sullo storage condiviso di varie implementazioni. Per ulteriori informazioni, consulta le sezioni Vantaggi e svantaggi di questa pagina.
Il metodo di replica a livello di blocco richiede l'installazione di un agente di AWS replica a livello di sistema operativo (OS) e tale agente supporta solo piattaforme x86 basate sul sistema operativo Windows o Linux (vedere Sistemi operativi supportati da Application Migration Service). Le piattaforme non x86 non rientrano nell'ambito di questo metodo di migrazione. Queste includono ARM, RISC/CISC sistemi, varianti PowerPC, sistemi IBM come pSeries, iSeries, zSeries e i rispettivi sistemi operativi come AIX, HP-UX, Solaris, Linux for PowerPC, zLinux su mainframe e altre architetture non x86.
L'agente AWS Replication funziona a livello di driver di dispositivo del file system virtuale* nello stack del sistema operativo, acquisendo tutti i blocchi di dati da scrivere sui dispositivi sottostanti a livello di blocco (inclusi unità, dischi rigidi e dispositivi SAN collegati direttamente), come spiegato nella pagina delle domande frequenti su Application Migration Service sotto queste domande:
* Vedi le definizioni di file system
Vantaggi
Per lift-and-shift le migrazioni di qualsiasi dimensione, Application Migration Service offre molti vantaggi:
-
La replica è facile da configurare (non richiede una curva di apprendimento ripida).
-
È veloce da scalare, implementando gli agenti sui computer di origine.
-
Puoi utilizzare la fabbrica di migrazione al cloud
per automatizzare la maggior parte delle attività manuali, gestire più macchine e orchestrare ondate di migrazione. -
Supporta un'ampia gamma di architetture di sistema operativo x86.
-
Supporta qualsiasi tipo di ambiente di origine (data center locale, qualsiasi altro cloud o altro Regione AWS).
-
È indipendente dall'applicazione, quindi supporta qualsiasi applicazione in esecuzione sui server di origine.
-
Non è richiesta alcuna licenza o acquisto. AWS offre pay-as-you-go prezzi, quindi paghi il servizio solo per il periodo in cui lo utilizzi, senza contratti a lungo termine o licenze complesse. Application Migration Service offre un periodo gratuito di 90 giorni per server, sufficiente per la maggior parte delle migrazioni. Per i dettagli, consulta i AWS Application Migration Service prezzi sul sito Web
. AWS
Svantaggi
Quando si utilizzano strumenti di replica a livello di blocco come Application Migration Service, è possibile che si verifichino i seguenti casi e fattori secondari da considerare:
-
Application Migration Service non supporta file system condivisi montati o dispositivi di archiviazione condivisi come NAS, inclusi i file system CIFS/SMB NFS. Per ulteriori informazioni sui metodi di replica per NAS o file system condivisi, vedere MGN replication agent to migrate NFS Share (articolo AWS re:POST) e Migrate
shared file system in an large migration (modello Prescriptive Guidance). AWS AWS -
Application Migration Service non supporta la maggior parte delle configurazioni di file server o cluster di database in cluster con storage condiviso a causa delle limitazioni nel modo in cui tale storage condiviso viene rappresentato a livello di sistema operativo attraverso i livelli dei driver del dispositivo. Ad esempio, i cluster Microsoft SQL Server con l'opzione Storage Space Direct (S2D) non sono supportati. Tuttavia, è ancora possibile utilizzare Application Migration Service per replicare altri tipi di sistemi cluster con storage a blocchi condiviso, ad esempio lo storage condiviso nelle configurazioni FCI (Failover Cluster Instance) in Windows Server Failover Cluster (WSFC), come descritto nel post di blog Migrazione dei cluster di Microsoft Windows a AWS Using Migration CloudEndure,
lo storage esposto da array SAN esterni (connessioni iSCSI) e alcuni gruppi di disponibilità Microsoft SQL Server Always On (AAs) AG) raggruppamenti in casi angolari specifici. In generale, Application Migration Service supporta la replica di un dispositivo a livello di blocco da un server in cui il dispositivo di storage è completamente presente sul server durante la migrazione. (L'agente di AWS replica deve essere installato sul server e il dispositivo deve essere visibile all'agente per la replica.) Tuttavia, tutti questi scenari richiedono procedure molto specifiche e comportano finestre di taglio più lunghe. -
I sistemi con un alto tasso di modifiche dei dati (come i database OLTP) potrebbero avere requisiti di rete o prestazioni più elevati, il che complica le operazioni di migrazione.
-
La larghezza di banda della rete deve essere sufficiente per trasferire la quantità di dati entro la finestra temporale di migrazione e conversione pianificata. Questo perché Application Migration Service non fornisce un'opzione di spedizione offline, a differenza AWS Snowball
di. -
La migrazione richiede un periodo di inattività ridotto, entro un RTO di pochi minuti. Application Migration Service utilizza le istantanee EBS come parte del processo di migrazione e i nuovi dischi EBS creati da tali istantanee hanno inizialmente prestazioni peggiori. Con alcuni modelli di lettura di database, ciò potrebbe aumentare la finestra di conversione effettiva prima che il database migrato raggiunga le massime prestazioni.
Scenari più adatti
Application Migration Service copre quasi tutte le lift-and-shift migrazioni, con alcuni svantaggi, come illustrato nelle due sezioni precedenti. Questo strumento è in grado di gestire la maggior parte dei casi straordinari, come i cluster di database, purché la finestra di conversione prolungata richiesta per tali sistemi soddisfi i requisiti di migrazione.
Le sezioni seguenti trattano in modo più approfondito due scenari:
-
Migrazione su larga scala con più ondate di migrazione
-
La migrazione di una singola applicazione che richiede tempi di inattività minimi
Migrazione su larga scala con più ondate di migrazione
Un esempio di migrazione su larga scala è l'uscita di un data center caratterizzata da requisiti di dimensioni e velocità. Di solito comporta anche un vincolo temporale specifico, come la fine del contratto di locazione del data center. In tal caso, è la scala a determinare l'approccio. Le ondate di migrazione sono determinate e raggruppate per applicazioni, inclusi i database, e ogni ondata prevede una fase pianificata di preparazione, migrazione e conversione con requisiti specifici relativamente ai tempi di inattività.
All'interno di ogni ondata di migrazione, è preferibile spostare i server di database su larga scala utilizzando la replica a livello di blocco dell'Application Migration Service, ad eccezione di alcune eccezioni per i seguenti casi speciali che potrebbero richiedere un approccio di migrazione separato:
-
La maggior parte dei sistemi di database in cluster
-
Sistemi di database in cui la frequenza di modifica supera la velocità di trasmissione effettiva della rete disponibile (il che potrebbe causare un ritardo nella replica)
Per ogni caso particolare, considera il compromesso tra i requisiti relativi ai tempi di inattività e il livello di impegno richiesto dall'uso di un altro strumento di migrazione. In alcuni casi, è molto più semplice utilizzare lo stesso approccio di migrazione per tutti i sistemi anziché utilizzare strumenti separati e creare processi diversi per sistemi specifici. Se Application Migration Service non supporta i requisiti di inattività per un sistema specifico, si consiglia di utilizzare invece uno dei metodi descritti nella sezione Migrazione con strumenti di database nativi.
Migrazione di singole applicazioni
Lo scenario con una singola applicazione rappresenta un approccio granulare per la migrazione di una singola applicazione aziendale critica che richiede tempi di inattività minimi o quasi nulli durante la migrazione o alcune applicazioni di questo tipo. L'ambito della migrazione potrebbe variare a seconda della criticità aziendale e dei requisiti di downtime, a differenza dei requisiti di velocità e scalabilità dello scenario precedente (migrazione su larga scala). Se l'applicazione consente tempi di inattività nell'ambito dell'RTO di Application Migration Service, deve essere gestita nello stesso modo di qualsiasi migrazione su larga scala descritta in precedenza.
Tuttavia, nei casi in cui il tempo limite deve essere il più vicino possibile al minimo, ad esempio quando il database migrato presenta schemi di lettura che richiedono molto tempo per funzionare a pieno regime e le finestre di cutover devono rimanere ridotte, è consigliabile prendere in considerazione un approccio più dettagliato e granulare. In generale, tale approccio prevede fasi e requisiti aggiuntivi, che richiedono più impegno e tempo. Una delle fasi consiste nel separare la migrazione dei database dalla migrazione dei server dell'applicazione e nell'utilizzare gli strumenti di migrazione di database descritti nella sezione successiva per mantenere sincronizzati il database di origine e quello di destinazione. Esistono vari metodi per eseguire la sincronizzazione. Ogni metodo presenta vantaggi e svantaggi e comporta diversi compromessi tra la quantità di tempi di inattività e la complessità della sincronizzazione. Tuttavia, mantenere il database sincronizzato tra l'ambiente di origine e quello di destinazione consente di separare il livello del database dal livello dell'applicazione. Partendo dal presupposto che i server delle applicazioni non archivino i dati persistenti localmente ma trasferiscano tutto al livello del database, la sincronizzazione rimuove anche le restrizioni relative ai tempi di inattività a livello di applicazione.
Il disaccoppiamento dei livelli di database e applicazione consente di migrare i server delle applicazioni utilizzando Application Migration Service come nello scenario precedente. I server dell'applicazione di destinazione possono essere avviati nell'ambiente di destinazione mentre i sistemi di origine sono ancora in funzione, elaborano i dati e li archiviano nel livello del database. Poiché il livello del database è già sincronizzato con la destinazione, il tempo di cutover è minimo: implica solo il cambio di rete e il reindirizzamento delle richieste dei clienti dal vecchio sistema di origine all'ambiente di destinazione. È possibile utilizzare diversi metodi per eseguire questa operazione, seguendo le indicazioni relative alle implementazioni blu/verdi, in genere attraverso il cambiamento degli endpoint DNS, l'uso di zone DNS ponderate, l'uso di AWS Global Accelerator
