Informazioni sulla distribuzione di Oracle E-Business Suite su Oracle Cloud Infrastructure

Se si desidera eseguire il provisioning di Oracle E-Business Suite su Oracle Cloud Infrastructure o eseguire la migrazione degli ambienti Oracle E-Business Suite dal data center a Oracle Cloud Infrastructure, è possibile pianificare una topologia multihost, sicura e ad alta disponibilità.

Oracle fornisce l'automazione per eseguire il provisioning, la migrazione e la gestione del ciclo di vita degli ambienti Oracle E-Business Suite in Oracle Cloud Infrastructure seguendo le procedure ottimali descritte in questo documento. Ciò può eliminare gran parte della complessità della distribuzione manuale e della gestione. Rivedere il documento 2517025.1, Guida introduttiva a Oracle E-Business Suite e Oracle Cloud Infrastructure per ulteriori informazioni.

Considerazioni per la distribuzione su Oracle Cloud Infrastructure

Oracle consiglia di creare subnet separate per le istanze, ad esempio host bastion, database, applicazione e istanze load balancer, per garantire che i requisiti di sicurezza appropriati possano essere implementati tra le diverse subnet.

Subnet private o pubbliche

È possibile creare istanze in una subnet privata o pubblica in base al fatto che si desideri consentire l'accesso alle istanze da Internet. Alle istanze create in una subnet pubblica viene assegnato un indirizzo IP pubblico ed è possibile accedere a queste istanze da Internet. Impossibile assegnare un indirizzo IP pubblico alle istanze create in una subnet privata. Pertanto non è possibile accedere a queste istanze su Internet.

L'immagine seguente mostra una rete cloud virtuale (VCN) con subnet pubbliche e private. VCN contiene due domini di disponibilità e ogni dominio di disponibilità contiene una subnet pubblica e privata. I server Web vengono posizionati nella subnet pubblica in questa immagine, pertanto a ogni istanza del server Web è associato un indirizzo IP pubblico. È possibile accedere a queste istanze di Oracle Cloud nella subnet pubblica da Internet abilitando la comunicazione tramite il gateway Internet (IGW). Sarà necessario aggiornare la tabella di instradamento per abilitare il traffico da e per la IGW. Per consentire il traffico verso i server Web da Internet, è necessario creare load balancer nella subnet pubblica. Per accedere alle istanze da Internet, è inoltre necessario creare un host bastione nella subnet pubblica e accedere all'host bastione dalla IGW.

I database server vengono posizionati nella subnet privata in questa immagine. È possibile accedere alle istanze Oracle Cloud nella subnet privata dai data center mediante il gateway di instradamento dinamico (DRG). DRG connette le reti in locale alla rete cloud. Per abilitare la comunicazione tra DRG e l'apparecchiatura in locale del cliente, utilizzare IPSec VPN o Oracle Cloud Infrastructure FastConnect. Sarà inoltre necessario aggiornare la tabella di instradamento per abilitare il traffico da e per DRG.

Descrizione dell'immagine public_private_subnets_jde.png

Scenario 1: Distribuisci tutte le istanze nelle subnet private

Oracle consiglia di distribuire tutte le istanze nelle subnet private per gli ambienti di produzione in cui non esistono endpoint con interfaccia Internet. Questo tipo di distribuzione è utile quando si desidera disporre di una distribuzione ibrida con il cloud come estensione ai data center esistenti.

In questa distribuzione, tutte le istanze, inclusi gli Application e i database server, vengono distribuite in una subnet privata. Impossibile assegnare un indirizzo IP pubblico alle istanze create in una subnet privata, pertanto non è possibile accedere a queste istanze su Internet. Per accedere ai server applicazioni dall'ambiente locale in questa configurazione, è possibile effettuare le operazioni riportate di seguito.

Configurare un tunnel VPN IPSec tra il data center e Oracle Cloud Infrastructure DRG prima di eseguire il provisioning degli Application Server.
Creare un host bastion in questa configurazione, quindi accedere a tutti i server nella subnet privata dall'host bastion.

Scenario 2: Distribuisci istanze in subnet pubbliche e private

