Condividi tramite


Ottimizzare la continuità aziendale e il ripristino di emergenza

Quando si esegue la migrazione delle risorse Oracle ad Azure, prendere in considerazione l'affidabilità del database e anche l'affidabilità dei livelli nelle macchine virtuali (VM), nelle subnet di rete virtuale e nei componenti di archiviazione.

Oracle nell'infrastruttura distribuita come servizio (IaaS) di Azure può soddisfare gli obiettivi di resilienza necessari dei carichi di lavoro Oracle più esigenti. Per usare in modo efficace le indicazioni contenute in questo articolo, definire prima di tutto gli indicatori di prestazioni chiave di resilienza in base ai requisiti aziendali. Usare i requisiti dell'obiettivo del tempo di ripristino (RTO) e dell'obiettivo del punto di ripristino (RPO) come indicatori KPI di base per determinare l'architettura migliore per il carico di lavoro Oracle in Azure.

L'obiettivo RTO è la quantità massima di tempo per cui un'applicazione rimane non disponibile dopo un evento di emergenza, un errore o un evento paragonabile.

L'RPO è la quantità massima di perdita di dati dopo un'emergenza, un errore o un evento paragonabile.

Metodi di backup per la protezione dei dati

I tre metodi di backup del database Oracle per un carico di lavoro Oracle in Azure IaaS includono:

  • Backup di streaming. Usare Oracle Gestione ripristino (RMAN) per questo metodo. RMAN trasmette i backup su supporti nastro sequenziali.

    Le destinazioni di backup in Azure includono:

    • Librerie di nastri virtuali non Microsoft, disponibili in Azure Marketplace.
    • Condivisioni file locali e remote, ad esempio Archiviazione BLOB di Azure con il protocollo Network File System, File di Azure e Azure NetApp Files.
  • Snapshot a livello di archiviazione. Usare Backup di Azure per questo metodo. Questo metodo si basa sul tipo di archiviazione usato per i file di database. Ad esempio, se si usano dischi gestiti di Azure, ad esempio SSD Premium di Azure, Backup di Azure si integra con il database Oracle. Se si usa Azure NetApp Files, è possibile usare le funzionalità di protezione dei dati di Azure NetApp Files, ad esempio il backup di Azure NetApp Files e la replica tra aree.

  • Backup a livello di macchina virtuale. Usare Backup di Azure per questo metodo.

    Attenzione

    Assicurarsi che le macchine virtuali nell'ambiente di backup eseguano sistemi operativi con supporto. Informazioni sui sistemi operativi supportati.

Quando si esegue il flusso di backup di database di grandi dimensioni, il tempo necessario per copiare i dati per poi ripristinarli può superare i requisiti RTO. Gli snapshot a livello di archiviazione sono l'opzione migliore per questo scenario.

Consigli

  • Valutare attentamente se implementare una strategia di backup basata sullo streaming, sugli snapshot a livello di archiviazione o su entrambe le strategie.

  • Valutare l'effetto della strategia di backup sui requisiti RTO e RPO.

  • Analizzare le destinazioni di archiviazione disponibili per i backup RMAN in base ai limiti di velocità effettiva documentati per ogni opzione. Scegliere l'opzione che soddisfa i requisiti.

  • Prendere in considerazione l'uso di Backup di Azure per gli snapshot a livello di archiviazione e valutare la possibilità di inserire gli snapshot in un'area abbinata o in una zona di disponibilità per ottenere una protezione aggiuntiva.

  • Prendere in considerazione varie opzioni di archiviazione per archiviare i backup del log di archiviazione necessari per ripristinare il database. Prendere in considerazione le considerazioni sulle prestazioni, la replica e i costi di ogni opzione.

  • Sviluppare e testare regolarmente i piani di backup e ripristino per evitare sorprese indesiderate nell'ambiente di produzione.

Protezione dei servizi e continuità aziendale

Questa sezione descrive come migliorare la disponibilità elevata complessiva e il ripristino di emergenza del carico di lavoro Oracle in Azure IaaS implementando le considerazioni sulla protezione del servizio e sulla continuità aziendale (BC).

Incorporare le raccomandazioni seguenti per migliorare la ridondanza dell'architettura e, in definitiva, ottimizzare la quantità di tempo disponibile per il servizio. Mirare a ridurre al minimo i tempi di inattività del servizio a causa di interruzioni pianificate, ad esempio patch, aggiornamenti e aggiornamenti e interruzioni non pianificate, ad esempio errori. Usare le funzionalità di Azure e Oracle per migliorare il ripristino da errori a livello di area geografica.

Azure offre molte opzioni per la disponibilità elevata di singoli componenti in un'architettura Oracle in IaaS. È ad esempio possibile:

  • Distribuire macchine virtuali usando un set di scalabilità di macchine virtuali flessibile, che distribuisce automaticamente le macchine virtuali tra domini di errore.
  • Creare zone di disponibilità per proteggersi da errori del data center.
  • Posizionare le distribuzioni in aree diverse per proteggersi da errori di area completa.

