1. Informazioni sulla distribuzione di JD Edwards EnterpriseOne su Oracle Cloud Infrastructure
  2. Informazioni sulla distribuzione di JD Edwards EnterpriseOne su Oracle Cloud Infrastructure

Informazioni sulla distribuzione di JD Edwards EnterpriseOne su Oracle Cloud Infrastructure

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

Prima di iniziare

Oracle Cloud Infrastructure supporta l'applicazione JD Edwards EnterpriseOne release 9.0, 9.1 e 9.2. Prima di iniziare a pianificare la distribuzione o la migrazione dell'applicazione JD Edwards EnterpriseOne, identificare se Oracle Cloud Infrastructure supporta la combinazione di release dell'applicazione JD Edwards EnterpriseOne, release degli strumenti JD Edwards EnterpriseOne e sistema operativo su cui si desidera eseguire le applicazioni.

  • Applicazione JD Edwards EnterpriseOne release 9.2 con JD Edwards EnterpriseOne Tools release 9.2. x. Supporta l'installazione manuale e automatica dei componenti JD Edwards EnterpriseOne sui sistemi operativi Oracle Linux e Windows.

  • L'applicazione JD Edwards EnterpriseOne release 9.1 con JD Edwards EnterpriseOne Tools rilascia 9.1. x o 9.2. x. Supporta solo l'installazione manuale dei componenti JD Edwards EnterpriseOne sui sistemi operativi Oracle Linux e Windows.

Per informazioni sulle versioni precedenti dell'applicazione JD Edwards EnterpriseOne, contattare Oracle Advanced Consulting Services.

Per informazioni sulle certificazioni definitive, fare riferimento a My Oracle Support.

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 e è 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, in modo che le istanze del server Web dispongano di un indirizzo IP pubblico ad essa collegato. È 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.


Segue una descrizione dell'immagine public_private_subnets_jde.png
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 in 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 oppure non è possibile accedere alle istanze tramite VPN e si desidera accedere all'infrastruttura tramite 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 tramite Internet, è possibile limitare l'accesso utilizzando liste di sicurezza e regole di sicurezza. Per eseguire task di amministrazione, Oracle consiglia di inserire un host bastione 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 sia 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 la 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 l'alta disponibilità dei database, è possibile creare sistemi di database Oracle Real Application Clusters (Oracle RAC) a 2 nodi. Per impostazione predefinita, i due nodi di Oracle RAC vengono sempre creati in domini di errore separati. 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 dalla parte superiore dello switch rack.

Architettura per la distribuzione di JD Edwards EnterpriseOne in un'unica area

È possibile distribuire JD Edwards EnterpriseOne in un singolo dominio di disponibilità assicurando l'alta disponibilità.

È possibile ottenere un'elevata disponibilità posizionando le istanze dell'applicazione all'interno di più domini di errore. Utilizzare questa architettura quando si desidera assicurarsi che l'applicazione sia disponibile anche quando un'istanza dell'applicazione viene inattiva in un dominio di errore. Le altre istanze di applicazione disponibili all'interno dell'altro dominio di errore continuano a elaborare le richieste. È possibile distribuire JD Edwards EnterpriseOne manualmente o utilizzando gli strumenti di automazione di JD Edwards EnterpriseOne su Oracle Cloud Infrastructure.

Questa architettura mostra che le istanze ridondanti vengono distribuite nel livello di presentazione e nel livello intermedio in un dominio di disponibilità per garantire un'elevata disponibilità all'interno del dominio di disponibilità. Tutte le istanze nel dominio di disponibilità sono attive. Questa elevata disponibilità di un'applicazione all'interno di un dominio di disponibilità può essere ottenuta posizionando istanze di applicazione in domini di errore separati. 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à. Un errore hardware o una manutenzione hardware di Oracle Cloud Infrastructure Compute che influisce su un dominio di errore non influisce sulle istanze in altri domini di errore. Se un'istanza non riesce, il traffico viene deviato verso altre istanze nel dominio di disponibilità che continuano a elaborare le richieste. Tuttavia, se la connessione al dominio di disponibilità non riesce o l'intero dominio di disponibilità non è attivo, le istanze non sono disponibili per elaborare le richieste.

Le istanze nella subnet privata richiedono la connessione in uscita a Internet per scaricare le patch e per applicare gli aggiornamenti del sistema operativo e dell'applicazione. 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.

