Migra le applicazioni aziendali strategiche su Oracle Database@Azure utilizzando una strategia a fasi

Migra un database e un'applicazione on-premise nel cloud, riducendo al minimo i tempi di inattività con strategie phased o ibride, garantendo una connettività perfetta per le applicazioni basate su cloud ai database on-premise. Un piano ben strutturato accelera l'uscita dal data center, mitiga i rischi e mantiene l'affidabilità. Un approccio ibrido a due fasi consente una transizione fluida mantenendo la stabilità.

Quando trasferisci un database e un'applicazione on-premise nel cloud, devi affrontare diverse sfide per garantire una transizione perfetta. Scegli una strategia di migrazione che riduca al minimo i tempi di inattività, come la migrazione graduale o le soluzioni di cloud ibrido, per mantenere i tempi di attività delle applicazioni, in particolare per i carichi di lavoro aziendali critici. Assicurati che anche le applicazioni già presenti nel cloud, che si connettono ai database on premise, siano prese in considerazione nel piano di migrazione per evitare problemi di connettività. Per le applicazioni SaaS, dove l'applicazione risiede nel cloud, ma il database è on-premise, assicurati una strategia completa che includa entrambi i componenti. Affronta queste sfide in modo proattivo per garantire una transizione fluida e mantenere l'affidabilità delle tue applicazioni aziendali strategiche. Una strategia ben strutturata consente inoltre di accelerare l'uscita dal data center e ridurre i rischi di migrazione, garantendo l'affidabilità delle applicazioni aziendali strategiche.

Oracle Database@Azure elimina la dipendenza da Exadata o da Oracle Real Application Clusters (Oracle RAC) on-premise avvicinando il database ai carichi di lavoro delle applicazioni all'interno di Microsoft Azure. Questa integrazione consente di ospitare sia il database che le applicazioni nello stesso data center, riducendo la latenza e riducendo la dipendenza dall'infrastruttura fisica.

L'implementazione di questa configurazione richiede spesso una soluzione attentamente progettata per stabilire l'architettura di destinazione senza interrompere le operazioni aziendali critiche. Molti carichi di lavoro mission-critical vengono distribuiti in più region per garantire la continuità del business attraverso ambienti di disaster recovery o standby. Questo approccio supporta una strategia di migrazione ibrida a due fasi, che consente transizioni senza interruzioni mantenendo la stabilità operativa.

Operazioni preliminari

Prima di iniziare, verificare di considerare quanto segue:

Disabilita il failover Fast-Start in Oracle Data Guard per garantire una transizione fluida e controllata tra le region primarie e standby durante la migrazione.
OCI Database Migration fornisce migrazioni convalidate, cross-version, tolleranti agli errori e incrementali di Oracle Database e MySQL per casi d'uso online e offline, come ZDM e OCI Migration.
Questa architettura di riferimento segue il modello MAA (Gold Maximum Availability Architecture) di Oracle in una configurazione di standby attivo con distribuzione tra più aree per una maggiore resilienza. Questa architettura di riferimento può essere estesa per utilizzare MAA platinum, in cui l'alta disponibilità locale viene ottenuta tramite la replica sincrona utilizzando Oracle Data Guard tra le zone di disponibilità, mentre il disaster recovery tra più aree viene implementato con la replica asincrona.

Architettura

Questa architettura delinea un approccio graduale per la migrazione di Oracle Database on-premise su Oracle Exadata Database Service in Oracle Database@Azure con tempi di inattività minimi.

Per semplificare questa strategia, la suddividiamo in tre aspetti chiave: stato attuale, stato futuro e fasi di migrazione.

Questa architettura di riferimento ha quattro componenti principali (contrassegnati con numeri blu nel diagramma).

Numero	Componente	Descrizione
1	Data center primario on-premise	Ospita il database e l'applicazione come sistema primario prima della migrazione.
2	Data center di standby on-premise	Gestisce un sistema in standby, replicando il database primario on premise.
3	Area principale di Azure	Esegue l'applicazione e il database su Oracle Database@Azure, diventando il sistema principale successivo alla migrazione.
4	standby region di Azure	Un sito di disaster recovery che replica l'area primaria utilizzando Oracle Data Guard.

