Informazioni sulla distribuzione di PeopleSoft su Oracle Cloud Infrastructure

Se si desidera eseguire il provisioning delle applicazioni OraclePeopleSoft su Oracle Cloud Infrastructure o eseguire la migrazione degli ambienti PeopleSoft dal data center a Oracle Cloud Infrastructure, è possibile pianificare una topologia con più host, sicura e ad alta disponibilità.

Considerazioni sulla distribuzione su Oracle Cloud Infrastructure

Oracle consiglia di creare subnet separate per le istanze, ad esempio l'host bastion, il database, l'applicazione e le istanze del load balancer per garantire l'implementazione dei requisiti di sicurezza appropriati nelle diverse subnet.

Subnet private o pubbliche

Puoi creare istanze in una subnet privata o pubblica a seconda che desideri accedere a tali istanze da Internet. Le istanze che si creano in una subnet pubblica vengono assegnate a 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 tramite Internet.

L'immagine seguente mostra una rete cloud virtuale (VCN) con subnet pubbliche e private. La rete VCN contiene due domini di disponibilità e ogni dominio di disponibilità contiene una rete secondaria pubblica e privata. I server Web vengono posizionati nella subnet pubblica in questa immagine, pertanto alle istanze di server Web è associato un indirizzo IP pubblico. Puoi 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 verso e da IGW. Per consentire il traffico ai server Web da Internet, è necessario creare load balancer nella subnet pubblica. Per accedere alle istanze da Internet, è necessario creare un host di base nella subnet pubblica e accedere all'host di base da IGW.

I database server vengono posizionati nella subnet privata in questa immagine. Puoi accedere alle istanze di Oracle Cloud nella subnet privata dai data center mediante la connessione mediante il gateway di instradamento dinamico (DRG). DRG è il gateway che connette la rete on premise alla tua rete cloud. Per abilitare la comunicazione tra DRG e i clienti, utilizzare IPSec VPN o Oracle Cloud Infrastructure FastConnect. Sarà inoltre necessario aggiornare la tabella di instradamento per abilitare il traffico da e da DRG.

Descrizione dell'immagine public_private_subnets_jde.png

Scenario 1: distribuzione di tutte le istanze nelle subnet private

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

In questa distribuzione, tutte le istanze, inclusi i server applicazioni e database, vengono distribuite in una subnet privata. Non è possibile assegnare un indirizzo IP pubblico alle istanze create in una subnet privata in modo da non poter accedere a queste istanze tramite Internet. Per accedere ai server applicazioni dall'ambiente locale in questa configurazione, è possibile:

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

Scenario 2: distribuire le istanze nelle subnet pubbliche e private

Puoi distribuire alcune istanze in una subnet pubblica e alcune istanze in una subnet privata. Questo tipo di distribuzione è utile se la distribuzione include endpoint su rete e non su netto.

In questa configurazione alcune istanze dell'applicazione vengono inserite in una subnet pubblica, mentre altre vengono collocate in una subnet privata. Ad esempio, è possibile che esistano istanze di applicazione che servano utenti interni e un altro set di istanze di applicazione che servono utenti esterni. In questo scenario, posizionare le istanze di applicazione che fungono da traffico interno in una subnet privata e collocare gli Application Server che fungono da traffico esterno in una subnet pubblica. Puoi anche impostare un load balancer pubblico sulle istanze delle applicazioni interne al posto dei server applicazioni che fungono da traffico esterno in una subnet pubblica. Se si posiziona l'host di base in una subnet pubblica, all'host di base viene assegnato un indirizzo IP pubblico e sarà possibile accedervi tramite Internet. Puoi accedere alle istanze nella subnet privata tramite il server di base.

Scenario 3: Distribuzione di tutte le istanze nelle subnet pubbliche

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

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

A ogni istanza della subnet pubblica è associato un indirizzo IP pubblico. Sebbene sia possibile accedere alle 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 posizionare un host di base in questa configurazione. In questo scenario non si apriranno le porte di amministrazione su Internet pubblico, ma si apriranno le solo sull'host di base e le regole di sicurezza di impostazione per garantire l'accesso all'istanza solo dall'host di base.