Oracle consiglia che il database e le applicazioni distribuite 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.

I backup automatici e su richiesta del database in Oracle Cloud Infrastructure Object Storage possono essere configurati mediante Oracle Cloud Infrastructure Console. Ciò richiede la connettività a Oracle Cloud Infrastructure Object Storage mediante 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 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.

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 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.

L'architettura è costituita da una rete cloud virtuale (VCN) con host bastion, livello load balancer, livello di presentazione, livello intermedio, livello di amministrazione e livello di database. I livelli vengono posizionati in una singola subnet di VCN in un singolo dominio di disponibilità.

Nel seguente diagramma di architettura, l'host bastione viene distribuito in una subnet pubblica e tutte le altre istanze vengono posizionate in subnet private. A seconda dei requisiti aziendali, è possibile posizionare le istanze nelle subnet pubbliche o private. È possibile accedere alle istanze presenti nelle subnet private sulla porta 22 mediante l'host bastion o il gateway di instradamento dinamico (DRG). Per abilitare la comunicazione tra DRG e l'apparecchiatura in locale del cliente, utilizzare IPSec VPN o Oracle Cloud Infrastructure FastConnect.

Server Manager nel livello Amministrazione comunica con il livello Presentazione, il livello intermedio e il livello Database per fornire la distribuzione del codice, la gestione della configurazione, l'accesso alle metriche runtime e l'accesso ai log. Il server di distribuzione nel livello di amministrazione comunica con il livello intermedio e il livello di database per creare e distribuire il codice. Il client di sviluppo comunica con il livello intermedio e il livello di database. ADF (Application Development Framework) e Oracle Business Intelligence Publisher comunicano con il server HTML nel livello Presentazione.


