Continuità aziendale e ripristino di emergenza per Oracle nell'acceleratore della zona di destinazione di Macchine virtuali di Azure

2025-06-21

Questo articolo si basa sulle considerazioni e le raccomandazioni definite nell'area di progettazione della zona di destinazione di Azure per la continuità aziendale e il ripristino di emergenza. Questo articolo segue le linee guida e descrive le considerazioni di progettazione e le procedure consigliate sulle opzioni BCDR per le distribuzioni dei carichi di lavoro Oracle nelle macchine virtuali dell'infrastruttura di Azure.

Azure offre servizi che è possibile usare per progettare architetture a disponibilità elevata e resilienti. Questa guida illustra varie opzioni e procedure consigliate per progettare la disponibilità elevata e il ripristino di emergenza per i database Oracle nell'acceleratore della zona di destinazione di Macchine virtuali di Azure. Descrive anche come configurare i servizi di Azure associati per ottenere un'elevata disponibilità end-to-end per la soluzione.

Inizia subito

Per creare un'architettura resiliente per l'ambiente del carico di lavoro, determinare i requisiti di disponibilità per la soluzione in base all'obiettivo del tempo di ripristino (RTO) e all'obiettivo del punto di ripristino (RPO) per vari livelli di errore. L'RTO è il tempo massimo durante il quale un'applicazione rimane non disponibile dopo che si è verificato un evento imprevisto. L'RPO è la quantità massima di perdita di dati durante un'emergenza. Dopo aver determinato i requisiti per la soluzione, progettare l'architettura in modo da fornire i livelli stabiliti di resilienza e disponibilità.

I carichi di lavoro Oracle in Azure usano principalmente Oracle Data Guard, che è una funzionalità predefinita di Oracle Database Enterprise Edition che usa la tecnologia di replica. È possibile usare Data Guard per soddisfare le esigenze di disponibilità elevata e ripristino di emergenza. Data Guard offre tre modalità di protezione: massime prestazioni, massima disponibilità e massima protezione. Scegli la modalità di protezione in base al tuo design architettonico e ai tuoi requisiti specifici di RPO e RTO.

Configurare il carico di lavoro per la disponibilità elevata

Le istanze di Macchine virtuali di Azure che eseguono carichi di lavoro Oracle traggono vantaggio dall'architettura dei set di scalabilità di macchine virtuali di Azure, in particolare dalla modalità di orchestrazione flessibile. Una configurazione a disponibilità elevata fornisce la replica dei dati quasi in tempo reale con funzionalità di failover potenzialmente veloci. Una configurazione a disponibilità elevata non fornisce protezione per gli errori a livello di data center o a livello di area di Azure.

Scegli l'opzione di disponibilità elevata appropriata

Utilizzare il diagramma di flusso seguente per scegliere l'opzione di disponibilità elevata migliore per il database Oracle.

Usare Data Guard in modalità di disponibilità massima per la disponibilità elevata

Data Guard in modalità di massima disponibilità offre la massima disponibilità con una promessa di perdita di dati pari a zero (RPO=0) per le normali operazioni. Per una configurazione a disponibilità elevata di due server di database Oracle creati all'interno di un'orchestrazione flessibile dei set di scalabilità di macchine virtuali, Azure offre una disponibilità del servizio di 99,95% per un contratto di servizio per le istanze distribuite tra domini di errore. Azure offre una disponibilità del servizio di 99,99% per le istanze distribuite tra zone di disponibilità. Per altre informazioni, vedere Disponibilità elevata per i set di scalabilità di macchine virtuali.

Per una configurazione dettagliata di Data Guard in Azure, vedere Implementare Oracle Data Guard in una macchina virtuale di Azure basata su Linux.

Usare Data Guard in modalità di protezione massima per la disponibilità elevata

Se è necessaria una copia coerente a livello transazionale del database, è consigliabile utilizzare Data Guard in modalità di protezione massima. Tuttavia, la modalità di protezione massima non consente di continuare le transazioni quando il database in standby non è disponibile. Pertanto, nonostante l'uso dell'orchestrazione flessibile dei set di scalabilità di macchine virtuali, il contratto di servizio viene ridotto a 99,9% x 99,9% = 99,8% quando si usa la modalità di protezione massima. Questa configurazione garantisce una copia coerente dei dati, ma non aumenta necessariamente la disponibilità.