Segue la descrizione dell'architettura logica diagram.png

Descrizione dell'immagine logico-architettura-diagram.png

logico-architettura-diagramma-oracle.zip

Stato corrente

Nell'impostazione esistente, sia il data center primario (1) che il data center in standby (2) sono ospitati on premise, supportando carichi di lavoro e database delle applicazioni. Il data center primario gestisce tutte le richieste, mentre il data center di standby gestisce la replica asincrona utilizzando Oracle Data Guard. Ciò garantisce l'alta disponibilità, con il sistema in standby pronto per il failover in caso di guasti imprevisti.

Stato futuro

L'architettura futura rispecchia l'impostazione corrente, ma è completamente ospitata nel cloud, in due aree geografiche di Azure: la region primaria (3) e la standby region (4). Viene eseguita la migrazione del database ai servizi Exadata Oracle Database@Azure, con replica asincrona tra i database primari e in standby gestiti tramite Oracle Data Guard sulla rete Oracle Cloud Infrastructure (OCI).

Per una connettività sicura tra il data center in locale e Azure, un firewall Azure viene distribuito all'interno di un hub vWAN (Virtual WAN) sicuro in Azure.

Fasi della migrazione

La migrazione segue un approccio a due fasi per garantire una transizione controllata e affidabile.

Fase 1: transizione dello standby on-premise a Azure e switchover

In questa fase viene eseguita la migrazione del sistema in standby (2) in locale in Azure (3). Una volta completati, i ruoli primario (1) e in standby (3) vengono scambiati, rendendo Azure la nuova region primaria.

Stabilire la connettività tra Azure e on premise utilizzando Azure ExpressRoute.
Configurare l'hub sicuro di Azure, il firewall di Azure e vWAN per la sicurezza (se non già in uso).
Esegui il provisioning di Oracle Exadata Cloud Infrastructure nell'area primaria di Azure, quindi:
1. Impostare un cluster VM (Virtual Machine) Oracle Exadata e creare il database di destinazione.
2. Abilitare i log di archivio e il log forzato sul database primario (se non è già abilitato).
Configurare Oracle Net per i nomi listener e TNS per la ricerca automatica.
Eseguire il ripristino dal servizio per impostare un database in standby nell'area primaria di Azure (3).
Eseguire uno switchover, rendendo il database di Azure (3) il nuovo database primario.
Eseguire la migrazione delle applicazioni nell'area primaria di Azure (3) e aggiornare gli instradamenti DNS.
Verificare la configurazione di Data Guard e monitorare lo stato della replica.

Fase 2: definizione dello standby in Azure e disattivazione on-premise

In questa fase, un sistema in standby (4) viene impostato in Azure e le risorse in locale (1 e 2) vengono disattivate.

Esegui il provisioning di Oracle Exadata Cloud Infrastructure nella standby region (4) con Oracle Database@Azure.
Impostare un cluster VM Oracle Exadata e creare il database di standby.
Abilitare Oracle Data Guard per associare il database dell'area primaria (3) al database di standby (4).
Utilizza la rete OCI per la replica con throughput elevato, sfruttando il peering locale e remoto all'interno di una topologia hub e spoke tra i database primari e in standby.
Eseguire la migrazione dei carichi di lavoro dell'applicazione nella standby region di Azure (4).
Arresta la sincronizzazione con le risorse on premise, quindi disattiva le risorse dell'applicazione e del database on premise dai data center primari (1) e in standby (2).

Il seguente diagramma illustra questa architettura di riferimento.

Segue la descrizione dell'architettura fisica diagram.png

Descrizione dell'immagine fisico-architettura-diagram.png

fisica-architettura-diagramma-oracle.zip

Microsoft Azure fornisce i seguenti componenti:

Area di Azure
Un'area di Azure è un'area geografica in cui risiedono uno o più data center fisici di Azure, denominati zone di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (tra paesi o addirittura continenti).