Segue una descrizione dell'immagine single_availability_domain_jd_edwards_deployment.png
Descrizione dell'immagine single_availability_domain_jd_edwards_deployment.png
Questa architettura è suddivisa in questi livelli:

  • 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 livello di sicurezza aggiuntivo, è 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 mediante 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 a un altro servizio di ascolto. Il tunnel dinamico fornisce un proxy SOCKS sulla porta locale, ma le connessioni provengono dall'host remoto.

  • Livello load balancer: il livello load balancer contiene le istanze Oracle Cloud Infrastructure Load Balancing che caricano il traffico in tutte le istanze del livello di presentazione. Il load balancer riceve richieste dagli utenti, quindi instrada queste richieste alle istanze nel livello di presentazione.

    Utilizzare Oracle Cloud Infrastructure Load Balancing per distribuire il traffico alle istanze di 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 è disponibile, il load balancer in standby inoltri le richieste. Il load balancer garantisce che le richieste vengano instradate alle istanze di applicazione in buono stato. Se si verifica un problema all'interno di un'istanza dell'applicazione, il load balancer instrada le richieste alle istanze di applicazione sane rimanenti.

    In base alle esigenze, è possibile posizionare i load balancer in una subnet pubblica o privata.

    • Per gli endpoint interni, che non sono accessibili da Internet, utilizzare un load balancer privato. Un load balancer privato ha un indirizzo IP privato e non è accessibile da Internet. Sia le istanze primarie che quelle in standby di un load balancer risiedono nella stessa subnet privata. È possibile accedere ai load balancer privati in VCN o nel data center tramite IPSec VPN tramite DRG. Il load balancer privato accetta il traffico dal data center e distribuisce il traffico alle istanze di applicazione di base.

    • Per gli endpoint rivolti a Internet, utilizzare un load balancer pubblico. Un load balancer pubblico ha un indirizzo IP pubblico ed è accessibile da Internet. È possibile accedere ai load balancer pubblici da Internet tramite il gateway Internet.

    • Per accedere agli endpoint interni e agli endpoint rivolti a Internet, impostare load balancer privati e load balancer pubblici. Impostare load balancer privati per servire il traffico interno e impostare load balancer pubblici per servire il traffico da Internet.

    Registrare l'indirizzo IP pubblico o privato delle istanze di Oracle Cloud Infrastructure Load Balancing nel server dei nomi di dominio locale o pubblico (DNS) per la risoluzione del dominio dell'endpoint dell'applicazione.

    Le porte fornite nel diagramma di architettura sono solo un esempio. È possibile utilizzare qualsiasi porta disponibile.

  • Livello di amministrazione: il livello di amministrazione contiene una singola istanza dei server riportati di seguito. Non è necessaria un'istanza ridondante di questi server per garantire un'elevata disponibilità.

    • Server di provisioning: utilizzare questo server per automatizzare la distribuzione end-to-end dei componenti JD Edwards EnterpriseOne su Oracle Cloud Infrastructure. Comunica con tutte le istanze negli altri livelli, incluse le istanze nel livello di database, sulla porta 22. Ospita JD Edwards EnterpriseOne One-Click Provisioning Console e JD Edwards EnterpriseOne Server Manager Console.

    • Server di distribuzione: durante il processo di installazione, questo server funge da repository centrale di tutti i file e pacchetti di installazione richiesti. Il software viene distribuito o distribuito su tutti gli altri server e client di questo server.

    • Client di sviluppo: il client di JD Edwards EnterpriseOne Development contiene componenti eseguiti come applicazioni Microsoft Windows standard (ad esempio Active Console, Forms Design Aid (FDA) e Report Design Aid (RDA)) e componenti eseguiti in un browser Web.

    • Server ADF (Application Development Framework): il server JD Edwards EnterpriseOne ADF è un'applicazione Web distribuita su un server Oracle WebLogic con runtime ADF. Viene utilizzato per eseguire applicazioni JD Edwards EnterpriseOne sviluppate con Oracle ADF.

    • Oracle Business Intelligence Publisher: Oracle Business Intelligence Publisher presenta i dati raccolti da JD Edwards EnterpriseOne sotto forma di report. Utilizzare Oracle Business Intelligence Publisher per presentare i report utilizzando modelli diversi in base alle esigenze aziendali. È possibile progettare e controllare le modalità di presentazione degli output dei report utilizzando i file dei modelli.

  • Livello di presentazione: il livello di presentazione contiene istanze ridondanti di Application Interface Services e Java Application Server per fornire un'elevata disponibilità. Questi server comunicano con i server nel livello intermedio. Tutte le istanze sono attive e ricevono traffico dal load balancer. Ogni istanza è associata a un volume di memorizzazione a blocchi. Questo livello contiene anche componenti che è possibile utilizzare per creare l'integrazione tra JD Edwards EnterpriseOne e un sistema esterno. L'implementazione può includere uno o più di questi componenti.

    Questo livello contiene i server riportati di seguito.

    • Server AIS (Application Interface Services): Application Interface Service Server fornisce l'interfaccia di comunicazione tra le applicazioni enterprise JD Edwards EnterpriseOne Mobile e JD Edwards EnterpriseOne.

    • Server applicazioni Java standard (JAS standard): riceve richieste dal load balancer ed esegue una logica business semplice. Per i task che richiedono una business logic complicata, JAS standard passa le richieste al server logico. In alcuni casi passa anche le richieste al server AIS. Tuttavia, non è configurato con il server AIS per il runtime AIS.

    • Server applicazioni Java dedicati (JAS dedicato): riceve richieste dal server AIS. Passa richieste al server logico per eseguire task che richiedono una business logic complicata. È configurato con il server AIS per il runtime AIS.

    Per garantire un'elevata disponibilità all'interno di un dominio di disponibilità, distribuire istanze ridondanti di ogni componente. Tutte le istanze sono attive e ricevono traffico dal load balancer e dal livello intermedio.

  • Livello intermedio: il livello intermedio contiene server logici e server batch. Non sono bilanciati dal carico diretto ma hanno un mapping uno-a-uno con i server nel livello di presentazione. È possibile ospitare il server logico e il server batch sulla stessa istanza del server enterprise. Si consiglia tuttavia di impostare il server logico e il server batch su istanze server enterprise distinte.

    Il livello intermedio riceve le richieste dal livello di presentazione. Dopo aver elaborato le richieste, inoltra le richieste ai database server. Tutte le istanze dei server sono attive e le richieste di elaborazione.

    Questo livello contiene i server riportati di seguito.

    • Server logici o server enterprise: questi server contengono la logica business o le funzioni business.

    • Server batch: questi server vengono utilizzati per l'elaborazione batch.

  • Livello di database: il livello di database contiene istanze di database server JD Edwards EnterpriseOne. Per i requisiti di alta disponibilità, Oracle consiglia di utilizzare sistemi di database a due nodi, Oracle Real Application Clusters (Oracle RAC) o un sistema Oracle Database Exadata Cloud Service in Oracle Cloud Infrastructure per impostare istanze di database server JD Edwards EnterpriseOne.

    È possibile impostare istanze di database ridondanti per fornire alta disponibilità. Per i sistemi di database Oracle RAC e Oracle Database Exadata Cloud Service, le richieste ricevute dalla subnet dell'applicazione vengono bilanciate in base al carico tra i database server. Se un'istanza di database non è disponibile, l'altra istanza di database elabora le richieste. È possibile utilizzare Oracle Cloud Infrastructure Object Storage per eseguire il backup del database JD Edwards EnterpriseOne utilizzando Oracle Recovery Manager (RMAN). Per eseguire il backup o la patch del database JD Edwards EnterpriseOne su Oracle Cloud Infrastructure Object Storage, è necessario configurare VCN del sistema DB con un gateway di servizio o un gateway Internet. Si consiglia di utilizzare un gateway di servizio anziché un gateway Internet per il backup e l'applicazione delle patch.

    Utilizzare le liste di sicurezza per limitare l'accesso ai database server solo dall'host bastion, dal livello applicazione e dai server in locale. È possibile impostare liste di sicurezza per assicurarsi che la comunicazione avvenga solo sulla porta 22, tramite l'host bastion e sulla porta 1521. Assicurarsi inoltre che i sistemi di database non siano accessibili su Internet.