Gli altri attributi di questa architettura sono gli stessi della modalità di disponibilità massima. Ad esempio, l'RPO è pari a zero e l'RTO è inferiore o uguale a due minuti.

Prendere in considerazione altri modi per implementare la disponibilità elevata

Nelle sezioni seguenti vengono descritte considerazioni speciali per la disponibilità elevata.

Utilizzare le zone di disponibilità per migliorare la disponibilità elevata

Le zone di disponibilità di Azure sono data center di Azure che si trovano all'interno della stessa area di Azure. Le zone di disponibilità hanno una latenza di andata e ritorno inferiore a due millisecondi. In genere si usano le zone di disponibilità per scopi di ripristino di emergenza, ma è possibile usarle per migliorare la disponibilità elevata. In tal caso, è necessario assicurarsi che la soluzione possa essere eseguita con la quantità di latenza e velocità effettiva fornita dalle zone di disponibilità.

Un vantaggio delle zone di disponibilità con un'orchestrazione flessibile dei set di scalabilità di macchine virtuali è che il contratto di servizio per la disponibilità delle macchine virtuali aumenta a 99,99%.

Utilizzare il clustering di archiviazione condiviso per l'alta disponibilità

Le tecnologie di clustering dello storage condiviso offrono attributi univoci che possono aiutarti a raggiungere i tuoi obiettivi aziendali. Ad esempio, è possibile implementare un cluster Pacemaker e Corosync (PCS) con archiviazione condivisa. È possibile usare dischi gestiti o Azure NetApp Files come archiviazione condivisa per le istanze del cluster PCS. Un cluster PCS non duplica i dati. Fornisce un servizio IP virtuale con un indirizzo IP statico o un nome di rete IP che non cambia tra i failover.

Annotazioni

Un cluster PCS non è una soluzione certificata Oracle. Tenere presente questo fattore quando si sceglie l'architettura a disponibilità elevata.

Utilizzare i gruppi di posizionamento di prossimità

Per fornire la latenza più bassa possibile, posizionare le macchine virtuali il più vicino possibile. È possibile distribuirli all'interno di un gruppo di posizionamento di prossimità. Un gruppo di posizionamento di prossimità è un raggruppamento logico che garantisce che le risorse di calcolo di Azure si trovino fisicamente l'una vicino all'altra. I gruppi di posizionamento di prossimità sono utili per i carichi di lavoro che richiedono una bassa latenza.

Configurare il carico di lavoro per il ripristino di emergenza

Un'architettura di ripristino di emergenza offre resilienza in caso di errori che interessano i data center o le aree di Azure o in caso di errori che ostacolano la funzionalità dell'applicazione in un'intera area. In uno scenario di questo tipo, è necessario spostare l'intero carico di lavoro in un data center o in un'area diversa.

Scegli l'architettura di disaster recovery in base ai requisiti della tua soluzione. Determini i tuoi requisiti in base all'RTO e all'RPO. Le architetture di disaster recovery sono per casi di errore eccezionali, quindi i processi di failover sono manuali. Nella progettazione a disponibilità elevata, i processi di failover sono automatici. In un'architettura di disaster recovery, è necessario avere requisiti più rilassati per RTO e RPO, il che consente di risparmiare denaro.

Questo articolo è incentrato sugli scenari in cui il server primario e i server secondari si trovano entrambi in Azure. È anche possibile avere un server primario locale e un server secondario in Azure per scopi di ripristino di emergenza. Per altre informazioni, vedere Sito primario locale e sito di ripristino di emergenza in Azure.

Scegli l'opzione di ripristino di emergenza corretta

Utilizzare il diagramma di flusso seguente per scegliere l'opzione di ripristino di emergenza migliore per il database Oracle.

Usare Data Guard per il ripristino di emergenza