Azure e le region OCI sono aree geografiche localizzate. Per Oracle Database@Azure, un'area di Azure è connessa a un'area OCI, con zone di disponibilità (AZ) in Azure connesse ai domini di disponibilità (AD) in OCI. Le coppie di aree Azure e OCI vengono selezionate per ridurre al minimo distanza e latenza.
Area di disponibilità di Azure
Le zone di disponibilità di Azure sono posizioni fisicamente separate all'interno di un'area di Azure, progettate per garantire alta disponibilità e resilienza fornendo alimentazione, raffreddamento e rete indipendenti.
Azure VNet
Microsoft Azure Virtual Network (VNet) è la base fondamentale per la tua rete privata in Azure. VNet consente a molti tipi di risorse di Azure, come le macchine virtuali (VM) di Azure, di comunicare in modo sicuro tra loro, Internet e reti on-premise.
Subnet delegata di Azure
La delega della subnet è la capacità di Microsoft di inserire un servizio gestito, in particolare un servizio platform-as-a-service (PaaS), direttamente nella rete virtuale. Ciò consente di designare o delegare una subnet come home per un servizio gestito esterno all'interno della rete virtuale, in modo che il servizio esterno funga da risorsa di rete virtuale, anche se si tratta di un servizio PaaS esterno.
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 le schede NIC (VNIC) virtuali associate alle schede 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 Azure
Azure Virtual Network Gateway 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.
WAN virtuale Azure
Microsoft Azure Virtual WAN (VWAN) è un servizio di networking che riunisce molte funzionalità di networking, sicurezza e routing per fornire un'unica interfaccia operativa.
Hub sicuro Azure
Un hub sicuro di Azure, noto anche come hub virtuale protetto, è un hub WAN virtuale di Azure migliorato con criteri di sicurezza e routing gestiti da Azure Firewall Manager. Semplifica la creazione di architetture di rete hub-and-spoke e transitive integrando servizi di sicurezza nativi per la governance e la protezione del traffico. Questa configurazione automatizza l'instradamento del traffico, eliminando la necessità di percorsi definiti dall'utente (UDR). Le organizzazioni possono utilizzare un hub sicuro per filtrare e proteggere il traffico tra reti virtuali, filiali e Internet, garantendo una sicurezza affidabile e una gestione semplificata della rete.
Gestione firewall Azure
Azure Firewall Manager è un servizio di gestione della sicurezza centralizzato che semplifica l'implementazione e la configurazione di Azure Firewall in più aree e sottoscrizioni. Consente la gestione gerarchica dei criteri, consentendo l'applicazione coerente dei criteri firewall globali e locali. Se integrato con Azure Virtual WAN (vWAN) e un hub sicuro, Azure Firewall Manager migliora la sicurezza automatizzando l'instradamento e il filtro del traffico senza la necessità di percorsi definiti dall'utente (UDR). Questa integrazione garantisce che il traffico tra reti virtuali, filiali e Internet sia gestito e monitorato in modo sicuro, fornendo una soluzione di sicurezza di rete solida e semplificata.
Azure ExpressRoute
Azure ExpressRoute è un servizio che consente connessioni private tra i data center on-premise e Microsoft Azure, bypassando la rete Internet pubblica. Ciò si traduce in maggiore sicurezza, affidabilità e velocità più elevate con latenze coerenti. Le connessioni ExpressRoute possono essere stabilite tramite un provider di connettività utilizzando vari metodi, ad esempio Ethernet point-to-point, Any-to-any (IP VPN) o cross connect virtuali. Durante l'integrazione con i data center on-premise, ExpressRoute consente un'estensione trasparente della rete nel cloud, facilitando scenari di cloud ibrido, disaster recovery e migrazione dei dati con prestazioni e sicurezza avanzate.

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, che ospitano domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (tra paesi o addirittura continenti).
Dominio di disponibilità
I domini di disponibilità sono data center standalone e indipendenti all'interno di un'area geografica. Le risorse fisiche in ciascun dominio di disponibilità sono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio alimentazione o raffreddamento, o la rete interna del dominio di disponibilità. Pertanto, un errore in un dominio di disponibilità non dovrebbe influire sugli altri domini di disponibilità nell'area.
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.
Tabella di instradamento
Le tabelle di instradamento virtuali contengono regole per instradare il traffico dalle subnet alle destinazioni esterne a una VCN, in genere attraverso i gateway.
Lista di sicurezza
Per ogni subnet, puoi creare regole di sicurezza che specificano l'origine, la destinazione e il tipo di traffico consentito all'interno e all'esterno della subnet.
Gruppo di sicurezza di rete (NSG)
I gruppi NSG fungono da firewall virtuali per le risorse cloud. Con il modello di sicurezza zero-trust di Oracle Cloud Infrastructure puoi controllare il traffico di rete all'interno di una VCN. Un gruppo NSG è costituito da un set di regole di sicurezza in entrata e in uscita che si applicano solo a un set specificato di VNIC in una singola VCN.
Oracle Database Autonomous Recovery Service
Oracle Database Autonomous Recovery Service è un servizio Oracle Cloud che protegge i database Oracle. L'automazione del backup e le funzionalità avanzate di protezione dei dati per i database OCI consentono di scaricare tutti i requisiti di elaborazione e storage del backup su Oracle Database Autonomous Recovery Service, riducendo i costi dell'infrastruttura di backup e il sovraccarico manuale dell'amministrazione.
Exadata Database Service
ti consente di sfruttare la potenza di Exadata nel cloud. Oracle Exadata Database Service offre funzionalità Oracle Database comprovate su un'infrastruttura Oracle Exadata ottimizzata e appositamente creata nel cloud pubblico. L'automazione cloud integrata, la scalabilità elastica delle risorse, la sicurezza e le prestazioni rapide per tutti i carichi di lavoro di Oracle Database ti aiutano a semplificare la gestione e a ridurre i costi.
Oracle Database@Azure
Oracle Database@Azure è il servizio Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure e Oracle Autonomous Database Serverless) in esecuzione su Oracle Cloud Infrastructure (OCI), distribuito nei data center Microsoft Azure. Il servizio offre funzioni e parità di prezzo con OCI. Acquistare il servizio su Azure Marketplace.

