Passa a Oracle Database@Azure con Oracle Zero Downtime Migration

Oracle Database@Azure ti consente di eseguire i tuoi database Oracle mission-critical su Oracle Exadata Database Service on Dedicated Infrastructure nel data center Microsoft Azure.

Sfrutta l'alta disponibilità, le prestazioni e la scalabilità integrate fornite da Oracle Exadata Database Service e Oracle Real Application Clusters (Oracle RAC), sfruttando al contempo la bassa latenza delle applicazioni Azure.

La migrazione del database al cloud è in genere un processo manuale associato ai tempi di inattività per la tua azienda. Oracle Zero Downtime Migration semplifica e automatizza le migrazioni dei database Oracle con tempi di inattività da zero a minimi, incorpora le best practice Oracle Maximum Availability Architecture (Oracle MAA) per impostazione predefinita, supporta le migrazioni della flotta ed è gratuito, tra gli altri vantaggi.

Dal suo rilascio nel 2019, Oracle Zero Downtime Migration è stato lo strumento di migrazione affidabile per i clienti di tutto il mondo per le migrazioni dei database Oracle alle macchine Oracle Exadata on-premise, Oracle Exadata Database Service on Cloud@Customer e Oracle Cloud Infrastructure (OCI). Scopri di più per saperne di più su Oracle Zero Downtime Migration.

Architettura

Questa architettura di riferimento descrive le migrazioni di Oracle Database da ambienti on-premise a Oracle Exadata Database Service on Dedicated Infrastructure su Oracle Database@Azure utilizzando il flusso di lavoro di migrazione online fisico basato su Oracle Data Guard e sul trasferimento diretto dei dati, offrendo semplicità, automazione e continuità aziendale durante le migrazioni del database a Oracle Database@Azure.

L'host del servizio Oracle Zero Downtime Migration viene installato su una virtual machine (VM) in locale separata accanto al database di origine. Il provisioning dell'Oracle Exadata Database Service on Dedicated Infrastructure di destinazione viene eseguito nel data center di Azure all'interno della rete virtuale di Azure (VNet) in una subnet delegata a Oracle Database@Azure. Il data center on-premise è connesso al data center di Azure tramite Azure ExpressRoute o VPN site-to-site. Il workflow fisico in linea di Oracle Zero Downtime Migration basato sul trasferimento diretto dei dati crea il database di destinazione utilizzando il metodo di ripristino da un servizio ed evita il backup del database di origine in una posizione di memorizzazione intermedia. Oracle Zero Downtime Migration utilizza automaticamente Oracle Data Guard per replicare i dati dal database in locale al database di destinazione. Oracle Zero Downtime Migration imposta automaticamente Oracle Data Guard, la mantiene ed esegue il cleanup della configurazione al termine della migrazione. Pertanto, le conoscenze necessarie per impostare e gestire Oracle Data Guard non sono necessarie. Al termine della migrazione, il database di destinazione può utilizzare la funzione Backup automatico per eseguire il backup del database in Oracle Database Autonomous Recovery Service.

Il seguente diagramma illustra questa architettura di riferimento.



oracle-db-azure-zdm-oracle.zip

Microsoft Azure fornisce i seguenti componenti:

  • VNIC di Azure

    I servizi nei data center di Azure dispongono di schede di interfaccia di rete fisiche (NIC). Le istanze delle virtual machine comunicano utilizzando NIC (VNIC) virtuali associate alle NIC fisiche. Ogni istanza dispone di una VNIC primaria creata e collegata automaticamente durante l'avvio ed è disponibile durante la durata dell'istanza.

  • Gateway di rete virtuale di Azure

    Azure Virtual Network Gateway è un servizio che stabilisce una connettività sicura e cross-premise tra una rete virtuale di Azure e una rete on-premise. Consente di creare una rete ibrida che abbraccia il data center e Azure.

  • Sottorete delegata di Azure

    La delega della subnet è la capacità di Microsoft di inserire un servizio gestito, in particolare un servizio platform-as-a-service, direttamente nella rete virtuale. Ciò significa che puoi designare o delegare una subnet come home per un servizio gestito esterno all'interno della tua rete virtuale. In altre parole, tale servizio esterno fungerà da risorsa di rete virtuale, anche se tecnicamente si tratta di un servizio platform-as-a-service esterno.

  • Rete virtuale di Azure

    La rete virtuale di Azure (VNet) è il componente di base fondamentale per la rete privata in Azure. VNet consente a molte risorse di Azure, come le macchine virtuali di Azure, di comunicare in modo sicuro tra loro, con Internet e con le reti locali.

