Introduzione
La configurazione in questo playbook utilizza un singolo dominio Oracle WebLogic Server in cui i server in due siti partecipano allo stesso cluster (noto come cluster esteso) e si basano su Data Guard per fornire protezione per il database.
In OCI, funzioni come la gestione del traffico, i controlli dello stato, i load balancer, le viste private DNS e i gateway di instradamento dinamico forniscono funzionalità avanzate per supportare questa impostazione. Per gli ambienti on-premise, è necessario utilizzare componenti di rete e infrastruttura equivalenti per soddisfare questi requisiti.
La latenza di rete tra i siti o le aree deve essere sufficientemente bassa per ridurre al minimo la penalità sulle prestazioni introdotta dal ritardo nei richiami e per evitare incongruenze durante la distribuzione e il runtime. Oracle supporta questa topologia solo quando la latenza tra i server WebLogic e il database è inferiore al tempo di andata e ritorno (RTT) di 10 ms.
Per ottenere prestazioni e comportamenti di failover ottimali, Oracle consiglia di analizzare ogni applicazione in esecuzione in un cluster esteso WebLogic e modificare di conseguenza i diversi parametri discussi in questo playbook (timeout, configurazione di replica delle sessioni, leasing di migrazione dei servizi, JTA (Java Transaction API) e così via).
Informazioni su Oracle Fusion Middleware Stretched Clusters
Fornire l'architettura di massima disponibilità (MAA, Maximum Availability Architecture) di Oracle è uno dei requisiti chiave per qualsiasi implementazione aziendale Oracle Fusion Middleware.
Oracle Fusion Middleware include un ampio set di funzioni ad alta disponibilità, come il rilevamento e il riavvio dei processi, il clustering dei server, la migrazione dei servizi, GridLink, il bilanciamento del carico, il failover, il backup e il ripristino, gli aggiornamenti in sequenza e le modifiche alla configurazione in sequenza, che proteggono una distribuzione aziendale da tempi di inattività non pianificati e riducono al minimo i tempi di inattività pianificati. Queste funzioni offrono una soluzione locale ad alta disponibilità all'interno di un singolo data center.
Inoltre, le applicazioni richiedono protezione da disastri imprevisti, calamità naturali e tempi di inattività che possono influire su un intero data center. La maggior parte dei sistemi di protezione da calamità tradizionali utilizza il modello attivo-passivo che prevede la creazione di un sito in standby in una posizione geografica diversa rispetto al sito di produzione. Questo modello viene generalmente adottato quando la latenza tra i siti è elevata e non consente il clustering tra i due siti. Questo approccio offre una protezione MAA (Maximum Availability Architecture) completa. Tuttavia, si traduce in costi operativi e amministrativi aggiuntivi, perché il sistema middleware standby rispecchia il sistema primario e richiede una replica continua. Questo modello è descritto nel manuale Oracle Fusion Middleware Disaster Recovery Guide.
In questo playbook viene descritto un altro modello: il modello attivo-attivo basato su cluster estesi di Oracle Fusion Middleware, che può essere utilizzato per proteggere un sistema Oracle Fusion Middleware dai tempi di inattività in più posizioni. Questo modello utilizza una configurazione attiva-attiva per il livello intermedio, mentre il livello di database utilizza una configurazione attiva-passiva con Data Guard. È progettato per ottimizzare la capacità e distribuire i carichi di lavoro tra i siti. Utilizza le risorse in modo più efficace rispetto al modello attivo-passivo utilizzando tutte le risorse disponibili anziché lasciare inattive le macchine in standby. Questo modello viene definito Distribuzione di cluster estesi FMW.
In particolare, questo playbook si concentra su come implementare questo modello nelle aree geografiche di Oracle Cloud Infrastructure (OCI). Vengono forniti i passi di configurazione per l'impostazione della topologia e le indicazioni sulle implicazioni relative alle prestazioni e al failover di questa impostazione.
I risultati e gli esempi riportati in questo playbook si basano su un sistema Oracle SOA Suite 14.1.2 che segue l'architettura di Enterprise Deployment Guide. Questo è un esempio significativo perché include molte funzioni come i componenti Jakarta standard, la replica delle sessioni HTTP, la persistenza dei metadati del database, un cluster Coherence e sia le aree di memorizzazione persistenti JMS (Java Message Service) che JTA (Java Transaction API), tra le altre considerazioni pertinenti per i cluster estesi. Di conseguenza, la topologia e i suggerimenti descritti possono essere applicati anche ad altri ambienti Oracle Fusion Middleware.
Terminologia
-
Mid-tier (anche livello intermedio o middleware)
Il livello intermedio si riferisce al livello all'interno di un'architettura applicativa a più livelli che si trova tra l'interfaccia utente (front-end) e lo storage dei dati (back-end). Gestisce la business logic, l'elaborazione dei dati e la sicurezza, fungendo da ponte tra l'utente e il database.
-
Oracle Fusion Middleware
Oracle Fusion Middleware è una famiglia completa di prodotti middleware aziendali di Oracle che consente alle organizzazioni di creare, distribuire e gestire le applicazioni in modo efficiente e sicuro. Include soluzioni per application server, integrazione, gestione dei processi aziendali, business intelligence, sicurezza, gestione delle identità, server Web e altro ancora.
-
Calamità
Evento catastrofico improvviso e non pianificato che provoca danni o perdite inaccettabili in un sito o in un'area geografica. Un disastro è un evento che compromette la capacità di un'organizzazione di fornire funzioni, processi o servizi critici per un periodo inaccettabile e induce l'organizzazione a invocare i propri piani di ripristino.
-
Disaster recovery
capacità di protezione da indisponibilità naturali o non pianificate in un luogo di produzione grazie all'uso di una strategia di ripristino per applicazioni e dati a una sede standby geograficamente separata.
-
Architettura di massima disponibilità Oracle
L'architettura Oracle Maximum Availability (Oracle MAA) è il progetto di best practice per la protezione e la disponibilità dei prodotti Oracle (Oracle Database, Oracle Fusion Middleware, Applications). L'implementazione delle best practice Oracle MAA è uno dei requisiti chiave per qualsiasi implementazione Oracle. Vengono forniti suggerimenti per l'impostazione e la gestione di un sistema Oracle. Oracle MAA include i suggerimenti di Oracle Fusion Middleware Enterprise Deployment Guide e aggiunge best practice per la protezione da calamità per ridurre al minimo i tempi di inattività pianificati e non per interruzioni che interessano un intero data center o un'intera area. Per i collegamenti alla documentazione correlata e ad altre risorse, vedere la sezione Esplora altro.
-
Sito (o centro dati)
Un sito è l'insieme di componenti diversi in un data center necessari per eseguire un gruppo di applicazioni. Ad esempio, un sito può essere costituito da istanze, database, storage e così via di Oracle Fusion Middleware.
-
Di sistema
Un sistema è un insieme di destinazioni (host, database, application server e così via) che funzionano insieme per ospitare le applicazioni. Ad esempio, per monitorare un'applicazione in Oracle Enterprise Manager, è innanzitutto necessario creare un sistema costituito dalle destinazioni database, listener, application server e host in cui viene eseguita l'applicazione.
-
Cluster esteso
Un cluster esteso si riferisce a un'architettura cluster in cui i nodi in un singolo cluster logico sono distribuiti tra data center o posizioni geograficamente separati.
-
Switchover
Lo switchover è il processo di inversione dei ruoli del sito di produzione e del sito in standby. Gli switchover sono operazioni pianificate eseguite per la convalida periodica o per eseguire la manutenzione pianificata nel sito di produzione corrente. Durante uno switchover, il sito in standby corrente diventa il nuovo sito di produzione e il sito di produzione corrente diventa il nuovo sito in standby. Questo playbook utilizza anche il termine switchover per fare riferimento a uno switchover del sito.
-
Switchback
Lo switchback è il processo di ripristino dei ruoli originali del sito di produzione corrente e del sito in standby corrente. Gli switchback sono operazioni pianificate eseguite dopo il completamento dell'operazione di switchover. Uno switchback ripristina i ruoli originali di ogni sito: il sito in standby corrente diventa il sito di produzione e il sito di produzione corrente diventa il sito in standby. Questo playbook utilizza anche il termine switchback per fare riferimento a uno switchback del sito.
-
Failover
Il failover è il processo di rendere il sito in standby corrente il nuovo sito di produzione dopo che il sito di produzione diventa inaspettatamente non disponibile a causa, ad esempio, di un disastro nel sito di produzione. Questo playbook utilizza anche il termine failover per fare riferimento a un failover del sito.
-
RPO (Recovery Point Obective)
L'obiettivo del punto di recupero è la quantità di perdita di dati che un sistema può tollerare da un punto di vista aziendale, ad esempio la quantità di perdita di dati accettabile quando si verifica un'interruzione.
-
RPO (Recovery Time ObJECT)
L'obiettivo del tempo di recupero è la quantità di tempo di inattività che un sistema può tollerare o la quantità accettabile di tempo in cui un'applicazione o un servizio può rimanere non disponibile quando si verifica un'interruzione, dal punto di vista aziendale.
- Infrastruttura Oracle Cloud
Oracle Cloud Infrastructure (OCI) è un set di servizi cloud complementari che ti consentono di creare ed eseguire una vasta gamma di applicazioni e servizi in un ambiente hosted ad alta disponibilità. OCI offre funzionalità di computazione ad alte prestazioni (come istanze hardware fisiche) e capacità di storage in una rete virtuale overlay flessibile accessibile in modo sicuro dalla tua rete on-premise.
-
Area OCI
Un'area geografica OCI è un'area geografica localizzata che contiene uno o più data center, che ospitano domini di disponibilità. Le regioni sono indipendenti da altre regioni e vaste distanze possono separarle (tra paesi o addirittura continenti).
Un'area è un sito in termini di disaster recovery.
- Dominio di disponibilità
I domini di disponibilità sono data center autonomi e indipendenti all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità sono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio alimentazione o raffreddamento, o la rete interna del dominio di disponibilità. Pertanto, un errore in un dominio di disponibilità non dovrebbe influire sugli altri domini di disponibilità nell'area.
- Rete e subnet cloud virtuale OCI
Una rete cloud virtuale (VCN, virtual cloud network) è una rete personalizzabile e definita dal software impostata in un'area OCI. Come le reti di data center tradizionali, le reti VCN ti danno il controllo sul tuo ambiente di rete. Una VCN può avere più blocchi CIDR (Classless Inter-Domain Routing) non sovrapposti che è possibile modificare dopo aver creato la VCN. È possibile segmentare una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. È possibile modificare le dimensioni di una sottorete dopo la creazione. Una subnet può essere pubblica o privata.
- 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 VCN e una rete esterna all'area, ad esempio una VCN in un'altra area OCI, una rete on premise o una rete in un altro provider cloud.
- DNS OCI
Il servizio DNS (Domain Name System) di Oracle Cloud Infrastructure è una rete DNS (Qualcast Domain Name System) altamente scalabile e globale che offre prestazioni, resilienza e scalabilità DNS ottimizzate, in modo che gli utenti finali si connettano rapidamente alle applicazioni Internet, da qualsiasi luogo.
-
Vista privata di DNS OCI
Una vista privata DNS OCI è una raccolta di una o più zone DNS private OCI, utilizzate per raggruppare logicamente le zone DNS e controllare la modalità di risoluzione. Una vista è collegata a un resolver DNS privato, che può essere il resolver predefinito per una rete cloud virtuale (VCN) o personalizzata. Ciò ti consente di gestire configurazioni DNS separate per ambienti o applicazioni diversi all'interno della tua VCN.
-
IP virtuale
Un indirizzo IP virtuale (VIP) si riferisce a un indirizzo IP che non è legato a una particolare interfaccia di rete fisica o dispositivo. Invece, è astratto e può muoversi tra i dispositivi o essere utilizzato per varie funzioni di rete.
-
Gestione del traffico OCI
OCI Traffic Management indirizza in modo intelligente il traffico degli utenti agli endpoint ottimali utilizzando criteri avanzati basati su DNS (OCI traffic steering policies). Consente alle organizzazioni di controllare il modo in cui vengono risolte le query DNS, ottimizzando l'instradamento delle richieste client per migliorare la disponibilità, le prestazioni e la resilienza delle applicazioni o dei servizi distribuiti su OCI o altrove.
-
Load balancer
Un load balancer è un sistema o un servizio che distribuisce il traffico di rete in entrata su più server per garantire alta disponibilità, affidabilità e prestazioni ottimali delle applicazioni.
-
Load balancer OCI
OCI Load Balancer è un servizio Oracle Cloud Infrastructure completamente gestito che distribuisce automaticamente il traffico in entrata su più server o risorse backend per garantire alta disponibilità, prestazioni migliori e scalabilità per le applicazioni.
-
Memorizzazione a blocchi
Lo storage a blocchi è un tipo di storage di dati in cui le informazioni vengono salvate in blocchi di dimensioni fisse e l'accesso può essere eseguito direttamente da server o applicazioni mediante protocolli di storage quali iSCSI o Fibre Channel.
- Volumi a blocchi OCI
Con Oracle Cloud Infrastructure Block Volumes, puoi creare, collegare, connettere e spostare volumi di storage e modificare le prestazioni dei volumi 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. Puoi anche disconnettere un volume e collegarlo a un'altra istanza senza perdere dati.
-
Storage condiviso
Lo storage condiviso si riferisce a un sistema di storage o a una risorsa a cui è possibile accedere contemporaneamente da più server, computer o applicazioni all'interno di un ambiente IT. Questa impostazione consente a tutti i sistemi partecipanti di leggere e scrivere nello stesso repository di dati, rendendolo ideale per scenari che richiedono coerenza, collaborazione, alta disponibilità e scalabilità dei dati.
- OCI File Storage
Oracle Cloud Infrastructure File Storage offre un file system di rete duraturo, scalabile, sicuro e di livello aziendale. Puoi connetterti allo storage di file OCI da qualsiasi istanza Bare Metal, virtual machine o container in una VCN. Puoi anche accedere allo storage di file OCI dall'esterno della VCN utilizzando Oracle Cloud Infrastructure FastConnect e IPSec VPN.
-
Servizi di database OCI
I servizi di database OCI fanno riferimento al portfolio di soluzioni di database gestiti fornite da Oracle Cloud Infrastructure (OCI). Questi servizi offrono una vasta gamma di opzioni di distribuzione e gestione del database in Oracle Cloud, supportando carichi di lavoro, esigenze di prestazioni e modelli di dati diversi, come Oracle Base Database Service e Oracle Exadata Database Service.
- Oracle Data Guard
Oracle Data Guard e Active Data Guard forniscono un set completo di servizi che creano, gestiscono, gestiscono e monitorano uno o più database in standby e che consentono ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database in standby come copie del database di produzione utilizzando la replica in memoria. Se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può sostituire qualsiasi database in standby con il ruolo di produzione riducendo al minimo i tempi di inattività associati all'indisponibilità. Oracle Active Data Guard offre la possibilità aggiuntiva di scaricare principalmente i carichi di lavoro di lettura sui database in standby e offre anche funzioni avanzate di protezione dei dati.
Questo playbook utilizza OCI come infrastruttura di esempio per la distribuzione di cluster estesi di Oracle Fusion Middleware. Queste sono le equivalenze da on-premise a OCI per i componenti principali richiesti per l'impostazione del cluster esteso di Oracle Fusion Middleware:
| On-premise (o generiche) | Equivalente OCI |
|---|---|
| Sito (o centro dati) | Area OCI |
| Storage condiviso (ad esempio, NFS) | OCI File Storage |
| Memorizzazione a blocchi | Volumi a blocchi OCI |
| Load balancer globale | Gestione del traffico OCI e criteri di indirizzamento |
| Load balancer locale | Load balancer OCI |
| Rete | Rete cloud virtuali OCI |
| Regole firewall/firewall | Regole di sicurezza della rete OCI |
| DNS interno | Vista privata di DNS OCI |
| Server fisico/virtual machine | Istanza di OCI Compute |
| Database on premise | Servizio di database OCI |
| Connettività in locale tra i siti | Peering remoto OCI con gateway di instradamento dinamico |
Architettura
Le considerazioni riportate di seguito si applicano all'architettura cluster estesa FMW.
- Aree
In questa topologia sono presenti due aree o siti. La latenza tra loro non deve essere superiore a 10 ms di tempo di andata e ritorno (RTT). I requisiti di larghezza di banda dipenderanno dai tipi di payload gestiti da ciascun sistema, ma si consiglia un minimo di 1 o 2 gigabit al secondo (Gbps).
- Livello intermedio
Il livello intermedio opera in un modello attivo-attivo, con un singolo dominio. La metà dei server gestiti viene distribuita in un sito, mentre il resto nell'altro. Il server di amministrazione viene eseguito in un sito ma, se necessario, può eseguire il failover sull'altro sito. Questa impostazione viene comunemente definita cluster esteso.
- Livello database
Il livello di database utilizza un'architettura attivo-passiva, supportata da Oracle Data Guard. Il database primario si trova in un sito, mentre il database in standby risiede nell'altro sito. Tutti i server di livello intermedio sono configurati in modo da connettersi al database attualmente utilizzato come primario, indipendentemente dalla posizione. L'Oracle Database configurato in ogni sito è un Oracle Real Application Clusters (Oracle RAC). Oracle RAC consente l'esecuzione di un database Oracle in un cluster di server garantendo tolleranza degli errori, prestazioni e scalabilità senza necessità di apportare modifiche all'applicazione.
- Memoria
Lo storage condiviso è locale per ogni sito. Per motivi di contesa e sicurezza, non è consigliabile utilizzare lo storage condiviso tra i siti. Si consiglia di eseguire il mirroring o la replica del disco da site1 a site2 e viceversa per fornire una copia recuperabile degli artifact in ogni sito.
- Aree di memorizzazione persistenti
Le aree di memorizzazione persistenti WebLogic (Java Message Service (JMS) e Java Transaction API (JTA)) sono configurate come aree di memorizzazione JDBC (Java Database Connectivity) all'interno del database. In questo modo, sono raggiungibili da entrambi i siti. Ciò consente alla funzione Migrazione automatica del servizio di funzionare tra entrambi i siti.
- Inoltro richieste
I server Web di ogni sito inoltrano richieste solo alle istanze di Oracle WebLogic Server situate all'interno dello stesso sito. Nessuna comunicazione tra più aree tra i server Web (istanze Oracle HTTP Server) e i server WebLogic nell'altro sito per ridurre al minimo la latenza e il traffico tra più aree.
- Load balancer
Ogni sito ha un proprio load balancer dedicato, che indirizza le richieste esclusivamente ai server Web all'interno di quel sito locale. Nessuna comunicazione tra più aree tra i load balancer e i server Web situati nell'altro sito.
- Accesso front-end
Di fronte al sistema, la soluzione fornisce un unico accesso front-end al sistema. I clienti si connettono utilizzando un unico indirizzo che rimane lo stesso, indipendentemente dal sito a cui sono indirizzati. Questo meccanismo offre un nome DNS (Domain Name System) accessibile a tutti i client e instrada le richieste a entrambi i siti in base a criteri e regole predefiniti, come la posizione geografica del client.
Il diagramma riportato di seguito illustra la topologia dei cluster estesa di Oracle Fusion Middleware
stretched-cluster-topologia-oracle.zip
Il diagramma riportato di seguito illustra il dominio e i cluster WebLogic nella topologia dei cluster estesa di Oracle Fusion Middleware.
Vantaggi
- Amministrazione semplificata
Le distribuzioni attivo-passivo comportano un sovraccarico amministrativo aggiuntivo per mantenere sincronizzata la configurazione tra il sito primario e il sito in standby. Sebbene la maggior parte delle informazioni di runtime e dei metadati si trovi nel database, la configurazione di Oracle WebLogic Server risiede nel file system. Pertanto, oltre alla replica di Oracle Data Guard per il database, il modello attivo-passivo richiede una replica continua del file system, che può essere implementata in vari modi (rsync, replica a livello di storage e così via).
Nel modello di cluster estesi FMW, tuttavia, l'infrastruttura di Oracle WebLogic Server mantiene la configurazione sincronizzata su più nodi nello stesso dominio. La maggior parte di questa configurazione risiede in genere nella directory del dominio del server di amministrazione. Questa configurazione viene propagata automaticamente agli altri nodi nello stesso dominio all'avvio dei server gestiti o quando viene implementata una modifica. Per questo motivo, il sovraccarico amministrativo della distribuzione è molto ridotto rispetto a qualsiasi approccio attivo-passivo, in cui è richiesta una replica costante delle modifiche alla configurazione.
- Maggiore disponibilità e riduzione di RTO e RPO per alcuni scenari di failover
Il modello di cluster esteso FMW fornisce un recovery point objective (RPO) e un recovery time objective (RTO) migliori rispetto al modello attivo-passivo in questi scenari:
- Completamento errore livello intermedio in un evento sito
Se tutti i server di livello intermedio in un'unica posizione non riescono, il sistema può continuare a soddisfare immediatamente le richieste con i server di livello intermedio nel sito peer. RTO e RPO sono zero in questo tipo di scenario.
Per raggiungere questo obiettivo, i server di livello intermedio nella posizione alternativa devono essere in grado di sostenere il carico di lavoro combinato delle due posizioni. Per tenere conto di tali scenari, è necessario eseguire un'adeguata pianificazione della capacità. A seconda della progettazione, potrebbe essere necessario limitare le richieste dei client finali quando è attivo un solo sito. In caso contrario, i siti devono essere progettati con capacità estensiva, sconfiggendo parzialmente lo scopo di un utilizzo costante ed efficiente della capacità.
- Errori negli eventi di livello del database
Uno switchover del database comporta gli stessi RTO e RPO in un modello di cluster esteso attivo-passivo e FMW. L'RTO complessivo del sistema, tuttavia, è inferiore nel modello di cluster allungato perché i server di livello medio sono già attivi nel sito secondario. Non è necessario riavviare i livelli intermedi. Una configurazione di origine dati appropriata, che utilizza una stringa di connessione doppia con notifiche GridLink e FAN (Fast Application Notification), automatizza il failover delle connessioni al database dai livelli intermedi, riducendo l'RTO del sistema.
- Completamento errore livello intermedio in un evento sito
Considerazioni
- Pianificazione della capacità
Questo modello richiede la pianificazione della capacità per tenere conto degli scenari di failover tra i due siti. Se un intero sito perde i livelli intermedi, l'altro deve essere in grado di sostenere l'intero carico di lavoro. In caso contrario, il sito disponibile potrebbe non rispondere a causa del sovraccarico. Ciò significa che durante il normale funzionamento, i nodi di livello intermedio devono essere sottoutilizzati per consentire una capacità sufficiente per gestire gli scenari di failover. La stessa regola si applica al livello Web. Se un sito perde tutti i suoi server web, i server web dell'altro sito devono essere in grado di gestire tutte le richieste di sistema.
- Throughput di rete tra i siti
Il throughput di rete dipende principalmente da due cose: quanto sono lontani i siti e quanto bene la rete gestisce l'affidabilità e la congestione. Non importa quanto siano veloci i server o il software, c'è un limite alla velocità di spostamento dei dati tra i siti. Due fattori importanti che influenzano questo sono latenza e jitter:
-
Latenza è il tempo necessario affinché i dati si spostino attraverso la rete da un sito all'altro. Può essere misurato unidirezionale (dalla fonte alla destinazione) o un andata e ritorno (ci e indietro). Il tempo di andata e ritorno (RTT) è più comune e può essere controllato con il comando
ping. -
Jitter è la variazione del tempo necessario per l'arrivo dei pacchetti di dati.
Per il modello corrente, mantenere la latenza bassa è particolarmente importante, poiché il jitter di solito conta solo quando la latenza è già molto bassa. Pertanto, il controllo della latenza è la priorità principale per ottenere buone prestazioni in questo tipo di configurazione. La distanza è in genere la causa più rilevante della latenza.
I test condotti hanno dimostrato che le prestazioni in questo modello (dove alcune istanze di Oracle WebLogic Server nel cluster si trovano in un sito diverso dal database) peggiorano notevolmente quando la latenza (RTT) supera i 10 millisecondi.
Oracle ha eseguito più test con diverse configurazioni interessate da latenze diverse. Le latenze di riferimento mostrate in questo playbook distinguono tra cluster con:- Tutti i membri nello stesso dominio di disponibilità
- Membri di domini di disponibilità diversi
- Membri in due region OCI vicine ma diverse
L'immagine riportata di seguito mostra il throughput (transazioni al secondo) per un sistema SOA di Oracle Fusion Middleware che esegue Fusion Order Demo (FOD) per diverse latenze tra il server WebLogic e il database.
L'immagine riportata di seguito mostra il tempo di attività JTA (Java Transaction API) per un sistema SOA di Oracle Fusion Middleware che esegue la demo FOD (Fusion Order Demo) che utilizza un database in un sito diverso con latenze diverse tra i siti.
L'immagine seguente mostra il degrado osservato nel throughput complessivo del sistema in transazioni al secondo per diverse latenze tra i siti (entrambi i siti lavorano insieme al database in uno dei siti).
Nota
Tenendo presente tutto quanto sopra e tenendo conto delle sanzioni per le prestazioni osservate in molti test, Oracle non supporta i cluster estesi di Oracle Fusion Middleware che superano i 10 millisecondi di latenza (RTT) tra i siti. I sistemi possono funzionare senza problemi, ma i tempi di transazione aumenteranno notevolmente. Anche le latenze oltre i 10 millisecondi (RTT) causeranno problemi nel cluster di Oracle Coherence utilizzato per la distribuzione e JTA, i servizi Web o i timeout delle applicazioni. Ciò rende le soluzioni presentate in questo playbook adatte principalmente a siti o regioni con bassa latenza tra loro.
-
- Traffico tra più aree
Nel modello corrente, è necessario ridurre al minimo il traffico tra i siti per ridurre l'effetto della latenza sul throughput del sistema. In un tipico sistema FMW, le comunicazioni tra i diversi livelli o elementi sono:
-
Accesso al database dalle istanze di Oracle WebLogic Server per l'accesso ai metadati e altre operazioni di lettura/scrittura del database.
-
Richiami HTTP in entrata da istanze LBR (load balancer) o Oracle HTTP Server e callback HTTP.
-
Richiami JNDI (Java Naming and Directory Interface)/RMI (Remote Method Invocation) e JMS (Java Message Service) tra le istanze di Oracle WebLogic Server.
-
Notifiche Oracle Coherence tra tutti i server del sistema. Ad esempio, SOA utilizza Coherence per fornire un'immagine composita e di metadati coerente.
-
Repliche delle sessioni HTTP tra le istanze di Oracle WebLogic Server. Alcuni componenti utilizzano applicazioni Web con conservazione dello stato che possono fare affidamento sulla replica delle sessioni per abilitare il failover trasparente delle sessioni tra i server. A seconda dei modelli di utilizzo e del numero di utenti, questo può generare una notevole quantità di dati di replica.
-
L'accesso all'area di memorizzazione LDAP (Lightweight Directory Access Protocol)/policy/identity viene eseguito dall'infrastruttura Oracle WebLogic Server a scopo di autorizzazione e autenticazione. Idealmente, ogni sito dovrebbe avere un'area di memorizzazione indipendente di identità e criteri che viene sincronizzata regolarmente per ridurre al minimo i richiami da un sito all'altro. In alternativa, entrambi i siti possono condividere lo stesso negozio. L'impatto della condivisione del negozio dipenderà dal tipo di negozio e dal modello di utilizzo del sistema.
Quando possibile, tutto quanto sopra dovrebbe essere contenuto all'interno del sito per migliorare le prestazioni. Ad esempio:
-
I server in un sito devono ricevere solo richiami da istanze di Oracle HTTP Server nello stesso sito.
-
I server in un sito devono effettuare richiami JMS, RMI e JNDI solo ai server nello stesso sito e devono ottenere callback generati dai server solo nello stesso sito.
-
La replica della sessione HTTP deve essere limitata solo agli altri server nello stesso sito. I requisiti di replica e failover devono essere analizzati per ogni business case, ma idealmente, il traffico di replica delle sessioni dovrebbe essere ridotto il più possibile tra i siti.
-
- Storage condiviso
La latenza per le scritture del file system di rete (NFS) nei siti può causare un grave peggioramento delle prestazioni. I server devono utilizzare dispositivi di storage locali al proprio sito per eliminare i conflitti nelle richieste di lettura/scrittura ai file system. La memorizzazione condivisa deve essere limitata all'interno di ogni sito.
- Altre risorse
I due siti possono condividere altre risorse esterne, ad esempio LDAP, destinazioni JMS esterne, servizi Web esterni e così via. È necessario che queste risorse siano costantemente disponibili in entrambi i siti. I dettagli di configurazione per queste risorse esterne non rientrano nell'ambito di questo playbook.