Anti-affinity

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 i 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 non si trovino sullo stesso hardware fisico all'interno di un singolo dominio di disponibilità. Pertanto, un errore hardware o la gestione dell'hardware Oracle Compute che incide su un dominio di errore non incide sulle istanze in altri domini di errore. L'uso dei domini di errore consente di proteggere le istanze da eventuali errori hardware imprevisti e indisponibilità pianificate.

Per l'alta disponibilità dei database, è possibile creare sistemi di database 2-node Oracle Real Application Clusters (Oracle RAC). I due nodi di Oracle RAC vengono sempre creati in domini di errore separati per impostazione predefinita. Pertanto, i nodi del database non si trovano sullo stesso host fisico né sullo stesso rack fisico. In questo modo si proteggono le istanze di database sull'host fisico di base e la parte superiore degli errori di switch rack.

Architettura

Informazioni sui concetti chiave che è possibile utilizzare per pianificare queste opzioni di distribuzione per PeopleSoft:

Architettura per distribuire PeopleSoft in un singolo dominio di disponibilità garantendo al contempo l'alta disponibilità. Utilizzare questa architettura quando si desidera assicurarsi che l'applicazione sia disponibile anche quando un'istanza dell'applicazione diventa inattiva. Le altre istanze di applicazione disponibili nel dominio di disponibilità continuano a elaborare le richieste.
Architettura per distribuire PeopleSoft in più domini di disponibilità garantendo al contempo l'alta disponibilità. Utilizzare questa architettura per assicurarsi che l'applicazione sia disponibile anche quando un dominio di disponibilità diventa inattivo. È comunque possibile accedere alle istanze dell'applicazione in un altro dominio di disponibilità.
Architettura per distribuire PeopleSoft assicurando un'elevata disponibilità e il recupero da errori irreversibili. Utilizzare questa architettura quando si desidera impostare un sito di recupero da errori irreversibili per l'applicazione in un'altra area.

L'architettura è valida per le distribuzioni di PeopleSoft eseguite manualmente o mediante gli strumenti di automazione di PeopleSoft su Oracle Cloud Infrastructure.

Tutti i diagrammi di architettura sono consigliati con la possibilità di non accedere agli host del database e dell'applicazione su Internet.

Architettura per la distribuzione di PeopleSoft in un dominio Single Availability

Questa architettura mostra la distribuzione di un'applicazione PeopleSoft in un unico dominio di disponibilità garantendo al contempo l'alta disponibilità.

L'architettura è costituita da una VCN con gli host di base, load balancer, applicazione e database posizionati in subnet separate della VCN in un singolo dominio di disponibilità. L'host di base viene distribuito in una subnet pubblica e tutte le altre istanze vengono distribuite nelle subnet private. È possibile posizionare le diverse istanze nelle subnet pubbliche o private in base ai requisiti aziendali. È possibile accedere alle istanze nelle subnet private tramite la porta 22 attraverso l'host di base o DRG se è stato impostato un tunnel IPSec VPN tra il data center e Oracle Cloud Infrastructure DRG.

In questa architettura, le istanze ridondanti vengono distribuite nel livello applicazione e nel livello database per garantire alta disponibilità all'interno del dominio di disponibilità. Ciò garantisce che l'applicazione sia disponibile anche quando un'istanza dell'applicazione diventa inattiva. Le altre istanze di applicazione disponibili nel dominio di disponibilità continuano a elaborare le richieste. Tutte le istanze di applicazione nel dominio di disponibilità sono attive. Le istanze del load balancer ricevono le richieste e le invia agli Application Server. È possibile ottenere questa alta disponibilità di un'applicazione all'interno di un dominio di disponibilità posizionando le istanze dell'applicazione in domini di errore separati. 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 gestione hardware che incide su un dominio di errore non incide sulle istanze in altri domini di errore.

Le istanze nella subnet privata richiedono la connessione in uscita a Internet per scaricare le patch, nonché per applicare gli aggiornamenti del sistema operativo e delle applicazioni. Per questo scopo, utilizzare un gateway NAT (Network Address Translation) nella tua VCN. Con un gateway NAT, gli host nella subnet privata possono avviare le connessioni a Internet e ricevere le risposte, ma non riceverà le connessioni in entrata avviate da Internet.

