Architetture per applicazioni Oracle con database in macchine virtuali di Azure

Questo articolo fornisce un'architettura di riferimento per distribuire l'applicazione Oracle in Azure IaaS in cui risiede anche il database Oracle o si trova in un percorso condiviso.

I carichi di lavoro Oracle comprendono non solo database Oracle, ma anche applicazioni di Oracle di prima parte, ad esempio Siebel, PeopleSoft, JD Edwards, E-Business Suite o applicazioni server WebLogic personalizzate. La distribuzione di applicazioni Oracle nell'infrastruttura distribuita come servizio (IaaS) di Azure è uno scenario comune per le organizzazioni che cercano di usare il cloud per i carichi di lavoro Oracle insieme a database Oracle. Microsoft offre architetture di riferimento e procedure consigliate per semplificare questo processo.

Linee guida generali sulla migrazione delle applicazioni

Quando le applicazioni Oracle si spostano in Azure IaaS, esistono considerazioni di progettazione comuni, che devono essere seguite indipendentemente dal tipo di applicazioni. Alcune considerazioni sono specifiche per le applicazioni. In questa sezione vengono elencate le considerazioni di progettazione comuni di tutte le applicazioni e tutte le considerazioni specifiche dell'applicazione vengono trattate in ogni applicazione.

Rete e sicurezza

Le impostazioni di rete fornite per le applicazioni Oracle in Azure riguardano vari aspetti delle considerazioni sulla rete e sulla sicurezza. Ecco una suddivisione delle impostazioni di rete consigliate:

• Single Sign-On (SSO) con Microsoft Entra ID e SAML: usare ID Microsoft Entra per l'accesso Single Sign-On (SSO) usando il protocollo SAML (Security Assertions Markup Language). Questo SSO consente agli utenti di eseguire l'autenticazione una sola volta e accedere facilmente a più servizi.

• Proxy dell'applicazione Microsoft Entra: è consigliabile usare proxy dell'applicazione Microsoft Entra, soprattutto per gli utenti remoti. Questo proxy consente di accedere in modo sicuro alle applicazioni locali dall'esterno della rete.

• Routing degli utenti interni tramite ExpressRoute: per gli utenti interni, instradare il traffico attraverso Azure ExpressRoute per una connessione privata dedicata ai servizi di Azure, garantendo una bassa latenza e una comunicazione sicura.

• Firewall di Azure: se necessario, è possibile configurare Firewall di Azure davanti all'applicazione per una maggiore sicurezza. Firewall di Azure consente di proteggere le risorse da accessi e minacce non autorizzati.

• Gateway applicazione per utenti esterni: quando gli utenti esterni devono accedere all'applicazione, è consigliabile usare il gateway applicazione di Azure. Fornisce funzionalità web application firewall (WAF) per proteggere le applicazioni Web e il bilanciamento del carico di livello 7 per distribuire il traffico.

• Gruppi di sicurezza di rete (NSG): proteggere le subnet usando gruppi di sicurezza di rete (NSG). I gruppi di sicurezza di rete consentono di controllare il traffico in ingresso e in uscita verso interfacce di rete, macchine virtuali e subnet definendo regole di sicurezza.

• Controllo degli accessi in base al ruolo: per concedere l'accesso a singoli utenti o ruoli specifici, usare il controllo degli accessi in base al ruolo di Azure. Controllo degli accessi in base al ruolo fornisce un controllo di accesso granulare alle risorse di Azure in base a ruoli e autorizzazioni.

• Bastion Host per l'accesso SSH: usare un host Bastion come jump box per migliorare la sicurezza per l'accesso SSH. Un host Bastion funge da gateway sicuro per consentire agli amministratori di accedere alle macchine virtuali nella rete virtuale. Questo host offre un ulteriore livello di sicurezza.

• Altre considerazioni:

  • Crittografia dei dati: assicurarsi che i dati inattivi e in transito siano crittografati. Azure offre strumenti come Crittografia dischi di Azure e SSL/TLS a questo scopo.
  • Gestione delle patch: aggiornare e applicare regolarmente patch all'ambiente EBS per proteggersi da vulnerabilità note.
  • Monitoraggio e registrazione: implementare Monitoraggio di Azure e Azure Defender per la sicurezza per controllare continuamente l'ambiente per individuare minacce e anomalie per la sicurezza. Configurare la registrazione per il controllo e l'analisi forense.