È possibile distribuire alcune istanze in una subnet pubblica e alcune istanze in una subnet privata. Questo tipo di distribuzione è utile quando la distribuzione include endpoint rivolti verso Internet e non verso Internet.

In questa configurazione, alcune istanze di applicazione vengono inserite in una subnet pubblica e altre vengono inserite in una subnet privata. Ad esempio, è possibile che le istanze di applicazione servano utenti interni e un altro set di istanze di applicazione che servono utenti esterni. In questo scenario, posizionare le istanze dell'applicazione che servono il traffico interno in una subnet privata e posizionare gli Application Server che servono il traffico esterno in una subnet pubblica. È inoltre possibile impostare un load balancer pubblico sulle istanze di applicazione rivolte alla rete anziché posizionare gli Application Server che servono traffico esterno in una subnet pubblica. Se si posiziona l'host bastione in una subnet pubblica, all'host bastione viene assegnato un indirizzo IP pubblico e è possibile accedervi tramite Internet. È possibile accedere alle istanze nella subnet privata tramite il server bastion.

Scenario 3: Distribuisci tutte le istanze nelle subnet pubbliche

Oracle consiglia questa distribuzione per dimostrazioni rapide o per distribuzioni a livello di produzione senza endpoint interni. Questa distribuzione è adatta solo se non si dispone del proprio data center o non è possibile accedere alle istanze tramite VPN e si desidera accedere all'infrastruttura su Internet.

In questa distribuzione, tutte le istanze, incluse le istanze dell'applicazione e del database, vengono distribuite nelle subnet pubbliche.

Ad ogni istanza della subnet pubblica è associato un indirizzo IP pubblico. Sebbene sia possibile accedere a istanze con indirizzi IP pubblici su Internet, è possibile limitare l'accesso utilizzando liste di sicurezza e regole di sicurezza. Per eseguire i task di amministrazione, Oracle consiglia di inserire un host bastion in questa configurazione. In questo scenario, non è possibile aprire porte di amministrazione a Internet pubblico, ma aprire le porte di amministrazione solo all'host bastione e impostare liste di sicurezza e regole di sicurezza per garantire che l'istanza possa essere accessibile solo dall'host bastione.

Anti-Affinità

Durante la creazione di più istanze per l'alta disponibilità in un dominio di disponibilità in Oracle Cloud Infrastructure, è possibile ottenere l'anti-affinità per le istanze utilizzando domini di errore.

Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità contiene tre domini di errore. I domini di errore consentono di distribuire le istanze in modo che queste non si trovino sullo stesso hardware fisico all'interno di un singolo dominio di disponibilità. Pertanto, un errore hardware o una manutenzione hardware di Oracle Compute che influisce su un dominio di errore non influisce sulle istanze in altri domini di errore. Utilizzando i domini di errore, è possibile proteggere le istanze da errori hardware imprevisti e indisponibilità pianificate.

Per un'elevata disponibilità di database, è possibile creare un sistema DB Virtual Machine (VM) a 2 nodi, che fornisce Oracle Real Applications Clusters (Oracle RAC). Per impostazione predefinita, i due nodi di Oracle RAC vengono sempre creati in domini di errore separati. È inoltre possibile scegliere manualmente un dominio di errore per i nodi RAC durante il provisioning del database Oracle RAC. Pertanto, i nodi del database non si trovano sullo stesso host fisico né sullo stesso rack fisico. Ciò protegge le istanze di database dagli errori fisici di base e dagli switch top-of-the-rack.

Architettura

È possibile progettare la distribuzione di Oracle E-Business Suite su Oracle Cloud Infrastructure in un singolo dominio di disponibilità, in più domini di disponibilità o in più aree. Inoltre, è possibile incorporare una zona demilitarizzata per isolare il traffico esterno e proteggere i sistemi interni.

