Eseguire la migrazione di carichi di lavoro Oracle ad Azure
Come parte del percorso di adozione del cloud, è necessario eseguire la migrazione dei carichi di lavoro esistenti al cloud. I carichi di lavoro Oracle sono simili ad altri carichi di lavoro e richiedono un approccio metodico per garantire una corretta migrazione. Per maggiori informazioni sulla metodologia di migrazione, consultare la sezione Migrazione cloud in Cloud Adoption Framework. Questo articolo descrive vincoli e considerazioni univoci specifici per i carichi di lavoro Oracle.
Processo di migrazione Oracle
È consigliabile rivalutare continuamente i requisiti dell'infrastruttura per migliorare le prestazioni e ridurre i costi usando il tipo di servizio pertinente per il carico di lavoro. Ad esempio, se si prevede di spostare il carico di lavoro in Oracle Database@Azure, assicurarsi che lo SKU selezionato soddisfi i requisiti. Analogamente, se si sposta il carico di lavoro in Oracle in Azure Macchine virtuali, assicurarsi che le dimensioni della macchina virtuale soddisfino i requisiti. Per maggiori informazioni, consultare la sezione Pianificazione della capacità per la migrazione dei carichi di lavoro Oracle alle zone di destinazione di Azure.
Esaminare le risorse di migrazione per definire il processo di migrazione da Oracle ad Azure. È anche possibile:
Verificare i limiti di quota della sottoscrizione di Azure: assicurarsi che i limiti di quota nella sottoscrizione di Azure siano in grado di soddisfare le dimensioni delle macchine virtuali di destinazione scelte se si esegue la migrazione a Oracle in Azure Macchine virtuali.
Identificare un modello di distribuzione: automatizzare la distribuzione dei componenti della soluzione il più possibile usando l'infrastruttura come codice (IaaS), l'integrazione continua e la distribuzione continua (CI/CD) e altre procedure DevOps.
Determinare le dipendenze dell'applicazione: assicurarsi che le attività di migrazione siano con interruzioni minime.
Identificare la capacità dei dati: identificare la quantità di dati di cui eseguire la migrazione e valutare la capacità corrente di connettività di rete disponibile dagli ambienti locali ad Azure. Usare queste informazioni per determinare se è possibile copiare i dati direttamente dagli ambienti locali ad Azure. Potrebbe essere necessaria un'appliance di trasferimento dati fisico come Azure Data Box per il caricamento iniziale dei dati.
Determinare i requisiti di disponibilità: determinare i requisiti di disponibilità del carico di lavoro perché potrebbero influire sugli strumenti di migrazione che è possibile usare.
Per Oracle Database@Azure, assicurarsi di:
Verificare che la soluzione Oracle Database@Azure sia disponibile nell'area in cui si vuole distribuire la soluzione. Per maggiori informazioni, consultare la sezione Aree disponibili.
Valutare l'uso di Oracle Zero Downtime Migration per il processo di migrazione. Valutare le strategie di migrazione per determinare l'approccio più adatto per i requisiti di migrazione specifici. Per maggiori informazioni, consultare la sezione Migrazione zero tempo di inattività.
Attività specifiche del carico di lavoro per la migrazione Oracle
Nella sezione seguente, viene descritto il processo di migrazione in modo più dettagliato. I passaggi non sono necessariamente sequenziali. È possibile eseguire alcuni passaggi in parallelo.
Valutare le versioni del sistema di origine e di destinazione: valutare se le versioni del sistema operativo locale, le versioni dell'applicazione e le versioni del database sono le stesse delle versioni che si prevede di usare in Azure.
Se è necessario aggiornare una o più risorse, aggiornarle prima della migrazione per evitare di complicare il processo di migrazione.
Se il database locale viene eseguito in un sistema operativo big-endian, ad esempio Oracle Solaris, IBM Advanced Interactive eXecutive o Hewlett Packard Unix, il processo di migrazione del database include una conversione endian. Azure supporta solo sistemi operativi little-endian. Questa limitazione riduce il numero di strumenti disponibili per la migrazione. In particolare, non è possibile usare Oracle Data Guard o altri metodi di copia file. I metodi di migrazione compatibili con la conversione endian includono Oracle Data Pump Export o Import, Oracle cross-platform transportable tablespaces (XTTS) o utilità di replica dei dati come Oracle GoldenGate, Quest SharePlex e Striim.
È possibile modernizzare o eseguire la migrazione di server applicazioni locali a seconda dei requisiti e della compatibilità. Per maggiori informazioni, consultare la sezione Scenari di adozione del cloud.
Valutare i requisiti di disponibilità del carico di lavoro durante il processo di migrazione: se è necessario ridurre al minimo i tempi di inattività del carico di lavoro, i metodi di migrazione, ad esempio Data Pump Export o Import, potrebbero non essere adatti al carico di lavoro. In tal caso, è possibile seguire questo processo in quattro passaggi:
Usare Oracle Gestione ripristino (RMAN) per eseguire il backup e quindi ripristinare l'intero database in Azure. Se necessario, eseguire una conversione endian tramite XTTS. Il risultato è un database che rappresenta una copia temporizzato del database di origine locale. Per maggiori informazioni, consultare la sezione Trasporto di dati tra piattaforme.
Usare Oracle Data Guard per sincronizzare il database appena ripristinato in Azure con il database di origine se entrambe le origini sono in formato little-endian. Non è possibile usare Data Guard se la migrazione prevede una conversione big-endian a little-endian. Usare invece un'utilità di replica dei dati basata su SQL, ad esempio Oracle GoldenGate, Quest SharePlex o Striim, per sincronizzare il database appena ripristinato in Azure con il database di origine.
Dopo aver sincronizzato il database di destinazione in Azure con il database locale di origine, è possibile pianificare un cutover. Un cutover arresta il database locale di origine e scarica le ultime transazioni nel database di destinazione in Azure. È quindi possibile aprire il database di destinazione in Azure come nuovo database di origine. Un cutover può richiedere poco meno di pochi minuti, a seconda del metodo di sincronizzazione usato.
A seconda dell'approccio di migrazione scelto per i servizi dell'applicazione, potrebbe essere necessario completare diverse attività del servizio applicazioni prima di eseguire completamente la migrazione dell'applicazione ad Azure.
Valutare le licenze necessarie: il database potrebbe richiedere diverse licenze a seconda degli strumenti di migrazione. Ad esempio:
Oracle Data Guard richiede Oracle Database Enterprise Edition.
Oracle GoldenGate richiede licenze Oracle GoldenGate.
Per maggiori informazioni sulle licenze Oracle in Azure, consultare la sezione Gestione delle licenze del software Oracle nell'ambiente di cloud computing.