Oracle consiglia che il database e le applicazioni distribuite su Oracle Cloud Infrastructure abbiano un backup efficace della strategia di recupero. Si consiglia di memorizzare il backup dei database e delle istanze dell'applicazione nello storage degli oggetti Oracle Cloud Infrastructure. È possibile eseguire il backup dei database e delle istanze di applicazione nelle subnet private nello storage degli oggetti Oracle Cloud Infrastructure utilizzando un gateway dei servizi. Un gateway di servizi consente di accedere allo storage degli oggetti Oracle Cloud Infrastructure senza analizzare Internet.

I backup dei database automatici e su richiesta per lo storage degli oggetti Oracle Cloud Infrastructure possono essere configurati utilizzando la console di 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 sono 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 30-day. È inoltre possibile eseguire un backup completo su richiesta dei database per soddisfare requisiti ad hoc.

Il backup dell'applicazione può essere configurato usando la funzione di backup basata su criteri di Oracle Cloud Infrastructure Block Volumes. Oracle Cloud Infrastructure Block Volumes consente di eseguire automaticamente i backup dei volumi in base a una pianificazione e di conservarli in base al criterio di backup selezionato. Ciò consente di rispettare i requisiti normativi e la conformità dei dati. Esistono tre criteri di backup predefiniti: Bronze, Silver e Gold. Ogni criterio di backup dispone di una frequenza di backup e di un periodo di conservazione predefiniti.

Descrizione dell'immagine peoplesoft_single_availability_domain_ha_topology.png

Questa architettura è suddivisa nei seguenti livelli:

Host di creazione: l'host di base è un componente facoltativo che è possibile utilizzare come server di collegamenti per accedere alle istanze nella subnet privata.
Livello load balancer: questo livello contiene le istanze di bilanciamento del carico di Oracle Cloud Infrastructure che caricano il traffico nei server Web di PeopleSoft. Il load balancer riceve le richieste dagli utenti e le instrada a livello di applicazione.
Livello applicazione: questo livello contiene istanze ridondanti dei server applicazioni PeopleSoft, dei server Web PeopleSoft, dei server ElasticSearch e di PeopleSoft Process Scheduler per garantire alta disponibilità. Configurare istanze ridondanti di tutti i server nel livello applicazione per assicurarsi di poter continuare ad accedere all'applicazione anche se un'istanza diventa inattiva.
Client di PeopleTools: utilizzare il client di PeopleTools per eseguire attività di amministrazione, quali lo sviluppo, la migrazione e l'aggiornamento.
Livello database: questo livello contiene le istanze di sistema del database Oracle Cloud Infrastructure. Per i requisiti di alta disponibilità, Oracle consiglia di utilizzare i sistemi di database Oracle Real Application Clusters (Oracle RAC) a due nodi o un sistema Oracle Database Exadata Cloud Service di Oracle Cloud Infrastructure.

Architettura per distribuire PeopleSoft in più domini di disponibilità

Questa architettura mostra la distribuzione degli Application Server PeopleSoft in più domini di disponibilità. Mostra una rete VCN con gli host di base, load balancer, applicazione e database posizionati in subnet separate tra due domini di disponibilità.

Nel diagramma dell'architettura, l'host di base 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 tramite la porta 22 attraverso l'host di base o DRG se è stato impostato un tunnel IPSec VPN tra il data center e Oracle Cloud Infrastructure DRG. Tutte le istanze sono attive nei due domini di disponibilità. Gli unici componenti passivi dell'architettura sono gli host del database nel dominio di disponibilità 2.

Gli host di base nel dominio di disponibilità 1 e nel dominio di disponibilità 2 sono attivi e possono servire contemporaneamente le richieste SSH per le istanze in entrambi i domini di disponibilità. Il servizio DNS locale o esterno riceve la richiesta per l'applicazione PeopleSoft. Queste richieste sono carichi a instradamento sequenziale bilanciati per uno dei load balancer nel dominio di disponibilità 1 o 2. Il load balancer instrada quindi la richiesta a uno dei Web server PeopleSoft di base nel dominio di disponibilità 1 o 2. Il Web server PeopleSoft instrada quindi la richiesta a uno degli Application Server PeopleSoft e infine le richieste di inoltro di Application Server alle istanze di database attive nel dominio di disponibilità 1 per l'elaborazione.