Oracle Cloud Infrastructure fornisce i seguenti componenti:

  • Area

    Un'area geografica Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (tra paesi o addirittura continenti).

  • Rete cloud virtuale (VCN) e subnet

    Una VCN è una rete personalizzabile e definita dal software configurata in un'area Oracle Cloud Infrastructure. Come le tradizionali reti di data center, le reti VCN consentono di controllare l'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo aver creato la VCN. Puoi segmentare una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. È possibile modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.

  • Rete in locale

    Questa rete è la rete locale utilizzata dall'organizzazione. È uno dei raggi della topologia.

  • Gateway del servizio

    Il gateway di servizi fornisce l'accesso da una VCN ad altri servizi, come Oracle Cloud Infrastructure Object Storage. Il traffico dalla VCN al servizio Oracle viaggia sul fabric di rete Oracle e non attraversa Internet.

  • Data Guard

    Oracle Data Guard e Oracle Active Data Guard offrono un set completo di servizi che creano, mantengono, gestiscono e monitorano uno o più database di standby e che consentono ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database di standby come copie del database di produzione utilizzando la replica in-memory. Se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può passare qualsiasi database di standby al ruolo di produzione, riducendo al minimo i tempi di inattività associati all'indisponibilità. Oracle Active Data Guard offre la possibilità aggiuntiva di scaricare i carichi di lavoro in lettura, principalmente sui database in standby e offre inoltre funzioni avanzate di protezione dei dati.

  • Servizio di database Exadata

    Oracle Exadata Database Service ti consente di sfruttare la potenza di Exadata nel cloud. È possibile eseguire il provisioning di sistemi Exadata X9M flessibili che consentono di aggiungere server di calcolo del database e server di storage al sistema di pari passo con l'aumento delle esigenze. I sistemi Exadata X9M offrono reti RDMA su Ethernet convergente (RoCE) per larghezza di banda elevata e bassa latenza, moduli di memoria persistente (PMEM) e software Exadata intelligente. È possibile eseguire il provisioning dei sistemi Exadata X9M utilizzando una forma equivalente a un sistema X9M con Quarter Rack, quindi aggiungere database server e storage in qualsiasi momento dopo il provisioning.

    Oracle Exadata Database Service on Dedicated Infrastructure fornisce Oracle Exadata Database Machine come servizio in un data center Oracle Cloud Infrastructure (OCI). L'istanza di Oracle Exadata Database Service on Dedicated Infrastructure è un cluster virtual machine (VM) che risiede nei rack Exadata in un'area OCI.

    Oracle Exadata Database Service on Cloud@Customer offre Oracle Exadata Database Service ospitato nel tuo data center.

  • Host del servizio di migrazione senza tempi di inattività

    L'host del servizio Oracle Zero Downtime Migration deve essere un sistema dedicato, ma può essere condiviso per altri scopi.

    Il software Oracle Zero Downtime Migration richiede un host Oracle Linux standalone in esecuzione su una qualsiasi delle seguenti piattaforme: Oracle Linux 7, Oracle Linux 8 o Red Hat Enterprise Linux 8.

    L'host del servizio Oracle Zero Downtime Migration deve essere in grado di connettersi ai server del database di origine e di destinazione; purché la connettività sia garantita, l'host del servizio può essere posizionato ovunque.

  • Oracle Database Autonomous Recovery Service

    Oracle Database Autonomous Recovery Service è un servizio Oracle Cloud che protegge i database Oracle. Grazie all'automazione del backup e alle funzionalità avanzate di protezione dei dati per i database OCI, puoi scaricare tutti i requisiti di elaborazione e storage del backup su Oracle Database Autonomous Recovery Service, eliminando così i costi dell'infrastruttura di backup e il sovraccarico manuale dell'amministrazione.

Oracle Zero Downtime Migration workflow di migrazione

Nota

Per ogni worklfow di migrazione elencato, vedere Esplora altri per ulteriori dettagli.

È possibile eseguire i seguenti flussi di lavoro per eseguire la migrazione di Oracle Database a Oracle Exadata Database Service on Dedicated Infrastructure su Oracle Database@Azure.

  • Migrazione fisica in linea

    Il flusso di lavoro di migrazione online fisico supporta le migrazioni tra le stesse versioni e piattaforme di database. Utilizza il trasferimento diretto dei dati e il metodo "restore from service" per creare il database di destinazione, evitando esplicitamente di eseguire il backup del database di origine in una posizione di storage intermedia. Oracle Data Guard mantiene sincronizzati i database di origine e di destinazione per ottenere una migrazione con tempi di inattività minimi.

  • Migrazione fisica offline

    Il workflow di migrazione offline fisica supporta le migrazioni tra le stesse versioni e piattaforme del database. Crea il database di destinazione utilizzando il backup e il ripristino di Recovery Manager (RMAN). Il servizio File di Azure fornisce una condivisione di file NFS per memorizzare i file di backup RMAN.

  • Migrazione online logica

    Il flusso di lavoro logico di migrazione in linea supporta le migrazioni tra le stesse e diverse versioni e piattaforme del database. Utilizza l'esportazione e l'importazione di Oracle Data Pump per creare il database di destinazione. Il servizio File di Azure fornisce una condivisione di file NFS per memorizzare i file di dump di Data Pump. OCI GoldenGate mantiene sincronizzati i database di origine e di destinazione per ottenere una migrazione con tempi di inattività minimi.

  • Migrazione logica non in linea

    Il workflow di migrazione offline logica supporta le migrazioni tra le stesse e diverse versioni e piattaforme del database. Utilizza l'esportazione e l'importazione di Oracle Data Pump per creare il database di destinazione. Il servizio File di Azure fornisce una condivisione di file NFS per memorizzare i file di dump di Data Pump.

