Continuità aziendale e ripristino di emergenza per Oracle in Azure Macchine virtuali acceleratore di zona di destinazione

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 (BCDR). Questo articolo segue le indicazioni e descrive le considerazioni di progettazione e le procedure consigliate sulle opzioni BCDR per le distribuzioni di 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 che consentono di progettare la disponibilità elevata e il ripristino di emergenza per i database Oracle in Azure Macchine virtuali acceleratore di zona di destinazione. Descrive anche come configurare i servizi di Azure che accompagnano per ottenere una disponibilità end-to-end elevata per la soluzione.

Operazioni preliminari

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. RTO è il tempo massimo per cui un'applicazione rimane non disponibile dopo che si verifica un evento imprevisto. RPO è la quantità massima di perdita di dati durante un'emergenza. Dopo aver determinato i requisiti per la soluzione, progettare l'architettura per fornire i livelli stabiliti di resilienza e disponibilità.

I carichi di lavoro Oracle in Azure usano principalmente Oracle Data Guard, una funzionalità predefinita di Oracle Database edizione Enterprise 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: prestazioni massime, disponibilità massima e massima protezione. Scegliere la modalità di protezione in base alla progettazione dell'architettura e ai requisiti RPO e RTO specifici.

Configurare il carico di lavoro per la disponibilità elevata

Le istanze di Azure Macchine virtuali che eseguono carichi di lavoro Oracle traggono vantaggio dall'architettura set di scalabilità di macchine virtuali di Azure, in particolare la modalità di orchestrazione flessibile. Una configurazione a disponibilità elevata offre una 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 di Azure o a livello di area.

Scegliere l'opzione di disponibilità elevata appropriata

Usare il grafico 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 disponibilità massima 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 in un'orchestrazione flessibile set di scalabilità di macchine virtuali, Azure offre una disponibilità del servizio del 99,95% per un contratto di servizio per le istanze distribuite tra domini di errore. Azure offre una disponibilità del servizio del 99,99% per le istanze distribuite tra zone di disponibilità. Per altre informazioni, vedere Disponibilità elevata per 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 di transazione del database, è consigliabile usare Data Guard in modalità di protezione massima. Tuttavia, la modalità di protezione massima non consente alle transazioni di continuare quando il database di standby non è disponibile. Pertanto, nonostante l'uso di Macchine virtuali orchestrazione flessibile dei set di scalabilità, il contratto di servizio viene ridotto al 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à.

Altri attributi di questa architettura sono gli stessi della modalità di disponibilità massima. Ad esempio, rpo è zero e l'obiettivo RTO è minore o uguale a due minuti.

Prendere in considerazione altri modi per implementare la disponibilità elevata

Le sezioni seguenti descrivono considerazioni speciali per la disponibilità elevata.

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

Le zone di disponibilità di Azure sono data center di Azure all'interno della stessa area di Azure. Le zone di disponibilità hanno una latenza di round trip inferiore a due millisecondi. In genere si usano zone di disponibilità a scopo di ripristino di emergenza, ma è possibile usarle per migliorare la disponibilità elevata. In questo caso, è necessario assicurarsi che la soluzione possa essere eseguita con la latenza e la velocità effettiva fornite dalle zone di disponibilità.

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

Usare il clustering di archiviazione condivisa per la disponibilità elevata

Le tecnologie di clustering di archiviazione condivisa forniscono attributi univoci che consentono di raggiungere gli obiettivi aziendali. Ad esempio, è possibile implementare un cluster Pacemaker e Corosync (PCS) con l'archiviazione condivisa. È possibile usare dischi gestiti o Azure NetApp Files come risorsa di 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.

Usare i gruppi di posizionamento di prossimità

Per garantire 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 vicine tra loro. I gruppi di posizionamento di prossimità sono utili per i carichi di lavoro che richiedono bassa latenza.

Configurare il carico di lavoro per il ripristino di emergenza

Un'architettura di ripristino di emergenza offre resilienza contro gli errori che influiscono su data center o aree di Azure o contro errori che impediscono 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 un'area diversa.

Scegliere l'architettura di ripristino di emergenza in base ai requisiti della soluzione. Si determinano i requisiti in base all'obiettivo RTO e al rpo. Le architetture di ripristino di emergenza 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 ripristino di emergenza è necessario disporre di requisiti più rilassati per RTO e RPO, che consente di risparmiare denaro.

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

Scegliere l'opzione corretta per il ripristino di emergenza

Usare il grafico 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 il 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 illustrato in precedenza, con alcune importanti differenze. Ad esempio:

• Quando si esegue il failover in una replica secondaria nello scenario a disponibilità elevata, azure Load Balancer viene configurato 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 a seconda dei requisiti.

La latenza all'interno di un singolo data center è minore della latenza tra data center separati l'uno dall'altro e molto meno della latenza tra aree diverse. Di conseguenza, l'opzione meno complessa e meno costosa consiste nell'usare Data Guard in modalità massima delle prestazioni a scopo di ripristino di emergenza. Se la potenziale perdita di dati in modalità massima delle prestazioni è troppo elevata, è possibile usare la modalità di disponibilità massima con il meccanismo Oracle Data Guard Far Sync. Un'istanza di Far Sync attiva tuttavia le licenze di Active Data Guard nell'ambiente primario e nell'ambiente standby. Per altre informazioni, vedere Dettagli della licenza Oracle.

Inoltre, quando si inviano dati tra aree di Azure o data center, 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 usare la replica basata su Oracle Golden Gate per replicare solo i dati parziali in base alle esigenze, riducendo così 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.

Usare Golden Gate per il ripristino di emergenza