Oracle Database@Azure integra le tecnologie Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) e Oracle Data Guard nella piattaforma Azure. Gli utenti gestiscono il servizio sulla console di Azure e con gli strumenti di automazione di Azure. Il servizio viene distribuito in Azure Virtual Network (VNet) e integrato con il sistema di gestione delle identità e degli accessi di Azure. Le metriche generiche e i log di audit di OCI e Oracle Database sono disponibili in modo nativo in Azure. Il servizio richiede agli utenti di disporre di una sottoscrizione Azure e di una tenancy OCI.

Autonomous Database è basato sull'infrastruttura Oracle Exadata, è self-managing, self-securing e self-repairing e aiuta a eliminare la gestione manuale del database e gli errori umani. Autonomous Database consente lo sviluppo di applicazioni scalabili basate sull'intelligenza artificiale con qualsiasi dato utilizzando funzionalità AI integrate utilizzando il modello di linguaggio di grandi dimensioni (LLM) e la posizione di distribuzione.

Sia Oracle Exadata Database Service che Oracle Autonomous Database Serverless vengono forniti facilmente tramite il portale nativo di Azure, consentendo l'accesso all'ecosistema Azure più ampio.
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.
Peering locale
Il peering locale ti consente di eseguire il peer di una VCN con un'altra VCN nella stessa area. Peering significa che le VCN comunicano utilizzando indirizzi IP privati, senza il traffico che attraversa Internet o l'instradamento tramite la rete on premise.
Peering remoto
Il peering remoto consente alle risorse all'interno di VCN diverse di comunicare utilizzando indirizzi IP privati. Il peering remoto elimina la necessità di un gateway Internet o di indirizzi IP pubblici per le istanze che devono comunicare con un'altra VCN in un'area diversa.
Hub di rete cloud virtuale
Una rete cloud virtuale hub (VCN, virtual cloud network) funge da punto centrale per gestire e instradare il traffico tra più VCN, sia all'interno della stessa area che tra aree diverse. Utilizzando i Local Peering Gateway (LPG), la VCN hub si connette a più VCN spoke all'interno della stessa area, facilitando comunicazioni efficienti e gestione centralizzata. Per la connettività tra più aree, vengono utilizzati i gruppi di peering remoti (RPG, Remote Peering Groups), in cui ogni VCN si collega a un gateway di instradamento dinamico (DRG, Dynamic Routing Gateway) e stabilisce connessioni di peering remoto (RPC, Remote Peering Connections). Questa impostazione è particolarmente utile per instradare il traffico di Oracle Data Guard, assicurando che i redo log e altri dati di sincronizzazione vengano trasmessi in modo efficiente dal database primario in un'area al database di standby in un'altra area, mantenendo la coerenza dei dati e l'alta disponibilità.