Se il dominio di disponibilità 1 non è disponibile, è necessario rimuovere manualmente la voce del load balancer del dominio di disponibilità 1 dal servizio DNS e passare al database alle istanze di database nel dominio di disponibilità 2. Le richieste ricevute dal servizio DNS vengono instradate al load balancer nel dominio di disponibilità 2 e infine al database nel dominio di disponibilità 2 per l'elaborazione.

Descrizione dell'immagine peoplesoft_multiple_availability_domain_ha_topology.png

Host di base: un host di base è un componente facoltativo che è possibile attivare in ogni dominio di disponibilità per agire come host di collegamento per accedere alle istanze di applicazione e database. Lo stato degli host di base nel dominio di disponibilità 1 e nel dominio di disponibilità 2 è attivo.
Istanze load balancer: le istanze di bilanciamento del carico di Oracle Cloud Infrastructure distribuiscono il traffico tra gli Application Server in entrambi i domini di disponibilità. Le istanze del load balancer sia nel dominio di disponibilità 1 che in quello 2 sono attive. Le richieste ricevute all'URL PeopleSoft sono un carico ad instradamento sequenziale bilanciato a un load balancer del dominio di disponibilità 1 o 2 da un servizio DNS locale o esterno.
Livello applicazione: dominio di disponibilità 1 e dominio di disponibilità 2 contengono istanze ridondanti di PeopleSoft Application Server, PeopleSoft Web Server, ElasticSearch Server e PeopleSoft Process Scheduler. Tutte le istanze nel livello applicazione nei due domini di disponibilità si trovano nello stato attivo.
Client di PeopleTools: utilizzare il client di PeopleTools per eseguire attività di amministrazione, quali lo sviluppo, la migrazione e l'aggiornamento.
Livello database: istanza di database ad alta disponibilità in entrambi i domini di disponibilità. Dominio di disponibilità 1 ospita le istanze di database primario. Il dominio di disponibilità 2 ospita le istanze di database in standby. In ogni dominio di disponibilità sono configurate almeno due istanze di database per garantire l'alta disponibilità. Se un'istanza di database non è disponibile nel dominio di disponibilità 1, la seconda istanza di database nel dominio di disponibilità 1 continua a elaborare le richieste.

Utilizzare Oracle Active Data Guard in modalità sincrona per replicare il database tra i domini di disponibilità in un'area.

Architettura per la distribuzione di PeopleSoft in più aree

Questa architettura mostra la distribuzione degli Application Server PeopleSoft in più aree garantendo alta disponibilità e recupero da errori irreversibili. Mostra una rete VCN con le istanze di base, load balancer, applicazione e database posizionate in subnet separate tra due aree. Per garantire l'accesso alle istanze dell'applicazione PeopleSoft, anche quando tutti i domini di disponibilità di un'area si spostano inattivi, distribuire PeopleSoft in più aree.

Il diagramma dell'architettura mostra due aree. Nell'area 1, PeopleSoft viene distribuito In più domini di disponibilità per garantire l'alta disponibilità In tutti i domini di disponibilità all'interno di un'area. L'area 2 è l'area di recupero da errori irreversibili. Tutte le istanze sono attive nei due domini di disponibilità disponibili nell'area 1. I componenti passivi dell'architettura sono gli host del database nel dominio di disponibilità 2 e tutte le istanze in Area 2. Oracle consiglia che il numero di istanze distribuite per ogni livello nel dominio di disponibilità in Area 2 corrisponda al numero di istanze distribuite in un dominio di disponibilità nell'Area 1. Ciò garantisce che le istanze dell'applicazione possano effettuare il caricamento dopo il richiamo del recupero da errori irreversibili.

È inoltre possibile che questa architettura venga distribuita in un solo dominio di disponibilità nell'area 1 e in un dominio di disponibilità nell'area 2 per il recupero da errori irreversibili. Tuttavia, questa architettura non fornisce la tolleranza degli errori per il dominio di disponibilità nell'area 1. Se l'unico dominio di disponibilità in cui l'applicazione è stata distribuita non è disponibile, sarà necessario richiamare il recupero da errori irreversibili per eseguire il failover dell'applicazione nell'area 2.