Golden Gate è un software di replica logica che è possibile usare per la replica in tempo reale, il filtro e la trasformazione 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 usare 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 è necessario proteggere solo alcuni dei dati. Per evitare la replica di dati non necessari, usare 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 aggiornati.

• Verificare una distribuzione aggiornata nel 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.

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

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

Approccio 1: per evitare il costo e le operazioni di manutenzione aggiuntive, non gestire alcuna distribuzione fisica nel sito di ripristino di emergenza. È possibile usare l'infrastruttura come procedure di progettazione per l'affidabilità del codice e 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.

Approccio 2: distribuire e gestire una versione ridimensionata dell'ambiente di produzione. Avere una versione in grado di funzionare correttamente per un carico di lavoro di piccole dimensioni e di poter aumentare le prestazioni in base alle esigenze durante un failover per il carico di produzione. Questo metodo viene comunemente usato, soprattutto per le 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: distribuire e gestire l'intera soluzione nel sito di ripristino di emergenza per i tempi di failover e RTO 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

Le sezioni seguenti descrivono considerazioni speciali per il ripristino di emergenza.

Usare La sincronizzazione lontano

La sincronizzazione lontano non migliora le funzionalità di disponibilità elevata, ma è possibile usarla per ottenere zero funzionalità di protezione dalla perdita di dati per i database Oracle. Se il database primario ha esito negativo, il carico di lavoro potrebbe richiedere zero perdite di dati. Per altre informazioni, vedere Architetture di riferimento Oracle in Azure.

Scegliere la tecnologia di replica dei dati appropriata

Oltre alle tecnologie di questo articolo, è possibile usare qualsiasi tecnologia che facilita la replica dei dati in due database Oracle per gestire 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: il tempo necessario per replicare un aggiornamento da un database primario a database secondari per la disponibilità elevata e il ripristino di emergenza devono essere conformi ai requisiti della soluzione.

Larghezza di banda: quantità e costo della larghezza di banda che è necessario 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, prendere in considerazione 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à: prendere in considerazione il costo dell'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à di protezione elevata, è possibile configurare per il failover automatico in modo che, quando il server primario ha esito negativo, il server secondario viene generato automaticamente. Quando si configurano correttamente i server applicazioni, è possibile assicurarsi di non avere quasi alcun tempo di inattività dell'applicazione durante un failover.

In questa implementazione, un database deve eseguire lo stesso dopo un failover. È quindi necessario configurare un server secondario con la stessa capacità di CPU, memoria e input/output (I/O) del server primario. È necessario mantenere una capacità elevata con un server secondario, aumentando i costi di Azure e i costi delle licenze di Oracle Database. Il server secondario in genere non elabora le richieste utente.

Azure offre una disponibilità del 99,9% per le macchine virtuali in una zona di disponibilità. Per altre informazioni, vedere Contratto di servizio relativo al tempo di attività della macchina virtuale. Quando si usa una tecnologia di replica 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à che deve rimanere aggiornata. Quando si verifica un errore, il database secondario viene ridimensionato alla stessa capacità del database primario. Questa operazione si verifica solo se si verifica un errore. Pertanto, durante il normale funzionamento, si paga solo per una frazione del costo del server primario. Il database primario non è operativo durante l'errore, quindi non sono necessarie altre licenze di database Oracle.

La capacità necessaria per gestire un database secondario come destinazione di replica dipende dalla tecnologia di replica usata. Essenzialmente, un carico di lavoro in un sistema OLTP (TransactionAl Online Transaction Processing) ha principalmente richieste di lettura. Ad esempio, il 90% di operazioni di lettura e il 10% di operazioni di scrittura o il 95% di operazioni di lettura e 5% 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 lettura del 90% e del 10% di scrittura) della capacità del database primario.

Automatizzare le procedure di failover per assicurarsi di soddisfare gli standard aziendali durante il processo di failover. È possibile configurare le procedure di failover per includere le 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 disponibilità elevata e ripristino di emergenza, è necessario prendere decisioni finanziarie e aziendali che bilanciano il tempo di ripristino o RTO e la potenziale perdita di dati, o RPO, rispetto ad altre licenze Oracle, manutenzione delle macchine virtuali e costi di trasferimento dei dati. 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 basso. Tuttavia, un errore in una singola macchina virtuale causa probabilmente tempi di inattività e perdita di dati. Pertanto, negli ambienti di produzione includere almeno un database Oracle secondario ospitato in una macchina virtuale separata con Data Guard. A seconda dei requisiti, 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 set di scalabilità di macchine virtuali flessibile 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 a disponibilità elevata e garantire la 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 possono influire sulle prestazioni, sugli RTO e sugli RPO.

• Protezione dei dati da un errore a livello di area. Per evitare potenziali perdite 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 millisecondi e 300 millisecondi tra le aree, quindi potrebbe non soddisfare le destinazioni RTO e RPO. Questa soluzione è ideale per il ripristino di emergenza a livello di area anziché per la disponibilità elevata.

La continuità aziendale richiede un approccio integrato che include tutti i componenti di un carico di lavoro. L'infrastruttura di rete è un componente primario per qualsiasi carico di lavoro in Azure. L'infrastruttura di rete deve essere allineata all'architettura di disponibilità elevata o ripristino di emergenza. Considerare i fattori seguenti dell'infrastruttura di rete:

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

  Per una maggiore protezione, è possibile posizionare le macchine virtuali in zone di disponibilità separate anziché in una singola zona di disponibilità. Questo approccio può impedire tempi di inattività durante un errore del data center.

• Per la protezione massima, è possibile inserire un database secondario in un'area di Azure diversa dall'area del database primario. Per applicare 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 tramite Internet pubblico.

  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

Passaggio successivo

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

Linee guida per la sicurezza per Oracle in Macchine virtuali acceleratore di zona di destinazione