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 altre informazioni sulla metodologia di migrazione, vedere migrazione Cloud in Cloud Adoption Framework per Azure. Questo articolo descrive i vincoli e le considerazioni specifici per i carichi di lavoro Oracle.
Scenari di migrazione Oracle
Quando si esegue la migrazione dei carichi di lavoro Oracle, è necessario eseguire la transizione di database e applicazioni. Questo articolo illustra l'approccio lift-and-shift per le migrazioni di applicazioni e database. L'approccio lift-and-shift include la distribuzione di applicazioni Oracle in macchine virtuali di Azure. Per la migrazione del database sono disponibili diverse opzioni. Questo articolo fornisce indicazioni valide per Oracle Database@Azure.
Applicazioni in macchine virtuali: Eseguire applicazioni aziendali Oracle, ad esempio Siebel, PeopleSoft, JD Edwards, E-Business Suite o applicazioni WebLogic Server personalizzate nell'infrastruttura di Azure.
Oracle Database Standard Edition o Enterprise Edition su macchine virtuali: In questo scenario si distribuisce Oracle Database su una macchina virtuale. Sono disponibili diverse opzioni, da autogestito a database gestiti. Se si preferisce una soluzione di database gestita, esaminare Tessell.
Oracle Database@Azure: Oracle Database@Azure è un servizio di database Oracle in esecuzione in Oracle Cloud Infrastructure (OCI) e che si trova nei data center Microsoft.
Nota
Per determinare i sistemi operativi supportati per la tua specifica versione del database, consulta database supportati e sistemi operativi.
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, per tutti gli scenari menzionati in precedenza, assicurarsi che sia disponibile una larghezza di banda sufficiente per la migrazione. Incoraggiamo vivamente a esaminare la larghezza di banda necessaria quando si esegue una prova di concetto (PoC).
Se si sposta il carico di lavoro su Oracle su macchine virtuali (VM), assicurarsi che le dimensioni delle macchine virtuali (VM) 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 delle sottoscrizioni 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 macchine virtuali.
Nota
Se si ospita il carico di lavoro in Oracle Database@Azure e si necessita di un aumento della quota, consultare il contatto Oracle.
Identificare un modello di distribuzione: Automatizzare la distribuzione dei componenti della soluzione il più possibile usando l'infrastruttura come codice, l'integrazione continua e le pipeline di recapito continuo e altre procedure DevOps.
Determinare le dipendenze dell'applicazione: Assicurarsi che le attività di migrazione siano il meno distruttive possibile.
Identificare la capacità dei dati: Identificare la quantità di dati da migrare e valutare la capacità corrente di connettività di rete disponibile dagli ambienti on-premises 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. Definire il tempo di inattività massimo accettabile. Questa metrica consente di definire gli strumenti di migrazione e l'approccio.
Questa considerazione si applica allo stesso modo alla tua richiesta. Se non è possibile accettare un'interruzione delle operazioni quotidiane, è necessario eseguire una migrazione online.
- Determinare gli strumenti per la migrazione del carico di lavoro a Oracle in macchine virtuali di Azure: I due percorsi di migrazione principali sono offline e online.
| Migrazione offline | Migrazione online |
|---|---|
| Copia diretta una tantum del database. | Copia iniziale del database seguita da acquisizione dei dati di modifica durante la migrazione. |
| Richiede che l'applicazione interessata sia offline durante la migrazione. | L'applicazione può rimanere online durante la migrazione. |
| Strumenti utilizzati: Data Box, DataPump, Oracle Recovery Manager (RMAN) | Tools usati: DataGuard, Oracle Recovery Manager (RMAN), GoldenGate |
Nota
Se si decide di eseguire una migrazione online, assicurarsi di configurare le regole del firewall per consentire il trasferimento dei dati.
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 in locale e in Azure.
Se è necessario aggiornare una o più risorse, aggiornarle prima della migrazione per semplificare 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 Oracle Data Pump 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 come Data Pump Export o Data Pump Import potrebbero non essere adatti al carico di lavoro. In tal caso, seguire questo processo in quattro passaggi:
Usare 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.
Se entrambe le origini sono in formato little-endian, usare Oracle Data Guard per sincronizzare il database appena ripristinato in Azure con il database di origine. Non è possibile usare Data Guard se la migrazione include la conversione da 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.
Indicazioni sulla migrazione di Oracle Database@Azure
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 altre informazioni, vedere migrazione senza tempo di inattività (ZDM). ZDM consente di scegliere scenari di migrazione logica o fisica. Per altre informazioni, vedere migrazione ZDM.
Nota
Se si sceglie Servizio di database autonomo (ADB-S), tenere presente che sono supportati solo gli scenari di migrazione logica.
Altre indicazioni
La sezione seguente consente di scegliere l'opzione di migrazione appropriata per i requisiti e le dimensioni dei dati.
Informazioni di riferimento sulla durata della migrazione basata su ExpressRoute
La tabella seguente funge solo da linea di base. Non considera altri carichi di lavoro di produzione che vengono eseguiti tramite la stessa connessione Di Azure ExpressRoute.
VMware potrebbe richiedere una larghezza di banda superiore a quella indicata. Valuta le esigenze di larghezza di banda durante la fase di PoC. Se hai bisogno di supporto, contatta il tuo contatto locale.
| Dimensioni dei dati | Larghezza di banda di 1 Gbps | Larghezza di banda di 10 Gbps |
|---|---|---|
| 1 TB | 3 ore | 15 minuti |
| 10 TB | 1 giorno | 3 ore |
| 35 TB | 4 giorni | 9 ore |
| 80 TB | 8 giorni | 20 ore |
| 100 TB | 11 giorni | 1 giorno |
| 200 TB | 21 giorni | 2 giorni |
| 500 TB | 53 giorni | 5 giorni |
Se prevedi di usare ExpressRoute per la migrazione, assicurati che la sua resilienza soddisfi i tuoi requisiti.