• In sintesi, queste impostazioni di rete e sicurezza mirano a fornire un ambiente affidabile e sicuro per l'hosting di applicazioni Oracle in Azure IaaS. Incorporano procedure consigliate per l'autenticazione, il controllo di accesso e la sicurezza di rete, sia per gli utenti interni che per gli utenti esterni. Considerano anche la necessità di accedere SSH ai server applicazioni. Questi consigli consentono di configurare un comportamento di sicurezza avanzato per la distribuzione di applicazioni Oracle in Azure IaaS.

livello Web: il livello Web bilancia le richieste e invia le richieste di conseguenza al livello applicazione, al livello di database e/o al backup.

Livello applicazione: il livello applicazione include in genere server applicazioni e file system condivisi.

Per la scalabilità automatica, i set di scalabilità di macchine virtuali possono essere una scelta ideale per aumentare il numero di istanze di più macchine virtuali in base alla richiesta con regole di scalabilità personalizzate per adattarsi al carico di lavoro.

Collaborare con gli esperti di materia di Azure (PMI) per eseguire una valutazione approfondita dell'architettura. Consentono di determinare i servizi di Azure più adatti in base ai requisiti specifici, tra cui prestazioni, disponibilità e scalabilità. Ricordarsi di prendere in considerazione fattori come costi, sicurezza dei dati, conformità e ripristino di emergenza durante la progettazione dell'architettura.

È anche essenziale controllare e ottimizzare continuamente le risorse di Azure per garantire efficienza ed efficienza in termini di costi.

Bilanciamento del carico e velocità effettiva: è importante valutare le caratteristiche del carico di lavoro dei server applicazioni. Alcuni server gestiscono più attività e creano una velocità effettiva superiore rispetto ad altre. Queste informazioni sono fondamentali quando si progettano i set di scalabilità di macchine virtuali di Azure e la configurazione del bilanciamento del carico per assicurarsi che le risorse vengano allocate in modo efficace

Livello di database: le architetture a disponibilità elevata sono consigliate con Oracle Data Guard per Oracle in Azure IaaS. Le applicazioni richiedono un tipo specifico di installazione a disponibilità elevata e sono elencate in ogni applicazione.

Backup: i backup vengono inviati dal livello applicazione e dal livello di database. È solo uno dei motivi per cui questi due livelli non devono essere separati in due fornitori diversi. I backup del database vengono eseguiti snapshot del volume di Backup di Azure in file Premium nell'area secondaria.

Ripristino di emergenza: sono disponibili diverse soluzioni tra cui scegliere. Dipende molto dalle proprie esigenze. L'architettura è stata creata per essere a disponibilità elevata. Per la replica del livello applicazione, è possibile usare Azure Site Recovery. Un'altra soluzione che è possibile scegliere sono le opzioni di ridondanza per i dischi gestiti. Entrambe le soluzioni replicano i dati. Le opzioni di ridondanza per i dischi gestiti sono una soluzione che può semplificare l'architettura, ma presenta anche alcune limitazioni.

Siebel in Azure

Oracle Siebel CRM continua a essere una soluzione CRM di livello aziendale preferita da molte aziende. Si tratta di una delle applicazioni più complesse del portfolio Oracle che offre una combinazione di funzionalità transazionali, analitiche e di engagement per gestire le operazioni rivolte ai clienti.

Di seguito è riportata l'architettura consigliata di una distribuzione di un'applicazione Siebel in Macchine virtuali di Azure per Innovation Pack 16 e versioni precedenti:

Il diagramma seguente è l'architettura di una distribuzione di un'applicazione Siebel in Macchine virtuali di Azure per Innovation Pack 17 e versioni precedenti:

Considerazioni sulla progettazione di Oracle Siebel

• Rete e sicurezza: le impostazioni di rete per Oracle Siebel in Azure devono seguire anche le considerazioni generali sulla rete e sulla sicurezza.

• La migrazione deve essere eseguita usando la subnet dello strumento Siebel.

Livello applicazione

• Sono necessarie configurazioni della versione 17 o successive – di determinati server e utilità nell'applicazione e nel database.

Livello database

• Verificare che le versioni di Database e Siebel corrispondano.
• Verificare che i database primari e replicati vengano copiati in un database secondario usando l'architettura di riferimento Oracle di Oracle Data Guard.

E-Business Suite in Azure

Oracle E-Business Suite (EBS) è una suite di applicazioni, tra cui Supply Chain Management (SCM) e Customer Relationship Management (CRM). Poiché EBS è un sistema SCM e CRM, in genere ha molte interfacce per sistemi di terze parti. L'architettura seguente è stata compilata per essere a disponibilità elevata all'interno di un'area.

