Imposta cluster estesi FMW

Imposta aree

Il modello cluster esteso di Oracle Fusion Middleware (FMW) è configurato in due siti separati.

In Oracle Cloud Infrastructure (OCI), puoi implementarlo in tutte le region OCI che hanno una bassa latenza tra di loro. La latenza massima tra le aree supportata è 10 ms round-trip time (RTT). È possibile controllare la latenza tra le aree nella console OCI selezionando Networking, Network Command Center e quindi Latenza tra più aree.

Considerando i valori di latenza, è possibile distribuire questo modello tra aree come Francoforte e Amsterdam, che hanno un RTT di 6-7 ms. Tuttavia, non è possibile distribuire questo modello tra posizioni come Ashburn e Phoenix, perché la latenza tra queste aree supera i 50 ms RTT.

Esempio di coppie di regioni con latenza interregionale inferiore a 10 ms RTT:

Amsterdam (AMS) - Parigi (CDG)
Amsterdam (AMS) - Newport (CWL)
Amsterdam (AMS) - Francoforte (FRA)
Amsterdam (AMS) - Londra (LHR)
Parigi (CDG) - Francoforte (FRA)
Parigi (CDG) - Londra (LHR)
Parigi (CDG) - Newport (CWL)
Marsiglia (MRS) - Milano (LIN)
Zurigo (ZHR) - Francoforte (FRA)
Zurigo (ZHR) - Milano (LIN)
Osaka (KIX) - Tokyo (NRT)
Singapore (SIN) - Batan (HSG)
San Paolo (GRU) - Vinhedo (VCP)
Singapore (SIN) - Singapore 2 (XSP)
Batan (HSG) - Singapore 2 (XSP)
Seul (ICN) - Chuncheon (YNY)
Toronto (YYZ) - Montreal (YUL)

Per quanto riguarda la larghezza di banda, non c'è una larghezza di banda garantita tra le aree OCI e OCI non offre uno strumento specifico di misurazione della larghezza di banda OCI. Per misure precise della larghezza di banda, utilizzare strumenti come iPerf. La larghezza di banda testata tra Francoforte e Amsterdam è di circa 2-2,5 gigabit al secondo (Gbps).

È inoltre possibile implementare questo modello tra domini di disponibilità (AD) che si trovano nella stessa area. La distribuzione dei server Oracle WebLogic Server negli AD è, infatti, il comportamento standard nei servizi platform as a service (PaaS) come Oracle SOA Suite on Marketplace e negli stack Oracle WebLogic Server for OCI. Tuttavia, l'implementazione di questo modello nei domini AD anziché in tutte le region non è davvero una soluzione di protezione da errori irreversibili, perché non protegge dagli eventi che influiscono su un'intera region.

Suggerimento

Per creare le subnet, le regole, le istanze di computazione, lo storage condiviso e i load balancer necessari per una distribuzione FMW in ogni sito, è possibile utilizzare il framework WLS-HYDR (fare riferimento alla procedura "Crea infrastruttura").

Configurazione della rete

Le reti cloud virtuali (VCN) nelle aree in cui viene distribuita questa topologia devono essere interconnesse per consentire il traffico tra tutti i server WebLogic nel cluster e dai server WebLogic ai database.

Per l'impostazione sono necessarie le funzioni di rete riportate di seguito.

Una VCN e subnet a più livelli in ogni area.
Connessione di peering remoto tra le reti VCN, con gateway di instradamento dinamico (DRG).
Le regole di instradamento appropriate per instradare il traffico tra i siti. Nell'area 1, le tabelle di instradamento devono includere un instradamento al CIDR VCN dell'area 2 tramite il gateway di instradamento dinamico. Analogamente, le tabelle di instradamento Area 2 devono includere un instradamento al CIDR VCN Area 1 tramite il gateway di instradamento dinamico.
Le regole di sicurezza di rete per consentire la comunicazione seguente per il cluster esteso:
- Aprire le porte WebLogic Server e Node Manager tra le subnet di livello intermedio dell'area 1 e dell'area 2. Se si utilizza Coherence, consentire il traffico TCP e UDP anche per le porte di Coherence.
- Consenti traffico al listener del database e alle porte Oracle Cloud Infrastructure Notifications (ONS) in entrambe le aree dalle subnet di livello intermedio di area 1 e area 2.
- Per impostazione predefinita, non è necessaria la comunicazione tra più aree tra i server OHS e WebLogic. Le porte WebLogic Server nella subnet di livello intermedio devono essere accessibili solo dai server OHS all'interno della stessa area. Tuttavia, la comunicazione tra più aree può essere richiesta in circostanze eccezionali, ad esempio se tutti i server Web di una regione falliscono. Ulteriori dettagli sono disponibili nella sezione Gestione degli errori.
Tutti i nomi host utilizzati dal sistema (indirizzi di ascolto WebLogic e indirizzi SCAN e VIP del database primario e in standby) devono essere risolvibili da entrambi i siti. Per impostazione predefinita, in OCI i nomi host possono essere risolti solo all'interno di ogni VCN. Per consentire la risoluzione dei nomi dell'area 1 nell'area 2, creare una vista DNS privata nell'area 2 per il dominio dell'area 1 e aggiungere i nomi e gli indirizzi IP pertinenti. Ripetere questo processo nell'area 1 per risolvere i nomi dall'area 2.
In ogni sito, il nome front-end del sistema (ad esempio frontend.example.com) deve puntare all'indirizzo IP del load balancer locale. A tale scopo, aggiungere il nome front-end a una vista DNS privata in ogni area o al file /etc/hosts degli host di livello intermedio. Ciò garantisce che tutti i callback da un server WebLogic al front-end vengano indirizzati all'area locale.