È possibile eseguire i seguenti flussi di lavoro di migrazione di Oracle Zero Downtime Migration per eseguire la migrazione di Oracle Database in Oracle Autonomous Database Serverless su Oracle Database@Azure.

  • Migrazione online logica

    Il flusso di lavoro logico di migrazione in linea supporta le migrazioni tra le stesse e diverse versioni e piattaforme del database. Utilizza l'esportazione e l'importazione di Oracle Data Pump per creare il database di destinazione. Il servizio File di Azure fornisce una condivisione di file NFS per memorizzare i file di dump di Data Pump. OCI GoldenGate mantiene sincronizzati i database di origine e di destinazione per ottenere una migrazione con tempi di inattività minimi.

  • Migrazione logica non in linea

    Il workflow di migrazione offline logica supporta le migrazioni tra le stesse e diverse versioni e piattaforme del database. Utilizza l'esportazione e l'importazione di Oracle Data Pump per creare il database di destinazione. Il servizio File di Azure fornisce una condivisione di file NFS per memorizzare i file di dump di Data Pump.

Suggerimenti

Utilizzare i seguenti suggerimenti come punto di partenza. Le vostre esigenze potrebbero differire dall'architettura descritta qui.
  • Scaricare la versione più recente del software Oracle Zero Downtime Migration da My Oracle Support (MOS) cercando la patch numero 33509650 nella scheda Patches & Updates.
  • Installare l'host del servizio Oracle Zero Downtime Migration in locale accanto al database di origine.
  • Assicurarsi che l'host del servizio Oracle Zero Downtime Migration disponga di almeno 100 GB di storage gratuito.
  • Garantisci una connettività di rete sicura e privata tra on-premise e Azure tramite VPN site-to-site o Azure ExpressRoute.
  • A seconda delle dimensioni del database, garantire un throughput di rete sufficiente dalla rete in locale ad Azure.

Considerazioni

Considerare i seguenti punti durante la distribuzione di questa architettura di riferimento.

  • Il database di destinazione deve:
    • Esegui il provisioning utilizzando gli strumenti di Oracle Cloud senza abilitare i backup automatici.
    • Avere una versione del file del fuso orario uguale o superiore al database di origine.
  • I database di origine e di destinazione devono:
    • Hanno lo stesso nome di database (DB_NAME).
    • Hanno nomi univoci di database diversi (DB_UNIQUE_NAME).
    • Utilizzare un file dei parametri del server (SPFILE).
    • Utilizzare lo stesso set di caratteri.
    • Avere lo stesso algoritmo di cifratura definito nel file sqlnet.ora.
    • Avere la stessa versione della release principale (ad esempio, 19c). Tuttavia, il database di destinazione potrebbe avere un livello di patch più elevato (ad esempio, origine alla versione 19.21 e destinazione alla versione 19.22). Se il database di destinazione si trova a un livello di patch superiore rispetto al database di origine, Oracle Zero Downtime Migration esegue automaticamente Datapatch come parte della migrazione.
  • La password dell'account utente SYS deve essere uguale nei database di origine e di destinazione.
  • Il parametro di inizializzazione del database COMPATIBLE deve essere lo stesso nei database di origine e di destinazione.
  • Per Oracle Database 12c Release 2 e successive, il wallet TDE deve esistere nell'origine e lo stato del wallet deve essere OPEN. Non è necessario cifrare il database di origine, ma è necessario configurare un wallet TDE.
  • Oracle Zero Downtime Migration richiede che la chiave SSH sull'host del servizio Oracle Zero Downtime Migration sia in formato RSA (in Oracle Linux 8, l'impostazione predefinita è OPENSSH).

Conferma

  • Autori: Sinan Petrus Toma, Ricardo Gonzalez, Thomas Van Buggenhout
  • Collaboratori: Emiel Ramakers, Wei Han, John Sulyok