Si presuppone che gli utenti esterni non attraversino la rete aziendale nel diagramma seguente.

Considerazioni sulla progettazione di Oracle EBS

Livello database: il database primario e secondario deve trovarsi all'interno di un data center. È consigliabile usare la configurazione sincrona. Se si installa l'applicazione tra data center, è necessario configurare Data Guard in modalità asincrona.

JD Edwards in Azure

JD Edwards di Oracle è una suite di applicazioni integrata di software completo per la pianificazione delle risorse aziendali. Attualmente JD Edwards viene usato in Supply Chain, Warehouse Management, Logistics, Manufacturing Resource Planning e altro ancora. A causa dell'uso dell'applicazione, si noterà che anche le interfacce ad altri sistemi sono importanti.

L'architettura seguente è stata creata per essere a disponibilità elevata. Si presuppone che gli utenti esterni non accedano alla rete aziendale. Se un utente esterno accede all'applicazione usando la rete aziendale, l'architettura può essere semplificata nella rete come indicato di seguito.

Considerazioni sulla progettazione di JD Edwards

Livello Web: il livello Web dell'applicazione è in genere costituito da più server applicazioni. In JD Edwards le regole vengono spesso salvate in questi server Web applicazioni.

• Livello presentazione: ogni istanza nel livello presentazione è associata all'archiviazione. Il taglio delle dipendenze tra istanze può causare latenze elevate, quindi è fondamentale valutarle attentamente.

• Variazione delle prestazioni del server: alcuni server possono gestire più attività e creare una velocità effettiva superiore rispetto ad altre. Durante la fase di progettazione, è essenziale valutare questa variazione della velocità effettiva per garantire che l'infrastruttura possa gestire i carichi di lavoro di picco in modo efficiente.

• Riprogettazione: l'uso di set di scalabilità di macchine virtuali di Azure per la scalabilità automatica non richiede una riprogettazione dell'installazione di JD Edwards. Si tratta di una soluzione scalabile che può essere implementata senza modifiche significative all'architettura dell'applicazione.

Livello database: il database primario e secondario rimangono all'interno di un data center, è consigliabile usare la configurazione sincrona. Se si installa l'applicazione tra data center, è necessario configurare Data Guard in modalità asincrona. I dati dal livello di database vengono inviati direttamente a un'archiviazione di Azure. L'archiviazione dipende dalla configurazione dell'architettura corrente.

PeopleSoft in Azure

La suite di applicazioni PeopleSoft di Oracle contiene software per le risorse umane e la gestione finanziaria. La suite di applicazioni è multilivello e le applicazioni includono: human resource management systems (HRMS), customer relationship management (CRM), financials and supply chain management (FSCM) e Enterprise Performance Management (EPM).

Considerazioni sulla progettazione di PeopleSoft

Livello applicazione: il livello applicazione contiene diverse attività e server. Esegue la logica di business e i processi, ma mantiene anche la connessione al database. Non appena questa dipendenza viene tagliata, causa latenze.

• Dipendenza tra livelli di applicazione e database: è importante ridurre al minimo la latenza tra l'applicazione e i livelli di database. Inserendo l'applicazione e il livello di database nello stesso provider di servizi cloud (Azure, in questo caso), si riduce la latenza di rete. Azure offre diverse opzioni di rete e servizi, ad esempio il peering reti virtuali o ExpressRoute, per garantire connessioni a bassa latenza tra i livelli.

• Considerazioni sul sistema operativo: se l'utilità di pianificazione dei processi richiede in modo specifico sistemi operativi Windows, è comunque possibile eseguirla in macchine virtuali di Azure. Azure supporta varie versioni di Windows Server, consentendo di scegliere quella che soddisfa i requisiti dell'applicazione.

• Valutazione dell'architettura: valutare attentamente i requisiti di architettura, tra cui scalabilità, disponibilità e prestazioni. Per garantire disponibilità elevata e scalabilità, è consigliabile configurare più istanze del server applicazioni in una configurazione con carico bilanciato.

Livello di database: il database primario e replicato in un database secondario deve rimanere all'interno di un data center. È consigliabile usare la configurazione sincrona. Se si installa l'applicazione tra data center, è necessario configurare Data Guard in modalità asincrona.

Passaggi successivi

Architetture di riferimento per Oracle Database

Eseguire la migrazione del carico di lavoro Oracle alle macchine virtuali di Azure