Configurare una soluzione DR ibrida per Oracle SOA Suite

Operazioni preliminari

Prima di iniziare a distribuire una soluzione di disaster recovery (DR) ibrida per il sistema Oracle SOA Suite, assicurarsi di avere familiarità con le best practice di High Availability su rete, storage e host impostate per i sistemi Oracle WebLogic Server on-premise.

Il sistema Oracle WebLogic Server utilizzato in questo documento è un ambiente High Availability configurato in base alle procedure ottimali standard MAA descritte nel manuale Enterprise Deployment Guide for Oracle SOA Suite (EDG) per i sistemi Fusion Middleware. Sebbene non tutti gli scenari seguano questa topologia esatta nei dettagli, questa copre molti componenti e combinazioni diversi, viene utilizzata frequentemente in implementazioni di grandi dimensioni e implementa suggerimenti di alta disponibilità che devono essere applicati prima di distribuire un sistema di disaster recovery (DR). Pertanto, è considerato il miglior esempio di riferimento di un sistema primario per una soluzione DR ibrida per Oracle WebLogic Server. In base a ciò, si consiglia vivamente di familiarizzare con le best practice di implementazione di Oracle WebLogic Server High Availability ed Enterprise per la configurazione di reti, storage e host prima di distribuire un sistema ibrido.

Consultare gli argomenti riportati di seguito per ulteriori dettagli.

Oracle Fusion Middleware High Availability Guide
Oracle Fusion Middleware Enterprise Deployment Guide per Oracle SOA Suite
Oracle Fusion Middleware Guide alla distribuzione Enterprise in Best practice MAA - Oracle Fusion Middleware

Assicurati di avere familiarità anche con i concetti e l'amministrazione di Oracle Cloud Infrastructure.

Architettura

Questa architettura mostra l'ambiente del data center primario on-premise con un sistema in standby su Oracle Cloud Infrastructure (OCI). Utilizza questa architettura per una soluzione di disaster recovery (DR) ibrida per l'ambiente Oracle SOA Suite on-premise.

Il sistema primario è un sistema Oracle SOA Suite che si trova in locale. Il sistema 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 on premise.

Il livello intermedio su OCI viene creato installando SOA sulle virtual machine (VM) OCI e non un'istanza di Oracle SOA Cloud Service o Oracle SOA Suite on Marketplace (sono previste limitazioni nelle versioni del sistema operativo, negli utenti del sistema operativo e nella struttura di directory che impediscono l'utilizzo corretto dell'istanza di Oracle SOA Cloud Service o Oracle SOA Suite on Marketplace come istanza di standby per un sistema on premise).

Il livello di database nel sito OCI è un sistema DB Oracle Real Application Clusters (Oracle RAC).

Descrizione dell'immagine maa-soa-hybrid-dr.png

maa-soa-ibrido-dr-oracle.zip

Questa architettura supporta i componenti riportati di seguito nel data center primario in locale.

Rete in locale
Questa rete è la rete locale utilizzata dall'organizzazione. È uno dei raggi della topologia.
Load balancer
Fornisce una distribuzione automatica del traffico da un singolo punto di accesso a più server nel back-end.
Oracle SOA Suite
L'ambiente SOA viene configurato in base al manuale standard Enterprise Deployment Guide for Oracle SOA Suite (EDG). Questa topologia copre molti componenti diversi che vengono spesso utilizzati in implementazioni 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 ti consente di eseguire un singolo Oracle Database su più server per massimizzare la disponibilità e abilitare la scalabilità orizzontale, accedendo allo storage condiviso. Le sessioni utente che si connettono alle istanze Oracle RAC possono eseguire il failover e ripetere le modifiche in modo sicuro durante le interruzioni, senza apportare modifiche alle applicazioni dell'utente finale, nascondendo l'impatto delle interruzioni da parte degli utenti finali.

Questa architettura supporta i seguenti componenti nell'ambiente secondario in standby su OCI:

