Considerazioni sulla continuità aziendale e sul ripristino di emergenza per Oracle Database@Azure
Questo articolo illustra le 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).
Il primo passaggio per creare un'architettura resiliente per l'ambiente del carico di lavoro consiste nell'identificare i requisiti di disponibilità per la soluzione. È necessario determinare l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO) per diversi livelli di errore. L'obiettivo RTO definisce il tempo di inattività massimo che un'applicazione può tollerare dopo un evento imprevisto. L'RPO specifica la perdita massima di dati che un'applicazione può tollerare a causa di un'emergenza. Dopo aver determinato i requisiti della soluzione, è possibile progettare l'architettura per soddisfare l'obiettivo RTO e RPO.
Considerazioni relative alla progettazione
Colocare il servizio di database Oracle Exadata nell'infrastruttura dedicata con Oracle Database@Azure nei data center di Azure e posizionare i data center in un'unica zona di disponibilità di Azure. Le zone di disponibilità sono specifiche di una sottoscrizione. Ad esempio, la zona di disponibilità 1 in una sottoscrizione potrebbe non rappresentare lo stesso data center fisico della zona di disponibilità 1 in una sottoscrizione diversa. Per altre informazioni, vedere Che cosa sono le zone di disponibilità.
La soluzione Oracle Database@Azure offre tecnologie Oracle native, ad esempio cluster di applicazioni reali (RAC) e Data Guard automatizzato, per la disponibilità elevata e il ripristino di emergenza.
La soluzione include una configurazione automatizzata di Data Guard per il database di standby iniziale, noto anche come primo database secondario. È necessario configurare manualmente eventuali repliche aggiuntive di Data Guard.
Per gli ambienti attivi, è consigliabile usare Oracle GoldenGate per l'integrazione dei dati in tempo reale e le funzionalità di replica. Questo approccio consente di garantire la disponibilità elevata e la coerenza dei dati tra i sistemi. Questo strumento supporta un'ampia gamma di database e piattaforme in modo da poter spostare e trasformare facilmente i dati. Usare Oracle GoldenGate per ridurre al minimo i tempi di inattività durante le migrazioni e gli aggiornamenti, migliorando le strategie di ripristino di emergenza. Oracle GoldenGate non è incluso nella soluzione, quindi è possibile che si verifichino costi di licenza.
La soluzione Oracle Database@Azure e i relativi componenti principali sono limitati alla sottoscrizione e all'area in cui si crea l'istanza. Il servizio non è multi-zonale e non si estende su più aree. Per ottenere resilienza multiarea o multiarea, è possibile distribuire nuove istanze in zone di disponibilità o aree di destinazione.
Oracle Database@Azure usa l'archiviazione oggetti OCI (Oracle Cloud Infrastructure) ridondante per integrare i backup automatici del database. Oracle Database Autonomous Recovery Service offre protezione per i database Oracle distribuiti in Exadata.
Suggerimenti per la progettazione
Prendere in considerazione queste considerazioni bcdr per oracle Database@Azure.
BcDR zona a disponibilità incrociata
Per garantire la disponibilità elevata e la protezione del ripristino di emergenza da errori di database, cluster di database o zone di disponibilità, usare Oracle RAC in Oracle Database@Azure e un database di standby simmetrico che si trova in un'altra zona. Questa configurazione consente di ottenere la resilienza del data center per i servizi di database.
Per prestazioni ottimali, posizionare i servizi dell'applicazione dipendenti dal database nella stessa zona di disponibilità del database. Se i servizi dell'applicazione si trovano in una sottoscrizione diversa rispetto ai servizi di database, è necessario applicare il codice appropriato. Usare la availabilityZoneMappings proprietà per identificare la zona di disponibilità fisica in cui è necessario condividere i servizi.
È possibile configurare Data Guard in modalità disponibilità massima con il trasporto SYNC o la modalità Prestazioni massime con il trasporto ASYNC in base ai servizi dell'applicazione e ai requisiti RPO.
È consigliabile usare la modalità di disponibilità massima (SYNC) per gli ambienti in cui l'integrità dei dati e la perdita di dati zero sono i fattori più importanti.
È consigliabile usare la modalità ASYNC (Maximum Performance Mode) per gli ambienti in cui le prestazioni sono critiche e l'ambiente può tollerare una perdita di dati.
BCDR tra aree
Configurare Data Guard in modalità Prestazioni massime per il ripristino di emergenza locale in base alle funzionalità dell'applicazione e alla latenza di rete tra aree. Per altre informazioni, vedere Risultati dei test di latenza di rete di Azure.
La combinazione di operazioni BCDR tra zone di disponibilità e tra aree è allineata al livello Gold delle architetture di riferimento oracle per l'architettura di riferimento dell'architettura di disponibilità massima. L'architettura di livello Gold offre protezione da un errore a livello di area completo.
Le raccomandazioni bcdr tra aree e zona a disponibilità incrociata sono incentrate sulla resilienza per il servizio Oracle Database@Azure. Per garantire la resilienza per i servizi dell'applicazione, è possibile usare Azure set di scalabilità di macchine virtuali, Azure Site Recovery, Frontdoor di Azure o altri servizi o funzionalità che consentono la disponibilità del servizio applicazioni tra zone o aree di disponibilità.
È consigliabile usare backup gestiti e archiviare i dati di backup in Archiviazione oggetti OCI.
Altre considerazioni
Usare l'infrastruttura come codice (IaC) per distribuire l'istanza iniziale di Oracle Database@Azure e i cluster di macchine virtuali.
Usare IaC per distribuire i database in OCI. È possibile usare IaC per replicare la stessa distribuzione in un sito di ripristino di emergenza e ridurre al minimo il rischio di errore umano.
Usare le operazioni di failover di test e switchback per assicurarsi che funzionino in uno scenario di emergenza reale. Automatizzare le operazioni di failover e switchback quando possibile per ridurre al minimo gli errori.