Dominio a disponibilità singola: è possibile distribuire Oracle E-Business Suite in un singolo dominio di disponibilità e garantire comunque un'elevata disponibilità impostando più istanze di applicazione. Utilizzare questa architettura quando si desidera assicurarsi che l'applicazione sia disponibile anche quando un'istanza dell'applicazione non è attiva. Le altre istanze di applicazione disponibili nel dominio di disponibilità continuano a elaborare le richieste.
Dominio a disponibilità singola con una zona demilitarizzata (DMZ): utilizzare questa architettura quando si desidera che l'applicazione sia accessibile da reti esterne non sicure mentre i sistemi interni sono isolati dalla rete esterna.
Più domini di disponibilità: utilizzare questa architettura quando si desidera garantire che l'applicazione sia disponibile anche quando un dominio di disponibilità viene inattivo. È ancora possibile accedere alle istanze dell'applicazione in un altro dominio di disponibilità.
Più aree: utilizzare questa architettura quando si desidera impostare un sito di disaster recovery per l'applicazione in un'area diversa. Questa architettura è essenzialmente la stessa dell'architettura del dominio di disponibilità multipla, ma invece di creare risorse in un secondo dominio di disponibilità nella stessa area, è possibile creare risorse in un'altra area.

Nota:

È possibile configurare un DMZ anche nei casi di più domini di disponibilità e di più aree.

Architettura per la distribuzione di Oracle E-Business Suite in un singolo dominio di disponibilità

Questa architettura mostra la distribuzione di un'applicazione Oracle E-Business Suite in un singolo dominio di disponibilità, garantendo al contempo un'elevata disponibilità.

L'architettura è costituita da una rete cloud virtuale (VCN) con gli host bastion, load balancer, applicazione e database posizionati in subnet separate di VCN in un singolo dominio di disponibilità. Nel seguente diagramma di architettura, l'host bastion viene distribuito in una subnet pubblica e tutte le altre istanze vengono distribuite in subnet private. È possibile posizionare le diverse istanze nelle subnet pubbliche o private in base alle esigenze aziendali.

In questa architettura, più istanze di livello applicazione vengono distribuite in un singolo dominio di disponibilità, ma le singole istanze di livello applicazione vengono posizionate in domini di errore separati, consentendo un'elevata disponibilità del livello applicazione. I domini di errore consentono di distribuire le istanze in modo che non si trovino sullo stesso hardware fisico all'interno di un singolo dominio di disponibilità. Di conseguenza, un errore hardware o una manutenzione hardware che influisce su un dominio di errore non influisce sulle istanze in altri domini di errore.

Le istanze nella subnet privata richiedono la connessione in uscita alla rete Oracle Services per applicare gli aggiornamenti del sistema operativo (yum). A tal fine, utilizzare un gateway di servizio in VCN. Con un gateway di servizio, gli host nella subnet privata possono accedere ai servizi Oracle supportati (ad esempio il repository yum) in modo privato. Le istanze nella subnet privata possono facoltativamente richiedere la connessione in uscita a Internet per scaricare le patch dell'applicazione e per le integrazioni esterne. A tal fine, utilizzare un gateway NAT (Network Address Translation) in VCN. Con un gateway NAT, gli host nella subnet privata possono avviare connessioni a Internet e ricevere risposte, ma non riceveranno connessioni in entrata avviate da Internet.

Tutte le istanze dell'applicazione nel dominio di disponibilità sono attive. Le istanze del load balancer ricevono richieste e le inviano ai server applicazioni. Gli Application Server elaborano queste richieste e le inoltrano alle istanze di database. È possibile accedere alle istanze nelle subnet private sulla porta 22 mediante l'host bastion o il gateway instradamento dinamico (DRG) se è stato impostato un tunnel VPN IPSec tra il data center e Oracle Cloud Infrastructure DRG.

Oracle consiglia che il database e le applicazioni distribuite su Oracle Cloud Infrastructure dispongano di una solida strategia di backup e recupero. Si consiglia di memorizzare i backup dei database e delle istanze di applicazione in Oracle Cloud Infrastructure Object Storage. I database e le istanze a livello di applicazione nelle subnet private possono essere sottoposti a backup in Oracle Cloud Infrastructure Object Storage utilizzando un gateway di servizio. Un gateway di servizio fornisce l'accesso a Oracle Cloud Infrastructure Object Storage senza attraversare Internet.

