Condividi tramite


Panoramica delle applicazioni e delle soluzioni Oracle in Azure

Si applica a: ✔️ macchine virtuali Linux

Questo articolo illustra come eseguire soluzioni Oracle usando l'infrastruttura di Azure.

Importante

Oracle RAC e Oracle RAC OneNode non sono supportati nell'infrastruttura Bare Metal di Azure.

Database Oracle nell'infrastruttura Azure

Oracle supporta l'esecuzione delle proprie edizioni Database 12.1 ed Enterprise successive in Azure in immagini di macchine virtuali (VM) basate su Oracle Linux. È possibile eseguire database Oracle nell'infrastruttura di Azure usando oracle database in immagini Oracle Linux disponibili in Azure Marketplace.

  • Oracle Database 12.2 e 18.3 edizione Enterprise
  • Oracle Database 12.2 e 18.3 edizione Standard
  • Oracle Database 19.3
    È anche possibile adottare uno degli approcci seguenti:
  • Configurare Oracle Database in un'immagine Linux non Oracle disponibile in Azure.
  • Creare una soluzione in un'immagine personalizzata creata da zero in Azure.
  • Caricare un'immagine personalizzata dall'ambiente locale.

È anche possibile scegliere di configurare la soluzione con più dischi collegati. È possibile migliorare le prestazioni del database installando Oracle Automated Storage Management (ASM). Per ottenere prestazioni ottimali per i carichi di lavoro di produzione di Oracle Database in Azure, assicurarsi di ridimensionare correttamente l'immagine della macchina virtuale e selezionare le opzioni di archiviazione appropriate in base alla velocità effettiva, alle operazioni di I/O al secondo e alla latenza. Per istruzioni su come iniziare rapidamente a usare un database Oracle in Azure tramite l'immagine della VM pubblicata da Oracle, vedere Creare un Oracle Database in una macchina virtuale di Azure.

Distribuire immagini di macchine virtuali Oracle in Microsoft Azure

Questa sezione illustra le informazioni sulle soluzioni Oracle basate su immagini di macchine virtuali (VM) pubblicate da Oracle in Azure Marketplace. Per ottenere un elenco delle immagini Oracle attualmente disponibili, eseguire il comando seguente usando l'interfaccia della riga di comando di Azure o Azure Cloud Shell

az vm image list --publisher oracle --output table –all

Le immagini sono bring-your-own-license. Vengono addebitati solo i costi di calcolo, archiviazione e rete sostenuti per l'esecuzione di una macchina virtuale. È anche possibile scegliere di compilare le soluzioni in un'immagine personalizzata creata da zero in Azure o caricare un'immagine personalizzata dall'ambiente locale.

Importante

È necessaria una licenza appropriata per usare il software Oracle e un contratto di supporto corrente con Oracle. Oracle garantisce la mobilità delle licenze da locale ad Azure. Per altre informazioni sulla mobilità delle licenze, vedere Le domande frequenti su Oracle e Microsoft Strategic Partnership.

Applicazioni in Oracle Linux e Server WebLogic

Eseguire applicazioni aziendali nel server WebLogic in Azure nelle immagini Oracle Linux supportate. Per altre informazioni, vedere la documentazione di WebLogic, Oracle WebLogic Server on Azure Solution Overview (Panoramica della soluzione Oracle WebLogic in Azure).

WebLogic Server con integrazioni dei servizi di Azure

Oracle e Microsoft collaborano per portare WebLogic Server in Azure Marketplace sotto forma di offerta app Azure lication. Per altre informazioni su queste offerte, vedere Quali sono le soluzioni per eseguire Oracle WebLogic Server?.

Immagini di macchine virtuali Oracle WebLogic Server

Il clustering è supportato solo nella Enterprise Edition. Si dispone della licenza per usare il clustering di WebLogic solo con la Enterprise Edition di Oracle WebLogic Server. Non usare il clustering con Oracle WebLogic Server Standard Edition. Il multicast UDP non è supportato. Azure supporta l'unicast UDP, ma non il multicast e il broadcast. Oracle WebLogic Server può basarsi sulle funzionalità unicast UDP di Azure. Per ottenere risultati ottimali basandosi sull'unicast UDP, è consigliabile che le dimensioni del cluster WebLogic siano statiche o che non siano presenti più di 10 server gestiti. Oracle WebLogic Server prevede che le porte pubbliche e private siano uguali per l'accesso T3. Ad esempio, quando si usa Enterprise JavaBeans (EJB). Si consideri uno scenario multilivello in cui un'applicazione livello di servizio è in esecuzione in un cluster Oracle WebLogic Server costituito da due o più macchine virtuali, in una rete virtuale denominata SLWLS. Il livello client è in una subnet diversa nella stessa rete virtuale, che esegue un semplice programma Java provando a chiamare EJB nel livello di servizio. Poiché è necessario bilanciare il carico del livello di servizio, è necessario creare un endpoint con carico bilanciato pubblico per le macchine virtuali nel cluster Oracle WebLogic Server. Se la porta privata specificata è diversa dalla porta pubblica, si verifica un errore. Ad esempio, se si usa 7006:7008, si verifica l'errore seguente perché per qualsiasi accesso T3 remoto, Oracle WebLogic Server prevede che la porta del servizio di bilanciamento del carico e la porta del server gestito WebLogic siano uguali.