È possibile usare Data Guard per replicare i dati nel sito di ripristino di emergenza. Usare tale sito come un'altra zona di disponibilità nella stessa area o in un'area diversa a seconda dei requisiti per la protezione dei dati. La configurazione dipende anche dalla struttura della zona di disponibilità nel sito di produzione. Un'implementazione di Data Guard in uno scenario di ripristino di emergenza è simile allo scenario di disponibilità elevata descritto in precedenza, con alcune differenze importanti. Per esempio:

Quando si esegue il failover in una replica secondaria nello scenario di disponibilità elevata, si configura Azure Load Balancer per reindirizzare le richieste alla nuova istanza del database primario.
Quando si esegue il failover nel sito di ripristino di emergenza, si esegue il failover dell'intera soluzione nel nuovo sito. Per evitare problemi di latenza, in genere è necessario configurare il failover per i servizi dell'applicazione.

Se il sito di ripristino di emergenza si trova in un'altra area, è necessario progettare il sito per il failover in base alle proprie esigenze.

La latenza all'interno di un singolo data center è inferiore alla latenza tra datacenter separati l'uno dall'altro e molto inferiore alla latenza tra aree diverse. Pertanto, l'opzione meno complessa e meno costosa consiste nell'utilizzare Data Guard in modalità prestazioni massime per scopi di ripristino di emergenza. Se la potenziale perdita di dati in modalità prestazioni massime è troppo elevata, è possibile utilizzare la modalità disponibilità massima con il meccanismo di sincronizzazione remota di Oracle Data Guard. Tuttavia, un'istanza di sincronizzazione lontana attiva le licenze di Active Data Guard nell'ambiente primario e nell'ambiente di standby. Per ulteriori informazioni, consulta Dettagli sulla licenza Oracle.

Inoltre, quando si inviano dati tra aree o data center di Azure, si pagano i costi in uscita per i dati, ad esempio i log di rollforward, inviati a un sito di ripristino di emergenza. Se non è necessario replicare tutti i dati nel database, è possibile utilizzare la replica basata su Oracle Golden Gate per replicare solo i dati parziali in base alle esigenze, riducendo i costi di uscita.

Per una configurazione dettagliata di Data Guard in Azure, vedere Implementare Data Guard in una macchina virtuale Linux di Azure basata su Linux.

Usa Golden Gate per il ripristino di emergenza

Golden Gate è un software di replica logica che può essere utilizzato per la replica, il filtraggio e la trasformazione in tempo reale dei dati da un database di origine a un database di destinazione o tra più database primari. Questa funzionalità garantisce che le modifiche nel database di origine vengano replicate quasi in tempo reale in modo che il database di destinazione sia aggiornato con i dati più recenti.

È possibile utilizzare Golden Gate per replicare i dati da un database primario a un database secondario in una configurazione di ripristino di emergenza. Golden Gate è particolarmente pratico se hai bisogno di proteggere solo alcuni dei tuoi dati. Per evitare la replica di dati non necessari, utilizzare Golden Gate per replicare in modo selettivo le tabelle e filtrare le righe della tabella durante la replica.

Per una guida dettagliata su come implementare Golden Gate in Azure, vedere Implementare Golden Gate in una macchina virtuale di Azure basata su Linux.

Usare il backup per il ripristino di emergenza

Il backup e il ripristino sono un metodo tradizionale per un'architettura di ripristino di emergenza. Esistono due componenti principali per il backup come metodo di ripristino di emergenza per i database Oracle in Azure:

Estrarre e spostare il backup dei dati da un database per assicurarsi che il sito di ripristino di emergenza disponga di dati up-todata.
Garantire una distribuzione up-tonel sito di ripristino di emergenza. Per aggiornare il sito, replicare la stessa distribuzione di tutti i componenti di rete, i server applicazioni e le configurazioni nel sito di ripristino di emergenza.

Esistono diverse opzioni di backup che è possibile utilizzare per replicare i dati. Per altre informazioni, vedere Strategie di backup per Oracle Database in Azure.

Prendere in considerazione l'utilizzo di uno degli approcci seguenti per gestire un sito di ripristino di emergenza:

