Progettare e implementare un database Oracle in Azure

Si applica a: ✔️ vm Linux

Si supponga di pianificare la migrazione di un database Oracle da una posizione locale ad Azure. Si dispone del pacchetto di diagnostica o del repository del carico di lavoro automatico per il database Oracle di cui si desidera eseguire la migrazione. Inoltre, si ha una conoscenza delle varie metriche in Oracle e si ha una conoscenza di base delle prestazioni dell'applicazione e dell'utilizzo della piattaforma.

Questo articolo illustra come ottimizzare la distribuzione di Oracle in Azure. Vengono esaminate le opzioni di ottimizzazione delle prestazioni per un database Oracle in un ambiente Azure. Si sviluppano aspettative chiare sui limiti dell'ottimizzazione fisica tramite l'architettura, sui vantaggi dell'ottimizzazione logica del codice del database e sulla progettazione complessiva del database.

Differenze tra i due ambienti

Quando si esegue la migrazione di applicazioni locali ad Azure, tenere presenti alcune importanti differenze tra i due ambienti.

Una differenza importante è che in un'implementazione in Azure le risorse, ad esempio VM, dischi e reti virtuali, vengono condivise con gli altri client. Le risorse possono anche essere limitate in base ai requisiti. Invece di concentrarsi su come evitare errori (talvolta indicati come tempo medio tra gli errori o MTBF), Azure è più incentrato sulla sopravvivenza all'errore (talvolta definito tempo medio per il ripristino oMTTR).

La tabella seguente elenca alcune differenze tra un'implementazione locale e un'implementazione in Azure di un database Oracle.

Implementazione locale Implementazione in Azure
Rete LAN/WAN SDN (Software Defined Networking)
Gruppo di protezione Strumenti di restrizione per indirizzi IP/porte Gruppo di sicurezza di rete
Resilienza MTBF Tempo medio di ripristino
Manutenzione pianificata Applicazione di patch/aggiornamenti Set di disponibilità (applicazione di patch/aggiornamenti gestita da Azure)
Risorsa Dedicato Condivisa con altri client
Aree Data center Coppie di aree
Archiviazione Dischi fisici/SAN Archiviazione gestita da Azure
Scalabilità Scalabilità verticale Scalabilità orizzontale

Requisiti

È consigliabile considerare i requisiti seguenti prima di iniziare la migrazione:

  • Determinare l'utilizzo reale della CPU. Oracle è concesso in licenza in base al core, il che significa che il dimensionamento delle esigenze della vCPU può essere un esercizio essenziale per ridurre i costi.
  • Determinare le dimensioni del database, l'archiviazione di backup e la velocità di crescita.
  • Determinare i requisiti di I/O, che è possibile stimare in base ai report Oracle Statspack e Automatic Workload Repository (AWR). È anche possibile stimare i requisiti degli strumenti di monitoraggio dell'archiviazione disponibili nel sistema operativo.

Opzioni di configurazione

È buona idea generare un report AWR e ottenere alcune metriche che consentono di prendere decisioni sulla configurazione. Sono quindi disponibili quattro potenziali aree che è possibile ottimizzare per migliorare le prestazioni in un ambiente Azure:

  • Dimensioni della macchina virtuale
  • Velocità effettiva della rete
  • Tipi di disco e configurazioni
  • Impostazioni della cache su disco

Generare un report AWR

Se si dispone di un database Oracle edizione Enterprise e si prevede di eseguire la migrazione ad Azure, sono disponibili diverse opzioni. Se si dispone del pacchetto di diagnostica per le istanze di Oracle, è possibile eseguire il report Oracle AWR per ottenere le metriche, ad esempio operazioni di I/O al secondo, Mbps e GiB. Per i database senza licenza di Diagnostics Pack o per un database Oracle edizione Standard, è possibile raccogliere le stesse metriche importanti con un report Statspack dopo la raccolta di snapshot manuali. Le principali differenze tra questi due metodi di creazione di report sono che AWR viene raccolto automaticamente e fornisce più informazioni sul database rispetto a Statspack.

È possibile valutare se eseguire il report AWR durante i carichi di lavoro sia normali che di picco, per poter effettuare un confronto. Per raccogliere il carico di lavoro più accurato, si consideri un report finestra esteso di una settimana anziché un giorno. AWR fornisce medie come parte dei calcoli nel report.