[java] javax.naming.CommunicationException [Root exception is java.net.ConnectException: t3://example.cloudapp.net:7006:

Bootstrap to: example.cloudapp.net/138.91.142.178:7006' over: 't3' got an error or timed out]

In questo caso, il client accede alla porta 7006, ovvero la porta del servizio di bilanciamento del carico, e il server gestito è in ascolto sulla porta 7008, ovvero la porta privata. Questa restrizione è applicabile solo per l'accesso T3 e non per quello HTTP.

Per evitare questo problema, utilizzare una delle soluzioni alternative seguenti:

  • Utilizzare gli stessi numeri di porta pubblica e privata per gli endpoint con carico bilanciato dedicati all'accesso T3.

  • Includere il parametro JVM seguente all'avvio di Oracle WebLogic Server: configCopy Dweblogic.rjvm.enableprotocolswitch=true

  • Limitazioni del clustering dinamico e del bilanciamento del carico. Si supponga di voler usare un cluster dinamico in Oracle WebLogic Server ed esporlo tramite un unico endpoint pubblico con carico bilanciato in Azure. Questo approccio può essere eseguito fino a quando si usa un numero di porta fisso per ogni server gestito, non assegnato dinamicamente da un intervallo. Non avviare più server gestiti di quanto ci siano computer monitorati dall'amministratore. Non deve essere presente più di un server gestito per ogni macchina virtuale. Se la configurazione comporta l'avvio di un numero di server Oracle WebLogic superiore rispetto a quello delle macchine virtuali, non è possibile associare più istanze di Oracle WebLogic Servers a un determinato numero di porta. Ovvero, se più istanze di Oracle WebLogic Server condividono la stessa macchina virtuale, le altre in tale macchina virtuale hanno esito negativo. Se si configura il server di amministrazione per assegnare automaticamente numeri di porta univoci ai server gestiti, il bilanciamento del carico non è possibile. Azure non supporta il mapping da una singola porta pubblica a più porte private, necessarie per questa configurazione.

  • Più istanze di Oracle WebLogic Server in una macchina virtuale. A seconda dei requisiti di distribuzione, si potrebbe prendere in considerazione di eseguire più istanze di Oracle WebLogic Server sulla stessa macchina virtuale, se la macchina virtuale è sufficientemente grande. Ad esempio, su una macchina virtuale di dimensioni medie, che contiene due core, si potrebbe scegliere di eseguire due istanze di Oracle WebLogic Server. Tuttavia, è comunque consigliabile evitare di introdurre singoli punti di errore nell'architettura. L'esecuzione di più istanze di Oracle WebLogic Server su una sola macchina virtuale sarebbe un singolo punto di quel tipo.

L'uso di almeno due macchine virtuali potrebbe essere un approccio migliore. Ogni macchina virtuale può eseguire più istanze di Oracle WebLogic Server. Ogni istanza di Oracle WebLogic Server potrebbe far ancora parte dello stesso cluster. Tuttavia, non è attualmente possibile usare Azure per bilanciare il carico degli endpoint esposti da distribuzioni Oracle WebLogic Server all'interno della stessa macchina virtuale. Azure Load Balancer richiede che i server con carico bilanciato vengano distribuiti tra singole macchine virtuali.

Opzioni di disponibilità elevata e ripristino di emergenza

Quando si usano soluzioni Oracle in Azure, si è responsabili dell'implementazione di una soluzione di disponibilità elevata e ripristino di emergenza per evitare tempi di inattività. È anche possibile implementare la disponibilità elevata e il ripristino di emergenza per Oracle Database edizione Enterprise usando Data Guard, Active Data Guard o Oracle GoldenGate. L'approccio richiede due database su due macchine virtuali distinte, che devono trovarsi nella stessa rete virtuale per assicurarsi che possano accedere l'una all'altra tramite l'indirizzo IP permanente privato.

È consigliabile posizionare le macchine virtuali nello stesso set di disponibilità per consentire ad Azure di inserirle in domini di errore e domini di aggiornamento separati. Se si vuole la ridondanza geografica, configurare questi due database affinché siano in grado di eseguire la replica tra due aree diverse e connettere le due istanze con un gateway VPN. Per una procedura di configurazione di base in Azure, vedere Implementare Oracle Data Guard in una macchina virtuale Linux di Azure.

Con Oracle Active Data Guard è possibile ottenere una disponibilità elevata con un database primario in una macchina virtuale, un database secondario (standby) in un'altra macchina virtuale e una replica unidirezionale configurati tra di essi. Il risultato è l'accesso in lettura alla copia del database. Con Oracle GoldenGate, è possibile configurare la replica bidirezionale tra due database. Per informazioni su come configurare una soluzione a disponibilità elevata per i database usando questi strumenti, vedere Active Data Guard e GoldenGate. Se è necessario accedere in lettura-scrittura alla copia del database, è possibile utilizzare Oracle Active Data Guard.

Per una procedura di configurazione di base in Azure, vedere Implementare Oracle Golden Gate in una macchina virtuale Linux di Azure.

È possibile ottenere una disponibilità elevata per i database Oracle usando il posizionamento del volume della zona di disponibilità di Azure NetApp Files con Oracle Data Guard per un'architettura a disponibilità elevata tra zone. In alternativa, per eliminare il costo delle licenze di Data Guard e l'esecuzione di macchine virtuali nella zona secondaria, è possibile usare la funzionalità di replica basata sull'archiviazione di Azure NetApp Files. I volumi di Azure NetApp Files possono essere inseriti nella zona di disponibilità desiderata nello stesso modo. Può quindi essere replicata tra zone all'interno dell'area usando la replica tra zone o in un'altra area usando la replica tra aree.

Oltre ad avere una soluzione a disponibilità elevata e ripristino di emergenza progettata in Azure, è necessario disporre di una strategia di backup per ripristinare il database.

Eseguire il backup dei carichi di lavoro Oracle

Sono disponibili diverse strategie di backup per Oracle in macchine virtuali di Azure. I backup seguenti sono altre opzioni:

Distribuire applicazioni Oracle in Azure

Usare i modelli Terraform, l'interfaccia della riga di comando di Azure o il portale di Azure per configurare l'infrastruttura di Azure e installare le applicazioni Oracle. È anche possibile usare Ansible per configurare il database all'interno della macchina virtuale. Per altre informazioni, vedere Terraform in Azure.

Oracle ha certificato le applicazioni seguenti da eseguire in Azure per la connessione a un database Oracle usando la soluzione di interconnessione Azure con Oracle Cloud:

  • E-Business Suite
  • JD Edwards EnterpriseOne
  • PeopleSoft
  • Applicazioni Oracle Retail
  • Oracle Hyperion Financial Management

È possibile distribuire applicazioni personalizzate in Azure che si connettono con OCI e altri servizi di Azure.

Supporto per JD Edwards

In base al supporto tecnico Oracle, JD Edwards EnterpriseOne 9.2 e versioni successive è supportato in qualsiasi offerta cloud pubblica che rispetta i requisiti tecnici minimi (MTR). È necessario creare immagini personalizzate che soddisfano le specifiche MTR per la compatibilità delle applicazioni con il sistema operativo e il software. Per altre informazioni, vedere Doc ID 2178595.1.

Licenze

La distribuzione di soluzioni Oracle in Azure si basa su un modello bring-your-own-license. Questo modello presuppone che si disponga di licenze per l'uso del software Oracle e che si disponga di un contratto di supporto corrente con Oracle.

Microsoft Azure è un ambiente cloud autorizzato per l'esecuzione di Oracle Database. La tabella Core Factor di Oracle non è applicabile alle licenze di database Oracle nel cloud. Per altre informazioni, vedere Oracle Processor Core Factor Table. Al contrario, quando si usano macchine virtuali con tecnologia Hyper-Threading abilitata per i database Enterprise Edition, se la tecnologia è abilitata due vCPU equivalgono a una licenza del processore Oracle, come indicato nel documento dei criteri. I dettagli dei criteri sono disponibili in Licenze software Oracle nell'ambiente cloud computing.

I database Oracle richiedono in genere una maggiore quantità di memoria e I/O. Per questo motivo, è consigliabile usare macchine virtuali ottimizzate per la memoria per questi carichi di lavoro. Per ottimizzare ulteriormente i carichi di lavoro, sono consigliabili vCPU core vincolate per carichi di lavoro Oracle Database che richiedono memoria, archiviazione e larghezza di banda I/O elevate, ma non un numero elevato di core.

Quando si esegue la migrazione di carichi di lavoro e software Oracle dall'ambiente locale a Microsoft Azure, Oracle fornisce la mobilità delle licenze come indicato nelle Domande frequenti sulla partnership strategica Oracle e Microsoft.

Passaggi successivi

È ora disponibile una panoramica dei database e delle soluzioni Oracle correnti basati sulle immagini delle macchine virtuali in Microsoft Azure. Il passaggio successivo consiste nel distribuire il primo database Oracle in Azure.