I backup automatici e su richiesta del database in Oracle Cloud Infrastructure Object Storage possono essere configurati utilizzando la console Oracle Cloud Infrastructure. Ciò richiede la connettività a Oracle Cloud Infrastructure Object Storage utilizzando un endpoint Swift. Tutti i backup del database in Oracle Cloud Infrastructure Object Storage vengono cifrati con la stessa chiave principale utilizzata per la cifratura del wallet TDE (Transparent Data Encryption). Il servizio di backup automatico del database utilizza la strategia di backup incrementale settimanale per eseguire il backup dei database con un criterio di conservazione personalizzato che è possibile personalizzare durante la configurazione dei backup automatici.

Il backup dell'applicazione può essere configurato utilizzando la funzione di backup basata su criteri di Oracle Cloud Infrastructure Block Volumes. Oracle Cloud Infrastructure Block Volumes consente di eseguire automaticamente i backup del volume in base a una pianificazione e di conservarli in base al criterio di backup selezionato. Ciò consente di rispettare i requisiti di conformità e di regolamentazione dei dati. Esistono tre criteri di backup predefiniti: Bronzo, Argento e Oro. Ogni criterio di backup ha una frequenza di backup e un periodo di conservazione predefiniti.

Descrizione dell'immagine single_availability_domain_ha_topology.png

Questa architettura supporta i seguenti componenti:

Host di base: l'host bastion è un componente facoltativo che può essere utilizzato come server jump per accedere alle istanze nella subnet privata. Un host bastion è un'istanza di Oracle Cloud Infrastructure Compute che utilizza Linux come sistema operativo. Posizionare l'host bastione in una subnet pubblica e assegnargli un indirizzo IP pubblico per accedervi da Internet.

Per fornire un ulteriore livello di sicurezza, è possibile impostare liste di sicurezza per accedere all'host bastion solo dall'indirizzo IP pubblico della rete locale. È possibile accedere alle istanze di Oracle Cloud Infrastructure nella subnet privata tramite l'host bastion. A tale scopo, abilitare l'inoltro ssh-agent, che consente di connettersi all'host bastion, quindi accedere al server successivo inoltrando le credenziali dal computer. È inoltre possibile accedere alle istanze nella subnet privata utilizzando il tunnel SSH dinamico. Il tunneling SSH è un modo per accedere a un'applicazione Web o ad altri servizi di ascolto. Il tunnel dinamico fornisce un proxy SOCKS sulla porta locale, ma le connessioni provengono dall'host remoto.
Livello load balancer: questo livello contiene Oracle Cloud Infrastructure Load Balancing. Riceve richieste dagli utenti dell'applicazione, quindi carica il traffico dei saldi nei server applicazioni Oracle E-Business Suite. Utilizzare Oracle Cloud Infrastructure Load Balancing per distribuire il traffico alle istanze dell'applicazione all'interno di un VCN. Questo servizio fornisce un'istanza primaria e in standby del load balancer per garantire che se il load balancer principale non è attivo, il load balancer in standby inoltri le richieste. Il load balancer garantisce che le richieste vengano instradate alle istanze dell'applicazione in buono stato. Se si verifica un problema con un'istanza dell'applicazione, il load balancer rimuove tale istanza dalla configurazione e avvia il instradamento delle richieste alle restanti istanze dell'applicazione in buono stato.
Livello applicazione: questo livello contiene più istanze di un'applicazione Oracle E-Business Suite per fornire un'elevata disponibilità. Impostare più istanze di un'applicazione in un dominio di errore separato per assicurarsi di poter continuare ad accedere all'applicazione anche se un'istanza dell'applicazione non è attiva.

Oracle consiglia di distribuire l'impostazione a più livelli di Oracle E-Business Suite con i file binari dell'applicazione condivisa. Utilizzare Oracle Cloud Infrastructure File Storage per creare un file system condiviso per condividere i file binari dell'applicazione Oracle E-Business Suite.
Livello di database: questo livello contiene istanze di Oracle Cloud Infrastructure Database. Per i requisiti di alta disponibilità, Oracle consiglia di utilizzare un sistema DB VM (Virtual Machine) a 2 nodi o Exadata DB System.

Architettura per la distribuzione di Oracle E-Business Suite con una zona Demilitarizzata (DMZ)

Questa architettura mostra la distribuzione di un'applicazione Oracle E-Business Suite in un singolo dominio di disponibilità contenente un DMZ.

