Scopri come distribuire Oracle Siebel CRM su Oracle Cloud Infrastructure
Se desideri eseguire il provisioning di Oracle Siebel CRM 19.x e versioni successive su Oracle Cloud Infrastructure o eseguire la migrazione degli ambienti Siebel CRM dal tuo data center a Oracle Cloud Infrastructure, puoi pianificare una topologia multihost, sicura e ad alta disponibilità per ambienti di sviluppo e ambienti di test.
Considerazioni per la distribuzione su Oracle Cloud Infrastructure
Oracle consiglia di creare subnet separate per le istanze, ad esempio istanze di host bastion, database, applicazioni e load balancer, per garantire che i requisiti di sicurezza appropriati possano essere implementati nelle diverse subnet.
Subnet private o pubbliche
Puoi creare istanze in una subnet privata o pubblica in base all'autorizzazione di accesso alle istanze da Internet. Alle istanze create in una subnet pubblica viene assegnato un indirizzo IP pubblico ed è possibile accedere a tali istanze da Internet. Non è possibile assegnare un indirizzo IP pubblico alle istanze create in una subnet privata. Pertanto, non è possibile accedere a queste istanze tramite Internet.
L'immagine riportata di seguito mostra una rete cloud virtuale (VCN) con subnet pubbliche e private. La VCN contiene due domini di disponibilità, ciascuno dei quali contiene una subnet pubblica e privata. I server Web vengono posizionati nella subnet pubblica in questa immagine, quindi a ogni istanza del server Web è collegato un indirizzo IP pubblico. Puoi accedere a queste istanze Oracle Cloud nella subnet pubblica da Internet abilitando la comunicazione tramite il gateway Internet (IGW). Dovrai aggiornare la tabella di instradamento per abilitare il traffico da e verso 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 bastion host nella subnet pubblica e accedere all'host bastion da IGW.
I database server vengono posizionati nella subnet privata in questa immagine. Puoi accedere alle istanze di Oracle Cloud nella subnet privata dai tuoi data center connettendoti tramite il gateway di instradamento dinamico (DRG). Il gateway DRG connette le tue reti on premise alla tua rete cloud. Per abilitare la comunicazione tra il gateway DRG e l'apparecchiatura on premise del cliente, utilizza IPSec VPN o Oracle Cloud Infrastructure FastConnect. Dovrai anche aggiornare la tabella di instradamento per abilitare il traffico verso e dal 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 sono presenti endpoint che si interfacciano con Internet. Questo tipo di implementazione è utile quando si desidera avere una distribuzione ibrida con il cloud come estensione dei data center esistenti.
In questa distribuzione, tutte le istanze, inclusi Application Server e Database Server, vengono distribuite in una subnet privata. Non è possibile assegnare un indirizzo IP pubblico alle istanze create in una subnet privata, pertanto non è possibile accedere a queste istanze tramite Internet. Per accedere agli Application Server dall'ambiente on premise in uso in questa configurazione, è possibile effettuare le operazioni riportate di seguito.
-
Configurare un tunnel IPSec VPN tra il data center e il DRG di Oracle Cloud Infrastructure 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: distribuzione delle 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 quando la distribuzione include endpoint che si interfacciano con Internet e non con Internet.
In questa configurazione, alcune istanze dell'applicazione vengono posizionate in una subnet pubblica e altre in una subnet privata. Ad esempio, si possono avere istanze di applicazione che servono utenti interni e un altro set di istanze di applicazione che servono utenti esterni. In questo scenario, posiziona le istanze dell'applicazione che servono il traffico interno in una subnet privata e posiziona gli Application Server che servono il traffico esterno in una subnet pubblica. Puoi anche impostare un load balancer pubblico sulle istanze delle applicazioni che si interfacciano con Internet, invece di posizionare gli application server che gestiscono il traffico esterno in una subnet pubblica. Se si posiziona l'host bastion in una subnet pubblica, all'host bastion verrà assegnato un indirizzo IP pubblico e sarà possibile accedervi tramite Internet. Puoi accedere alle tue istanze nella subnet privata tramite il server bastion.
Scenario 3: distribuzione di tutte le istanze nelle subnet pubbliche
Oracle consiglia questa distribuzione per dimostrazioni rapide o per distribuzioni di livello produzione senza endpoint interni. Questa distribuzione è adatta solo se non si dispone del proprio data center o se non è possibile accedere alle istanze tramite VPN e si desidera accedere all'infrastruttura tramite Internet.
In questa distribuzione, tutte le istanze, incluse quelle dell'applicazione e del database, vengono distribuite nelle subnet pubbliche.
A ogni istanza della subnet pubblica è collegato 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 i task di amministrazione, Oracle consiglia di inserire un bastion host in questa configurazione. In questo scenario, non aprire le porte di amministrazione alla rete Internet pubblica, ma aprire le porte di amministrazione solo all'host bastion e impostare le liste di sicurezza e le regole di sicurezza per garantire che l'accesso all'istanza sia consentito solo dall'host bastion.
Anti-affinità
Durante la creazione di più istanze per l'alta disponibilità in un dominio di disponibilità su Oracle Cloud Infrastructure, l'anti-affinità per le istanze può essere raggiunta utilizzando i domini di errore.
Un dominio di errore consiste in un gruppo 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 dell'hardware Oracle Compute che interessa un dominio di errore non influisce sulle istanze negli altri domini di errore. Utilizzando i domini di errore, puoi proteggere le tue istanze da guasti hardware imprevisti e interruzioni 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 nello stesso host fisico né nello stesso rack fisico. Ciò protegge le istanze di database dagli errori dello switch rack e dell'host fisico di base.