Approccio 1: Per evitare il lavoro e i costi di manutenzione aggiuntivi, non mantenere alcuna distribuzione fisica nel sito di ripristino di emergenza. È possibile utilizzare l'infrastruttura come codice e le procedure di ingegneria dell'affidabilità del sito per sviluppare e gestire un repository. Questo repository può replicare la distribuzione come configurazione in un sito di ripristino di emergenza al momento del failover. Questo metodo ottimizza i costi perché non usa risorse fisiche fino a quando non si verifica il failover.

Importante

Se si crea un'intera distribuzione da zero durante un failover, è necessario assicurarsi che la distribuzione sia in grado di soddisfare i requisiti RTO della soluzione. Per assicurarsi che il codice di distribuzione non venga danneggiato, è necessario simulare e testare regolarmente lo scenario di ripristino di emergenza.

Approccio 2: Distribuisci e gestisci una versione scalabile del tuo ambiente di produzione. Disporre di una versione in grado di funzionare correttamente per un carico di lavoro di piccole dimensioni e che sia possibile aumentare le prestazioni in base alle esigenze durante un failover per gestire il carico di produzione. Questo metodo viene comunemente usato, soprattutto per distribuzioni complesse in cui non si vuole rischiare di creare un intero ambiente o se si vuole eseguire rapidamente il failover per fornire un RTO basso.

Approccio 3: Distribuisci e gestisci l'intera soluzione nel sito di ripristino di emergenza per ottenere i tempi di RTO e failover più rapidi. Questo metodo aumenta i costi a causa dell'esecuzione di un'infrastruttura completamente ridondante.

Prendere in considerazione altri modi per implementare il ripristino di emergenza

Nelle sezioni seguenti vengono descritte considerazioni specifiche per il ripristino di emergenza.

Usa la sincronizzazione lontana

Far Sync non migliora le funzionalità di disponibilità elevata, ma è possibile utilizzarla per ottenere funzionalità di protezione dalla perdita di dati pari a zero per i database Oracle. Il carico di lavoro potrebbe richiedere una perdita di dati pari a zero in caso di errore del database primario. Per altre informazioni, vedere Architetture di riferimento Oracle in Azure.

Scegli la giusta tecnologia di replica dei dati

Oltre alle tecnologie descritte in questo articolo, è possibile usare qualsiasi tecnologia che faciliti la replica dei dati tra due database Oracle per mantenere una replica a disponibilità elevata e una replica di ripristino di emergenza per i database Oracle in Azure. La tecnologia scelta deve soddisfare i requisiti della soluzione in queste categorie.

Latenza: La quantità di tempo necessaria per replicare un aggiornamento da un database primario a database secondari per la disponibilità elevata e il ripristino di emergenza deve essere conforme ai requisiti della soluzione.

Larghezza di banda: La quantità e il costo della larghezza di banda necessaria per replicare i dati nei database secondari per la disponibilità elevata e il ripristino di emergenza. Azure offre un'infrastruttura di rete ad alta velocità tra le zone di disponibilità. Quando si considera la replica in altre aree di Azure a scopo di ripristino di emergenza, considerare la quantità di larghezza di banda e i costi in uscita per i dati che lasciano il data center di Azure.

Impatto: Il livello di impatto della replica sull'elaborazione delle transazioni nel database primario deve essere conforme ai requisiti della soluzione.

Perdita di dati: La quantità di perdita di dati prevista durante un errore improvviso del database primario deve essere conforme ai requisiti della soluzione.

Costo totale di proprietà: Considerare il costo di acquisizione per una soluzione di replica non Microsoft e la quantità di lavoro necessaria per configurare e gestire la soluzione di replica. Verificare che questi fattori siano conformi ai requisiti della soluzione.

Ottimizzare un'istanza di failover

Quando si usa Data Guard in modalità a disponibilità elevata o in modalità a protezione elevata, è possibile configurare il failover automatico in modo che, in caso di errore del server primario, il server secondario venga attivato automaticamente. Quando si configurano correttamente i server applicazioni, è possibile assicurarsi che non si verifichino quasi tempi di inattività delle applicazioni durante un failover.

