Configurare una soluzione DR ibrida per Oracle WebLogic Server
Operazioni 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 WebLogic Server 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 eseguendo il provisioning delle immagini di Oracle WebLogic Server for OCI e non dello stack di Oracle WebLogic Server for OCI (sono previste limitazioni nelle versioni del sistema operativo, negli utenti del sistema operativo e nella struttura di directory che impediscono agli stack di Oracle WebLogic Server for OCI di funzionare correttamente come standby per un sistema in locale).
Il livello di database nel sito OCI è un sistema DB Oracle Real Application Clusters (Oracle RAC).
Descrizione dell'immagine maa-wls-hybrid-dr.png
Questa architettura supporta i seguenti componenti del data center principale in locale:
- Rete in locale
Questa è la rete locale utilizzata dall'organizzazione. È uno dei portavoce della topologia.
- Load balancer
Fornisce la distribuzione automatica del traffico da un singolo punto di accesso a più server nel backend.
- Oracle WebLogic Server
Il dominio Oracle WebLogic Server è un ambiente High Availability configurato secondo le procedure ottimali standard MAA per High Availability.
- Oracle Real Application Clusters (Oracle RAC)
Oracle RAC 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 in modo sicuro le modifiche durante le indisponibilità, senza apportare modifiche alle applicazioni utente finali, nascondendo l'impatto delle indisponibilità da parte degli utenti finali.
Questa architettura supporta i seguenti componenti nell'ambiente di standby secondario su OCI:
- 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 grandi distanze possono separarle (tra paesi o addirittura continenti).
- Rete cloud virtuale (VCN) e subnet
Una VCN è una rete personalizzabile definita dal software che si imposta in un'area Oracle Cloud Infrastructure. Analogamente alle reti di data center tradizionali, i VCN offrono il controllo completo sull'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che puoi 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. 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 DRG è un router virtuale che fornisce un percorso per il traffico privato della rete 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 in locale 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 fornisce opzioni a 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 deve essere consentito 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 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 backend.
- 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 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 in modo sicuro le modifiche durante le indisponibilità, senza apportare modifiche alle applicazioni utente finali, nascondendo l'impatto delle indisponibilità 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 si 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. Successivamente, se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può passare qualsiasi database in standby al ruolo di produzione, riducendo al minimo il tempo di inattività associato all'indisponibilità.
Descrizione topologia
Nel livello database, 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 (in standby).
Il livello intermedio secondario viene installato sulle istanze di computazione OCI, che possono essere immagini Oracle WebLogic Server for Oracle Cloud Infrastructure per sfruttare la licenza di abilitazione WebLogic inclusa in queste immagini. I file binari Oracle Fusion Middleware e il dominio Oracle WebLogic sono una replica dei file binari e del dominio primario, utilizzando i servizi 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 del nome host primario vengono utilizzati anche come indirizzi listener di Oracle WebLogic Server 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, incluse 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 principale a quella secondaria. Questa replica è necessaria ed eseguita durante l'impostazione iniziale della funzionalità DR ed è anche necessaria durante il ciclo di vita del sistema. Quando vengono eseguite modifiche alla configurazione nel dominio primario, è necessario replicarle nella posizione secondaria.
Quando un database in standby viene chiuso durante le normali operazioni aziendali, non riceve gli aggiornamenti dal database primario e potrebbe diventare non sincronizzato. Poiché questo può comportare una perdita di dati in uno scenario di switchover, non è consigliabile 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, non verrà eseguito il push delle modifiche alla configurazione replicate dal sito primario nel dominio secondario. In questo caso, quando si verifica uno switchover, l'obiettivo RTO (Recovery Time Objective) viene aumentato poiché è necessario avviare gli host di livello intermedio in standby e sincronizzare il dominio con le modifiche primarie.
Considerazioni per la topologia
Di seguito sono riportate le ipotesi topologiche più rilevanti considerate in questa impostazione.
- 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 su 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.
- 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 primario e secondario 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 sulla 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 on-premise e OCI in genere sconsiglia questa cross connectectivity. Per evitare connessioni accidentali e problemi del carico di lavoro, precludere 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 è richiesto 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 front-end virtuale
Il sistema primario deve utilizzare un nome di frontend virtuale (un URL univoco, ad esempio wlsfrontend.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.
Considerazioni sulla memorizzazione
- 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 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 dello 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 i sistemi operativi
Le immagini Oracle WebLogic Server for Oracle Cloud Infrastructure supportano i sistemi operativi Oracle Linux 7.9 e Oracle Linux 8.5.
Le istanze di computazione di livello intermedio e Web devono utilizzare l'immagine del sistema operativo e la forma di computazione più simili all'immagine e alla forma utilizzate dagli host on premise. Quando si utilizza WebLogic Server per le immagini OCI, la soluzione è limitata alla versione del sistema operativo in uso (in questo momento Oracle Linux 7.X o 8.X).
- Versioni del sistema operativo per gli host di livello intermedio
Un Oracle WebLogic Server in esecuzione su Oracle Cloud Infrastructure (OCI) deve essere coperto con un contratto di licenza e supporto valido oltre al contratto di licenza e supporto utilizzato per coprire Oracle WebLogic Server in esecuzione on-premise. In Oracle Cloud, è possibile creare le istanze di computazione con le immagini Oracle WebLogic Server for OCI. Le istanze di computazione create con queste immagini includono l'abilitazione per eseguire Oracle WebLogic Server e vengono fatturate per OCPU/ora quando sono in stato di esecuzione. Queste immagini sono disponibili per i sistemi operativi Oracle Linux 7.9 e Oracle Linux 8.5.
- Versioni del sistema operativo per gli host a livello Web
È necessario che un Oracle HTTP Server in esecuzione in OCI sia coperto da un contratto di licenza e supporto valido oltre al contratto di licenza e supporto utilizzato per coprire Oracle HTTP Server in esecuzione in locale. In Oracle Cloud, è possibile creare istanze di computazione con le immagini Oracle WebLogic Server for OCI. Le istanze di computazione create con queste immagini includono l'abilitazione per eseguire Oracle HTTP Server e vengono fatturate su base OCPU/ora per l'abilitazione all'esecuzione del software WebLogic quando sono in stato di esecuzione. Queste immagini sono disponibili per i sistemi operativi Oracle Linux 7.9 e Oracle Linux 8.5.
Considerazioni per Oracle WebLogic Server
Quando si implementa questa soluzione, tenere presente quanto riportato di seguito.
- Prodotti sopra Oracle WebLogic Server
Gli ambienti con prodotti aggiuntivi installati sopra Oracle WebLogic Server possono trarre vantaggio dalle procedure descritte in questa guida, ma le specifiche di altri prodotti non rientrano nell'ambito di applicazione di questo documento.
- Oracle WebLogic Server Edizione
Questo documento può essere applicato a Oracle WebLogic Suite Edition e a Oracle WebLogic Server Enterprise Edition. Quando invece il database è un database Oracle Real Application Clusters (Oracle RAC) (procedura consigliata per ottenere l'alta disponibilità locale), questo documento presuppone che venga utilizzata l'edizione Oracle WebLogic Suite perché Oracle WebLogic Server Enterprise Edition non include l'abilitazione all'uso delle origini dati Active GridLink.
- Domini WebLogic abilitati per JRF
Questo documento si applica ai domini con i componenti JRF (Java Required Files) abilitati e i domini di base.
I domini abilitati per JRF hanno più dipendenze nel database rispetto ai domini di base. Per questo motivo, un modello di disaster recovery (DR) progettato per il dominio abilitato per JRF presenta più vincoli. I domini di base hanno una maggiore flessibilità in termini di recupero da errori irreversibili (DR), ma un modello DR valido per un dominio di base potrebbe non essere valido per un dominio abilitato per JRF perché non considera le dipendenze del database JRF WebLogic. Un modello DR valido per un dominio abilitato per JRF è valido anche per un dominio di base. Il modello descritto in questo documento si basa su domini abilitati per JRF, pertanto si applica a entrambi i tipi di domini Oracle WebLogic.
Considerazioni per il database
Quando si configurano i database, tenere presente quanto riportato di seguito.
- Multi-tenancy
Il database primario deve essere un database multi-tenant (CDB/PDB). È necessario configurare un Oracle Data Guard ibrido 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.
- Alta 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 primario in locale deve utilizzare un servizio di database dell'applicazione per connettersi 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 Disaster Recovery 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 per accedervi (di solito un nome host virtuale), che non cambia quando è presente 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. |
Nella tabella riportata di seguito vengono riepilogate le considerazioni relative al sistema operativo e a Oracle WebLogic oltre alle considerazioni riportate nella tabella precedente.
| Considerazioni per | Riepilogo | Obbligatorio o altamente consigliato |
|---|---|---|
| Sistema operativo | Versioni del sistema operativo di livello intermedio on-premise Oracle Linux 7 o 8 | Altamente consigliato (per sfruttare le immagini di Oracle WebLogic Server for OCI) |
| Sistema operativo | Versioni del sistema operativo a livello Web in locale Oracle Linux 7 o 8 | Altamente consigliato (per sfruttare le immagini di Oracle WebLogic Server for OCI) |
| Oracle WebLogic Server | Solo software WebLogic. Altri prodotti che non rientrano nell'ambito di applicazione del documento | n/d |
| Oracle WebLogic Server | Oracle WebLogic Suite Edition se si utilizza Oracle RAC, per utilizzare le origini dati GridLink | Obbligatorio |
| Oracle WebLogic Server | WebLogic Domini abilitati per JRF e non abilitati per JRF | n/d (entrambi sono validi) |
Informazioni sui servizi e i ruoli necessari
Questa soluzione richiede i servizi e i ruoli riportati di seguito.
Questi sono i ruoli necessari per ogni servizio.
| Nome servizio: ruolo | Richiesto 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 della 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 degli 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. |
Scopri come ottenere i servizi Oracle Cloud per le soluzioni Oracle per ottenere i servizi cloud di cui hai bisogno.