L'architettura è costituita da una rete cloud virtuale (VCN) con l'host bastion, un load balancer interno, un livello di applicazione interno, un load balancer esterno, un livello di applicazione esterno e host di database posizionati in subnet separate di VCN in un singolo dominio di disponibilità. Nel seguente diagramma di architettura, il load balancer esterno viene distribuito in una subnet pubblica e tutte le altre istanze vengono distribuite in subnet private.

Segue una descrizione dell'immagine ebs-singlead-dmz.png
Descrizione dell'immagine ebs-singlead-dmz.png

Il DMZ, implementato utilizzando una subnet del load balancer pubblico, riceve richieste da partner commerciali e fornitori, mentre il load balancer interno, implementato utilizzando una subnet del load balancer privato, riceve richieste da utenti interni. I livelli di applicazione dedicati elaborano le richieste provenienti da questi due diversi tipi di utenti.

Oracle consiglia che il database e le applicazioni distribuite su Oracle Cloud Infrastructure dispongano di una solida strategia di backup e recupero. Si consiglia di memorizzare i backup dei database e delle istanze a livello di applicazione in Oracle Cloud Infrastructure Object Storage. I database e le istanze a livello di applicazione nelle subnet private possono essere sottoposti a backup in Oracle Cloud Infrastructure Object Storage utilizzando un gateway di servizio. Un gateway di servizio fornisce l'accesso a Oracle Cloud Infrastructure Object Storage senza attraversare Internet.

Questa architettura supporta i seguenti componenti:

Host di base: l'host bastion è un componente facoltativo che può essere utilizzato come server jump per accedere alle istanze nella subnet privata. Un host bastion è un'istanza di Oracle Cloud Infrastructure Compute che utilizza Linux come sistema operativo.

Per fornire un ulteriore livello di sicurezza, è possibile impostare liste di sicurezza per accedere all'host bastion solo dall'indirizzo IP pubblico della rete locale. È possibile accedere alle istanze di Oracle Cloud Infrastructure nella subnet privata tramite l'host bastion. A tale scopo, abilitare l'inoltro ssh-agent, che consente di connettersi all'host bastion, quindi accedere al server successivo inoltrando le credenziali dal computer. È inoltre possibile accedere alle istanze nella subnet privata utilizzando il tunnel SSH dinamico. Il tunneling SSH è un modo per accedere a un'applicazione Web o ad altri servizi di ascolto. Il tunnel dinamico fornisce un proxy SOCKS sulla porta locale, ma le connessioni provengono dall'host remoto.
Livello load balancer interno Questo livello contiene Oracle Cloud Infrastructure Load Balancing. Riceve richieste dagli utenti interni dell'applicazione, quindi carica il traffico dei saldi nei server applicazioni interni di Oracle E-Business Suite. Utilizzare Oracle Cloud Infrastructure Load Balancing per distribuire il traffico alle istanze dell'applicazione all'interno di un VCN. Questo servizio fornisce un'istanza primaria e in standby del load balancer per garantire che se il load balancer principale non è attivo, il load balancer in standby inoltri le richieste. Il load balancer garantisce che le richieste vengano instradate alle istanze dell'applicazione in buono stato. Se si verifica un problema con un'istanza dell'applicazione, il load balancer rimuove tale istanza dalla configurazione e avvia il instradamento delle richieste alle restanti istanze dell'applicazione in buono stato.
Livello load balancer esterno: questo livello ha lo stesso scopo del livello load balancer interno, ma per utenti di applicazioni esterne, ad esempio quelli associati ai fornitori.
Livello applicazione: questo livello contiene più istanze di un'applicazione Oracle E-Business Suite per fornire un'elevata disponibilità. Impostare più istanze di un'applicazione in un dominio di errore separato per assicurarsi di poter continuare ad accedere all'applicazione anche se un'istanza dell'applicazione non è attiva.

In questa architettura, sfruttando livelli applicativi separati per gli utenti interni ed esterni, è possibile isolare il traffico e proteggere la sicurezza del sistema.