In questa implementazione, un database deve essere eseguito allo stesso modo dopo un failover. È quindi necessario configurare un server secondario con la stessa CPU, memoria e capacità di input/output (I/O) del server primario. È necessario mantenere una capacità elevata con un server secondario, il che aumenta i costi di Azure e i costi di licenza di Oracle Database. Il server secondario di solito non elabora le richieste degli utenti.

Azure offre una disponibilità di 99,9% per le macchine virtuali in una zona di disponibilità. Per altre informazioni, vedere Contratto di servizio per il tempo di attività della macchina virtuale. Quando si utilizza una tecnologia di replica dei dati per gestire una replica secondaria del database nella stessa zona di disponibilità, in una zona di disponibilità diversa o in un'area diversa, è possibile ottimizzare la capacità secondaria.

Con questo approccio, il database secondario viene configurato con la capacità necessaria per rimanere aggiornato. Quando si verifica un errore, il database secondario viene ridimensionato alla stessa capacità del database primario. Questa operazione si verifica solo in caso di errore. Quindi, durante il normale funzionamento, si paga solo una frazione del costo del server primario. Il database primario non è operativo durante l'errore, quindi non sono necessarie altre licenze per database Oracle.

La capacità necessaria per gestire un database secondario come destinazione di replica dipende dalla tecnologia di replica utilizzata. Essenzialmente, un carico di lavoro che si trova in un sistema di elaborazione delle transazioni online transazionali (OLTP) ha principalmente richieste di lettura. Ad esempio, 90 operazioni di lettura% e 10 operazioni di scrittura% o 95 operazioni di lettura% e 5 operazioni di scrittura% sono comuni nelle applicazioni OLTP. La replica dei dati replica essenzialmente il risultato della scrittura delle richieste nel database di origine. Con questa configurazione, è possibile prevedere che il database secondario funzioni con 1/10 (se si dispone di un rapporto di 90% in lettura e 10% in scrittura) della capacità del database primario.

Automatizzare le procedure di failover per garantire il rispetto degli standard aziendali durante il processo di failover. È possibile configurare le procedure di failover in modo da includere operazioni di ridimensionamento del server che semplificano il processo end-to-end.

Configurare la topologia di rete per la protezione dei servizi e la protezione dei dati

Per ottenere la disponibilità elevata e il ripristino di emergenza, è necessario prendere decisioni finanziarie e aziendali che bilancino il tempo di ripristino, o RTO, e la potenziale perdita di dati, o RPO, con altri costi di licenza, manutenzione delle macchine virtuali e trasferimento dei dati Oracle. Quando si ospita un carico di lavoro in una singola macchina virtuale di Azure, si ottiene una protezione di base per gli errori hardware comuni a un costo contenuto. Tuttavia, un errore in una singola macchina virtuale può causare tempi di inattività e perdita di dati. Quindi, negli ambienti di produzione, includere almeno un database Oracle secondario ospitato in una macchina virtuale separata con Data Guard. A seconda delle esigenze, usare una o più delle configurazioni di Data Guard seguenti per la replica dei dati:

RTO e RPO ottimali. Per ridurre al minimo la latenza, incorporare un database Oracle secondario in una macchina virtuale separata all'interno della stessa orchestrazione flessibile dei set di scalabilità di macchine virtuali e nella stessa zona di disponibilità del database primario. Questa configurazione offre disponibilità elevata e protezione da un errore a istanza singola.
Protezione dei dati da un errore del data center. Posizionare il database Oracle secondario in una seconda zona di disponibilità per fornire una configurazione ad alta disponibilità e per fornire protezione in caso di errore di un'intera zona di disponibilità. Questa configurazione può avere fino a due millisecondi di latenza tra il database primario e quello secondario, che può influire sulle prestazioni, sugli RTO e sugli RPO.
Protezione dei dati da un errore a livello di area. Per evitare la potenziale perdita di dati a causa di un errore a livello di area di Azure, è possibile posizionare il database secondario in un'area diversa. Questa configurazione può avere una latenza compresa tra 30 e 300 millisecondi tra le aree, quindi è possibile che non si raggiungano gli obiettivi RTO e RPO. Questa soluzione è ideale per il ripristino di emergenza a livello di area piuttosto che per la disponibilità elevata.

