Configurare una soluzione DR ibrida per Oracle SOA Suite
Informazioni preliminari
Il sistema Oracle WebLogic Server utilizzato in questo documento è un ambiente ad alta disponibilità configurato in base alle procedure ottimali standard MAA descritte in Enterprise Deployment Guide for Oracle SOA Suite (EDG) for Fusion Middleware Systems. Sebbene non tutti gli scenari seguano questa topologia esatta nei dettagli, questo riguarda molti componenti e combinazioni diverse, viene utilizzato spesso in distribuzioni di grandi dimensioni e implementa suggerimenti di alta disponibilità che devono essere applicati prima di distribuire un sistema di disaster recovery (DR). Di conseguenza, è considerato l'esempio di riferimento migliore di un sistema primario per una soluzione di DR ibrido per Oracle WebLogic Server. In base a ciò, si consiglia di acquisire familiarità con le procedure ottimali di distribuzione di Oracle WebLogic Server High Availability e Enterprise per la rete, lo storage e l'impostazione dell'host prima di distribuire un sistema ibrido.
- Oracle Fusion Middleware High Availability Guide
- Guida alla distribuzione di Oracle Fusion Middleware - Enterprise per Oracle SOA Suite
- Oracle Fusion Middleware Guide alla distribuzione Enterprise in Best practice MAA - Oracle Fusion Middleware
Assicurati di conoscere anche i concetti e l'amministrazione di Oracle Cloud Infrastructure.
Architettura
Il sistema primario è un sistema Oracle SOA Suite disponibile in locale. Il sistema in standby viene creato ex novo in una tenancy OCI che utilizza Oracle Cloud Infrastructure FastConnect (o VPN da sito a sito) per connettersi all'ambiente in locale.
Il livello intermedio su OCI viene creato installando SOA nelle virtual machine (VM) OCI e non in un'istanza di Oracle SOA Cloud Service o Oracle SOA Suite su Marketplace (sono previste limitazioni nelle versioni del sistema operativo, negli utenti del sistema operativo e nella struttura di directory che impediscono a Oracle SOA Cloud Service o Oracle SOA Suite su Marketplace di funzionare correttamente come database in standby per un sistema in locale).
Il livello di database nel sito OCI è un sistema DB Oracle Real Application Clusters (Oracle RAC).
Descrizione dell'illustrazione maa-soa-hybrid-dr.png
Questa architettura supporta i seguenti componenti nel data center principale in locale:
- Rete
Questa è la rete locale utilizzata dall'organizzazione. È uno dei raggi della topologia.
- Load balancer
Fornisce la distribuzione automatica del traffico da un singolo punto di ingresso a più server nel backend.
- Oracle SOA Suite
L'ambiente SOA viene configurato in base al documento standard Enterprise Deployment Guide for Oracle SOA Suite (EDG). Questa topologia copre molti componenti diversi che vengono spesso utilizzati in distribuzioni di grandi dimensioni e implementa suggerimenti per l'alta disponibilità che devono essere applicati prima di distribuire un sistema DR.
- Oracle Real Application Clusters (Oracle RAC)
Oracle RAC consente di eseguire un singolo Oracle Database su più server per ottimizzare la disponibilità e abilitare la scalabilità orizzontale, accedendo allo storage condiviso. Le sessioni utente che si connettono alle istanze di Oracle RAC possono eseguire il failover e replicare le modifiche in modo sicuro durante le indisponibilità, senza apportare modifiche alle applicazioni utente finali, nascondendo l'impatto delle indisponibilità degli utenti finali.
Questa architettura supporta i seguenti componenti nell'ambiente secondario in standby nell'infrastruttura OCI:
- Area
Un'area Oracle Cloud Infrastructure è un'area geografica localizzata contenente uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni e le grandi distanze possono separarle (tra paesi o addirittura continenti).
- Rete cloud virtuale (VCN) e subnet
Una VCN è una rete personalizzabile e definita dal software impostata dall'utente in un'area Oracle Cloud Infrastructure. Come le reti di data center tradizionali, le VCN offrono il controllo completo sull'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo aver creato la VCN. È possibile segmentare una VCN in subnet, che può essere definita in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono con le altre subnet nella VCN. Puoi modificare la dimensione di una subnet dopo la creazione. Una subnet può essere pubblica o privata.
Le subnet private sono generalmente consigliate per motivi di sicurezza, a meno che la risorsa non sia accessibile dalla rete Internet pubblica (se si accede a un load balancer dalla rete Internet pubblica, è necessario che si trovi in una subnet pubblica).
- Gateway di instradamento dinamico (DRG)
Il gateway DRG è un router virtuale che fornisce un percorso per il traffico di rete privato tra VCN nella stessa area, tra una VCN e una rete esterna all'area, ad esempio una VCN in un'altra area Oracle Cloud Infrastructure, una rete on premise o una rete in un altro provider cloud.
- FastConnect
Oracle Cloud Infrastructure FastConnect offre un modo semplice per creare una connessione dedicata e privata tra il tuo data center e Oracle Cloud Infrastructure. FastConnect fornisce opzioni di larghezza di banda più elevata e un'esperienza di rete più affidabile rispetto alle connessioni basate su Internet.
- Lista di sicurezza
Per ogni subnet, puoi creare regole di sicurezza che specificano l'origine, la destinazione e il tipo di traffico che devono essere consentiti all'interno e all'esterno della subnet.
- Tabella di instradamento
Le tabelle di instradamento virtuale contengono regole per instradare il traffico dalle subnet alle destinazioni esterne a una VCN, in genere tramite i gateway.
- Load balancer
Il servizio Oracle Cloud Infrastructure Load Balancing fornisce la distribuzione automatica del traffico da un singolo punto di accesso a più server nel back-end.
- Cloud Guard
Puoi utilizzare Oracle Cloud Guard per monitorare e gestire la sicurezza delle tue risorse in Oracle Cloud Infrastructure. Cloud Guard utilizza ricette del rilevatore che è possibile definire per esaminare le risorse per individuare eventuali punti deboli della sicurezza e per monitorare operatori e utenti per determinate attività rischiose. Quando viene rilevata una configurazione errata o un'attività non sicura, Cloud Guard consiglia azioni correttive e aiuta a eseguire tali azioni, in base alle ricette dei rispondenti che è possibile definire.
- Sistema DB
Oracle Database System è un servizio di database Oracle Cloud Infrastructure (OCI) che consente di creare, ridimensionare e gestire database Oracle completi. Il sistema DB utilizza lo storage dei volumi a blocchi OCI anziché lo storage locale e può eseguire Oracle Real Application Clusters (Oracle RAC) per migliorare la disponibilità.
- Servizio Oracle Cloud Infrastructure File Storage
Il servizio Oracle Cloud Infrastructure File Storage fornisce un file system di rete di livello Enterprise duraturo, scalabile, sicuro. Puoi connetterti a un file system del servizio di storage di file da qualsiasi istanza Bare Metal, Virtual Machine o container nella tua rete VCN. Il servizio di storage di file supporta il protocollo Network File System versione 3.0 (NFSv3). Il servizio supporta il protocollo NLM (Network Lock Manager) per la funzionalità di blocco dei file.
Oracle Cloud Infrastructure File Storage utilizza lo storage replicato a 5 vie, situato in domini di errore diversi, per fornire ridondanza per la protezione dei dati resiliente. I dati sono protetti con codifica di cancellazione. Il servizio di storage di file è progettato per soddisfare le esigenze di applicazioni e utenti che richiedono un file system di livello Enterprise in una vasta gamma di casi d'uso.
- Oracle Cloud Infrastructure Block Volumes
Il servizio Oracle Cloud Infrastructure Block Volumes consente di eseguire il provisioning e la gestione dinamici dei volumi di storage a blocchi. Puoi creare, collegare, connettere e spostare volumi nonché apportare le modifiche necessarie alle prestazioni dei volumi per soddisfare i requisiti a livello di storage, prestazioni e applicazioni. Dopo aver collegato e connesso un volume a un'istanza, puoi utilizzare il volume come un normale disco fisso.
- Sistema DB Oracle RAC
Oracle Real Application Clusters (Oracle RAC) consente ai clienti di eseguire un singolo Oracle Database su più server per ottimizzare la disponibilità e abilitare la scalabilità orizzontale accedendo allo storage condiviso. Le sessioni utente che si connettono alle istanze di Oracle RAC possono eseguire il failover e replicare le modifiche in modo sicuro durante le indisponibilità, senza apportare modifiche alle applicazioni utente finali, nascondendo l'impatto delle indisponibilità degli utenti finali. La struttura High Availability di Oracle RAC gestisce la disponibilità dei servizi memorizzando le informazioni di configurazione di ogni servizio in Oracle Cluster Registry (OCR).
Il sistema DB Oracle RAC si trova a livello di database.
- Data Guard
Oracle Data Guard offre un set completo di servizi che consentono di creare, gestire, gestire e monitorare uno o più database in standby per consentire ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database in standby come copie del database di produzione. Quindi, se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può passare da un database in standby al ruolo di produzione riducendo al minimo i tempi di inattività associati all'indisponibilità.
Descrizione topologia
Nel livello di database, i database primari e secondari vengono configurati con Oracle Data Guard. Con Oracle Data Guard, tutte le modifiche applicate al database primario vengono replicate nel database secondario (in standby).
Il livello intermedio secondario viene installato sulle virtual machine (VM) OCI. I file binari Oracle Fusion Middleware e il dominio SOA sono una replica dei file binari e del dominio SOA del dominio primario, utilizzando il servizio Oracle Cloud Infrastructure File Storage come soluzione di file system di rete e Oracle Cloud Infrastructure Block Volumes come soluzione di file system di accesso privato al nodo. Gli alias del nome host primario vengono utilizzati anche come indirizzi del listener dei server WebLogic nell'ambiente secondario. Nella posizione secondaria gli alias dei nomi host vengono risolti con gli indirizzi IP degli host secondari.
Il livello Web nel data center primario segue il modello EG (Enterprise Deployment Guide) con due host Oracle HTTP Server e un load balancer (LBR). La stessa topologia viene distribuita nel sistema secondario utilizzando un load balancer OCI e gli host Oracle HTTP Server installati nelle istanze di computazione OCI. Nel sistema secondario, puoi implementare il livello Web in alternativa solo con un load balancer OCI, che offre la maggior parte delle funzioni necessarie per la topologia di distribuzione Enterprise. Entrambe le opzioni, solo Load Balancer OCI o Load Balancer OCI e gli host Oracle HTTP Server, sono incluse in questo documento.
Viene configurato un indirizzo front-end univoco per accedere alle applicazioni in esecuzione nel sistema. Il nome del frontend virtuale punta all'IP del load balancer sul sito primario. In uno switchover, il nome frontend viene aggiornato nel DNS per puntare all'IP del load balancer OCI sul sito secondario. Deve sempre puntare all'IP del load balancer del sito che dispone del ruolo primario.
Durante la normale operazione aziendale, il database di standby è un database di standby fisico. L'elemento si trova nello stato di MOUNT o viene aperto in modalità di sola lettura quando si utilizza Active Data Guard. Il database in standby riceve e applica redo dal database primario, ma non può essere aperto in modalità di lettura-scrittura. Oracle Data Guard replica automaticamente le informazioni che risiedono nel database al sito secondario, inclusi gli schemi SOA (Server Oriented Architecture), le informazioni di Oracle Platform Security Services, gli schemi personalizzati, i log delle transazioni (TLOG), le aree di memorizzazione persistenti JDBC (Java Database Connectivity) e molto altro ancora.
Durante i passi di impostazione DR e convalida del ciclo di vita descritti in questo documento, è possibile convertire il database in standby da uno standby fisico a uno standby snapshot per convalidare il sito secondario senza eseguire uno switchover completo. Un database in modalità standby snapshot è un database completamente aggiornabile. Un database in standby snapshot riceve e archivia, ma non applica, i dati redo ricevuti da un database primario. Tutte le modifiche applicate a un database in standby snapshot vengono eliminate quando vengono convertite in un database in standby fisico.
La configurazione del dominio WebLogic deve essere replicata dal sito primario al sito secondario. Questa replica è necessaria ed eseguita durante l'impostazione iniziale della riconfigurazione dinamica, ed è inoltre necessaria durante il ciclo di vita del sistema in corso. Quando vengono eseguite modifiche alla configurazione nel dominio primario, queste devono essere replicate nella posizione secondaria.
Quando un database in standby viene arrestato durante il normale funzionamento aziendale, non riceve aggiornamenti dal database primario e potrebbe diventare non sincronizzato. Poiché questo può causare una perdita di dati in uno scenario di switchover, si sconsiglia di arrestare il database in standby durante il normale funzionamento aziendale. È possibile arrestare gli host di livello intermedio in standby. Tuttavia, quando gli host in standby vengono arrestati, le modifiche di configurazione replicate dal sito primario non verranno sottoposte a PUSH nel dominio secondario. In questo caso, quando si verifica uno switchover, l'obiettivo del tempo di recupero (RTO) viene aumentato da quando gli host di livello intermedio in standby devono essere avviati e il dominio deve essere sincronizzato con le modifiche principali.
Considerazioni per la topologia
Di seguito sono riportate le ipotesi di topologia più pertinenti prese in considerazione in questa configurazione.
- Il sistema primario è un ambiente in locale esistente
L'ambiente include un database Oracle Real Application Clusters (Oracle RAC), host di livello intermedio e un load balancer. L'impostazione del sistema in locale non rientra nell'ambito di questo documento.
- Il sistema secondario si trova in Oracle Cloud Infrastructure (OCI)
Il sistema secondario viene creato ex novo su OCI e fornisce una versione Oracle Cloud del sistema on-premise. Si tratta di un sistema Oracle Cloud completamente standard che consente di diventare il sistema primario.
- Oracle SOA Suite e componenti
Questo documento è incentrato sul sistema Oracle SOA Suite, inclusi i relativi componenti. Ad esempio, Oracle Service Bus, Oracle Business Process Management, Oracle Enterprise Scheduler Service e molto altro ancora. Sebbene le procedure e i suggerimenti contenuti nel presente documento possano essere applicati ad altri componenti di Oracle Fusion Middleware che non fanno parte di Oracle SOA Suite (ad esempio Web Center e Business Intelligence), le specifiche e la supportabilità di tali componenti sono escluse da questo esercizio.
- I sistemi primario e secondario sono simmetrici
Il sistema secondario ha lo stesso numero di nodi nel livello intermedio, nel livello Web e nel livello DB. Il livello del livello Web può presentare differenze quando il load balancer OCI viene utilizzato da solo in OCI (senza Oracle HTTP Server).
- I sistemi primari e secondari utilizzano risorse simili
Sebbene le forme OCI disponibili possano non corrispondere agli stessi valori esatti nella CPU e nella memoria della configurazione primaria esistente, è necessario utilizzare le forme più simili. Oracle consiglia di utilizzare sistemi simmetrici che forniscano una potenza di elaborazione simile al sistema primario. Altrimenti, potrebbero verificarsi problemi di prestazioni e errori in cascata quando il carico di lavoro viene trasferito al sistema OCI.
Considerazioni per la rete
- Connettività tra la rete in locale e Oracle Cloud Infrastructure (OCI)
I database in locale e OCI devono comunicare tra loro tramite Oracle SQL*Net Listener (porta 1521) per il trasporto Oracle Data Guard
redo. Gli host di livello intermedio in locale e OCI devono comunicare tra loro utilizzando la porta SSH (per le copiersync). Oracle consiglia di utilizzare la comunicazione Oracle Cloud Infrastructure FastConnect tra il data center on premise e l'area geografica OCI. Oracle Cloud Infrastructure FastConnect offre connettività e larghezza di banda sicure dedicate, con latenza prevedibile, jitter e costi. In alternativa, puoi usare la VPN da sito a sito che fornisce anche una connettività sicura tra le soluzioni on premise e OCI. Tuttavia, ciò garantisce una larghezza di banda inferiore e latenza variabile, jitter e costi. - Disabilita la connettività tra gli host di livello intermedio e il database remoto
Si prevede che gli host di livello intermedio non si connetteranno mai al database remoto durante il runtime. La latenza tra OCI e on premise in genere sconsiglia questa cross connect. Per evitare connessioni accidentali e problemi relativi al carico di lavoro, impedire la connettività dagli host di livello intermedio al database remoto.
- Nomi host virtuali
Come procedura ottimale, si presuppone che il sistema in locale primario utilizzi i nomi host virtuali, anziché il nome host del nodo fisico, come indirizzi di ascolto per Oracle WebLogic Server. I nomi host virtuali sono in genere alias del nome host del nodo fisico. L'uso di nomi host virtuali facilita lo spostamento delle configurazioni su host diversi, ma non è obbligatorio. La configurazione in questo documento funziona purché i server secondari in OCI possano utilizzare i nomi host utilizzati come indirizzi di ascolto primari come alias in ogni nodo (come risolto in DNS o
/etc/hostslocale). - Un IP virtuale è obbligatorio solo per l'indirizzo di ascolto del server di amministrazione
La migrazione automatica dei servizi è supportata e consigliata per la funzione High Availability (HA) locale, pertanto i server gestiti non devono utilizzare indirizzi IP virtuali. Solo il server di amministrazione richiede un VIP per il failover locale. Come procedura ottimale, si presuppone che il server di amministrazione nel sistema in locale primario ascolti in un indirizzo VIP. Questo documento fornisce istruzioni per la configurazione di un VIP per il server di amministrazione in OCI. Tuttavia, questo indirizzo VIP non è un requisito difficile per la configurazione di Disaster Recovery su OCI con questo documento. Se il server di amministrazione principale non ascolta un VIP, è possibile saltare questo punto.
- Load balancer
Un load balancer frontend (LBR, front-end Load Balancer) viene utilizzato nell'ambiente in locale primario e un load balancer OCI viene utilizzato nell'ambiente in standby.
- Indirizzo frontend virtuale
Il sistema primario deve utilizzare un nome di frontend virtuale (un URL univoco, ad esempio mysoa.example.com) come punto di ingresso per i client. Questo nome frontend viene risolto nel DNS con l'indirizzo IP del load balancer primario. In una topologia DR il sistema secondario è configurato per utilizzare lo stesso nome front-end virtuale. Quando si verifica uno switchover o un failover per il sistema secondario, il nome frontend virtuale viene modificato nel DNS in modo da puntare all'indirizzo IP del load balancer secondario. In questo modo, l'accesso dai client al sistema è indipendente dal sito utilizzato come primario. Lo stesso vale per qualsiasi nome di front-end virtuale utilizzato nel sistema. Ad esempio, è possibile utilizzare un nome front-end aggiuntivo, ad esempio
admin.example.com, per accedere alle funzioni di amministrazione per la console di amministrazione di Oracle WebLogic Server o la console di Fusion Middleware Control.È possibile utilizzare un nome front-end separato, ad esempio
osb.example.com, per accedere ai servizi Oracle Service Bus. Questo documento utilizza un nome host front-end per semplificarlo.
Considerazioni sullo storage
- Struttura delle directory basata su EDG
Questo documento utilizza una struttura di directory Enterprise Deployment Guide (EDG) per la configurazione del dominio Oracle WebLogic Server del sistema primario. Il modello EDG utilizza directory di dominio separate per l'amministrazione di Oracle WebLogic Server e per ogni Oracle WebLogic Server gestito, come descritto in Preparazione del file system per una distribuzione Enterprise. La struttura di directory EDG viene utilizzata come riferimento negli esempi. Utilizza una combinazione di cartelle condivise e private, che copre più casi d'uso. Se il sistema non utilizza la struttura di directory EDG, adattare gli esempi per soddisfare le specifiche dell'ambiente.
- Considerazioni per lo storage in database primario (on premise)È consigliabile memorizzare non solo le cartelle condivise (directory di dominio del server di amministrazione Oracle WebLogic Server, home dei piani di distribuzione, runtime condiviso e così via), ma anche i file binari della home di Oracle Fusion Middleware e le configurazioni locali (directory di dominio del server gestito, cartella Node Manager) nella memoria NFS nella posizione primaria. Ciò facilita la copia dal database primario al database in standby. Sebbene ogni host utilizzerà i propri file binari e la propria configurazione locale in modo privato (volumi NFS separati per ciascun server), la copia della configurazione tra i siti è più semplice se questi risiedono in una memorizzazione condivisa. Utilizzando questo approccio, è possibile eseguirne il MOUNT da un nodo univoco ed eseguire la copia rsync sui nodi remoti in un'unica operazione. Senza questo approccio, la copia deve avvenire singolarmente, da ogni nodo primario che memorizza i dati in modo privato.
Nota:
Gli script forniti per la copiarsyncdi questi sono abbastanza flessibili da poter essere adattati in ogni caso. - Considerazioni per le cartelle condivise nella secondaria (OCI)
Le cartelle che devono essere condivise tra gli host di livello intermedio (ad esempio, la directory di dominio del server di amministrazione Oracle WebLogic Server, la home dei piani di distribuzione, il runtime condiviso e così via) devono essere memorizzate nella memoria condivisa. OCI fornisce Oracle Cloud Infrastructure File Storage come soluzione di file system di rete.
Gli artifact diversi sono cartelle condivise e hanno un uso e un ciclo di vita diversi. Devono essere collocati in una memoria condivisa separata, in base al suo utilizzo. Ad esempio:- La configurazione condivisa (ad esempio, la directory del dominio del server di amministrazione WebLogic Server, home dei piani di distribuzione) è accessibile principalmente dall'host del server di amministrazione. L'accesso viene eseguito in modo residuo dal resto degli host (per i piani di distribuzione, i keystore condivisi e così via). Deve essere posizionato in un file system Oracle Cloud Infrastructure File Storage.
- Se il sistema utilizza una cartella condivisa per gli artifact runtime, ad esempio i file creati e letti dall'applicazione, in genere viene utilizzata contemporaneamente da tutti gli host di livello intermedio. È necessario posizionare gli artifact di runtime in un altro file system Oracle Cloud Infrastructure File Storage o in un accesso DBFS (Database File System).
- Considerazioni sull'archiviazione di cartelle private nell'OCI secondaria
I file binari FMW e le configurazioni locali vengono utilizzati da ciascun host singolarmente. È consigliabile memorizzarle nella memoria esterna anziché nel volume di avvio predefinito degli host.
- In OCI, puoi memorizzare i binari FMW in Oracle Cloud Infrastructure Block Volumes per ogni host. Quando sono presenti più di due host di livello intermedio, è consigliabile utilizzare le home binarie condivise ridondanti (vedere Guida ad alta disponibilità). Per fare ciò, usa Oracle Cloud Infrastructure File Storage per memorizzare i file binari FMW.
- È possibile memorizzare la configurazione locale (ad esempio, le directory di dominio del server gestito WebLogic e la cartella Node Manager) in Oracle Cloud Infrastructure Block Volumes perché è previsto che vengano utilizzate privatamente da ciascun host. In alternativa, puoi utilizzare i file system Oracle Cloud Infrastructure File Storage di cui è stato eseguito il MOUNT in modalità privata da ogni nodo.
Per agevolare la copia dal sito primario al sito remoto, è possibile eseguire il MOUNT dei file di storage da un nodo univoco ed eseguire la copiarsyncin una singola operazione (per i volumi a blocchi, un altro host può eseguire il MOUNT dei file in modalità di sola lettura). In alternativa, la copia può essere eseguita singolarmente, da ognuno dei nodi che memorizza i dati in modo privato.Nota:
Gli script forniti per la copiarsyncdi questi sono abbastanza flessibili da poter essere adattati in ogni caso. - Replica di storage
Non esiste alcuna replica diretta a livello di storage tra ambienti on premise e OCI. La copia dei file binari e della configurazione da primario a standby viene eseguita con
rsyncsu Secure Shell (SSH) tramite una connessione privata su Oracle Cloud Infrastructure FastConnect o VPN da sito a sito (non utilizzare mai la rete Internet pubblica). La copia degli artifact di configurazione e runtime può essere basata anche su DBFS, a seconda delle esigenze del cliente. Ulteriori dettagli su questo argomento sono forniti successivamente. - WebLogic aree di memorizzazione persistenti
Si suppone che le aree di memorizzazione persistenti WebLogic utilizzate per i messaggi TLOGS e JMS siano aree di memorizzazione persistenti JDBC e siano memorizzate nelle tabelle di database. In questo modo, le aree di memorizzazione persistenti sono accessibili da qualsiasi membro del cluster (per fornire l'alta disponibilità locale con la migrazione dei servizi). Questa operazione sfrutta inoltre il Oracle Data Guard di base, che replica automaticamente TLOGS e JMS nel sito secondario.
Considerazioni per il database
Considerare quanto riportato di seguito durante la configurazione dei database.
- Multi-tenancy
Il database primario deve essere un database multi-itenant (CDB/PDB). È necessario configurare una Oracle Data Guard ibrida in Oracle Cloud Infrastructure.
- Livelli patch
La Oracle home per il database in locale deve essere allo stesso livello di patch del database in standby.
- Cifratura dei dati trasparente
Utilizzare Transparent Data Encryption (TDE) per i database primari e in standby per garantire che tutti i dati siano cifrati. Se il database in locale non è già abilitato con TDE, è consigliabile eseguire la conversione in TDE prima di configurare Oracle Data Guard per fornire l'ambiente più sicuro.
- Elevata disponibilità
Per ottenere l'alta disponibilità locale a livello di database e seguire la topologia EDG, utilizzare Oracle Real Application Clusters (Oracle RAC) sia per i database primari che per quelli in standby. Sebbene si concentri su Oracle RAC, questa procedura è applicabile a un singolo database. Tuttavia, si consiglia di utilizzare Oracle RAC per ottenere l'alta disponibilità locale nel livello DB.
- Servizio di database
Il livello intermedio on premise primario deve utilizzare un servizio di database delle applicazioni per la connessione al database primario.
- Sistema di database Oracle Cloud Infrastructure (OCI)
Utilizzare un sistema DB OCI (bare metal, virtual machine o Oracle Exadata Database Service) come database di standby. Un Oracle Autonomous Database, condiviso o dedicato, non rientra nell'ambito di questo documento. Non fornisce le funzioni necessarie per l'impostazione del recupero da errori irreversibili ibridi, come la possibilità di configurare Oracle Data Guard con un database in locale e la conversione dello snapshot in standby.
- Alias TNS nelle stringhe di connessione al database WebLogic
Questo documento utilizza un alias TNS per definire la stringa di connessione al database nella configurazione di Oracle WebLogic. L'alias TNS viene risolto con un file
tnsnames.ora, diverso in ogni sito e punta al database locale. Poiché lo stesso nome alias viene utilizzato nel nome principale e nel nome secondario, non è necessario modificare la configurazione WebLogic dopo averla replicata dal nome principale al nome secondario.Se il database primario non utilizza già questo approccio, è necessaria una configurazione iniziale monouso. I dettagli sono descritti più avanti in questo documento.
Considerazioni per Identity Management
- LDAP (Lightweight Directory Access Protocol)
Il sistema può utilizzare un LDAP esterno per l'autenticazione (ad esempio, Oracle Unified Directory), purché il protocollo LDAP esterno sia raggiungibile sia dal sistema primario che da quello in standby.
- Soluzione di ripristino di emergenza per LDAP
La soluzione di disaster recovery per qualsiasi servizio LDAP esterno non rientra nell'ambito del presente documento e dovrebbe essere fornita dallo specifico prodotto LDAP. La soluzione DR per LDAP deve fornire un modo univoco di accedervi (in genere un nome host virtuale), che non viene modificato in presenza di uno switchover nel sistema LDAP.
Riepilogo considerazioni
Di seguito viene fornito un riepilogo di ciò che è necessario considerare quando si pianifica una soluzione di disaster recovery.
| Considerazioni per | Riepilogo | Obbligatorio o altamente consigliato |
|---|---|---|
| Topologia | Il sistema primario è un ambiente in locale esistente. | Altamente consigliato |
| Topologia | Il sistema secondario è disponibile su Oracle Cloud Infrastructure (OCI) e viene creato da zero su OCI. | Obbligatorio |
| Topologia | I sistemi primario e secondario sono simmetrici e hanno lo stesso numero di nodi in db-tier, mid-tier e web-tier. | Obbligatorio |
| Topologia | Il livello Web primario consiste in un load balancer che si trova davanti a Oracle HTTP Server. | Altamente consigliato |
| Topologia | I sistemi primario e secondario utilizzano risorse simili (CPU, memoria e così via). | Obbligatorio |
| Rete | Utilizza OCI FastConnect per la connettività tra la VPN on premise e OCI, in alternativa la VPN da sito a sito. Mai internet pubblica. | Obbligatorio |
| Rete | Disabilita la connettività tra gli host di livello intermedio e il database remoto. Necessario solo se Oracle Database File System (DBFS) viene utilizzato per la replica della configurazione. | Altamente consigliato |
| Rete | Utilizzare i nomi host virtuali per gli indirizzi di ascolto del server WebLogic. | Altamente consigliato |
| Rete | IP virtuale per il server di amministrazione. | Altamente consigliato |
| Rete | Indirizzo front-end virtuale. | Obbligatorio |
| Memoria | Struttura di directory basata su EDG. | Altamente consigliato |
| Memoria | Cartelle private e condivise in locale nello storage esterno in modo che possano essere montate da un nodo univoco per centralizzare le operazioni rsync. | Altamente consigliato |
| Memoria | Configurazione condivisa OCI in Oracle Cloud Infrastructure File Storage. | Obbligatorio |
| Memoria | Runtime condiviso OCI in OCI File Storage o Oracle Database File System (DBFS). | Obbligatorio |
| Memoria | Cartelle dei file binari FMW OCI nello storage dei file OCI con MOUNT privato. | Altamente consigliato |
| Memoria | Configurazioni locali OCI in Oracle Cloud Infrastructure Block Volumes (in alternativa OCI File Storage attivato in modo privato). | Altamente consigliato |
| Memoria | Attivazione DBFS nell'area intermedia (solo quando viene utilizzata la replica basata su DBFS per la configurazione). | Altamente consigliato |
| Memoria | Replica dello storage basata su rsync (o DBFS per alcuni artifact specifici, ad esempio la configurazione).
|
Altamente consigliato |
| Memoria | WebLogic aree di memorizzazione persistenti (TLOGS, JMS) nelle aree di memorizzazione persistenti JDBC. | Obbligatorio (*se le informazioni JMS sono rilevanti) |
| Database | Il livello di patch del database in locale è uguale al database in standby. | Obbligatorio |
| Database | Transparent Data Encryption (TDE) per i database primari e in standby. Se il database in locale non è già abilitato con TDE, è consigliabile eseguire la conversione in TDE prima di configurare Oracle Data Guard. | Obbligatorio |
| Database | Oracle RAC Database per l'alta disponibilità locale. | Altamente consigliato |
| Database | Database multi-tenancy primario. | Obbligatorio |
| Database | Utilizzare un servizio di database dell'applicazione, non il servizio di amministrazione predefinito, per connettersi al database. | Obbligatorio |
| Database | In OCI, utilizzare il sistema DB (BM, VM o Oracle Exadata Database Service), non Oracle Autonomous Database. | Obbligatorio |
| Database | Alias TNS nelle stringhe di connessione al database WebLogic. | Altamente consigliato |
| Gestione identità | Il sistema può utilizzare un LDAP esterno per l'autenticazione (ad esempio, Oracle Unified Directory), purché il protocollo LDAP esterno sia raggiungibile sia dal sistema primario che da quello in standby. | Obbligatorio (l'utilizzo di LDAP esterno NON è obbligatorio, ma se utilizzato deve essere raggiungibile da entrambi i siti) |
| Gestione identità | La soluzione di disaster recovery per qualsiasi servizio LDAP esterno non rientra nell'ambito del presente documento e dovrebbe essere fornita dallo specifico prodotto LDAP. La soluzione DR per LDAP deve fornire un modo univoco per accedervi (di solito un nome host virtuale), che non cambia quando è presente uno switchover nel sistema LDAP. | Obbligatorio. L'utilizzo di LDAP esterno NON è obbligatorio, ma se utilizzato e protetto da DR deve fornire un indirizzo di accesso virtuale che rimane invariato quando si verifica uno switchover/failover per la modalità di accesso LDAP. |
Informazioni sui servizi e i ruoli necessari
Questa soluzione richiede i servizi e i ruoli riportati di seguito.
Si tratta dei ruoli necessari per ogni servizio.
| Nome servizio: ruolo | Obbligatorio per... |
|---|---|
Oracle Cloud Infrastructure: administrator |
Crea le risorse necessarie nella tenancy OCI: compartimento, sistema DB, istanze di computazione, risorse FSS e load balancer. |
Rete: administrator
|
Configura le risorse di rete necessarie sia in locale che in OCI: Fast Connect, VCN e subnet in OCI, regole di sicurezza della rete e regole di instradamento. |
Oracle Data Guard: root, oracle e sysdba |
Configura Oracle Data Guard tra OCI principale in locale e in standby ed esegui le conversioni dei ruoli. |
Oracle Database: sysdba |
Gestire i database. |
Oracle WebLogic Server: root, oracle |
Configurare gli host di livello intermedio in base alle esigenze: eseguire la configurazione a livello di sistema operativo, aggiungere alias host, gestire gli indirizzi IP virtuali e installare i file system. |
Oracle WebLogic Server: Weblogic Administrator |
Gestire Oracle WebLogic Server: arrestare, avviare e applicare le modifiche alla configurazione WebLogic. |
Per ottenere i servizi cloud necessari, vedere https://docs.oracle.com/pls/topic/lookup?ctx=en/solutions/soa-dr-on-cloud&id=GCSSL.