Oracle consiglia di distribuire l'impostazione a più livelli di Oracle E-Business Suite con i file binari dell'applicazione condivisa. Utilizzare Oracle Cloud Infrastructure File Storage per creare un file system condiviso per condividere i file binari dell'applicazione Oracle E-Business Suite.
Livello di database: questo livello contiene istanze di Oracle Cloud Infrastructure Database. Per i requisiti di alta disponibilità, Oracle consiglia di utilizzare un sistema DB VM (Virtual Machine) a 2 nodi o Exadata DB System.

Architettura per distribuire Oracle E-Business Suite in più domini di disponibilità

Questa architettura mostra la distribuzione di un'applicazione Oracle E-Business Suite su più domini di disponibilità. Mostra una rete cloud virtuale (VCN) con le istanze bastion, load balancer, applicazione e database posizionate in subnet separate in due domini di disponibilità.

In ogni dominio di disponibilità vengono distribuiti più Application Server per garantire un'elevata disponibilità all'interno di un dominio di disponibilità. Tutti gli Application Server all'interno di un dominio di disponibilità vengono distribuiti su domini di errore diversi. Utilizzando domini di errore diversi, le istanze dell'applicazione sono protette da errori hardware imprevisti e indisponibilità pianificate a causa della manutenzione hardware. Inoltre, per garantire la disponibilità nel caso in cui il dominio di disponibilità primario non sia disponibile, le istanze ridondanti vengono create in un altro dominio di disponibilità. Nel diagramma di architettura, le istanze nel dominio di disponibilità 1 sono attive e le istanze nel dominio di disponibilità 2 sono in standby. Oracle consiglia di impostare le istanze di applicazione e di database nella topologia simmetrica tra i domini di disponibilità per garantire che le istanze attive servano l'intero carico quando il dominio di disponibilità primario non è disponibile. Nella topologia simmetrica è possibile distribuire lo stesso numero di istanze di applicazione e database sia sui siti attivi che in standby. Quando le istanze nel dominio di disponibilità 1 sono attive, il load balancer è configurato per indirizzare il traffico solo a queste istanze attive. Il load balancer non è configurato per indirizzare il traffico alle istanze dell'Application Server nel dominio di disponibilità 2. Ciò significa che le istanze dell'applicazione nel dominio di disponibilità 2 non vengono aggiunte al set di backend del load balancer. Se il dominio di disponibilità 1 non è disponibile, sarà necessario passare manualmente l'applicazione e il database all'altro dominio di disponibilità. In questo scenario, le istanze dell'applicazione e del database server nel dominio di disponibilità 2 diventano attive. In questo momento è necessario aggiornare il set di backend del load balancer con le istanze dell'applicazione nel dominio di disponibilità 2 e rimuovere anche le istanze dell'applicazione del dominio di disponibilità 1. Il load balancer accetterà le richieste e le inoltrerà ai server applicazioni nel dominio di disponibilità 2.

Per un failover senza soluzione di continuità tra i domini di disponibilità, utilizzare i nomi host logici per il database Oracle E-Business Suite e le istanze di applicazione. Utilizzare gli stessi nomi host logici nei siti primario e in standby per ridurre lo sforzo di riconfigurazione delle istanze durante lo switchover o il failover.

È consigliabile che il database e l'applicazione distribuiti su Oracle Cloud Infrastructure dispongano di un backup robusto della strategia di recupero. Si consiglia di memorizzare il backup dei database e delle istanze di applicazione in Oracle Cloud Infrastructure Object Storage. I database e le istanze di applicazione nelle subnet private possono essere sottoposti a backup in Oracle Cloud Infrastructure Object Storage utilizzando un gateway di servizio. Un gateway di servizio fornisce l'accesso a Oracle Cloud Infrastructure Object Storage senza attraversare Internet.

Il servizio di backup automatico del database utilizza una strategia di backup incrementale settimanale per eseguire il backup dei database con un criterio di conservazione di 30 giorni. È inoltre possibile eseguire un backup completo su richiesta dei database per i requisiti ad hoc.

Nel seguente diagramma di architettura, l'host bastion viene distribuito in una subnet pubblica e tutte le altre istanze vengono distribuite in subnet private. È possibile posizionare le diverse istanze nelle subnet pubbliche o private in base alle esigenze aziendali. È possibile accedere alle istanze nelle subnet private sulla porta 22 mediante l'host bastion o DRG se è stato impostato un tunnel VPN IPSec tra il data center e Oracle Cloud Infrastructure DRG.

