Distribuisci un database Bare Metal altamente disponibile
Oracle Data Guard garantisce l'elevata disponibilità, la protezione dei dati e il ripristino dei disastri per i dati aziendali. Con Data Guard, il failover del database primario al database in standby può essere eseguito manualmente utilizzando l'interfaccia della riga di comando Data Guard Broker (DGMGRL CLI) o Oracle Enterprise Manager oppure configurando automaticamente un nodo Compute in modo da fungere da osservatore FSFO (fast-start failover). L'observer può avviare automaticamente il failover e ripristinare automaticamente un database primario non riuscito come database in standby. Avere osservatori FSFO nella distribuzione rimuove la necessità di un intervento manuale quando il failover del database è necessario.
Architettura
Questa architettura di riferimento mostra come distribuire due sistemi DB Bare Metal e i componenti dell'infrastruttura necessari per configurare FSFO per un Oracle Database 12c Release 2 (12.2) distribuito su Oracle Cloud Infrastructure in due aree.
Questa architettura di database cloud può essere utilizzata come livello di database resiliente per molte applicazioni, tra cui Oracle E-Business Suite, JD Edwards e PeopleSoft.
Il seguente diagramma illustra questa architettura di riferimento.

Descrizione dell'immagine ha-db.png
- Area
Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati 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 indipendenti e autonomi all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità vengono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono infrastrutture quali l'alimentazione o il raffreddamento o la rete di dominio di disponibilità interna. È quindi improbabile che un errore a un dominio di disponibilità influenzi gli altri domini di disponibilità nell'area.
I domini di disponibilità non vengono visualizzati nel diagramma di architettura.
- Domini di errore
Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità ha tre domini di guasto con alimentazione e hardware indipendenti. Quando si distribuiscono risorse su più domini di errore, le applicazioni possono tollerare errori fisici del server, la manutenzione del sistema e gli errori di alimentazione all'interno di un dominio di errore.
I domini di errore non vengono visualizzati nel diagramma di architettura.
- Rete cloud virtuale (VCN) e subnet
Un VCN è una rete customizzabile e definita dal software impostata in un'area Oracle Cloud Infrastructure. Come le tradizionali reti di data center, i VCN ti danno il controllo completo sul tuo ambiente di rete. Un VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo la creazione di VCN. È possibile segmentare un 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 in VCN. È possibile modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.
- Liste di sicurezza
Per ogni subnet è possibile creare regole di sicurezza che specifichino l'origine, la destinazione e il tipo di traffico che devono essere consentiti all'interno e all'esterno della subnet.
- Osservatori
Gli osservatori sono nodi di calcolo che dispongono del software Oracle Database necessario installato e configurato per avviare FSFO di Oracle Database in esecuzione sul sistema DB Bare Metal. Una procedura ottimale di FSFO consiste nell'eseguire il processo observer su un host che si trova in un data center diverso dal database primario o in standby. Per soddisfare questa best practice, questa architettura di riferimento distribuisce tre nodi di observer. Per questa impostazione è necessario Oracle Database release 12.2 o successiva.
- Sistemi DB primari e in standby
Questi sistemi DB Bare Metal dispongono di un Oracle Database 12c Release 2 (12.2) configurato per la replica di Data Guard.
Suggerimenti
Le vostre esigenze potrebbero differire dall'architettura descritta qui. Utilizzare come punto di inizio i suggerimenti riportati di seguito.
- Forme di sistema DB
Questa architettura di riferimento utilizza la forma Bare Metal di BM.Standard2.52 per i sistemi DB. Questa forma ha 51.2 TB di SSD NVMe collegati localmente con latenza bassa. Abbiamo selezionato la forma bare metal perché consente di creare più home e database di database.
- Calcola forme
Questa architettura di riferimento utilizza una forma VM (core virtual machine) VM.Standard2.1 per i nodi observer. Il nodo observer è un client Oracle Call Interface a basso impatto integrato nella CLI DGMGRL. Una forma VM one-core è sufficiente per questa architettura.
- VCN
Quando si crea un VCN, determinare il numero di blocchi CIDR richiesti e la dimensione di ogni blocco in base al numero di risorse che si prevede di associare alle subnet in VCN. Utilizzare blocchi CIDR all'interno dello spazio di indirizzi IP privati standard.
Selezionare blocchi CIDR che non si sovrappongono a nessun'altra rete (in Oracle Cloud Infrastructure, nel data center in locale o in un altro provider cloud) a cui si intende impostare connessioni private.
Dopo aver creato un VCN, è possibile modificare, aggiungere e rimuovere i blocchi CIDR.
Quando si progettano le subnet, prendere in considerazione il flusso di traffico e i requisiti di sicurezza. Allegare tutte le risorse all'interno di un livello o ruolo specifico alla stessa subnet, che può fungere da limite di sicurezza.
Utilizzare subnet regionali.
- Liste di sicurezza
Utilizzare gli elenchi di sicurezza per definire le regole di ingresso e uscita che si applicano all'intera subnet. Ad esempio, questa architettura di riferimento consente ICMP internamente per l'intera subnet privata.
- Guardia cloud
Duplicare e personalizzare le ricette predefinite fornite da Oracle per creare ricette di rilevatori e rispondenti personalizzati. Queste ricette consentono di specificare il tipo di violazioni della sicurezza che generano un'avvertenza e le azioni che possono essere eseguite su di esse. Ad esempio, è possibile rilevare i bucket di storage degli oggetti con visibilità impostata su Pubblico.
Applicare Cloud Guard a livello di tenancy per coprire l'ambito più ampio e ridurre gli oneri amministrativi derivanti dalla gestione di più configurazioni.
È inoltre possibile utilizzare la funzione Elenco gestito per applicare determinate configurazioni ai rilevatori.
- Zone di sicurezza
Per le risorse che richiedono la massima sicurezza, Oracle consiglia di utilizzare le zone di sicurezza. Una zona di sicurezza è un compartimento associato a una ricetta definita da Oracle di criteri di sicurezza basati sulle best practice. Ad esempio, le risorse in una zona di sicurezza non devono essere accessibili da Internet pubblico e devono essere cifrate utilizzando chiavi gestite dal cliente. Quando si creano e aggiornano le risorse in una zona di sicurezza, Oracle Cloud Infrastructure convalida le operazioni in base ai criteri nella composizione della zona di sicurezza e nega le operazioni che violano uno qualsiasi dei criteri.
Considerazioni
Considerare questi punti quando si distribuisce questa architettura di riferimento.
- Prestazioni
Per ottenere le migliori prestazioni per i carichi di lavoro dell'applicazione, assicurarsi che il sistema DB bare metal primario disponga di core sufficienti per supportare l'applicazione e la configurazione Data Guard.
- Disponibilità
I nodi observer vengono distribuiti in più aree di disponibilità per garantire che FSFO possa verificarsi automaticamente anche se uno dei nodi observer non è in linea. Dopo l'esecuzione del failover, il database in standby diventa il database primario.
- Costo
Misura le CPU sui sistemi DB Bare Metal in base alle tue esigenze. È possibile iniziare con due o più core e scalare fino a 52 core su una forma BM.DenseIO2.52. È inoltre possibile scalare dinamicamente i core senza tempi di inattività.