Il sistema in locale include i componenti riportati di seguito.

Data center primario
Un data center on-premise che ospita applicazioni e un database Oracle funge da sito principale per le operazioni aziendali, garantendo alte prestazioni e disponibilità dei dati. Per migliorare il disaster recovery e la business continuity, questo data center primario è associato a un data center in standby, spesso situato in una diversa area geografica. Il data center di standby gestisce una copia sincronizzata del database Oracle utilizzando Oracle Data Guard, che replica continuamente le modifiche dal database primario al database di standby. In caso di guasto o disastro nel sito primario, il data center di standby può assumere rapidamente il controllo, riducendo al minimo i tempi di inattività e la perdita di dati, garantendo in tal modo operazioni aziendali ininterrotte.
Data center in standby
Un data center in standby è un componente fondamentale di una strategia di disaster recovery, progettata per garantire la continuità del business in condizioni impreviste. Ospita una replica delle applicazioni primarie e di Oracle Database, mantenuta sincronizzata attraverso tecnologie come Oracle Data Guard. In caso di guasto o disastro nel data center primario, il data center di standby può rilevare senza problemi le operazioni, riducendo al minimo i tempi di inattività e la perdita di dati. Questa impostazione garantisce che i processi aziendali continuino a funzionare senza problemi, fornendo resilienza contro le interruzioni e mantenendo la disponibilità del servizio per utenti e clienti.
Database
Un database Oracle ospitato in un data center on-premise svolge un ruolo cruciale nell'archiviazione e nella gestione dei dati aziendali. Offre un ambiente sicuro e altamente performante per la gestione di business operations strategiche, garantendo integrità e disponibilità dei dati. Questa configurazione consente alle organizzazioni di mantenere il pieno controllo sulla propria infrastruttura di dati, personalizzare le configurazioni per soddisfare esigenze specifiche e rispettare i requisiti normativi. Sfruttando le solide funzionalità del database di Oracle, le aziende possono elaborare in modo efficiente le transazioni, generare report e supportare i processi decisionali.
Applicazioni
Le applicazioni in esecuzione in un data center on-premise su un database Oracle sono parte integrante delle operazioni aziendali. Queste applicazioni sfruttano il solido e affidabile database Oracle per elaborare le transazioni, gestire i dati dei clienti e generare insight aziendali strategici. Operando all'interno di un ambiente sicuro e controllato, garantiscono prestazioni elevate, integrità dei dati e conformità agli standard normativi. Questa configurazione consente alle aziende di personalizzare la propria infrastruttura per soddisfare esigenze specifiche, fornendo una base stabile per le operazioni quotidiane e il processo decisionale strategico.

Suggerimenti

Utilizzare i seguenti suggerimenti come punto di partenza. Le vostre esigenze potrebbero differire dall'architettura descritta qui.

Prestazioni

Una rete OCI è fortemente consigliata per la replica del disaster recovery (DR). L'infrastruttura di rete ad alte prestazioni di OCI garantisce una connettività a bassa latenza e a larghezza di banda elevata, essenziale per una replica e una sincronizzazione dei dati efficienti tra i database primari e in standby. Sfruttare la rete OCI per Oracle Data Guard con Oracle Database@Azure offre vantaggi significativi in termini di prestazioni, sicurezza e affidabilità.

