Informazioni su Fast-Start Failover di Oracle Data Guard
Ottieni alta disponibilità, prestazioni e scalabilità integrate di Oracle Exadata Database Machine e Oracle Real Application Clusters (Oracle RAC), con bassa latenza per le applicazioni basate su Azure.
L'estensione della soluzione con un database in standby in un'altra zona di disponibilità o area fornisce protezione dei dati e disaster recovery per i data center e le interruzioni regionali.
Data Guard trasporta in modo sincrono i dati nel database di standby per garantire che non si verifichi alcuna perdita di dati. Fast-start failover consente al broker di eseguire automaticamente il failover del database di standby di destinazione sul ruolo primario senza passi di failover manuale.
I siti degli osservatori monitorano l'ambiente di Fast-Start Failover. Un observer è un componente lato client separato che viene eseguito su una VM di computazione diversa dai database primario e in standby e monitora la disponibilità del database primario.
Fast-start failover fornisce un failover più veloce con un Recovery Time Objective (RTO) configurabile, con perdita di dati pari a zero in modalità sincrona o un Recovery Point Objective (RPO) limitato in modalità asincrona.
In questa guida sulle soluzioni, scopri come configurare e distribuire Data Guard e abilitare il failover rapido nelle zone di disponibilità di Oracle AI Database@Azure utilizzando Oracle Exadata Database Service on Exascale Infrastructure. La stessa soluzione si applica a Oracle Exadata Database Service on Dedicated Infrastructure.
Operazioni preliminari
Prima di iniziare, assicurarsi che siano rispettate le condizioni sotto riportate.
- I cluster VM Exascale vengono distribuiti in diverse zone di disponibilità di Azure.
- Oracle AI Database 26ai viene creato nella zona di disponibilità primaria.
- Gli intervalli CIDR IP di rete per i cluster VM Exascale primari e in standby non si sovrappongono.
Esaminare le soluzioni riportate di seguito.
Successivamente, devi eseguire il provisioning di una VM di computazione in Azure per ospitare l'observer, preferibilmente in una zona di disponibilità diversa rispetto ai database primari e in standby. L'observer può essere eseguito su una VM leggera mentre opera come client Oracle che si connette ai database primari e in standby.
Architettura
L'architettura seguente mostra un Data Guard tra zone con l'observer in esecuzione in una zona di disponibilità diversa:
cross-zones-dg-oracledb-azure-oracle.zip
Puoi instradare il traffico di Data Guard attraverso la rete Oracle Cloud Infrastructure (OCI) o Azure. Questa architettura indirizza il traffico di rete di Data Guard attraverso la rete Azure per mantenere tutti i dati all'interno della piattaforma Azure. Le reti VCN sul sito OCI vengono create dopo la creazione dei cluster VM Oracle Exadata Database Service on Exascale Infrastructure su Oracle AI Database@Azure per i database primari e in standby.
In questa architettura:
- Il cluster VM Exascale primario viene distribuito nella zona di disponibilità primaria in
VNet1con CIDR10.10.0.0/16e CIDR10.10.1.0/24della subnet delegata. - Il cluster VM Exascale in standby viene distribuito nella zona di disponibilità in standby in
VNet2con CIDR10.20.0.0/16e CIDR10.20.1.0/24della subnet delegata. - L'observer viene distribuito in
VNet3con CIDR10.30.0.0/16e CIDR10.30.1.0/24della subnet. VNet1viene sottoposto a peering conVNet2per consentire il flusso di traffico Data Guard tra i database primario e in standby.- Il peering
VNet3viene eseguito sia conVNet1che conVNet2per consentire all'observer di connettersi a entrambi i database.
Questa architettura include i seguenti componenti:
- Area Azure
Un'area Azure è un'area geografica in cui risiedono uno o più data center fisici di Azure, denominati zone di disponibilità. Le regioni sono indipendenti da altre regioni e vaste distanze possono separarle (tra paesi o addirittura continenti).
Azure e le aree OCI sono aree geografiche localizzate. Per Oracle AI Database@Azure, un'area Azure è connessa a un'area OCI, con le zone di disponibilità (AZ) in Azure connesse ai domini di disponibilità (AD) in OCI. Le coppie di aree Azure e OCI sono selezionate per ridurre al minimo la distanza e la latenza.
- Dominio di disponibilità Azure
Il dominio di disponibilità di Azure o set di disponibilità è un raggruppamento logico di virtual machine.
- Rete virtuale di Azure e subnet
La rete virtuale di Azure (VNet) consente di distribuire le risorse di Azure in una rete privata e isolata logicamente definita dall'utente. Questa rete assomiglia a una rete on-premise tradizionale, sfruttando al contempo l'infrastruttura cloud scalabile e ad alta disponibilità di Azure. Dopo aver creato una VNet, è possibile segmentarla in una o più subnet per organizzare e controllare il traffico di rete per i carichi di lavoro.
- Sottorete delegata di Azure
Una subnet delegata è una subnet VNet riservata e delegata al servizio Oracle AI Database@Azure, che consente a Oracle di distribuire e gestire le risorse di database richieste all'interno dello spazio IP della rete privata.
- Scheda di interfaccia di rete virtuale Azure (VNIC)
I servizi nei data center di Azure dispongono di schede di interfaccia di rete fisiche (NIC). Le istanze delle virtual machine comunicano utilizzando le NIC virtuali (VNIC) associate alle NIC fisiche. Ogni istanza dispone di una VNIC primaria creata e collegata automaticamente durante l'avvio ed è disponibile durante la durata dell'istanza.
- VM di computazione Microsoft Azure
Le Virtual Machine (VM) di Azure offrono risorse di calcolo scalabili e on-demand che puoi utilizzare come un server o un desktop fisico. Utilizzare le VM quando è necessario il controllo completo sul sistema operativo e sull'ambiente software.
Le VM non richiedono la gestione dell'hardware fisico, ma è comunque possibile configurare, applicare patch e gestire il software in esecuzione. Supporta carichi di lavoro personalizzati e legacy.
- Area OCI
Un'area geografica OCI è un'area geografica localizzata che contiene uno o più data center, che ospitano domini di disponibilità. Le regioni sono indipendenti da altre regioni e vaste distanze possono separarle (tra paesi o addirittura continenti).
- Dominio di disponibilità
I domini di disponibilità sono data center autonomi e indipendenti all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità sono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio alimentazione o raffreddamento, o la rete del dominio di disponibilità interno. Pertanto, un errore in un dominio di disponibilità non dovrebbe influire sugli altri domini di disponibilità nell'area.
- Rete e subnet cloud virtuale OCI
Una rete cloud virtuale (VCN, virtual cloud network) è una rete personalizzabile e definita dal software impostata in un'area OCI. Come le reti di data center tradizionali, le reti VCN offrono il controllo sull'ambiente di rete. Una VCN può avere più blocchi CIDR (Classless Inter-Domain Routing) non sovrapposti che è possibile modificare dopo aver creato la VCN. È possibile segmentare una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. È possibile modificare le dimensioni di una sottorete dopo la creazione. Una subnet può essere pubblica o privata.
- Gruppo di sicurezza di rete (NSG)
I gruppi NSG fungono da firewall virtuali per le risorse cloud. Con il modello di sicurezza zero-trust di OCI puoi controllare il traffico di rete all'interno di una VCN. Un gruppo NSG è costituito da un set di regole di sicurezza in entrata e in uscita che si applicano solo a un set specificato di schede VNIC (Virtual Network Interface Card) in una singola VCN.
- Oracle Data Guard
Oracle Data Guard e Active Data Guard forniscono un set completo di servizi che creano, gestiscono, gestiscono e monitorano uno o più database in standby e che consentono ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database in standby come copie del database di produzione utilizzando la replica in memoria. Se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può sostituire qualsiasi database in standby con il ruolo di produzione riducendo al minimo i tempi di inattività associati all'indisponibilità. Oracle Active Data Guard offre la possibilità aggiuntiva di scaricare principalmente i carichi di lavoro di lettura sui database in standby e offre anche funzioni avanzate di protezione dei dati.
- Oracle AI Database@Azure
Oracle AI Database@Azure è il servizio Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure e Oracle Autonomous AI Database Serverless) in esecuzione su OCI, distribuito nei data center Microsoft Azure. Il servizio offre funzionalità e parità di prezzo con OCI. Acquista il servizio su Azure Marketplace.
Oracle AI Database@Azure integra le tecnologie Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) e Oracle Data Guard nella piattaforma Azure. Gli utenti gestiscono il servizio sulla console di Azure e con gli strumenti di automazione di Azure. Il servizio è distribuito in Azure Virtual Network (VNet) e integrato con il sistema di gestione delle identità e degli accessi di Azure. Le metriche generiche e i log di audit di OCI e Oracle AI Database sono disponibili in modo nativo in Azure. Il servizio richiede agli utenti di disporre di una sottoscrizione Azure e di una tenancy OCI.
Autonomous AI Database si basa sull'infrastruttura Oracle Exadata, è autogestito, self-securing e self-repairing, aiutando a eliminare la gestione manuale del database e gli errori umani. Autonomous AI Database consente lo sviluppo di applicazioni scalabili basate sull'intelligenza artificiale con qualsiasi dato utilizzando funzionalità AI integrate utilizzando il modello linguistico di grandi dimensioni (LLM, large language model) e la posizione di distribuzione.
Il provisioning di Oracle Exadata Database Service e Oracle Autonomous AI Database Serverless viene eseguito facilmente tramite il portale nativo di Azure, consentendo l'accesso all'ecosistema Azure più ampio.
Suggerimenti
I requisiti potrebbero essere diversi dall'architettura descritta qui.
- Posizionare l'osservatore su un host in un terzo sito separato. In questo modo, se il sito primario o in standby non riesce completamente, l'observer rimane attivo per coordinare il failover o monitorare il sito rimanente.
- Nel caso in cui non sia disponibile un terzo sito, posizionare l'osservatore nel sito principale.
- Configurare più osservatori su server diversi per l'alta disponibilità. Mentre solo un osservatore può essere l'osservatore principale, altri osservatori fungono da osservatori di riserva.
- Seguire la documentazione Oracle per impostare i valori per le proprietà di configurazione Fast-Start Failover, ad esempio le proprietà Fast-Start Failover, ad esempio
FastStartFailoverThreshold,FastStartFailoverLagLimiteFastStartFailoverAutoReinstate. - Esegui sempre l'observer Broker di Data Guard utilizzando la stessa release e lo stesso livello di patch principali (incluso Release Update [RU]) delle home di Oracle AI Database all'interno della configurazione Data Guard. Questa combinazione riceve i test più accurati e riduce al minimo i rischi operativi. Garantisce inoltre che tutte le correzioni che interessano sia il codice lato client (osservatore) che il codice lato server (database) siano in vigore in qualsiasi momento. È consentita una differenza fino a un'importante release di supporto a lungo termine (LTS) tra l'Observer e il database, principalmente per facilitare gli aggiornamenti in sequenza e ridurre al minimo i tempi di inattività. Ad esempio, l'osservatore a 26ai con Database a 19c durante le procedure di upgrade o viceversa.
Considerazioni
- Non posizionare mai l'observer sullo stesso sito del database di standby. Se il sito in standby si spegne, verrà arrestato anche il database primario perché non è in grado di comunicare con l'osservatore, causando un'interruzione completa
- L'observer può essere eseguito su una VM leggera. Tuttavia, la stabilità della connessione di rete al database primario e in standby è fondamentale per garantire il corretto funzionamento ed evitare failover non necessari.
- Configurare la modalità di massima disponibilità di Data Guard per garantire nessuna perdita di dati. Se si è più preoccupati per le prestazioni del database primario rispetto a una perdita minima di dati, considerare la possibilità di abilitare il failover di avvio rapido quando la modalità di protezione della configurazione è impostata sulle massime prestazioni.
-
Il tempo di failover dipende dal fatto che il database di standby di destinazione abbia applicato tutti i redo data ricevuti dal database primario. Il failover di avvio rapido è più rapido quando si eseguono passi per ottimizzare il recupero in modo che l'applicazione dei dati di redo al database in standby venga mantenuta aggiornata con la velocità dell'applicazione di redo del database primario. Vedere la sezione Considerazioni sulle prestazioni per il failover di avvio rapido nella documentazione Data Guard, Broker Concepts.
- Il tempo di failover dipende dallo stato di applicazione di redo nel database di standby.
Informazioni sui servizi e i ruoli richiesti
Questa soluzione richiede i seguenti servizi e ruoli:
- Oracle Exadata Database Service su infrastruttura Exascale
- Oracle Cloud Infrastructure Networking
Questi sono i ruoli necessari per ogni servizio.
| Nome servizio: ruolo | Obbligatorio per... |
|---|---|
Database OCI: manage database-family |
Creare un database di standby Data Guard |
Networking OCI: manage vcn-family |
Gestire il gruppo di sicurezza di rete in OCI |
Consulta i prodotti, le soluzioni e i servizi Oracle per ottenere ciò di cui hai bisogno.