Impostazione del database

Impostare un sistema di database Oracle Real Application Clusters (Oracle RAC) nell'area 1 con un sistema di database RAC in standby nell'area 2.

È importante utilizzare RAC all'interno di ogni area perché l'alta disponibilità locale è un requisito chiave. La configurazione del dominio di disponibilità incrociata (AD, Cross-Availability Domain) o della protezione tra più aree è efficace solo se esiste già una protezione affidabile dagli errori locali all'interno di una singola area. Se non è stata implementata la funzionalità High Availability locale, come quella fornita da RAC, l'aggiunta di protezione a più domini AD o aree non consente di risolvere il rischio di errori all'interno dell'ambiente locale.

Per mantenere l'applicazione connessa e ricevere le notifiche di Oracle Notification Service in caso di errori dei nodi o delle istanze del database RAC, assicurarsi che l'applicazione si connetta al pluggable database (PDB) utilizzando un servizio di database CRS (Cluster Ready Services). Lo stesso servizio CRS deve esistere nel database primario e in standby. Comandi di esempio per creare un servizio per la connessione al PDB:


srvctl add service -db $ORACLE_UNQNAME -service pdbservice.example.com -preferred ORCL1,ORCL2 -pdb pdb1 
srvctl modify service -db $ORACLE_UNQNAME -service pdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT

Imposta memorizzazione condivisa

Oracle Cloud Infrastructure File Storage è un servizio di file system completamente gestito, scalabile e sicuro fornito da OCI. È progettato per offrire storage di file ad alte prestazioni per le applicazioni aziendali che richiedono file system condivisi e persistenti.

Più istanze di computazione possono eseguire il MOUNT e accedere allo stesso file system contemporaneamente tramite il protocollo NFS (Network File System).

Il modello cluster esteso di Oracle Fusion Middleware (FMW) in OCI utilizza i sistemi di archiviazione di file OCI in ogni area per i file system condivisi (ad esempio, per la configurazione condivisa o per i dati runtime condivisi). Lo storage di file OCI fornisce l'alta disponibilità all'interno dell'area: utilizza internamente lo storage ridondante tra più domini di errore all'interno di un dominio di disponibilità. Tuttavia, non è possibile accedere allo storage di file OCI in tutte le aree. Pertanto, lo storage condiviso è locale per l'area.

Usare i backup locali e le repliche del file system tra le aree per fornire una copia recuperabile degli artifact.

Imposta livello intermedio

I nodi di calcolo di livello intermedio sono distribuiti tra le due aree.

I nodi di calcolo di livello intermedio sono distribuiti nelle due aree, con metà dei nodi situati nell'area 1 e l'altra metà nell'area 2. Il processo di provisioning e installazione è lo stesso di quando si crea un singolo dominio WebLogic. Per implementare le funzioni High Availability (come Java Message Service (JMS) e la migrazione del servizio Java Transaction API (JTA), il failover del server di amministrazione, il rilevamento automatico degli arresti anomali con Node Manager e così via) utilizzano le best practice consigliate nelle guide alla distribuzione di FMW Enterprise a cui si fa riferimento nella sezione Esplora altro.

Puoi creare il dominio e configurarlo con tutti i server gestiti fin dall'inizio oppure puoi eseguire lo scale-out di un dominio esistente eseguito in una singola area aggiungendo nodi nell'altra area.

Nota

Il modello cluster esteso di Oracle Fusion Middleware (FMW) può essere applicato ai domini creati utilizzando i servizi Platform as a Service (PaaS), ad esempio Oracle WebLogic Server for OCI e gli stack Oracle SOA Suite on Marketplace. Le funzioni di provisioning e scale-out di questi servizi PaaS supportano solo una singola area per impostazione predefinita, pertanto è necessario eseguire manualmente lo scale-out del cluster per aggiungere nodi in un'altra area. Fare riferimento alle procedure per lo scale-out di un cluster WLS per i passi necessari per eseguire questa operazione. Tenere presente che questi servizi PaaS non includono un livello Web e non implementano alcune procedure ottimali ad alta disponibilità, ad esempio il failover del server di amministrazione. Pertanto, alcuni dei suggerimenti contenuti in questo documento potrebbero non essere applicabili a questi ambienti.

Questi sono gli aspetti più rilevanti da implementare nella configurazione WebLogic quando si utilizza il modello di cluster esteso FMW:

