Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo illustra le considerazioni sulla continuità aziendale e il ripristino di emergenza (BCDR) descritti nell'area di progettazione della zona di atterraggio di Azure . Incorpora i principi Oracle Maximum Availability Architecture (MAA) per Oracle Database@Azure utilizzando il servizio Oracle Exadata Database.
Il primo passaggio per creare un'architettura resiliente per i database Oracle eseguiti in Oracle Database@Azure consiste nell'identificare i requisiti di disponibilità per la soluzione. È fondamentale stabilire l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO) per diversi livelli di errori, inclusi gli eventi pianificati e non pianificati. Il RTO definisce il tempo di inattività massimo che un'applicazione o un servizio può tollerare dopo un'interruzione. L'RPO specifica la durata massima della perdita di dati che un'applicazione o un'azienda può tollerare. È necessario soddisfare questo prerequisito prima di iniziare la progettazione BCDR. Dopo aver stabilito i requisiti della soluzione, è possibile progettare l'ambiente Oracle Database@Azure in modo che sia allineato con i tuoi obiettivi RTO e RPO.
Per altre informazioni, vedere le linee guida di Microsoft Azure Well-Architected Framework su come progettare una strategia di ripristino di emergenza.
Considerazioni sulla progettazione
Il servizio Database@Azure Oracle Exadata è disponibile in due diverse zone di disponibilità all'interno di un'area. Questa disponibilità aiuta a garantire l'affidabilità del servizio e il ripristino d'emergenza. Per verificare il percorso di distribuzione del Oracle Exadata Database@Azure, controllare il cluster di macchine virtuali nel portale di Azure.
Oracle Exadata Database@Azure e i relativi componenti principali sono limitati alla zona di disponibilità in cui si crea l'istanza. Il servizio non copre più zone o si estende su più aree. Per ottenere la resilienza a più zone o multiregionali, è possibile distribuire nuove istanze di Oracle Exadata Database@Azure in zone o regioni di disponibilità di destinazione.
Oracle Exadata Database@Azure offre tecnologie Oracle native, ad esempio cluster di applicazioni reali Oracle per la disponibilità elevata e Oracle Data Guard per il ripristino di emergenza. Data Guard e Active Data Guard sono supportati per l'architettura DR.
Oracle Exadata Database@Azure fornisce HA, garantendo disponibilità elevata contro i guasti a livello di istanza di database e di hardware per impostazione predefinita. Questa architettura è allineata al livello argento MAA. Le operazioni di manutenzione pianificata possono essere eseguite in modo in sequenza. Tuttavia, un'architettura predefinita a zona singola ha una tolleranza di errore zero in caso di errori del sito o dell'area.
La soluzione fornisce la configurazione automatizzata di Data Guard per il ripristino di emergenza. Questa configurazione consente di proteggere da errori del sito richiedendo un'altra distribuzione di Database@Azure Oracle Exadata in una zona o un'area di disponibilità diversa.
È possibile stabilire la connettività di rete tra istanze Oracle Exadata primarie e standby Database@Azure tramite la rete di Azure e la rete OCI (Oracle Cloud Infrastructure). Per impostazione predefinita, la route primaria per questa connettività è tramite Azure.
Le tre opzioni di backup disponibili per i Database@Azure Oracle Exadata sono:
backup gestito da OCI: Questa opzione include due soluzioni integrate, che sono Oracle Database Autonomous Recovery Service e Oracle Cloud Infrastructure Object Storage. Queste soluzioni vengono gestite tramite la console OCI.
Il servizio di ripristino autonomo è progettato per carichi di lavoro cruciali a livello aziendale con requisiti RTO e RPO rigorosi. Offre disponibilità tramite contratti di servizio. Per ulteriori informazioni, vedere il documento pilastro dei servizi cloud pubblici "Oracle Platform as a Service (PaaS) e Infrastructure as a Service (IaaS)" .
Archiviazione oggetti OCI è una soluzione di backup per utilizzo generico adatta ai carichi di lavoro con requisiti RTO o RPO meno rigorosi.
Queste soluzioni consentono la pianificazione e la gestione automatica dei backup del database con un periodo di conservazione predefinito. Per ulteriori informazioni, vedere Gestire il backup e il ripristino del database su Exadata Database Service su infrastruttura dedicata Oracle.
Backup autogestito: È possibile configurare Oracle Exadata Database@Azure per lo streaming dei backup dei database nei servizi di archiviazione di Azure, tra cui Archiviazione blob di Azure, File di Azure (tramite endpoint privati) e Azure NetApp Files.
Questa opzione richiede la configurazione manuale e la manutenzione in corso.
soluzioni di backup non Microsoft: È possibile usare soluzioni di backup non Microsoft disponibili in Azure Marketplace, ad esempio Commvault, per gestire e archiviare i backup del database.
Consigli per la progettazione
Per creare un'architettura resiliente personalizzata in base ai requisiti specifici, prendere in considerazione le raccomandazioni BCDR seguenti per Oracle Exadata Database@Azure.
È consigliabile configurare almeno due istanze di Oracle Exadata Database@Azure con Data Guard per proteggere da errori a sito singolo. Questa configurazione è allineata allo standard d'oro MAA.
BCDR a più zone
L'architettura BCDR a più zone è consigliata per i clienti che richiedono un RPO zero o quasi zero con ridondanza a più zone rispettando i requisiti di residenza dei dati a singola area.
Questa soluzione include una distribuzione secondaria di Oracle Exadata Database@Azure in una zona di disponibilità diversa all'interno della stessa area. Per garantire la resilienza in caso di errori del database, del cluster o della zona di disponibilità, implementare un database di standby che si trova nell'istanza secondaria. Questa configurazione offre protezione da errori a livello di sito.
Modalità di trasporto redo di Data Guard: Configurare la modalità di trasporto redo di Data Guard in base ai servizi delle applicazioni e ai requisiti di RPO:
l'integrità dei dati e la perdita di dati zero: Quando l'integrità dei dati e la perdita di dati zero sono le priorità più elevate, usare la modalità di disponibilità massima (SYNC). Questa modalità replica in modo sincrono i dati nel database di standby, assicurando che non vengano persi dati.
Prestazioni di sistema: Quando le prestazioni del sistema sono critiche e un piccolo grado di perdita di dati è accettabile, usare la modalità di prestazioni massima (ASYNC). Questa modalità usa la replica asincrona, che comporta un RPO leggermente maggiore di zero (o è vicino a zero).
Mantenere un'istanza di standby simmetrica: è necessario mantenere un'istanza di standby simmetrica con risorse equivalenti al database primario per garantire prestazioni coerenti durante le operazioni di passaggio e failover. In alternativa, è possibile configurare il database standby con risorse minime e aumentare dinamicamente il cluster di macchine virtuali in base alle esigenze dopo il passaggio o il failover. Tuttavia, questo approccio potrebbe aumentare i tempi per le operazioni di ridimensionamento e la loro riflessione a livello di database.
Automatizzare le operazioni di failover: Usare Oracle Data Guard Fast-Start Failover per automatizzare l'operazione di failover, riducendo al minimo il RTO e gli errori.
Annotazioni
Fast-Start Failover non è un servizio gestito e richiede la configurazione manuale.
Per questa configurazione, sono necessarie macchine virtuali aggiuntive che eseguono osservatori di Oracle Data Guard per abilitare Data Guard Fast-Start Failover. Queste macchine virtuali observer monitorano lo stato del database e della replica, automatizzando il processo di failover.
Se è necessaria un'architettura di ripristino di emergenza simmetrica se è presente un failover, è necessario posizionare un'istanza osservatore nella posizione in cui è configurata la distribuzione secondaria di Oracle Exadata Database@Azure.
BCDR multiregionale
Per una strategia BCDR multimultidimensionale, implementare una distribuzione secondaria di Oracle Exadata Database@Azure con un database standby situato in un'area diversa in cui è disponibile il servizio. Questa configurazione garantisce la protezione dalle interruzioni complete a livello di area.
Configurare Data Guard per la replica asincrona per il ripristino di emergenza a livello di area in base ai requisiti dell'applicazione e alla latenza di rete tra l'area primaria e quella secondaria. Per altre informazioni, vedere statistiche sulla latenza di andata e ritorno nella rete di Azure.
Annotazioni
Data Guard automatizzato consente solo la configurazione in modalità Massime Prestazioni (ASYNC) per le distribuzioni tra aree.
- Le raccomandazioni BCDR a più zone e multiregionali sono incentrate sulla resilienza del servizio di database. Per garantire la resilienza complessiva del carico di lavoro, prendere in considerazione l'uso di servizi e funzionalità di Azure, ad esempio set di scalabilità di macchine virtuali di Azure, Azure Site Recovery e Frontdoor di Azure per progettare un'architettura affidabile tra zone o aree di disponibilità.
Scenari BCDR estesi
Database di standby locali e remoti
Per soddisfare i requisiti per la disponibilità e la resilienza dei servizi affidabili in caso di interruzioni a livello di area, è consigliabile implementare più database di standby per carichi di lavoro cruciali.
Un database di standby locale in una distribuzione di Database@Azure Oracle Exadata si trova in una zona di disponibilità diversa all'interno della stessa area. Questa configurazione offre una soluzione praticabile per le applicazioni sensibili alla latenza risolvendo i requisiti di failover senza perdita di dati tramite la replica SYNC Data Guard. Questa strategia consente di garantire la disponibilità del servizio senza influire sulla velocità effettiva dell'applicazione o sul tempo di risposta complessivo.
Un database di standby remoto in un'istanza di Oracle Exadata Database@Azure che si trova in un'area diversa soddisfa i requisiti di ripristino di emergenza a livello di area.
Questa architettura è ideale per carichi di lavoro cruciali e richiede almeno tre distribuzioni di Oracle Exadata Database@Azure.
Annotazioni
Se è necessaria una configurazione simmetrica a causa di uno scenario di failover, posizionare un database di standby aggiuntivo in Oracle Exadata Database@Azure nell'area secondaria, all'interno di una zona di disponibilità diversa.
Architettura di Data Guard Far Sync
È possibile soddisfare il requisito di implementare una replica senza perdita di dati a qualsiasi distanza usando la configurazione di Data Guard Far Sync. Questo approccio include l'inserimento di un'istanza sincrona lontano alla distribuzione primaria di Oracle Exadata Database@Azure, essenzialmente in un'altra zona di disponibilità all'interno della stessa area, per inviare in modo sincrono i log di rollforward. L'istanza di sincronizzazione lontano trasferisce quindi questi log in modo asincrono al database standby eseguito nella distribuzione secondaria di Oracle Exadata Database@Azure in un'altra area. Questa configurazione comporta in modo efficace una replica senza perdita di dati tra aree.
Se si desidera una architettura di ripristino di emergenza simmetrica in caso di failover, posizionare un'istanza far sync in una zona di disponibilità separata, dove è configurata la distribuzione secondaria di Oracle Exadata Database@Azure.
Annotazioni
L'architettura Far Sync richiede una licenza di Active Data Guard e deve essere configurata manualmente.
Consigli per il backup
Se si prevede di usare i backup come unica soluzione per i requisiti BCDR, tenere presente che RTO è superiore rispetto agli scenari di replica perché si basa sulle dimensioni del database e sui metodi di backup usati.
Eseguire il backup dei dati in Azure: Per soddisfare i requisiti dell'organizzazione che impongono che i dati e i backup rimangano in Azure, prendere in considerazione le soluzioni seguenti:
Usare il servizio di ripristino autonomo (ARS) in Azure: Durante la configurazione dei criteri di backup, scegliere di archiviare i dati di backup nello stesso provider di servizi cloud del database per usare l'ARS in Azure.
Usare i servizi di archiviazione: Usare servizi di archiviazione come Blob Storage, Azure Files e Azure NetApp Files per montare l'archiviazione come punti NFS sul server di database e salvare i backup di Oracle Recovery Manager (RMAN) nell'archiviazione.
Conservazione dei backup a lungo termine: Se la tua organizzazione richiede la conservazione dei backup a lungo termine, puoi configurare backup RMAN autogestiti in Azure Storage.
Configurazioni dei backup di archiviazione: Quando i backup sono configurati nei servizi di archiviazione, prendere in considerazione le seguenti raccomandazioni:
Pianificazione con processi cron: Usare processi cron a livello di nodo del database per pianificare i backup in momenti specifici in base alla strategia di backup.
Replicare i backup: Usare le funzionalità di replica di archiviazione sottostanti da Azure come l'archiviazione con ridondanza della zona e l'archiviazione con ridondanza geografica per replicare i backup.
operazioni di backup e ripristino: eseguire manualmente il backup di macchine virtuali Oracle Exadata Database@Azure per ripristinare i file critici in caso di eliminazioni o danneggiamenti accidentali. Per altre informazioni, vedere operazioni di backup e ripristino del nodo Oracle Exadata Cloud Compute (ID documento 2809393.1).
Altre raccomandazioni
Mantenere i dati in Azure: Se è necessario mantenere i dati esclusivamente all'interno di Azure, instradare il traffico di Data Guard attraverso la rete di Azure e configurare i backup per rimanere in Azure.
Test di ripristino di emergenza: Test delle operazioni di failover e switchover per assicurarsi che funzionino in uno scenario reale di emergenza.
Usare Oracle Fast-Start Failover per automatizzare le operazioni di failover quando possibile per ridurre al minimo gli errori.
Usare Continuità dell'Applicazione Oracle per mascherare senza problemi l'interruzione nel layer applicativo.
Dati e replica in tempo reale: Per gli ambienti attivi, è consigliabile usare Oracle GoldenGate per l'integrazione e la replica dei dati in tempo reale. Richiede la consapevolezza a livello di applicazione per gestire in modo efficace la risoluzione dei conflitti.
Annotazioni
GoldenGate non è incluso in questa soluzione e potrebbe comportare costi di licenza aggiuntivi.
Ridurre al minimo le interruzioni: Per ridurre al minimo le interruzioni per il carico di lavoro, pianificare la manutenzione pianificata durante le ore di minore attività. Quando è possibile, usare gli aggiornamenti in sequenza per garantire un processo senza interruzioni.
Usare l'infrastruttura come codice (IaC): Per un'automazione dell'infrastruttura più affidabile, distribuire l'istanza iniziale di Oracle Exadata Database@Azure e i cluster di macchine virtuali usando IaC. Per altre informazioni sull'automazione di Oracle Database@Azure, vedere Guida introduttiva Database@Azure Oracle con i moduli Terraform o OpenTofu.
Usare i moduli verificati di Azure per distribuire istanze di Oracle Exadata Database@Azure e cluster di macchine virtuali. Per altre informazioni, vedere le risorse seguenti:
Usare IaC per distribuire i database nella console 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.