È possibile utilizzare Oracle Cloud Infrastructure Object Storage per eseguire il backup delle istanze nel livello di presentazione e nel livello intermedio.

Architettura per la distribuzione di JD Edwards EnterpriseOne con Disaster Recovery

Questa architettura mostra la distribuzione di Application Server JD Edwards EnterpriseOne con disaster recovery. Mostra un VCN con bastione in una subnet pubblica e tutti gli altri server in una subnet privata.

I server di produzione vengono posizionati in due aree diverse. I server in un'area sono in modalità attiva e i server nella seconda area (area Disaster Recovery) sono in modalità in standby.

Nel diagramma di architettura, l'host bastione viene distribuito in una subnet pubblica e tutte le altre istanze vengono distribuite in subnet private. È possibile posizionare le istanze nelle subnet pubbliche o private in base ai requisiti aziendali. È possibile accedere alle istanze nelle subnet private sulla porta 22 mediante l'host bastion o DRG. Per abilitare la comunicazione tra DRG e le apparecchiature locali del cliente, utilizzare IPSec VPN o Oracle Cloud Infrastructure FastConnect.

In questa architettura, più istanze di applicazione vengono distribuite in più domini di errore per garantire un'elevata disponibilità. Ciò garantisce che l'applicazione sia disponibile anche quando uno dei domini di disponibilità non è disponibile. Le istanze di applicazione disponibili in un altro dominio di disponibilità continuano a elaborare le richieste.

Gli host bastione in entrambe le regioni sono attivi e possono servire richieste SSH a entrambe le regioni in qualsiasi momento. Il servizio DNS in locale o DNS esterno riceve una richiesta per l'applicazione JD Edwards EnterpriseOne. Queste richieste sono il carico arrotondato bilanciato del load balancer nell'area attiva. Il load balancer instrada quindi la richiesta alle istanze nel livello di presentazione e nel livello intermedio. Le istanze nel livello intermedio instradano la richiesta alle istanze di database attive per l'elaborazione. Il client di sviluppo nel livello di amministrazione comunica anche con il database. Il server di provisioning nel livello di amministrazione comunica con le istanze in tutti i livelli.

Se l'area primaria non è disponibile, è necessario passare manualmente al database server in esecuzione nell'area Disaster Recovery e iniziare a utilizzare l'host bastion o il load balancer in esecuzione nell'area Disaster Recovery.

È possibile eseguire il backup dei database e delle istanze di applicazione nelle subnet private alla memorizzazione degli oggetti Oracle Cloud Infrastructure mediante un gateway dei servizi. Un gateway di servizio consente di accedere allo storage degli oggetti senza attraversare Internet.