Usa aree di memorizzazione persistenti del database
Oracle supporta i cluster stretch che utilizzano le aree di memorizzazione persistenti del database per i log delle transazioni e JMS di Oracle WebLogic Server. La memorizzazione dei log delle transazioni e dei dati persistenti nel database sfrutta le funzioni di replica integrate e ad alta disponibilità del database, come Oracle Real Application Clusters (Oracle RAC) e Oracle Data Guard. Con JMS, i log delle transazioni (TLOG) e i metadati in un database protetto da Data Guard, la sincronizzazione tra siti è semplificata e la coerenza a livello di applicazione è garantita. Ciò significa anche che il livello intermedio non ha più bisogno di storage condiviso per questi artifact (anche se ne ha ancora bisogno per il failover del server di amministrazione, i piani di distribuzione e alcuni adattatori come l'adattatore di file).

L'utilizzo di TLOG e JMS nel database comporta tuttavia una penalità per le prestazioni del sistema. Questa penalità viene aumentata quando uno dei livelli intermedi deve comunicare in modo incrociato con il database dell'altro sito. Dal punto di vista delle prestazioni, uno storage condiviso locale per ogni sito avrebbe prestazioni migliori, ma ciò introduce complessità e limitazioni per garantire una perdita di dati pari a zero tra le aree e la coerenza delle applicazioni.
Artifact di file system condivisi locali per ogni area
Come indicato nelle guide di distribuzione di Oracle Fusion Middleware Enterprise, la directory di dominio di Administration Server (ASERVER_HOME) deve risiedere nella memoria condivisa, separata dalla cartella di dominio del server gestito (MSERVER_HOME). Questo, insieme all'utilizzo di un nome host virtuale per l'indirizzo di ascolto del server di amministrazione, consente al server di amministrazione di eseguire il failover su un altro host, all'interno della stessa area o in un'area diversa.

Altri artifact che risiedono nei file system condivisi sono le installazioni (binarie) della Oracle home, i piani di distribuzione e le directory dell'adattatore di file (cartella runtime).

In una topologia cluster estesa FMW, ogni area utilizza il proprio storage condiviso locale. Di conseguenza, la seconda area mantiene i propri file binari ridondanti (assicurando almeno due installazioni binarie per sito per l'alta disponibilità) e le proprie directory condivise per la configurazione condivisa, i piani di distribuzione, i file runtime e altro ancora. Tutti questi artifact devono utilizzare percorsi identici in entrambe le aree per garantire coerenza e failover senza interruzioni.
Utilizzare un algoritmo basato sull'affinità per il cluster WebLogic
Per ridurre al minimo il traffico cross-site, utilizzare l'affinità locale per la risoluzione del factory di contesti JNDI (Java Naming and Directory Interface). Per impostare l'algoritmo di caricamento predefinito del cluster WebLogic su un algoritmo basato su affinità, effettuare le operazioni riportate di seguito.
1. Andare alla Modifica struttura nella WebLogic Remote Console.
2. Andare a Ambiente, selezionare Cluster e selezionare il cluster.
3. Nella scheda Generale, impostare l'algoritmo di caricamento predefinito del cluster WebLogic su affinità round-robin (l'impostazione predefinita è round-robin) o su qualsiasi algoritmo "basato sulla affinità".
Non è necessario impostare l'indirizzo cluster con la lista esplicita di tutti i server nel cluster. Quando è vuoto, il valore Indirizzo cluster viene generato automaticamente. Assicurarsi che la proprietà Numero di server nell'indirizzo cluster, che limita il numero di server da elencare durante la generazione automatica dell'indirizzo cluster, disponga di un valore sufficiente per includere tutti i server nel cluster.
Usa configurazione migrazione automatica servizi
Oracle consiglia di configurare la migrazione automatica dei servizi insieme alle aree di memorizzazione persistenti JDBC (Java Database Connectivity) per le topologie di distribuzione enterprise. In una topologia cluster estesa FMW, la migrazione automatica del servizio è possibile all'interno e anche tra le aree, a condizione che i dati JMS e TLOG siano accessibili da entrambi i siti. Quando si utilizzano le aree di memorizzazione persistenti JDBC, non sono necessarie considerazioni speciali per la configurazione di ASM in un cluster esteso.

Il tempo necessario per un'operazione di migrazione del servizio dall'area 1 all'area 2 può aumentare quando vi è un'elevata latenza tra i siti. Questo aumento è causato dal tempo impiegato per recuperare i messaggi nell'altro server, poiché vengono letti dall'area di memorizzazione persistente nel database nell'altra area. Questa latenza aumenta con il numero di messaggi in sospeso nelle aree di memorizzazione persistenti. Tuttavia, la penalità diventa rilevante solo con latenze molto elevate o con un gran numero di messaggi in sospeso. Fare riferimento alla sezione "Rivedi dati sulle prestazioni" per i dettagli sui comportamenti previsti.
Risoluzione e nome host front-end
Quando si configura l'host front-end per il cluster WebLogic, specificare il nome host virtuale utilizzato dai client per accedere al sistema, come in qualsiasi distribuzione standard. I client devono risolvere questo nome host virtuale in un indirizzo esterno bilanciato tra le istanze di OCI Load Balancer nell'area 1 e nell'area 2. Vedere "Informazioni sul bilanciamento del carico globale".

Per assicurarsi che i server WebLogic in ogni area instradino le chiamate interne solo al rispettivo load balancer OCI locale, configurare i server in modo che risolvano il nome host del front end all'indirizzo IP del load balancer OCI all'interno della propria area. Ciò può essere ottenuto aggiungendo una voce al file /etc/hosts su ogni host del server WebLogic o aggiungendola a una vista privata DNS in ogni area:

Per i server nell'area 1:
```
[IP address of Region 1 OCI Load Balancer] [frontend hostname]
```
Per i server nell'area 2:
```
[IP address of Region 2 OCI Load Balancer] [frontend hostname]
```
Questa configurazione garantisce che le comunicazioni interne dai server WebLogic vengano indirizzate al load balancer regionale appropriato, ottimizzando instradamento e prestazioni.

Impostazione origini dati WebLogic

Utilizzare origini dati GridLink con una stringa di connessione doppia in tutte le origini dati WebLogic (per i metadati Oracle Fusion Middleware (FMW), le aree di memorizzazione persistenti del database, le tabelle di leasing, l'adattatore DB e così via) per automatizzare il failover del database. Dovrebbero riconnettersi automaticamente quando si verifica un errore o un arresto in uno dei nodi di Oracle Real Application Clusters (Oracle RAC), ma anche quando si verifica uno switchover completo del database nell'altra area. A tale scopo, applicare le raccomandazioni riportate di seguito.

Usa origini dati GridLink
Le origini dati GridLink utilizzano Oracle Notification Service (ONS) per rilevare e rispondere rapidamente a errori dei nodi del database o interruzioni di rete, migliorando la disponibilità e la resilienza delle applicazioni. Distribuiscono automaticamente le connessioni al database in base alle informazioni sul carico di lavoro in tempo reale, ottimizzando le prestazioni e l'uso delle risorse in tutti i nodi RAC. Le modifiche nella topologia del database, come l'aggiunta o la rimozione di nodi RAC, vengono riconosciute e gestite in modo automatico, riducendo il sovraccarico amministrativo e riducendo al minimo i tempi di inattività.

Non è necessario specificare manualmente l'host e la porta ONS nella configurazione dell'origine dati GridLink. La lista ONS viene fornita automaticamente dal database al driver, che recupera le informazioni ONS sia per i database primari che per quelli in standby, facilitando le connessioni a entrambi.
Usa alias TNS
Nella stringa di connessione delle origini dati, utilizzare un alias TNS che punta a una voce nel file tnsnames.ora, che include sia gli indirizzi SCAN primari che quelli in standby. Il formato di stringa di connessione consigliato è il seguente, con una descrizione e due liste di indirizzi, una per ogni database RAC:
```
PDB =
(DESCRIPTION=   
(CONNECT_TIMEOUT=15)(RETRY_COUNT=5)(RETRY_DELAY=5)(TRANSPORT_CONNECT_TIMEOUT=3)   
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
     (ADDRESS=(PROTOCOL=TCP)(HOST=primdb-scan.dbsubnet.region1vcn.oraclevcn.com)(PORT=1521))
 )
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stbydb-scan.dbsubnet.region2vcn.oraclevcn.com)(PORT=1521))    
)
(CONNECT_DATA=(SERVICE_NAME=pdbservice.example.com))
)
```
Per ulteriori informazioni su come configurare l'alias TNS nelle origini dati e nei file di configurazione FMW, vedere Uso dell'alias TNS nelle stringhe di connessione nel manuale Enterprise Deployment Guide for Oracle SOA Suite.
Utilizzare l'opzione Test delle connessioni riservate
Assicurarsi che l'opzione Test connessioni su prenotazione sia abilitata per tutte le origini dati. Ciò è particolarmente importante per le origini dati utilizzate per accedere alle aree di memorizzazione persistenti, poiché le aree di memorizzazione persistenti sono critiche nello stato generale dei server WebLogic. Questo flag consente al server WebLogic di eseguire il test di una connessione prima di assegnarla all'applicazione.

Per Nome tabella di test utilizzare il valore predefinito SQL ISVALID. Si tratta di un test rapido ed efficiente, in quanto esegue una convalida leggera per determinare se la connessione al database è ancora attiva, senza richiedere l'accesso a una tabella fisica specifica.
Ottimizza la capacità iniziale
Quando si avvia un server WebLogic, viene dedicato un periodo di tempo considerevole alla creazione delle connessioni iniziali per i pool di origini dati. Si prevedono ritardi diversi in base alle impostazioni di capacità iniziali nelle origini dati. Per impostazione predefinita, la maggior parte delle origini dati FMW utilizza una capacità iniziale pari a zero per il connection pool. Tuttavia, per ridurre il tempo di risposta del sistema durante il normale funzionamento di runtime, può essere utile aumentare la capacità iniziale del pool.
Poiché la capacità iniziale è configurata a livello di origine dati (connection pool), queste impostazioni influiscono sul tempo di avvio per tutti i server all'interno del cluster (quelli locali al database e quelli remoti ad esso). In un cluster esteso FMW, i server che risiedono in remoto dal database mostreranno una maggiore latenza all'inizio poiché viene utilizzata una maggiore capacità iniziale del pool (vedere "Tempi di inizio revisione"). Pertanto, è necessaria una decisione equilibrata tra l'ottimizzazione dei tempi di risposta durante il normale funzionamento e la riduzione al minimo dell'ora di inizio per determinare le impostazioni di capacità iniziali ideali.
Ottimizza la capacità massima
Il numero di connessioni all'origine dati attive aumenta con una latenza più elevata al database. Nei test condotti, i server nell'area remota mostrano fino a 2x connessioni attive rispetto al server collocato con il database (vedere "Esaminare i test di stress"). Monitora l'uso nell'applicazione e considera questo per un dimensionamento corretto delle origini dati e delle sessioni del database WebLogic.

Imposta server Web

Se il sistema utilizza un livello Web con istanze di Oracle HTTP Server, ogni area deve disporre di almeno due server per fornire alta disponibilità all'interno dell'area.

Per ridurre il traffico tra le aree, non utilizzare una configurazione di lista di server dinamici nelle sezioni di instradamento di Oracle WebLogic Server. Configurare invece un elenco statico dei server, impostando il parametro DynamicServerList su OFF. Questo ha l'avvertenza di un rilevamento degli errori più lento: quando un server WebLogic si blocca, il server HTTP impiega più tempo per rilevare l'errore rispetto a un elenco dinamico. Inoltre, richiede aggiornamenti nella configurazione se vengono aggiunti nuovi server. Tuttavia, migliora le prestazioni del sistema.

Gli estratti seguenti dai file mod_wl_ohs.conf in Oracle HTTP Server forniscono un esempio della configurazione richiesta per l'instradamento all'applicazione Web soa-infra.

Nella regione 1:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region1_server1.example.com:7004,region1_server2.example.com:7004
    DynamicServerList OFF
</Location>

Nella regione 2:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region2_server1.example.com:7004,region2_server2.example.com:7004
    DynamicServerList OFF
</Location>

Imposta load balancer

Ogni area deve avere il proprio load balancer per distribuire le richieste tra i server all'interno di quel sito.

Configurare il listener in entrambe le aree con lo stesso certificato SSL su ogni load balancer. Impostare i server backend in modo che il load balancer nell'area 1 includa le istanze di Oracle HTTP Server (OHS) dall'area 1 (se il sistema non utilizza server Web, i server di cui è stato eseguito il backup sono WebLogic) i server dell'area 1) e il load balancer dell'area 2 include i server OHS dell'area 2 (se il sistema non utilizza i server Web, i server backend sono i server WebLogic dell'area 2).

Configurare i controlli dello stato per determinare la disponibilità dei server backend, utilizzando un URL che rifletta accuratamente lo stato dell'applicazione. Ciò impedisce che il traffico venga instradato a un server in cui è in esecuzione Oracle WebLogic Server, ma l'applicazione stessa non è disponibile, il che può verificarsi se il controllo dello stato si rivolge solo al contesto radice (/). Tuttavia, evita di utilizzare controlli dello stato a uso intensivo di risorse, poiché frequenti controlli intensi potrebbero sovraccaricare i server di cui è stato eseguito il backup. Ad esempio, per Oracle SOA, l'URL di controllo dello stato consigliato è /soa-infra/services/isSoaServerReady .

Informazioni sul bilanciamento del carico globale

Il modello cluster esteso di Oracle Fusion Middleware (FMW) richiede un elemento al di sopra del load balancer di ogni data center per bilanciare le richieste del client tra le due aree.

Nelle implementazioni on-premise, questo viene tradizionalmente implementato con un load balancer globale, che è responsabile dell'instradamento intelligente, in genere basato sugli indirizzi IP dell'origine. Questo load balancer globale si trova in genere in uno dei siti, con un backup nell'altro sito per il failover.

In Oracle Cloud Infrastructure (OCI), non esiste un servizio di load balancer globale dedicato. Tuttavia, è possibile ottenere funzionalità di bilanciamento del carico globali utilizzando i criteri di gestione del traffico.

Utilizza i criteri di indirizzamento per la gestione del traffico OCI come load balancer globale

Utilizzare i criteri di indirizzamento per la gestione del traffico di Oracle Cloud Infrastructure (OCI) per bilanciare il carico del traffico del client tra i due siti.

I criteri di indirizzamento per la gestione del traffico servono risposte intelligenti alle query DNS (Domain Name System), il che significa che potrebbero essere fornite risposte diverse per la query a seconda della logica definita nel criterio. Esistono vari tipi di criteri:

Criterio del load balancer
I criteri del load balancer distribuiscono il traffico su molti endpoint. Agli endpoint possono essere assegnati pesi uguali per distribuire il traffico in modo uniforme tra gli endpoint o è possibile assegnare pesi personalizzati per il bilanciamento del carico del rapporto. I monitor e le sonde on-demand di Oracle Cloud Infrastructure Health Checks vengono utilizzati per valutare lo stato dell'endpoint. Se un endpoint non è in buono stato, il traffico DNS viene distribuito automaticamente agli altri endpoint.
Criterio di failover
I criteri di failover consentono di assegnare la priorità all'ordine in cui si desidera che le risposte vengano fornite in un criterio, ad esempio primario e secondario. I monitoraggi e le sonde on-demand di OCI Health Checks vengono utilizzati per valutare lo stato delle risposte nei criteri. Se la risposta primaria non è in buono stato, il traffico DNS viene indirizzato automaticamente alla risposta secondaria.
Criterio di indirizzamento geolocalizzazione
I criteri di indirizzamento della geolocalizzazione distribuiscono il traffico DNS a endpoint diversi in base alla posizione dell'utente finale. I clienti possono definire aree geografiche composte da continente di origine, da paesi o stati/province (Nord America) e definire un endpoint distinto o una serie di endpoint per ogni area.
Criterio di indirizzamento ASN
I criteri di indirizzamento ASN consentono di indirizzare il traffico DNS in base ai numeri ASN (Autonomous System Number). Le interrogazioni DNS che provengono da un ASN specifico o da uno specifico set di ASN possono essere indirizzate a un endpoint specificato.
Criterio di indirizzamento prefisso IP
I criteri di indirizzamento basati su prefissi IP consentono ai clienti di indirizzare Il traffico DNS in base al prefisso IP della query di provenienza.

Scegli il criterio più adatto alle tue esigenze. Le opzioni più adatte per una distribuzione cluster estesa sono il criterio di indirizzamento della geolocalizzazione e il criterio di indirizzamento del prefisso IP. Il criterio di failover è adatto per i servizi eseguiti solo in uno dei siti, ad esempio la WebLogic Remote Console.

Indipendentemente dal tipo di criterio, è necessario definire un controllo dello stato OCI per verificare la disponibilità del sito. Ciò evita che il traffico raggiunga un sito in cui i server vengono arrestati o l'applicazione non è disponibile. Assicurarsi di consentire il traffico in entrata dai punti di osservazione che eseguono il controllo dello stato alle porte OCI Load Balancer che si stanno controllando.

Il diagramma riportato di seguito mostra il bilanciamento del carico globale con i criteri di indirizzamento della gestione del traffico OCI.

Segue la descrizione dell'immagine global-load-balancer-steering-policies.png

Descrizione dell'illustrazione global-load-balancer-steering-policies.png

global-load-balancer-steering-policies-oracle.zip

Quando si utilizzano i criteri di indirizzamento di gestione del traffico OCI per emulare un load balancer globale, effettuare le operazioni riportate di seguito.

Tempo di reazione failover
Il tempo di risposta a un errore del sito dipende sia dagli intervalli di controllo dello stato (che determinano la velocità con cui un sito viene contrassegnato come non disponibile) sia dal valore TTL (Time To Live) del record DNS. Anche dopo che un sito è contrassegnato come non disponibile e il traffico viene indirizzato a un'altra posizione, i client non riceveranno l'indirizzo IP aggiornato fino alla scadenza del TTL DNS precedente nella cache locale. Per ridurre al minimo i ritardi di failover, si consiglia di impostare un valore TTL dei criteri basso.
Limitazione persistenza sessione
Poiché il bilanciamento del carico con questi criteri si basa sui valori di risposta DNS, non esiste un meccanismo integrato per la persistenza della sessione. Di conseguenza, quando si utilizza un criterio di load balancer casuale o semplice, la risposta DNS fornita ai client può cambiare in qualsiasi momento, influendo potenzialmente sulle sessioni dell'applicazione che richiedono persistenza. Se l'applicazione richiede sessioni persistenti, assicurarsi che tutte le possibili posizioni client siano definite in modo esplicito all'interno di regole basate sulla geolocalizzazione ed evitare di utilizzare algoritmi di indirizzamento casuali o del load balancer.

Di seguito è riportata una configurazione di esempio dei criteri di indirizzamento di gestione del traffico OCI per un sistema cluster esteso di Oracle Fusion Middleware (FMW) distribuito nelle aree di Francoforte e Amsterdam, con tre front-end: uno per Oracle SOA, uno per OSB e un altro per la WebLogic Remote Console. L'IP del load balancer (LBR) di Francoforte è 111.111.111.111 e l'IP dell'LBR di Amsterdam è 222.222.222.222. In questo esempio i criteri di indirizzamento definiscono le regole riportate di seguito.

Per i front-end SOA e OSB, i client delle sedi di Germania, Europa, Asia e Sud America riceveranno dal DNS l'IP del load balancer di Francoforte come risposta principale.
Per i front-end SOA e OSB, i client dei Paesi Bassi, dell'Africa, dell'Oceania e del Nord America riceveranno da DNS l'IP del load balancer di Amsterdam come risposta principale.
Per tutti gli altri client (che non sono previsti, poiché tutte le regioni sono incluse nelle regole di geolocalizzazione), il DNS restituirà una risposta predefinita in modo che vengano reindirizzati a Francoforte.
I controlli dello stato OCI vengono definiti per ogni front end, pertanto se il database primario è contrassegnato come non disponibile, il traffico viene indirizzato al record IP alternativo.
Il front-end della WebLogic Remote Console utilizza un modello di failover. Il DNS restituisce l'IP del load balancer di Francoforte per tutti i client. Quando il controllo dello stato non riesce a Francoforte, il DNS restituisce l'IP del load balancer di Amsterdam.

Di seguito sono riportati i criteri di indirizzamento di gestione del traffico OCI definiti.

Criterio di indirizzamento di geolocalizzazione per l'accesso al front-end SOA.

Elemento di configurazione	Valori di esempio
Nome criterio	strecthed_cluster_steering_policy-SOA
Modello	Indirizzamento geolocalizzazione
TTL criterio	60s
Rispondere Pool1 (Frankfurt_Pool)	Nome: Frankfurt_LBR_IP Tipo: A RDATA: 111.111.111.111
Pool di risposte 2 (Amsterdam_Pool)	Nome: Amsterdam_LBR_IP Tipo: A RDATA: 222.222.222.222
Regola di indirizzazione geolocalizzazione 1	Geolocalizzazione: Germania, Europa, Asia, Sud America Priorità pool 1: Frankfurt_Pool Priorità pool 2: Amsterdam_Pool
Regola di indirizzazione geolocalizzazione 2	Geolocalizzazione: Paesi Bassi, Africa, Oceania, Nord America Priorità pool 1: Amsterdam_Pool Priorità pool 2: Frankfurt_Pool
Catch-all globale	Rispondere Pool1 (Frankfurt_Pool)
Collega controllo dello stato	Tipo di richiesta: HTTP Controllo dello stato: `SOA_IS_ALIVE` (HTTPS)
Domini collegati	soafrontend.example.com

Criterio di indirizzamento di geolocalizzazione per l'accesso al front-end OSB.

Elemento di configurazione	Valori di esempio
Nome criterio	strecthed_cluster_steering_policy-OSB
Modello	Indirizzamento geolocalizzazione
TTL criterio	60s
Pool risposte 1 (Frankfurt_Pool)	Nome: Frankfurt_LBR_IP Tipo: A RDATA: 111.111.111.111
Pool di risposte 2 (Amsterdam_Pool)	Nome: Amsterdam_LBR_IP Tipo: A RDATA: 222.222.222.222
Regola di indirizzazione geolocalizzazione 1	Geolocalizzazione: Germania, Europa, Asia, Sud America Priorità pool 1: Frankfurt_Pool Priorità pool 2: Amsterdam_Pool
Regola di indirizzazione geolocalizzazione 2	Geolocalizzazione: Paesi Bassi, Africa, Oceania, Nord America Priorità pool 1: Amsterdam_Pool Priorità pool 2: Frankfurt_Pool
Catch-all globale	Rispondere Pool1 (Frankfurt_Pool)
Collega controllo dello stato	Tipo di richiesta: HTTP Controllo dello stato: `OSB_IS_ALIVE` (HTTPS)
Domini collegati	osbfrontend.example.com

Per accedere alla WebLogic Remote Console viene utilizzato un criterio di failover. Durante il normale funzionamento, il server di amministrazione viene eseguito solo in uno dei siti (in questo caso Francoforte). Solo in caso di errore del sito, viene avviato nell'altro sito. Pertanto, l'accesso alla WebLogic Remote Console ed EM è controllato da un criterio di failover.

Elemento di configurazione	Valori di esempio
Nome criterio	strecthed_cluster_steering_policy-AMMINISTRATORE
Modello	Failover
TTL criterio	60s
Rispondere Pool1 (Frankfurt_Pool)	Nome: Frankfurt_LBR_IP Tipo: A RDATA: 111.111.111.111
Pool di risposte 2 (Amsterdam_Pool)	Nome: Amsterdam_LBR_IP Tipo: A RDATA: 222.222.222.222
Priorità pool 1	Frankfurt_Pool
Priorità pool 2	Amsterdam_Pool
Collega controllo dello stato	Tipo di richiesta: HTTP Controllo dello stato: `EM_IS_ALIVE` (HTTPS)
Domini collegati	admin.example.com

Questa è la configurazione dei controlli dello stato OCI utilizzati da ciascun criterio di indirizzamento DNS:

Controllo dello stato per il front end SOA. SOA fornisce una pagina semplice per verificare lo stato SOA, nel percorso /soa-infra/services/isSoaServerReady. Pertanto, questo controllo dello stato esegue una richiesta HEAD con HTTPS a quel percorso per verificare se l'applicazione SOA è disponibile. L'intestazione host è necessaria per specificare il nome del front-end da sottoporre a test (in questo esempio, soafrontend.example.com) quando si utilizzano host virtuali denominati nei server Web e nei load balancer.

Elemento di configurazione	Valori di esempio
Nome controllo dello stato	SOA_IS_ALIVE
Destinazioni	111.111.111.111 (IP LBR Francoforte) 222.222.222.222 (IP Amsterdam LBR)
Punti di osservazione	Microsoft Azure Nord Europa Google Stati Uniti orientali
Type	HTTP
Protocollo	HTTPS
Porta	443
Percorso	`/soa-infra/services/isSoaServerReady`
Intestazioni	Ospite: soafrontend.example.com:443
Metodo	HEAD
aggregazione	30 secondi
Timeout	10 secondi

Controllo dello stato per il front end OSB. OSB non implementa un URL di stato per i propri servizi. Alcuni degli URL utilizzati normalmente per verificare lo stato dell'OSB (ad esempio /sbinspection.wsil) richiedono l'autenticazione e OCI Health Checks non supporta l'intestazione authorization. Pertanto, per verificare lo stato di OSB, distribuire un semplice servizio proxy REST personalizzato. Questo controllo dello stato OCI esegue una richiesta HEAD a tale endpoint tramite HTTPS. L'intestazione host è necessaria per specificare il nome del front-end da sottoporre a test (in questo esempio, osbfrontend.example.com) quando si utilizzano host virtuali denominati nei server Web e nei load balancer.

Elemento di configurazione	Valori di esempio
Nome controllo dello stato	OSB_IS_ALIVE
Destinazioni	111.111.111.111 (IP LBR Francoforte) 222.222.222.222 (IP Amsterdam LBR)
Punti di osservazione	Microsoft Azure Nord Europa Google Stati Uniti orientali
Type	HTTP
Protocollo	HTTPS
Porta	443
Percorso	/`default/isOSBReadySample`
Intestazioni	Ospite: osbfrontend.example.com:443
Metodo	HEAD
aggregazione	30 secondi
Timeout	10 secondi

Controllo dello stato per la console remota WebLogic front-end EM_IS_ALIVE.

OCI Health Checks esegue una richiesta HEAD con HTTPS al percorso /em/faces/targetauth/emasLogin per verificare lo stato della console del controllo FMW.

Elemento di configurazione	Valori di esempio
Nome controllo dello stato	SOA_IS_ALIVE
Destinazioni	111.111.111.111 (IP LBR Francoforte) 222.222.222.222 (IP Amsterdam LBR)
Punti di osservazione	Microsoft Azure Nord Europa Google Stati Uniti orientali
Type	HTTP
Protocollo	HTTPS
Porta	443
Percorso	`/em/faces/targetauth/emasLogin`
Intestazioni	Ospite: admin.example.com:445
Metodo	HEAD
aggregazione	30 secondi
Timeout	10 secondi

Usa un load balancer globale di terze parti

In alternativa ai criteri di indirizzamento per la gestione del traffico di Oracle Cloud Infrastructure (OCI), puoi utilizzare un load balancer globale (GLBR) di terze parti.

Sarà responsabile dell'esecuzione dell'instradamento intelligente delle richieste tra i load balancer locali.

GLBR è un load balancer configurato per essere accessibile come indirizzo dagli utenti di tutti i siti e le posizioni esterne. Il dispositivo fornisce un server virtuale mappato a un nome DNS (Domain Name System) accessibile a qualsiasi client, indipendentemente dal sito a cui si connetterà.

GLBR indirizza il traffico a entrambi i siti in base a criteri e regole configurati. Questi criteri possono essere basati sull'IP del client, ad esempio. Questa opzione deve essere utilizzata per creare un profilo di persistenza che consenta al GLBR di mappare gli utenti sullo stesso sito in caso di richieste iniziali e successive. GLBR gestisce un pool costituito dagli indirizzi di tutti i load balancer locali. In caso di guasto di uno dei siti, gli utenti vengono automaticamente reindirizzati al sito attivo sopravvissuto.

In ogni sito, un load balancer locale riceve la richiesta dal GLBR e indirizza le richieste al server HTTP appropriato. Per eliminare i cicli indesiderati, il GLBR è configurato anche con regole specifiche che instradano i callback solo al LBR che è locale ai server che li hanno generati. Ad esempio, è utile per i consumer interni dei servizi Oracle SOA. Le regole GLBR possono essere riepilogate come indicato di seguito.

Se le richieste provengono da site1 (ad esempio, le richieste provenienti dai server WebLogic nel sito 1), GLBR instrada l'LBR in site1.
Se le richieste provengono da site2 (ad esempio, le richieste originate dai server WebLogic nel sito 2), GLBR instrada l'LBR in site2.
Se le richieste provengono da qualsiasi altro indirizzo (invocazioni client), il carico GLBR bilancia le connessioni a entrambi gli LBR.
Ulteriori regole di instradamento possono essere definite nel GLBR per instradare client specifici a siti specifici (ad esempio, i due siti possono fornire tempi di risposta diversi in base alle risorse hardware in ogni caso).

Imposta altre risorse

Le due aree possono utilizzare risorse esterne, ad esempio LDAP, aree di memorizzazione delle identità, aree di memorizzazione dei criteri, destinazioni JMS (Java Message Service) esterne, servizi Web esterni, Oracle Cloud Infrastructure Object Storage e così via.

I dettagli di configurazione per queste risorse esterne non rientrano nell'ambito di questo documento. È necessario, tuttavia, che queste risorse siano coerenti in entrambe le regioni per fornire un comportamento uniforme.

Ad esempio, in Oracle SOA, i callback asincroni possono reidratare le istanze avviate in un'area diversa. Analogamente, in caso di ripristino automatico, qualsiasi Oracle WebLogic Server può assumere il ruolo di master cluster ed eseguire operazioni di recupero in entrambe le aree. Per garantire che questi processi funzionino senza problemi e forniscano un comportamento coerente, le stesse risorse esterne devono essere accessibili da entrambe le aree.