Diverse funzionalità di archiviazione di Azure offrono livelli di ridondanza dell'archiviazione diversi, ad esempio l'archiviazione con ridondanza locale, l'archiviazione con ridondanza della zona e l'archiviazione con ridondanza geografica. Prendere in considerazione ogni opzione quando si pianifica la distribuzione del carico di lavoro Oracle in Azure IaaS.

È anche possibile usare Oracle Data Guard, uno strumento per le configurazioni di protezione del servizio di database Oracle. Data Guard inoltra e applica i log delle transazioni a uno o più database di standby. Questo processo gestisce copie esatte del database primario a cui è possibile eseguire il failover in caso di manutenzione pianificata o di uno scenario di errore.

Data Guard offre tre modalità di replica dei dati: protezione massima, disponibilità massima e prestazioni massime. Ogni modalità di replica offre una combinazione diversa di modalità di trasporto log e garanzie transazionali diverse per l'applicazione nel database secondario.

A seconda della strategia, ad esempio una strategia di perdita di dati zero o zero latenza, è possibile scegliere una configurazione sincrona o asincrona. È anche possibile implementare il failover di avvio rapido, a seconda dei requisiti di tempo di inattività massimi. Sono disponibili architetture di riferimento che forniscono un ripristino in meno di un minuto o meno di cinque minuti e fino a quattro ore. Il edizione Enterprise di Oracle Database include Data Guard.

Oracle GoldenGate è un altro strumento che è possibile usare per replicare i dati tra due database e abilitare scenari multi-primario. È necessario acquistare GoldenGate separatamente.

Consigli

  • Prendere in considerazione le funzionalità offerte da Azure per la disponibilità elevata di vari componenti dell'infrastruttura nell'implementazione Oracle in Azure IaaS.

  • Selezionare attentamente la modalità di protezione del database che soddisfa i requisiti quando si usa Data Guard per disponibilità elevata e ripristino di emergenza. Ad esempio, la modalità massima delle prestazioni riduce al minimo l'impatto sull'origine, ma ha il massimo potenziale per la perdita di dati. Per altre informazioni, vedere BCDR per Oracle in Azure Macchine virtuali acceleratore di zona di destinazione e modalità di protezione di Oracle Data Guard.

  • Valutare la possibilità di automatizzare il processo di failover. Ad esempio, è possibile usare il failover di avvio rapido.

  • Stabilire procedure di test per i processi di failover ed eseguire test regolari per evitare eventuali problemi.

  • Progettare la soluzione in modo olistico usando funzionalità native di Azure, ad esempio zone di disponibilità e strumenti nativi oracle, come Data Guard, per soddisfare i requisiti di disponibilità elevata e ripristino di emergenza. I due esempi seguenti usano i componenti nativi di Azure e Oracle.

Creare un failover con standby passivo

Questa sezione descrive un esempio di scenario di failover per le applicazioni Oracle critiche per l'azienda in una distribuzione a due zone di disponibilità con standby passivo.

Le applicazioni Oracle critiche per l'azienda, ad esempio Oracle E-Business Suite, richiedono la prevenzione degli errori e quindi un'architettura olistica.

Questo esempio:

  • Ha una distribuzione a due zone di disponibilità. Il livello applicazione usa Azure Site Recovery con una macchina virtuale secondaria passiva.

  • Sfrutta la funzionalità di failover di avvio rapido di Data Guard. Per ottenere la massima disponibilità, è consigliabile installare due osservatori. L'osservatore primario si trova nella zona di disponibilità 1 e l'osservatore secondario si trova nella zona di disponibilità 2. Gli osservatori monitorano e indirizzano il traffico. Quando il database primario non è disponibile, l'osservatore esegue automaticamente il failover nel database secondario. Data Guard esegue una sincronizzazione di rollforward. L'intervallo di tempo della sincronizzazione di rollforward dipende dalla configurazione di rollforward.

  • Dispone di Data Guard configurato per una modalità di protezione dei dati, ad esempio disponibilità massima, prestazioni massime o protezione massima. Per altre informazioni sulla scelta di una modalità per i requisiti del carico di lavoro, vedere Modalità di protezione di Oracle Data Guard.

L'architettura seguente mira a una soglia di tempo di inattività inferiore a cinque minuti.

Diagramma che mostra l'architettura per un failover con standby passivo.

Creare un failover con standby attivo

Questa sezione descrive un esempio di scenario di failover per le applicazioni Oracle critiche per l'azienda in una distribuzione a due zone di disponibilità con standby attivo.

In questo esempio:

  • Il livello server Web, il livello applicazione e il livello di database risiedono nella propria subnet di rete virtuale.

  • Il database primario risiede nella zona di disponibilità 1.

  • Il database che usa Active Data Guard per replicare il database primario in uno standby attivo risiede nella zona di disponibilità tre.

Nota

Questa configurazione richiede una licenza di Active Data Guard.

L'architettura seguente mira a una soglia di tempo di inattività inferiore a un minuto. Questo scenario di failover ha una configurazione di standby attiva, ma dispone di funzionalità di sola lettura.

Diagramma che mostra l'architettura per un failover con standby attivo.

Passaggio successivo