Segue una descrizione di jde2.png.
Descrizione dell'illustrazione jde2.png

  • Host di base: un host bastion è un componente facoltativo a cui è possibile eseguire il provisioning in ogni area per fungere da host saltato per accedere alle istanze dell'applicazione e del database. Gli host di base in entrambe le regioni si trovano nello stato attivo.

  • Istanza load balancer: le istanze Oracle Cloud Infrastructure Load Balancing distribuiscono il traffico tra gli Application Server. L'istanza del load balancer nell'area attiva/principale è attiva. Le richieste ricevute nell'URL di JD Edwards EnterpriseOne vengono inviate al load balancer nell'area attiva da un servizio DNS in locale o esterno.

  • Livello di presentazione: il livello di presentazione contiene istanze ridondanti di Application Interface Services (AIS) e Java Application Server (JAS) per fornire un'elevata disponibilità. Questi server comunicano con i server nel livello intermedio. Tutte le istanze sono attive e ricevono traffico dal load balancer. Ogni istanza è associata a un volume di memorizzazione a blocchi. Questo livello contiene anche componenti che è possibile utilizzare per creare l'integrazione tra JD Edwards EnterpriseOne e un sistema esterno. L'implementazione può includere uno o più di questi componenti.

  • Livello intermedio: il livello intermedio contiene server logici e server batch. Non sono bilanciati dal carico diretto, ma hanno un mapping uno-a-uno con i server nel livello di presentazione.

  • Livello database: impostare istanze di database altamente disponibili in entrambe le aree. Il database server in esecuzione nell'area attiva/primaria è in stato attivo. In ogni area vengono impostate almeno due istanze di database per garantire un'elevata disponibilità all'interno di un'area. Se un'istanza di database non è disponibile nell'area attiva/primaria, passare all'istanza di database nell'area Disaster Recovery e iniziare a utilizzare il load balancer nell'area Disaster Recovery per accedere all'ambiente.

    Utilizzare Oracle Active Data Guard in modalità sincrona per replicare il database in tutte le aree.

Informazioni sui gruppi di sicurezza di rete

In Oracle Cloud Infrastructure, le regole firewall vengono configurate tramite gruppi di sicurezza di rete. Per ogni livello viene creato un gruppo di sicurezza di rete separato.

Utilizzare le liste di sicurezza per consentire il traffico tra livelli diversi e tra l'host bastione e gli host esterni. Le regole di sicurezza contengono regole di ingresso e uscita per filtrare il traffico a livello di livello. Essi contengono anche informazioni sulle porte di comunicazione attraverso le quali è consentito il trasferimento dei dati. Tali porte (o, in alcuni casi, i protocolli che avranno bisogno di porte aperte nelle regole di sicurezza) vengono mostrati su ogni riga del gruppo di sicurezza di rete nei diagrammi di architettura.

Ogni gruppo di sicurezza di rete viene applicato a livello VNIC. Il trasferimento di un pacchetto di dati è consentito se una regola in una qualsiasi delle liste consente il traffico (o se il traffico fa parte di una connessione esistente monitorata). Oltre al gruppo di sicurezza di rete, utilizzare iptables per implementare un altro livello di sicurezza a livello di istanza.

Per le distribuzioni in una subnet pubblica, è possibile fornire un ulteriore livello di sicurezza impedendo l'accesso alle istanze dell'applicazione e del database da Internet. Utilizzare un gruppo di sicurezza di rete personalizzato per impedire l'accesso a Internet alle istanze di applicazione e di database e consentire l'accesso al database e agli host di applicazione sulla porta 22 dall'host bastion ai fini dell'amministrazione. Non abilitare l'accesso SSH all'applicazione e alle istanze di database da Internet, ma è possibile consentire l'accesso SSH a queste istanze dalla subnet che contiene l'host bastion.

È possibile accedere alle istanze nella subnet privata tramite il server bastion.

Gruppo di sicurezza di rete per l'host di base

Il gruppo di sicurezza della rete bastion consente di accedere all'host bastion da Internet pubblico sulla porta 22.

  • Per consentire il traffico SSH dalla rete on-premise all'host bastione su Internet:

    Ingresso statico: consente il traffico TCP dall'origine CIDR 0.0.0.0/0 e da tutte le porte di origine alla porta di destinazione 22 (SSH).

    Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

    È inoltre possibile limitare l'accesso all'host bastion su Internet sulla porta 22 solo dal data center anziché da Internet pubblico (0.0.0.0/0). A tale scopo, utilizzare l'IP del router edge anziché il CIDR di origine come 0.0.0.0/0 nella regola di ingresso con conservazione dello stato.

  • Per consentire a tutto il traffico dall'host bastion a Oracle Cloud Infrastructure, procedere come segue.

    Uscita statica: consente al traffico TCP di destinazione CIDR 0.0.0.0/0 da tutte le porte di origine a tutte le porte di destinazione.

    Destination Type = CIDR, Destination CIDR = <CIDR block of VCN>, IP Protocol = TCP, Source Port Range = All, Destination port range = All