La business continuity richiede un approccio integrato che includa tutti i componenti di un carico di lavoro. L'infrastruttura di rete è un componente principale per qualsiasi carico di lavoro in Azure. L'infrastruttura di rete deve essere allineata con l'architettura di alta disponibilità o di disaster recovery. Considerare i seguenti fattori dell'infrastruttura di rete:

Data Guard offre disponibilità elevata e, nella maggior parte degli scenari, fornisce un supporto sufficiente per gli errori comuni. È possibile inserire le macchine virtuali in un'orchestrazione flessibile dei set di scalabilità di macchine virtuali. Per ridurre la latenza di rete, tutti i servizi in una singola soluzione devono risiedere all'interno della stessa zona di disponibilità e i servizi devono condividere la stessa rete virtuale.

Per una maggiore protezione, è possibile posizionare strategicamente le macchine virtuali in zone di disponibilità separate anziché in una singola zona di disponibilità. Questo approccio consente di evitare tempi di inattività durante un errore del data center.
Per ottenere la massima protezione, è possibile posizionare un database secondario in un'area di Azure diversa da quella del database primario. Per applicare gli aggiornamenti continui, è possibile usare Data Guard per implementare il peering di rete virtuale globale. Usare questo approccio per applicare gli aggiornamenti dei dati all'area secondaria privatamente tramite il backbone Microsoft. Le risorse comunicano direttamente senza gateway, hop aggiuntivi o transito sulla rete Internet pubblica.

Questa opzione di rete offre una connessione a larghezza di banda elevata e bassa latenza tra reti virtuali con peering in aree diverse. È possibile usare il peering di rete virtuale globale per connettere il sito primario a un sito di ripristino di emergenza in un'area diversa tramite una rete ad alta velocità.

Riepilogo della resilienza rispetto a vari tipi di errore

Scenario di errore	Scenario di disponibilità elevata o ripristino di emergenza di Oracle in Azure	RPO/RTO
Guasto di un singolo componente, ad esempio host, rack, raffreddamento, rete o interruzione dell'alimentazione	Data Guard con due nodi nella stessa scalabilità di macchine virtuali Imposta l'orchestrazione flessibile nello stesso data center: - Protegge da un errore di una singola istanza. - Causa tempi di inattività in caso di errore di un intero data center.	Se si usa Observer per il failover di avvio rapido e la modalità MAX_AVAILABILITY o MAX_PROTECTION per Data Guard: - L'RPO è zero. - L'RTO è inferiore o uguale a 2 min.
Errore del data center	Data Guard con due nodi in zone di disponibilità separate: - Protegge da un errore del data center. - Causa tempi di inattività in caso di guasto di un'intera regione. - Richiede una maggiore configurazione di failover per i server app per gestire la latenza di rete.	- L'RPO è inferiore o uguale a 5 minuti. - L'RTO è inferiore o uguale a 5 minuti. Se si utilizza la modalità MAX_PERFORMANCE e la modalità MAX_AVAILABILITY per Data Guard: - L'RPO è zero. - L'RTO è inferiore o uguale a 5 minuti.
Errore a livello di area	Data Guard con due nodi in aree di Azure separate: - Protegge dai fallimenti regionali. - Richiede una maggiore configurazione di failover per i server app per gestire la latenza di rete.	Se si utilizza la modalità MAX_PERFORMANCE per Data Guard: - L'RPO è maggiore o uguale a 10 minuti. - RTO è maggiore o uguale a 15 min.
Tutti gli scenari: un errore di un singolo componente, di un singolo data center e di un'area	Backup spediti in un'area di Azure diversa: - Proteggersi dai fallimenti regionali. - Richiedere la configurazione di un intero ambiente Azure nell'area di destinazione durante un failover.	- L'RPO è maggiore o uguale a 24 ore. - RTO è maggiore o uguale a 4 ore.

Passo successivo

Informazioni sulle considerazioni di progettazione per la sicurezza dell'acceleratore della zona di destinazione Oracle nelle macchine virtuali in uno scenario su scala aziendale.

Linee guida di sicurezza per l'acceleratore della zona di destinazione Oracle in Macchine virtuali