Descrizione dell'immagine multiple_availability_domain_ha_topology.png

Questa architettura supporta i seguenti componenti:

Host di base: l'host bastion è un componente facoltativo che è possibile utilizzare come server jump per accedere alle istanze dell'applicazione e del database. Per un'elevata disponibilità, distribuire un host bastione in entrambi i domini di disponibilità.
Livello load balancer: Oracle Cloud Infrastructure Load Balancing distribuisce il traffico tra gli Application Server in un dominio di disponibilità. Il load balancer può essere eseguito come load balancer pubblico o privato.
Livello applicazione: in ogni dominio di disponibilità vengono impostati più Application Server per garantire un'elevata disponibilità. Lo stato degli Application Server nel dominio di disponibilità 1 è attivo e gli Application Server nel dominio di disponibilità 2 sono passivi. Per sincronizzare gli Application Server tra i domini di disponibilità, utilizzare rsync.

Oracle consiglia di distribuire l'impostazione a più livelli di Oracle E-Business Suite con i file binari dell'applicazione condivisa. Utilizzare Oracle Cloud Infrastructure File Storage per creare un file system condiviso per condividere i file binari dell'applicazione Oracle E-Business Suite.
Livello di database: impostare istanze di database altamente disponibili in entrambi i domini di disponibilità. Il diagramma di architettura mostra che i database server nel dominio di disponibilità 1 sono attivi e che i database server nel dominio di disponibilità 2 sono in standby. Per replicare il database in tutti i domini di disponibilità, utilizzare Oracle Active Data Guard o Oracle Data Guard. È possibile abilitare Oracle Data Guard per un database dalla console Oracle Cloud Infrastructure o utilizzando le API Oracle Cloud Infrastructure.

Architettura per la distribuzione di Oracle E-Business Suite in più aree

È possibile distribuire l'applicazione Oracle E-Business Suite in più aree per il recupero di emergenza. Questa architettura è simile alla distribuzione dell'applicazione Oracle E-Business Suite su più domini di disponibilità. In questa architettura bastion, load balancer, applicazione e istanze di database vengono posizionate in subnet separate in più aree.

Per garantire la disponibilità nel caso in cui l'area principale non sia disponibile, nell'area in standby vengono create istanze ridondanti. L'area primaria contiene istanze attive in un dominio di disponibilità. Le istanze in un dominio di disponibilità nella seconda area, denominata area di disaster recovery, sono in standby. Oracle consiglia di impostare le istanze di applicazione e di database nella topologia simmetrica in tutte le aree per garantire che le istanze attive servano l'intero carico quando l'area primaria non è disponibile. Nella topologia simmetrica è possibile distribuire lo stesso numero di istanze di applicazione e database sia nelle aree primarie che in standby. In questa architettura, in ogni dominio di disponibilità vengono distribuiti più Application Server per garantire un'elevata disponibilità all'interno di un dominio di disponibilità.

Poiché questa architettura è distribuita in un solo dominio di disponibilità nell'area 1 e in un dominio di disponibilità nell'area 2 per il recupero di emergenza, non fornisce tolleranza di errore per il dominio di disponibilità nell'area 1. Se l'unico dominio di disponibilità in cui è stata distribuita l'applicazione non è disponibile, sarà necessario richiamare il disaster recovery per eseguire il failover dell'applicazione nell'area 2.

Se le istanze nell'area 1 non sono disponibili, è necessario passare manualmente alle istanze nell'area 2. Per un failover senza interruzioni in tutte le aree, utilizzare i nomi host logici per il database Oracle E-Business Suite e le istanze di applicazione. Utilizzare gli stessi nomi host logici sui siti primario e in standby per semplificare il failover o il switchback senza riconfigurare le istanze.

Per replicare il database in più aree, utilizzare Oracle Active Data Guard o Oracle Data Guard in modalità asincrona. Per sincronizzare gli Application Server in più aree, utilizzare rsync.

Segue una descrizione dell'immagine multiple_region_topology.png
Descrizione dell'immagine multiple_region_topology.png