Area
Un'area geografica 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 grandi distanze possono separarle (tra paesi o addirittura continenti).
Rete cloud virtuale (VCN) e subnet
Una VCN è una rete personalizzabile e definita dal software configurata in un'area Oracle Cloud Infrastructure. Come le tradizionali reti di data center, le reti VCN offrono un controllo completo sull'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo aver creato la VCN. Puoi 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 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 debba essere accessibile dalla rete Internet pubblica (se si accede a un load balancer dalla rete Internet pubblica, tale risorsa deve trovarsi 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 le reti VCN nella stessa area, tra una rete VCN e una rete esterna all'area, ad esempio una rete 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 consente di creare facilmente una connessione dedicata e privata tra il data center e Oracle Cloud Infrastructure. FastConnect offre opzioni per una maggiore larghezza di banda 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 virtuali contengono regole per instradare il traffico dalle subnet alle destinazioni esterne a una VCN, in genere attraverso i gateway.
Load balancer
Il servizio Oracle Cloud Infrastructure Load Balancing fornisce la distribuzione automatica del traffico da un unico 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 ti consente di creare, ridimensionare e gestire database Oracle completi di tutte le funzionalità. 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 di Oracle Cloud Infrastructure File Storage
Il servizio Oracle Cloud Infrastructure File Storage offre 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 cloud virtuale (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 uno storage replicato a 5 vie, situato in domini di errore diversi, per fornire ridondanza per una protezione dei dati resiliente. I dati sono protetti con la codifica della cancellazione. Il servizio di storage di file è progettato per soddisfare le esigenze di applicazioni e utenti che necessitano di un file system aziendale in una vasta gamma di casi d'uso.
Oracle Cloud Infrastructure Block Volumes
Il servizio Oracle Cloud Infrastructure Block Volumes ti consente di eseguire il provisioning e gestire dinamicamente i volumi di storage a blocchi. Puoi creare, collegare, connettere e spostare volumi, nonché modificare le prestazioni dei volumi, se necessario, per soddisfare i requisiti di storage, prestazioni e applicazioni. Dopo aver collegato e connesso un volume a un'istanza, puoi utilizzare il volume come un normale disco rigido.
Sistema DB Oracle RAC
Oracle Real Application Clusters (Oracle RAC) consente ai clienti di eseguire un singolo Oracle Database su più server, al fine di ottimizzare la disponibilità e garantire la scalabilità orizzontale, pur accedendo allo storage condiviso. Le sessioni utente che si connettono alle istanze Oracle RAC possono eseguire il failover e ripetere le modifiche in modo sicuro durante le interruzioni, senza apportare modifiche alle applicazioni dell'utente finale, nascondendo l'impatto delle interruzioni da parte 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 nel livello di database.
Data Guard
Oracle Data Guard offre un set completo di servizi che creano, mantengono, gestiscono e monitorano 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 diventa non disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può passare qualsiasi database di standby al ruolo di produzione, riducendo al minimo i tempi di inattività associati all'indisponibilità.

Descrizione topologia

La topologia DR ibrida di Oracle SOA Suite utilizza un modello attivo-passivo. Il sistema primario si trova in un data center on-premise e il sistema secondario si trova su Oracle Cloud Infrastructure (OCI). Le reti on premise e OCI sono interconnesse con Oracle Cloud Infrastructure FastConnect (preferito) o VPN da sito a sito.

Nel livello db, i database primario e secondario vengono configurati con Oracle Data Guard. Con Oracle Data Guard, tutte le modifiche applicate al database primario vengono replicate nel database secondario (standby).

Il livello intermedio secondario viene installato sulle virtual machine (VM) OCI. I file binari di Oracle Fusion Middleware e il dominio SOA sono una replica dei file binari e del dominio SOA del database primario, che utilizza 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 del nodo. Gli alias dei nomi host del primario vengono utilizzati anche come indirizzi del listener del 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 Enterprise Deployment Guide (EDG) 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, in alternativa, puoi implementare il livello Web solo con un load balancer OCI, che fornisce la maggior parte delle funzioni richieste dalla topologia di distribuzione aziendale. Entrambe le opzioni, solo OCI Load Balancer o OCI Load Balancer e gli host Oracle HTTP Server, sono incluse in questo documento.

Un indirizzo front-end univoco viene configurato per accedere alle applicazioni in esecuzione nel sistema. Il nome frontend virtuale punta all'IP del load balancer sul sito primario. In uno switchover, il nome front-end viene aggiornato nel DNS per puntare all'IP del load balancer OCI nel sito secondario. Deve sempre puntare all'IP del load balancer del sito che ha il ruolo primario.

Durante il normale funzionamento aziendale, il database di standby è in standby fisico. È in stato di MOUNT oppure è aperto in modalità di sola lettura quando si utilizza Active Data Guard. Il database di 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 presenti nel database nel 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 altro ancora.

Durante i passi di impostazione e convalida del ciclo di vita DR descritti nel presente documento, è possibile convertire il database di 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 di standby snapshot riceve e archivia, ma non si applica, i dati redo ricevuti da un database primario. Tutte le modifiche applicate a uno standby snapshot vengono ignorate quando vengono convertite in uno standby fisico.

La configurazione del dominio WebLogic deve essere replicata dal sito primario al secondario. Questa replica è necessaria ed eseguita durante l'impostazione iniziale del DR ed è necessaria anche durante il ciclo di vita continuo del sistema. Quando le modifiche alla configurazione vengono eseguite nel dominio primario, devono essere replicate nella posizione secondaria.

Quando un database di standby viene chiuso durante la normale operazione business, non riceve aggiornamenti dal database primario e potrebbe non essere sincronizzato. Poiché ciò può comportare una perdita di dati in uno scenario di switchover, non è consigliabile arrestare il database di standby durante la normale operazione aziendale. È possibile arrestare gli host di livello intermedio in standby. Tuttavia, quando gli host in standby vengono arrestati, le modifiche alla configurazione replicate dal sito primario non verranno sottoposte a push nel dominio secondario. In questo caso, quando si verifica uno switchover, l'obiettivo RTO (Recovery Time Objective) viene aumentato poiché gli host di livello intermedio in standby devono essere avviati e il dominio deve essere sincronizzato con le modifiche primarie.

Considerazioni per la topologia

Di seguito sono riportate le ipotesi di topologia più rilevanti prese in considerazione in questa impostazione.

Il sistema primario è un ambiente on premise 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 su Oracle Cloud Infrastructure (OCI)
Il sistema secondario viene creato da zero su OCI e fornisce una versione Oracle Cloud del sistema on-premise. Si tratta di un sistema Oracle Cloud completamente standard con la possibilità 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 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 Web può presentare differenze quando OCI Load Balancer viene utilizzato da solo in OCI (senza Oracle HTTP Server).
I sistemi primari e secondari utilizzano risorse simili
Sebbene le forme OCI disponibili potrebbero 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 standby simmetrici che forniscono una potenza di elaborazione simile a quella del sistema primario. In caso contrario, i problemi di prestazioni e gli errori in cascata potrebbero verificarsi quando il carico di lavoro viene trasferito al sistema OCI.

Considerazioni per la rete

Durante la configurazione della rete, tenere presente quanto riportato di seguito.

Connettività tra la rete on-premise e Oracle Cloud Infrastructure (OCI)
I database on-premise 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 on premise e OCI devono comunicare tra loro utilizzando la porta SSH (per le copie rsync). 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, jitter e costi prevedibili. In alternativa, puoi utilizzare la VPN da sito a sito, che fornisce anche una connettività sicura tra on premise e OCI. Tuttavia, ciò fornisce una larghezza di banda inferiore e latenza variabile, jitter e costi.
Disabilita la connettività tra host di livello intermedio e database remoto
Si prevede che gli host di livello intermedio non si connetteranno mai al database remoto durante il runtime. La latenza tra on-premise e OCI in genere scoraggia questa cross connectvità. Per evitare connessioni accidentali e problemi di carico di lavoro, precludere la connettività dagli host di livello medio al database remoto.
nomi host virtuali
Come best practice, si presume che il sistema on premise primario utilizzi 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; tuttavia, questo non è un requisito obbligatorio. La configurazione in questo documento funziona finché i server secondari in OCI possono utilizzare i nomi host utilizzati come indirizzi di ascolto nel database primario come alias in ogni nodo (come risolto in DNS o /etc/hosts locale).
Un IP virtuale è richiesto solo per l'indirizzo di ascolto del server di amministrazione
La migrazione automatica dei servizi è supportata e consigliata per l'High Availability (HA) locale, ovvero i server gestiti non sono tenuti a utilizzare gli indirizzi IP virtuali. Solo il server di amministrazione richiede un VIP per il failover locale. Come best practice, si presume che il server di amministrazione nel sistema locale principale 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 essenziale per la configurazione di Disaster Recovery su OCI con questo documento. Se il server di amministrazione principale non ascolta in un VIP, è possibile saltare questo punto.
Load balancer
Un load balancer front-end (LBR) viene utilizzato nell'ambiente on-premise primario e un load balancer OCI viene utilizzato nell'ambiente in standby.
Indirizzo front-end virtuale
Il sistema primario deve utilizzare un nome frontend virtuale (un URL univoco, ad esempio mysoa.example.com) come punto di accesso per i client. Questo nome front-end viene risolto nel DNS con l'indirizzo IP del load balancer primario. In una topologia DR, il sistema secondario viene configurato per utilizzare lo stesso nome frontend virtuale. Quando si verifica uno switchover o un failover per il sistema secondario, il nome frontend virtuale viene modificato nel DNS per puntare all'indirizzo IP del load balancer secondario. In questo modo, l'accesso dai client al sistema è indipendente dal sito utilizzato come principale. Lo stesso vale per qualsiasi nome 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 frontend separato, ad esempio osb.example.com, per accedere ai servizi Oracle Service Bus. Questo documento utilizza un solo nome host front-end per semplificare l'operazione.

Considerazioni sullo storage

Durante la configurazione dello storage, tenere presente quanto riportato di seguito.

Struttura di 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 sullo storage nel database primario (on-premise)
È consigliabile memorizzare non solo le cartelle condivise (directory del dominio di Oracle WebLogic Server Admin 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 del dominio del server gestito, cartella di Node Manager) nello storage NFS nella posizione primaria. Ciò facilita la copia dal database primario al database in standby. Sebbene ciascun host utilizzi privatamente i propri file binari e la propria configurazione locale (volumi NFS separati per ciascun server), la copia della configurazione tra i siti è più semplice se questi risiedono nello storage condiviso. Utilizzando questo approccio, è possibile eseguirne il MOUNT da un nodo univoco ed eseguire la copia rsync sui nodi remoti in una singola operazione. Senza questo approccio, la copia deve avvenire individualmente, da ciascuno dei nodi primari che memorizzano i dati in privato.

Nota
Gli script forniti per la copia rsync di questi sono abbastanza flessibili da essere adattati in ogni caso.
Considerazioni per le cartelle condivise nel secondario (OCI)
Le cartelle che devono essere condivise tra gli host di livello intermedio (ad esempio, la directory del 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 uno spazio condiviso separato, in base al loro utilizzo. Ad esempio:
- La configurazione condivisa (ad esempio, la directory del dominio del server di amministrazione WebLogic Server, la home dei piani di distribuzione) è accessibile principalmente dall'host del server di amministrazione. Vi si accede abitualmente dal resto degli host (per i piani di distribuzione, i keystore condivisi e così via). Questo deve essere inserito in un file system di Oracle Cloud Infrastructure File Storage.
- Se il sistema utilizza un artifact di cartella condivisa per il runtime (ad esempio, file creati e letti dall'applicazione), in genere viene utilizzato contemporaneamente da tutti gli host di livello intermedio. È necessario posizionare gli artifact di runtime in un altro file system di Oracle Cloud Infrastructure File Storage o in un MOUNT DBFS (Database File System).
Considerazioni per la memorizzazione delle cartelle private nel secondario (OCI)
I file binari FMW e le configurazioni locali vengono utilizzati da ciascun host singolarmente. È consigliabile memorizzarli su uno storage esterno 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 del dominio del server gestito WebLogic e la cartella Node Manager) in Oracle Cloud Infrastructure Block Volumes perché dovrebbero essere utilizzate privatamente da ciascun host. In alternativa, puoi utilizzare i file system di Oracle Cloud Infrastructure File Storage attivati privatamente da ciascun nodo.
Per facilitare la copia dal sito primario al sito remoto, è possibile eseguire il MOUNT dei file di storage da un nodo univoco ed eseguire la copia rsync in 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 ciascuno dei nodi che memorizzano i dati privatamente.

Nota
Gli script forniti per la copia rsync di questi sono abbastanza flessibili da essere adattati in ogni caso.
Replica dello storage
Non esiste alcuna replica diretta a livello di storage tra on premise e OCI. La copia dei file binari e della configurazione dal database primario al database in standby viene eseguita con rsync tramite 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ò inoltre essere basata su DBFS, a seconda delle esigenze del cliente. Ulteriori dettagli su questo argomento verranno forniti in seguito.
WebLogic aree di memorizzazione persistenti
Si presume 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 ad HA locale la migrazione dei servizi). Ciò sfrutta anche Oracle Data Guard di base, che replica automaticamente TLOGS e JMS nel sito secondario.

Considerazioni per il database

Durante la configurazione dei database, tenere presente quanto riportato di seguito.

Multitenancy
Il database primario deve essere un database multi-tenant (CDB/PDB). Ciò è necessario per configurare un Oracle Data Guard ibrido in Oracle Cloud Infrastructure.
Livelli patch
La Oracle home per il database in locale deve avere lo stesso livello di patch del database in standby.
Cifratura dei dati trasparente
Utilizza la Cifratura dei dati trasparente (TDE) sia per i database primari che per quelli in standby per garantire che tutti i dati siano cifrati. Se il database in locale non è già abilitato con TDE, si consiglia di eseguire la conversione in TDE prima di configurare Oracle Data Guard per fornire l'ambiente più sicuro.
High Availability
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 sia incentrata su Oracle RAC, questa procedura è applicabile a un singolo database. Tuttavia, la procedura consigliata consiste nell'utilizzare Oracle RAC per ottenere l'alta disponibilità locale nel livello DB.
Servizio di database
Il livello intermedio in locale primario deve utilizzare un servizio di database delle applicazioni per connettersi al database primario.
Sistema di database Oracle Cloud Infrastructure (OCI)
Utilizza 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 una serie di funzioni necessarie per l'impostazione del disaster recovery ibrido, come la possibilità di configurare Oracle Data Guard con un database in locale e una conversione di standby snapshot.
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 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 primario e nel nome secondario, non è necessario modificare la configurazione WebLogic dopo averla replicata dal nome primario al nome secondario.

Se il principale non utilizza già questo approccio, è necessaria un'impostazione iniziale una tantum. I dettagli al riguardo sono descritti più avanti in questo documento.

Considerazioni per Identity Management

Durante la configurazione di Identity Management, tenere presente quanto riportato di seguito.

LDAP (Lightweight Directory Access Protocol)
Il sistema può utilizzare un LDAP esterno per l'autenticazione (ad esempio, Oracle Unified Directory), purché il LDAP esterno sia raggiungibile sia dai sistemi primario che in standby.
Soluzione di disaster recovery per LDAP
La soluzione di disaster recovery per qualsiasi servizio LDAP esterno non rientra nell'ambito di questo documento e deve essere fornita dal prodotto LDAP specifico. La soluzione DR per LDAP deve fornire un modo univoco di accesso a tale soluzione (in genere un nome host virtuale), che non cambia in caso di 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 on premise esistente.	Altamente consigliato
Topologia	Il sistema secondario si trova su Oracle Cloud Infrastructure (OCI) 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 principale è costituito da un load balancer di fronte 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 on-premise e OCI, in alternativa VPN da sito a sito. Mai internet pubblico.	Obbligatorio
Rete	Disabilitare la connettività tra gli host di livello intermedio e il database remoto. Necessario solo se per la replica della configurazione viene utilizzato il file system (DBFS) di Oracle Database.	Altamente consigliato
Rete	Usare 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
Memorizzazione	Struttura di directory basata su EDG.	Altamente consigliato
Memorizzazione	Cartelle private e condivise in locale nello storage esterno in modo che possano essere installate da un nodo univoco per centralizzare le operazioni rsync.	Altamente consigliato
Memorizzazione	Configurazione condivisa OCI in Oracle Cloud Infrastructure File Storage.	Obbligatorio
Memorizzazione	Runtime condiviso OCI in OCI File Storage o Oracle Database File System (DBFS).	Obbligatorio
Memorizzazione	Le cartelle binari FMW OCI nello storage di file OCI sono state installate privatamente.	Altamente consigliato
Memorizzazione	Configurazioni locali OCI in Oracle Cloud Infrastructure Block Volumes (in alternativa, OCI File Storage attivato privatamente).	Altamente consigliato
Memorizzazione	Accesso DBFS temporaneo (solo quando viene utilizzata la replica basata su DBFS per la configurazione).	Altamente consigliato
Memorizzazione	Replica dello storage basata su `rsync` (o DBFS per alcuni artifact specifici come la configurazione).	Altamente consigliato
Memorizzazione	WebLogic aree di memorizzazione persistenti (TLOGS, JMS) nelle aree di memorizzazione persistenti JDBC.	Obbligatorio (*se le informazioni JMS sono rilevanti)
Database	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	Database Oracle RAC 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
Identity Management	Il sistema può utilizzare un LDAP esterno per l'autenticazione (ad esempio, Oracle Unified Directory), purché il LDAP esterno sia raggiungibile sia dai sistemi primario che in standby.	Obbligatorio (l'utilizzo di LDAP esterno NON è obbligatorio, ma se utilizzato deve essere raggiungibile da entrambi i siti)
Identity Management	La soluzione di disaster recovery per qualsiasi servizio LDAP esterno non rientra nell'ambito di questo documento e deve essere fornita dal prodotto LDAP specifico. La soluzione DR per LDAP deve fornire un modo univoco di accesso a tale soluzione (in genere un nome host virtuale), che non cambia in caso di switchover nel sistema LDAP.	Obbligatorio (l'utilizzo di LDAP esterno NON è obbligatorio, ma se utilizzato ed è protetto da DR, deve fornire un indirizzo di accesso virtuale che rimane invariato quando si verifica uno switchover/failover per il modo LDAP di accedervi).

Informazioni sui servizi e sui ruoli richiesti

Questa soluzione richiede i seguenti servizi e ruoli:

Questi sono i ruoli necessari per ogni servizio.

Nome servizio: Ruolo	Obbligatorio per...
Oracle Cloud Infrastructure: `administrator`	Creare 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 di rete e regole di instradamento.
Oracle Data Guard: `root`, `oracle` e `sysdba`	Configura Oracle Data Guard tra OCI in locale e in standby primario ed esegui 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 eseguire il MOUNT dei 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.