È possibile aggiungere o rimuovere regole dal gruppo di sicurezza di rete in base alle proprie esigenze. Specificare inoltre le porte su cui si desidera accedere ai server applicazioni Java e ai server Application Interface Services.

Gruppo sicurezza rete per il livello di amministrazione

  • Ingresso statico: consente il traffico TCP sulla porta di destinazione 22 (SSH) dal blocco CIDR di origine di VCN e da qualsiasi porta di origine.

  • Ingresso statico: blocco CIDR di origine di VCN su TCP, porta di origine = tutto, porta di destinazione = 445, 5985, 14501-14510, 3000, 8998–8999, 5150

  • Uscita statica: Consenti tutto il traffico.

Gruppo di sicurezza di rete per il livello load balancer

L'architettura contiene load balancer privati, posizionati in subnet private. Se si inseriscono le istanze del load balancer in una subnet pubblica, si sta consentendo il traffico da Internet alle istanze del load balancer.

  • Ingresso statico: blocco CIDR di origine della rete VCN e in locale su TCP, porta di origine = tutto, porta di destinazione = porte su cui è stato creato il listener nelle istanze del load balancer

  • Uscita statica: Consenti tutto il traffico.

Gruppo di sicurezza di rete per il livello di presentazione

  • Per consentire il traffico dall'ambiente in locale e da VCN alla subnet del livello di presentazione, effettuare le operazioni riportate di seguito.

    Ingresso statico: blocco CIDR di origine della rete VCN e in locale su TCP, porta di origine = tutto, porta di destinazione = 14501–14510, 5150, porta server di amministrazione Weblogic, porte server Web

  • Ingresso statico: blocco CIDR di origine di VCN su TCP, porta di origine = tutto, porta di destinazione = 22 (SSH)

  • Per consentire il traffico dalla subnet di livello di presentazione alla subnet di livello intermedio, effettuare le operazioni riportate di seguito.

    Uscita con conservazione dello stato: origine 0.0.0.0/0 su TCP, porta di origine = tutto, porta di destinazione = tutto

Specificare inoltre le porte su cui si desidera accedere ai server di Java Application Server e Application Interface Services e le porte su cui si desidera accedere ai server di Oracle Business Intelligence Publisher.

Gruppo di sicurezza di rete per il livello intermedio

  • Per consentire il traffico dall'ambiente in locale e da VCN alla subnet di livello intermedio, effettuare le operazioni riportate di seguito.

    Ingresso statico: blocco CIDR di origine di VCN e di rete in locale su TCP, porta di origine = tutto, porta di destinazione = 6017-6023, 14502-14510, 5150

  • Ingresso statico: blocco CIDR di origine di VCN su TCP, porta di origine = tutto, porta di destinazione = 22 (SSH)

  • Per consentire il traffico dalla subnet di livello intermedio alla subnet di livello di presentazione:

    Uscita con conservazione dello stato: Origine 0.0.0.0/0 su TCP, porta di origine = tutto, porta di destinazione = tutto

Lista di sicurezza per il livello di database

  • Per consentire il traffico dall'host bastione al livello di database, effettuare le operazioni riportate di seguito.

    Ingresso statico: blocco CIDR di origine dell'host bastion su TCP, porta di origine = tutto, porta di destinazione = 22

  • Per consentire il traffico dal livello intermedio al livello di database, procedere come segue.

    Ingresso statico: blocco CIDR di origine dei livelli intermedi su TCP, porta di origine = tutto, porta di destinazione = 1521

  • Per consentire il traffico dall'ambiente in locale e da VCN alla subnet del livello di presentazione, procedere come segue.

    Ingresso statico: blocco CIDR di origine di VCN su TCP, porta di origine = tutto, porta di destinazione = 14502–14510, 5150

  • Per consentire il traffico dal livello database al livello intermedio, procedere come segue.

    Uscita con conservazione dello stato: destinazione 0.0.0.0/0 su TCP, porta di origine = all, porta di destinazione = all