Per una migrazione dei data center, è buona idea raccogliere report per il dimensionamento nei sistemi di produzione. Stimare le copie rimanenti del database usate per i test utente, i test e lo sviluppo in base alle percentuali (ad esempio, il 50% del dimensionamento di produzione).

Per impostazione predefinita, il repository AWR conserva 8 giorni di dati e accetta snapshot a intervalli orari. Per eseguire un report AWR dalla riga di comando, usare il comando seguente:

$ sqlplus / as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql;

Metriche principali

Il report richiede le informazioni seguenti:

  • Tipo di report: HTML o TEXT. Il tipo HTML fornisce altre informazioni.
  • Numero di giorni di snapshot da visualizzare. Ad esempio, per intervalli di un'ora, un report di una settimana produce 168 ID snapshot.
  • Inizio della SnapshotID finestra del report.
  • Fine della SnapshotID finestra del report.
  • Nome del report che deve essere creato dallo script AWR.

Se si esegue il report AWR in un cluster di applicazioni reali (RAC), il report della riga di comando è il file awrgrpt.sql, anziché awrrpt.sql. Il g report crea un report per tutti i nodi nel database RAC, in un singolo report. Questo report elimina la necessità di eseguire un report in ogni nodo RAC.

È possibile ottenere le metriche seguenti dal report AWR:

  • Nome del database, nome dell'istanza e nome host
  • Versione del database (supporto di Oracle)
  • CPU/core
  • SGA/PGA (e advisor per in grado di determinare se è sottovasato)
  • Memoria totale in GB
  • Percentuale CPU occupata
  • CPU del database
  • OPERAZIONI DI I/O al secondo (lettura/scrittura)
  • MBPs (lettura/scrittura)
  • Velocità effettiva della rete
  • Latenza di rete (bassa/alta)
  • Principali eventi di attesa
  • Impostazioni dei parametri per il database
  • Database RAC, Exadata o uso di funzionalità o configurazioni avanzate

Dimensioni della macchina virtuale

Ecco alcuni passaggi che è possibile eseguire per configurare le dimensioni della macchina virtuale per ottenere prestazioni ottimali.

Stimare le dimensioni della macchina virtuale in base a utilizzo di CPU, memoria e I/O dal report AWR

Esaminare i primi cinque eventi in primo piano a tempo che indicano dove si verificano i colli di bottiglia del sistema. Nel diagramma seguente, ad esempio, la sincronizzazione dei file di log è all'inizio. Indica il numero di attese necessarie prima che il writer di log scrive il buffer di log nel file di log di rifornitore. Questi risultati indicano che è necessario migliorare le prestazioni della risorsa di archiviazione o dei dischi. Il diagramma indica anche il numero di CPU (core) e la quantità di memoria.

Screenshot che mostra la sincronizzazione dei file di log nella parte superiore della tabella.

Il diagramma seguente mostra l'I/O totale di lettura e scrittura. Sono stati registrati 59 GB in lettura e 247,3 GB in scrittura durante il periodo di esecuzione del report.

Screenshot che mostra l'I/O totale di lettura e scrittura.

Scegliere una VM

In base alle informazioni raccolte dal report AWR, il passaggio successivo è scegliere una macchina virtuale di dimensioni simili che soddisfi i requisiti. È possibile trovare un elenco delle macchine virtuali disponibili in Ottimizzato per la memoria.

Ottimizzare il dimensionamento delle macchine virtuali con una serie di macchine virtuali simili basate sull'ACU

Dopo aver scelto la macchina virtuale, prestare attenzione all'unità di calcolo di Azure per la macchina virtuale. In base al valore ACU, è possibile scegliere una macchina virtuale diversa più adatta agli specifici requisiti. Per altre informazioni, vedere Unità di calcolo di Azure.

Screenshot della pagina ACU units (Unità ACU).

Velocità effettiva della rete

Come illustra il diagramma seguente, esiste una relazione tra velocità effettiva e IOPS:

Diagramma che mostra la relazione tra velocità effettiva e operazioni di I/O al secondo.

La velocità effettiva totale della rete viene stimata in base alle informazioni seguenti:

  • Traffico SQL*Net
  • MBps x numero di server (flusso in uscita, ad esempio Oracle Data Guard)
  • Altri fattori, ad esempio la replica dell'applicazione

Screenshot della velocità effettiva SQL*Velocità effettiva netta.