Nell'area 1 gli host di base del dominio di disponibilità 1 e del dominio di disponibilità 2 sono attivi e possono servire le richieste SSH alle istanze In entrambi i domini di disponibilità. Il servizio DNS locale o esterno riceve la richiesta per l'applicazione PeopleSoft. Queste richieste sono carichi a instradamento sequenziale bilanciati per uno dei load balancer nel dominio di disponibilità 1 o 2. Il load balancer instrada quindi la richiesta a uno dei Web server PeopleSoft di base nel dominio di disponibilità 1 o 2. Il Web server PeopleSoft instrada quindi la richiesta a uno degli Application Server PeopleSoft e infine le richieste di inoltro di Application Server alle istanze di database attive nel dominio di disponibilità 1 per l'elaborazione.

Se le istanze nell'area 1 non sono disponibili, è necessario eseguire lo switchover manuale alle istanze dell'area 2. In questo scenario, il load balancer e le istanze di database in Region 2 fungono da load balancer primario e da istanze di database. Le richieste ricevute all'URL di PeopleSoft vengono instradate al load balancer della regione 2, che successivamente instrada il traffico verso il Web server di PeopleSoft sottostante nella sezione 2. I Web server PeopleSoft instradano la richiesta alle istanze dell'applicazione PeopleSoft, quindi i Web server inoltrano le richieste alle istanze di database in Area 2 per l'elaborazione.

Nel diagramma dell'architettura, l'host di base e il load balancer vengono distribuiti nelle subnet pubbliche e tutte le altre istanze vengono distribuite nelle subnet private. È possibile posizionare le istanze nelle subnet pubbliche o private in base ai requisiti aziendali. È possibile accedere alle istanze nelle subnet private tramite la porta 22 attraverso l'host di base o DRG se è stato impostato un tunnel IPSec VPN tra il data center e Oracle Cloud Infrastructure DRG.

Descrizione dell'immagine peoplesoft_multiple_regions_ha_topology.png

L'architettura supporta i componenti riportati di seguito.

Host di base: un host di base è un componente facoltativo che è possibile attivare in ogni dominio di disponibilità per agire come host di collegamento per accedere alle istanze di applicazione e database. Lo stato degli host di base nel dominio di disponibilità 1 e nel dominio di disponibilità 2 è attivo.
Istanze load balancer: le istanze di bilanciamento del carico di Oracle Cloud Infrastructure distribuiscono il traffico tra gli Application Server in entrambi i domini di disponibilità. Dominio di disponibilità 1 e 2 nell'area 1 ospita le istanze del load balancer primario.
Livello applicazione: dominio di disponibilità 1 e dominio di disponibilità 2 nell'area 1 contengono almeno un'istanza dell'Application Server PeopleSoft, del Web server PeopleSoft, dei server ElasticSearch e dello scheduler dei processi PeopleSoft. Lo stato di tutte le istanze nei due domini di disponibilità nell'area 1 è attivo. Le istanze a livello di applicazione nella Area 2 sono in stato passivo. Per sincronizzare i server applicazioni tra domini di disponibilità e tra le varie aree, utilizzare rsync.
Client di PeopleTools: utilizzare il client di PeopleTools per eseguire attività di amministrazione, quali lo sviluppo, la migrazione e l'aggiornamento.
Livello database: il dominio di disponibilità 1 in Area 1 ospita le istanze di database primario. Dominio di disponibilità 2 nell'area 1 e nell'area 2 che ospitano le istanze di database in standby. In ogni dominio di disponibilità sono configurate almeno due istanze di database per garantire l'alta disponibilità. Se un'istanza di database diventa inattiva nel dominio di disponibilità 1, la seconda istanza di database nel dominio di disponibilità 1 continua a elaborare le richieste. Se l'area 1 non è disponibile, le richieste vengono elaborate dalle istanze di database dell'area 2.

Oracle consiglia di utilizzare Oracle Active Data Guard in modalità sincrona per replicare il database tra i domini di disponibilità in un'area. Per replicare il database tra le varie aree, utilizzare Oracle Active Data Guard in modalità asincrona.