Questa impostazione rafforza il DR consentendo una trasmissione rapida e sicura dei redo log e dei dati critici, riducendo al minimo la perdita e i tempi di inattività dei dati durante gli scenari di failover. Inoltre, le funzioni di sicurezza integrate di OCI, tra cui la cifratura di rete e i controlli di accesso avanzati, offrono una solida protezione per i dati sensibili.

Integrando il networking OCI con Oracle Database@Azure, le organizzazioni possono ottenere un'architettura di database trasparente, resiliente e ad alta disponibilità che migliora la continuità aziendale e l'efficienza operativa.

Considerazioni

Quando si distribuisce questa architettura di riferimento, tenere presente quanto riportato di seguito.

Continuità aziendale
L'integrazione di Oracle Database Autonomous Recovery Service con Oracle Data Guard crea una strategia di protezione dei dati completa e resiliente per le impostazioni del database primario e in standby. Oracle Data Guard garantisce alta disponibilità e disaster recovery mantenendo un database di standby sincronizzato che può rilevare in caso di errore del database primario, riducendo al minimo i tempi di inattività e la perdita di dati.

A complemento di questo, Oracle Database Autonomous Recovery Service offre una soluzione di backup completamente gestita e centralizzata con funzionalità di protezione dalla perdita di dati e ripristino in tempo reale. Questa combinazione garantisce una protezione continua dei dati attraverso la replica in tempo reale e meccanismi di backup efficaci, migliorando l'integrità dei dati e la continuità aziendale.
Disponibilità
La distribuzione di più istanze di Oracle Database in diverse zone di disponibilità (AZ) all'interno di un'area geografica, insieme ad Active Data Guard, migliora notevolmente le funzionalità di alta disponibilità e disaster recovery. Gli AZ sono isolati l'uno dall'altro, garantendo che i guasti in uno non influiscano sugli altri. Distribuendo le istanze di database su più AZ, le organizzazioni possono mitigare i rischi associati a guasti localizzati come interruzioni di corrente o problemi hardware.

Active Data Guard rafforza ulteriormente questa impostazione mantenendo una replica sincronizzata in tempo reale del database primario, consentendo il failover senza interruzioni in caso di errore di un'istanza primaria. Questo approccio garantisce una protezione continua dei dati, tempi di inattività minimi e una solida strategia di disaster recovery, fornendo un'infrastruttura resiliente per le applicazioni mission-critical.
Throughput
Quando si esegue la migrazione dei database da ambienti on premise ad Azure, è fondamentale considerare la larghezza di banda di Azure ExpressRoute per garantire un trasferimento fluido ed efficiente. Ad esempio, se si sta eseguendo la migrazione di un database di piccole dimensioni da 100 GB, un circuito ExpressRoute da 200 Mbps può gestire il trasferimento in circa 1 ora e 10 minuti, presupponendo condizioni ottimali e senza sovraccarico. Tuttavia, per un database più grande di 1 TB, lo stesso circuito da 200 Mbps richiederebbe circa 11 ore e 40 minuti. L'aggiornamento a un circuito da 1 Gbps ridurrebbe significativamente questo tempo a circa 2 ore e 20 minuti. Pianifica di conseguenza in modo che l'intera larghezza di banda non venga utilizzata; in caso contrario, potrebbero essere interessate altre applicazioni che comunicano tra on-premise e cloud.

Visualizza altro

Per ulteriori informazioni su Oracle Database e sugli strumenti correlati, consulta le risorse riportate di seguito.

Esaminare le risorse di distribuzione riportate di seguito per implementare questa architettura di riferimento.

Terraform: provider di Oracle Cloud Infrastructure
Oracle Cloud Infrastructure Ansible Collection 5.4.0
Command Line Interface (CLI) nella documentazione di Oracle Cloud Infrastructure
Terraform: provider di Azure
Documentazione sull'interfaccia della riga di comando di Azure
Riferimento ed endpoint delle API nella documentazione di Oracle Cloud Infrastructure
Riferimento all'API REST di Azure
Portale Oracle Cloud
Portale Azure

Esaminare le risorse aggiuntive riportate di seguito.

conferme

Autori: Neeraj Tyagi, Thomas Van Buggenhout
Collaboratori: Emiel Ramakers, John Sulyok