In base ai requisiti di larghezza di banda della rete, sono disponibili diversi tipi di gateway tra cui scegliere, ad esempio Basic, VpnGw e Azure ExpressRoute. Per altre informazioni, vedere la pagina Prezzi di Gateway VPN.

Consigli

  • La latenza di rete è superiore rispetto a una distribuzione locale. La riduzione dei round trip di rete può migliorare notevolmente le prestazioni.
  • Per ridurre i round trip, consolidare le applicazioni con transazioni elevate o con un livello di comunicazioni elevato nella stessa macchina virtuale.
  • Usare macchine virtuali con rete accelerata per migliorare le prestazioni di rete.
  • Per alcune distribuzioni Linux, è consigliabile abilitare il supporto TRIM/UNMAP.
  • Installare Oracle Enterprise Manager in una macchina virtuale separata.
  • Le pagine di grandi dimensioni non sono abilitate in Linux per impostazione predefinita. Prendere in considerazione l'abilitazione di pagine di grandi use_large_pages = ONLY Oracle DB. Ciò può contribuire a migliorare le prestazioni. Per altre informazioni, vedere USE_LARGE_PAGES.

Tipi di disco e configurazioni

Ecco alcuni suggerimenti per l'utente quando si considerano i dischi.

  • Dischi del sistema operativo predefiniti: Questi tipi di dischi offrono dati persistenti e memorizzazione nella cache. Sono ottimizzati per l'accesso al sistema operativo all'avvio e non sono progettati per carichi di lavoro transazionali o data warehouse (analitici).

  • Dischi gestiti: Azure gestisce gli account di archiviazione da usare per i dischi delle macchine virtuali. Specificare il tipo di disco (nella maggior parte dei casi, si tratta di unità SSD Premium per i carichi di lavoro Oracle) e le dimensioni del disco necessarie. Azure crea e gestisce il disco automaticamente. Un disco gestito SSD Premium è disponibile solo per le serie di macchine virtuali ottimizzate per la memoria e progettate in modo specifico. Dopo avere scelto determinate dimensioni per la VM, il menu mostra solo gli SKU di Archiviazione Premium disponibili in base a tali dimensioni della VM.

    Screenshot della pagina del disco gestito.

Dopo avere configurato la risorsa di archiviazione in una macchina virtuale, è possibile sottoporre i dischi a test di carico prima di creare un database. Conoscendo la velocità di I/O in termini di latenza e velocità effettiva, è possibile determinare se le macchine virtuali supportano la velocità effettiva prevista con gli obiettivi di latenza. Sono disponibili diversi strumenti per i test di carico delle applicazioni, ad esempio Oracle Orion, Sysbench, SLOB e Fio.

Dopo avere distribuito un database Oracle, eseguire nuovamente il test di carico. Avviare i carico di lavoro normali e di picco. I risultati indicheranno la baseline dell'ambiente. Essere realistici nel test del carico di lavoro. Non ha senso eseguire un carico di lavoro che non sia simile a quello che verrà eseguito nella macchina virtuale in realtà.

Poiché Oracle può essere un database con utilizzo intensivo di I/O, è molto importante ridimensionare lo spazio di archiviazione in base alla frequenza delle operazioni di I/O al secondo anziché alle dimensioni di archiviazione. Se ad esempio le operazioni di I/O al secondo necessarie sono 5.000, ma servono solo 200 GB, si potrebbe comunque scegliere il disco Premium classe P30 anche se ha più di 200 GB di spazio di archiviazione.

È possibile ottenere la frequenza delle operazioni di I/O al secondo dal report AWR. che è determinata da log di rollforward, letture fisiche e frequenza delle scritture. Verificare sempre che anche la serie di macchine virtuali scelta sia in grado di gestire la richiesta di I/O del carico di lavoro. Se la macchina virtuale ha un limite di I/O inferiore rispetto all'archiviazione, il limite massimo verrà impostato dalla macchina virtuale.

Screenshot della pagina del report AWR.

Ad esempio: la dimensione di rollforward è 12.200.000 byte al secondo, equivalente a 11,63 Mbps. Le operazioni di I/O al secondo corrispondono a 12.200.000/2.358 = 5.174.

Dopo avere ottenuto un quadro preciso dei requisiti di I/O, è possibile scegliere la combinazione delle unità più adatte per soddisfare tali requisiti.

Consigli

  • Per lo spazio di tabella dei dati, ripartire il carico di lavoro di I/O tra diversi dischi usando l'archiviazione gestita o Oracle ASM.
  • Usare la compressione avanzata Oracle per ridurre le operazioni di I/O (sia per i dati che per gli indici).
  • Separare i log di ripristino, temporaneo e annullare gli spazi di tabella in dischi dati separati.
  • Non inserire file dell'applicazione nei dischi predefiniti del sistema operativo. Questi dischi non sono ottimizzati per l'avvio rapido delle macchine virtuali e potrebbero non offrire prestazioni valide per l'applicazione.
  • Quando si usano macchine virtuali serie M in Archiviazione Premium, abilitare l'acceleratore di scrittura nel disco dei log di ripristino.
  • Provare a spostare i log di ripristino con latenza elevata nel disco Ultra.

Impostazioni della cache su disco

Sebbene siano disponibili tre opzioni per la memorizzazione nella cache dell'host, è consigliabile solo la memorizzazione nella cache di sola lettura per un carico di lavoro del database in un database Oracle. La lettura/scrittura può introdurre vulnerabilità significative a un file di dati, perché l'obiettivo di una scrittura del database è registrarlo nel file di dati, non memorizzare nella cache le informazioni. Con la modalità di sola lettura, tutte le richieste vengono memorizzate nella cache per le operazioni di lettura future. Tutte le operazioni di scrittura continuano a essere scritte su disco.

Consigli

Per ottimizzare la velocità effettiva, iniziare con la modalità di sola lettura per la memorizzazione nella cache dell'host quando possibile. Per l'archiviazione Premium, tenere presente che è necessario disabilitare le barriere quando si monta il file system con le opzioni di sola lettura. Aggiornare il file /etc/fstab con l'identificatore univoco universale per i dischi.

Screenshot della pagina del disco gestito che mostra l'opzione di sola lettura.

  • Per i dischi del sistema operativo, usare unità SSD Premium con memorizzazione nella cache dell'host di lettura/scrittura.
  • Per i dischi dati che contengono quanto segue, usare unità SSD Premium con memorizzazione nella cache dell'host di sola lettura: file di dati Oracle, file temporanei, file di controllo, file di rilevamento delle modifiche, file BFILE, file per tabelle esterne e log di flashback.
  • Per i dischi dati che contengono file di log di ripristino online Oracle, usare SSD Premium o UltraDisk senza memorizzazione nella cache dell'host (opzione Nessuno). I file di log di ripristino Oracle archiviati e i set di backup Gestione ripristino Oracle possono risiedere anche con i file di log di ripristino online. Si noti che la memorizzazione nella cache dell'host è limitata a 4095 GiB, quindi non allocare un'unità SSD Premium superiore a P50 con memorizzazione nella cache dell'host. Se sono necessari più di 4 TiB di archiviazione, eseguire lo stripe di più unità SSD Premium con RAID-0, usando Linux LVM2 o Oracle Automatic Archiviazione Management.

Se i carichi di lavoro variano notevolmente tra il giorno e la sera e il carico di lavoro di I/O può supportarlo, L'unità SSD Premium P1-P20 con bursting potrebbe fornire le prestazioni necessarie durante i caricamenti batch notturni o richieste di I/O limitate.

Sicurezza

Dopo aver configurato l'ambiente di Azure, è necessario proteggere la rete. Di seguito sono elencati alcuni suggerimenti:

  • Criteri del gruppo di sicurezza di rete: È possibile definire il gruppo di sicurezza di rete tramite una subnet o una scheda di interfaccia di rete. È più semplice controllare l'accesso a livello di subnet, sia per la sicurezza che per i firewall applicazione con routing forzato.

  • Jumpbox: Per un accesso più sicuro, gli amministratori non devono connettersi direttamente al database o al servizio dell'applicazione. Usare un jumpbox tra il computer amministratore e le risorse di Azure. Diagramma che mostra la topologia jumpbox.

    Il computer amministratore deve offrire solo l'accesso con restrizioni IP al jumpbox. Il jumpbox deve avere accesso all'applicazione e al database.

  • Rete privata (subnet): È buona idea avere il servizio dell'applicazione e il database in subnet separate, in modo che i criteri del gruppo di sicurezza di rete possano impostare un controllo migliore.

Altre letture

Passaggi successivi