Architetture per il database Oracle in macchine virtuali di Azure

Si applica a: ✔️ macchine virtuali Linux

Questo articolo include informazioni sulla distribuzione di un database Oracle a disponibilità elevata in Azure. Inoltre, questa guida illustra le considerazioni sul ripristino di emergenza. Queste architetture sono state create in base alle distribuzioni dei clienti. Questa guida si applica solo a Oracle Database edizione Enterprise.

Per altre informazioni sull'ottimizzazione delle prestazioni del database Oracle, vedere Progettare e implementare un database Oracle in Azure.

Prerequisiti

• Conoscenza dei diversi concetti di Azure, ad esempio le zone di disponibilità
• Oracle Database edizione Enterprise 12c o versione successiva
• Consapevolezza delle implicazioni relative alle licenze quando si usano le soluzioni in questo articolo
• Requisiti RPO e RTO definiti

Disponibilità elevata per i database Oracle

Il raggiungimento della disponibilità elevata nel cloud è una parte importante della pianificazione e della progettazione di ogni organizzazione. Azure offre zone di disponibilità e set di disponibilità da usare nelle aree in cui le zone di disponibilità non sono disponibili. Per altre informazioni su come progettare per il cloud, vedere Opzioni di disponibilità per Azure Macchine virtuali.

Oltre agli strumenti e alle offerte native del cloud, Oracle offre soluzioni per la disponibilità elevata che possono essere configurate in Azure:

• Oracle Data Guard
• Data Guard con FSFO
• Partizionamento orizzontale
• GoldenGate

Questa guida illustra le architetture di riferimento per ognuna di queste soluzioni.

Quando si esegue la migrazione o si creano applicazioni per il cloud, è consigliabile usare modelli nativi del cloud, ad esempio modello di ripetizione dei tentativi e modello di interruttore. Per altri modelli che potrebbero contribuire a rendere l'applicazione più resiliente, vedere La guida ai modelli di progettazione cloud.

Oracle RAC nel cloud

Oracle Real Application Cluster (RAC) è una soluzione di Oracle che consente ai clienti di ottenere velocità effettiva elevate grazie alla presenza di molte istanze che accedono a un'archiviazione di database. Questo modello è un'architettura condivisa. Anche se Oracle RAC può essere usato per la disponibilità elevata in locale, Oracle RAC da solo non può essere usato per la disponibilità elevata nel cloud. Oracle RAC protegge solo da errori a livello di istanza e non da errori a livello di rack o di data center. Per questo motivo, Oracle consiglia di usare Oracle Data Guard con il database, sia a singola istanza che a RAC, per la disponibilità elevata.

I clienti richiedono in genere un contratto di servizio elevato per eseguire applicazioni cruciali. Oracle attualmente non certifica o supporta Oracle RAC in Azure. Azure offre tuttavia funzionalità come le zone di disponibilità e le finestre di manutenzione pianificata per proteggersi da errori a livello di istanza. Oltre a queste offerte, è possibile usare Oracle Data Guard, Oracle GoldenGate e Oracle Sharding per prestazioni e resilienza elevate. Queste tecnologie consentono di proteggere i database da errori a livello di rack, a livello di data center e geografici.

Quando si eseguono Oracle Databases in più zone di disponibilità con Oracle Data Guard o GoldenGate, è possibile ottenere un contratto di servizio con tempo di attività del 99,99%. Nelle aree di Azure in cui le zone di disponibilità non sono ancora presenti, è possibile usare i set di disponibilità e ottenere un contratto di servizio di tempo di attività del 99,95%.

Ripristino di emergenza per i database Oracle

Quando si ospitano applicazioni cruciali nel cloud, è importante progettare per la disponibilità elevata e il ripristino di emergenza.

Per Oracle Database edizione Enterprise, Oracle Data Guard è una funzionalità utile per il ripristino di emergenza. È possibile configurare un'istanza di database di standby in un'area di Azure abbinata e configurare il failover di Data Guard per il ripristino di emergenza. Per una perdita di dati zero, è consigliabile distribuire un'istanza di Oracle Data Guard Far Sync oltre ad Active Data Guard.

Per la replica dei dati a lunga distanza, è consigliabile usare La sincronizzazione lontano. Far Sync è una funzionalità Oracle Active Data Guard.

Oracle Far Sync punta a una lunga distanza tra il database primario e il database secondario introducendo un server intermedio noto come Istanza di sincronizzazione lontano. Questo server riceve i dati di rollforward dal database primario e quindi lo inoltra al database di standby. Di conseguenza, l'istanza Di sincronizzazione lontano viene posizionata più vicina al database primario per ridurre il tempo di comunicazione. Il server Di sincronizzazione lontano trasferisce quindi i dati di rollforward in modo asincrono al database secondario.

Architetture di riferimento

Oracle Data Guard

Oracle Data Guard garantisce disponibilità elevata, protezione dei dati e ripristino di emergenza per i dati aziendali. Data Guard gestisce i database di standby come copie coerenti in modo transazionale del database primario. A seconda della distanza tra i database primari e secondari e la tolleranza dell'applicazione per la latenza, è possibile configurare la replica sincrona o asincrona.

Oracle Data Guard con failover fast-start

Data Guard può essere distribuito tramite Fast Start Failover (FSFO). Fast-Start-Failover è una funzionalità fornita all'interno della configurazione di Data Guard Broker. Questa funzionalità consente di eseguire automaticamente il failover in caso di errore. L'ora predefinita usata dai clienti è di 30 secondi, ma può essere modificata in base alle esigenze. Questa operazione denominata OperationTimeout fa parte delle proprietà di Data Guard definite durante la distribuzione.

Funzionamento di Data Guard con questa proprietà

L'attività Guardie dati consiste nel monitorare continuamente l'integrità e lo stato del database primario e secondario. Non appena si abilita Fast-Start-Failover (FSFO), il processo osservatore viene attivato e rivede lo stato di integrità a intervalli regolari per garantire la disponibilità elevata in un determinato momento.

Ora, se il database primario non è più disponibile, l'osservatore e Data Guard Broker rilevano questa interruzione. Di conseguenza, il parametro OperationTimeout di 30 secondi specifica per quanto tempo Broker deve attendere una risposta dal database primario prima di eseguire ulteriori azioni.

Il che comporta quindi se il database primario non risponde all'interno di questa finestra di 30 secondi, l'osservatore presuppone che il database primario non sia accessibile e inizi il processo di failover.

Broker promuove immediatamente il database di standby allo stato primario, cambiando i ruoli e assicurando che l'applicazione possa riprendere rapidamente dallo standby.

Durante questo periodo, Il broker garantisce anche che le transazioni siano aggiornate nello standby. Con la modalità configurata, che può essere Disponibilità massima o Protezione massima, una replica sincrona offre una perdita minima di dati pari a zero. I database Oracle vengono posizionati in più zone di disponibilità per la disponibilità elevata. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. Per garantire la resilienza, vengono configurate almeno tre zone separate in tutte le aree abilitate. La separazione fisica delle zone di disponibilità all'interno di un'area protegge i dati dagli errori del data center. Inoltre, due osservatori FSFO sono configurati in due zone di disponibilità per avviare il failover nel database secondario in caso di errore. Dopo che il failover è stato eseguito e il database primario precedente è nuovamente disponibile, può essere ripristinato. Data Guard Broker facilita questo processo.

In definitiva, se il database primario non è disponibile a causa di un'interruzione pianificata o non pianificata, Data Guard passa o esegue il failover nel database di standby.

Questa funzionalità può offrire resilienza aggiuntiva configurando l'osservatore in una macchina virtuale separata. Di conseguenza, si distribuisce l'osservatore in una macchina virtuale leggera. Questo approccio consente disponibilità elevata e resilienza.

Con Oracle Database versione 12.2 e successive, è anche possibile configurare più osservatori con una singola configurazione del broker Oracle Data Guard. Offre disponibilità aggiuntiva, nel caso in cui un osservatore e il database secondario subisca tempi di inattività. Per altre informazioni su Data Guard Broker e sui relativi vantaggi, vedere Concetti relativi a Oracle Data Guard Broker.

Il diagramma seguente illustra un'installazione di Oracle Data Guard senza Far Sync con un tempo di recupero inferiore a 5 minuti.

I database Oracle vengono posizionati in più zone di disponibilità per la disponibilità elevata. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. Per garantire la resilienza, vengono configurate almeno tre zone separate in tutte le aree abilitate. La separazione fisica delle zone di disponibilità all'interno di un'area protegge i dati dagli errori del data center. Inoltre, due osservatori FSFO sono configurati in due zone di disponibilità per avviare il failover nel database secondario in caso di errore.

È inoltre consigliabile distribuire Oracle Enterprise Manager per avere una panoramica del livello di database. È consigliabile distribuire Monitoraggio di Azure con le metriche seguenti: Monitorare i dischi:

• Percentuale di operazioni di I/O al secondo del disco del sistema operativo utilizzate
• Percentuale di operazioni di I/O al secondo del disco dati utilizzate
• Byte letti da disco dati/sec
• Byte scritti su disco dati/sec
• Profondità coda disco
• Larghezza di banda del disco in % per lun

Oltre a quanto indicato sopra, è consigliabile abilitare anche le informazioni dettagliate sulle macchine virtuali.

La macchina virtuale viene scelta in base alla valutazione AWR. Per altre informazioni, vedere Oracle Capacity Planning (Pianificazione della capacità Oracle). È consigliabile usare vCPU core vincolati per risparmiare sui costi di licenza e ottimizzare le prestazioni.

La scelta del tipo di disco dipende dall'output della valutazione AWR.

Come accennato in precedenza, Far Sync è una funzionalità prevalentemente usata negli scenari in cui si esegue la replica tra aree superando lunghe distanze. Facendo riferimento a questo scenario, Oracle Active Data Guard Far Sync offre zero funzionalità di protezione dalla perdita di dati per i database Oracle. L'istanza di Oracle Far Sync deve essere installata in una macchina virtuale separata.

L'unità SSD Premium v2 non è supportata per i file che fanno riferimento al sistema operativo. Per altre informazioni, vedere Distribuire SSD Premium v2.

Quando viene usata la destinazione backup di File Premium di Azure. Questa soluzione è la più efficiente. È anche possibile usare Archiviazione BLOB di Azure come destinazione di backup. Assicurarsi sempre di testare l'opzione più adatta alle proprie esigenze. Vedere anche Oracle Database Backup Strategies (Strategie di backup del database Oracle).

Oracle Data Guard Far Sync

Come accennato in precedenza, Far Sync è una funzionalità prevalentemente usata negli scenari in cui si esegue la replica tra aree superando lunghe distanze. Facendo riferimento a questo scenario, Oracle Far Sync offre una funzionalità di protezione dalla perdita di dati zero per i database Oracle. L'istanza di Oracle Far Sync deve essere installata in una macchina virtuale separata.

Per una protezione dalla perdita di dati zero, è necessario che sia presente una comunicazione sincrona tra il database primario e l'istanza di Far Sync. L'istanza di Far Sync riceve il rollforward dal database primario in modo sincrono e lo inoltra immediatamente a tutti i database di standby in modo asincrono. Questa configurazione riduce anche il sovraccarico del database primario, perché deve inviare solo il rollforward all'istanza di Sincronizzazione lontano anziché a tutti i database di standby. Se un'istanza di Sincronizzazione lontano ha esito negativo, Active Data Guard usa automaticamente il trasporto asincrono per il database secondario dal database primario per mantenere la protezione dalla perdita di dati quasi zero. Per una maggiore resilienza, i clienti potrebbero distribuire più istanze di Far Sync per ogni istanza del database, incluse le istanze primarie e secondarie.

Il diagramma seguente è un'architettura che usa Oracle Active Data Guard FSFO e Far Sync per ottenere disponibilità elevata e ripristino di emergenza:

Oracle GoldenGate

GoldenGate consente lo scambio e la manipolazione dei dati a livello di transazione tra più piattaforme eterogenee in tutta l'azienda. Sposta le transazioni di cui è stato eseguito il commit con integrità delle transazioni e un sovraccarico minimo sull'infrastruttura esistente. L'architettura modulare offre la flessibilità necessaria per estrarre e replicare record di dati selezionati, modifiche transazionali e modifiche al linguaggio DDL (Data Definition Language) in varie topologie.

Oracle GoldenGate consente di configurare il database per la disponibilità elevata fornendo la replica bidirezionale. Questo approccio consente di configurare una configurazione multimaster o attiva-attiva che richiede la consapevolezza a livello di applicazione. Il diagramma seguente è un'architettura consigliata per la configurazione attiva-attiva di Oracle GoldenGate in Azure. Nell'architettura seguente il database Oracle è stato configurato usando una macchina virtuale ottimizzata per la memoria iperthreading con vCPU core vincolati per risparmiare sui costi di licenza e ottimizzare le prestazioni. L'architettura usa più dischi Premium o Ultra (dischi gestiti) per prestazioni e disponibilità.

Oracle GoldenGate include processi come Extract, Pump e Replicat che consentono di replicare in modo asincrono i dati da un server di database Oracle a un altro. Questi processi consentono di configurare una replica bidirezionale per garantire la disponibilità elevata del database in caso di tempi di inattività a livello di zona di disponibilità.

Nel diagramma precedente il processo di estrazione viene eseguito nello stesso server del database Oracle. I processi Data Pump e Replicat vengono eseguiti in un server separato nella stessa zona di disponibilità. Il processo di replica viene usato per ricevere dati dal database nell'altra zona di disponibilità ed eseguire il commit dei dati nel database Oracle nella relativa zona di disponibilità. Analogamente, il processo Data Pump invia i dati estratti dal processo extract al processo di replica nell'altra zona di disponibilità.

Mentre il diagramma dell'architettura precedente mostra i processi Data Pump e Replicat configurati in un server separato, è possibile configurare tutti i processi Oracle GoldenGate nello stesso server, in base alla capacità e all'utilizzo del server. Consultare sempre il report AWR e le metriche in Azure per comprendere il modello di utilizzo del server.

Quando si configura la replica bidirezionale di Oracle GoldenGate in zone di disponibilità diverse o in aree diverse, è importante assicurarsi che la latenza tra i diversi componenti sia accettabile per l'applicazione. La latenza tra le zone di disponibilità e le aree può variare. La latenza dipende da più fattori. È consigliabile configurare i test delle prestazioni tra il livello applicazione e il livello di database in aree o zone di disponibilità diverse. I test possono verificare che la configurazione soddisfi i requisiti di prestazioni dell'applicazione.

Il livello applicazione può essere configurato nella propria subnet e il livello di database può essere separato nella propria subnet. Quando possibile, è consigliabile usare app Azure lication Gateway per bilanciare il carico del traffico tra i server applicazioni. gateway applicazione è un solido servizio di bilanciamento del carico del traffico Web. Fornisce affinità di sessione basata su cookie che mantiene una sessione utente nello stesso server, riducendo al minimo i conflitti nel database. Le alternative a gateway applicazione sono Azure Load Balancer e Gestione traffico di Azure.

Partizionamento orizzontale oracle

Il partizionamento orizzontale è un modello di livello dati introdotto in Oracle 12.2. Consente di partizionare orizzontalmente e ridimensionare i dati tra database indipendenti. Si tratta di un'architettura senza condivisione in cui ogni database è ospitato in una macchina virtuale dedicata. Questo modello consente una velocità effettiva di lettura e scrittura elevata oltre alla resilienza e alla maggiore disponibilità.

Questo modello elimina singoli punti di errore, fornisce l'isolamento degli errori e abilita gli aggiornamenti in sequenza senza tempi di inattività. Il tempo di inattività di una partizione o di un errore a livello di data center non influisce sulle prestazioni o sulla disponibilità delle altre partizioni in altri data center.

Il partizionamento orizzontale è adatto per applicazioni OLTP con velocità effettiva elevata che non possono permettersi tempi di inattività. Tutte le righe con la stessa chiave di partizionamento orizzontale sono sempre sempre presenti nella stessa partizione. Questo fatto aumenta le prestazioni, garantendo una coerenza elevata. Le applicazioni che usano il partizionamento orizzontale devono avere un modello di dati ben definito e una strategia di distribuzione dei dati, ad esempio hash coerente, intervallo, elenco o composito. La strategia accede principalmente ai dati usando una chiave di partizionamento orizzontale, ad esempio customerId o accountNum. Il partizionamento orizzontale consente anche di archiviare specifici set di dati più vicini ai clienti finali, consentendo così di soddisfare i requisiti di prestazioni e conformità.

È consigliabile replicare le partizioni per la disponibilità elevata e il ripristino di emergenza. Questa configurazione può essere eseguita usando tecnologie Oracle, ad esempio Oracle Data Guard o Oracle GoldenGate. Un'unità di replica può essere una partizione, una parte di una partizione o un gruppo di partizioni. Un'interruzione o un rallentamento di una o più partizioni non influisce sulla disponibilità di un database partizionato.

Per la disponibilità elevata, le partizioni di standby possono essere posizionate nella stessa zona di disponibilità in cui vengono posizionate le partizioni primarie. Per il ripristino di emergenza, le partizioni di standby possono trovarsi in un'altra area. È anche possibile distribuire partizioni in più aree per gestire il traffico in tali aree. Per altre informazioni sulla configurazione della disponibilità elevata e della replica del database partizionato, vedere Disponibilità elevata a livello di partizione.

Il partizionamento orizzontale oracle è costituito principalmente dai componenti seguenti. Per altre informazioni, vedere Panoramica del partizionamento orizzontale di Oracle:

• Catalogo partizioni. Database Oracle per utilizzo speciale che è un archivio permanente per tutti i dati di configurazione del database partizioni. Tutte le modifiche di configurazione, ad esempio l'aggiunta o la rimozione di partizioni, il mapping dei dati e gli DDL in un database di partizione vengono avviati nel catalogo di partizioni. Il catalogo delle partizioni contiene anche la copia master di tutte le tabelle duplicate in un database SDB.

  Il catalogo delle partizioni usa viste materializzate per replicare automaticamente le modifiche alle tabelle duplicate in tutte le partizioni. Il database del catalogo di partizioni funge anche da coordinatore di query usato per elaborare query e query su più partizioni che non specificano una chiave di partizionamento orizzontale.

  È consigliabile usare Oracle Data Guard con zone di disponibilità o set di disponibilità per la disponibilità elevata del catalogo partizioni come procedura consigliata. La disponibilità del catalogo partizioni non ha alcun effetto sulla disponibilità del database partizionato. Un tempo di inattività nel catalogo delle partizioni influisce solo sulle operazioni di manutenzione e sulle query su più partizioni durante il breve periodo di completamento del failover di Data Guard. Il database SDB continua a instradare ed eseguire transazioni online. Un'interruzione del catalogo non influisce su di essi.

• Direttori partizioni. Servizi leggeri che devono essere distribuiti in ogni area o zona di disponibilità in cui si trovano le partizioni. I director di partizionamento orizzontale sono global service manager distribuiti nel contesto del partizionamento orizzontale di Oracle. Per la disponibilità elevata, è consigliabile distribuire almeno un director di partizione in ogni zona di disponibilità in cui sono presenti le partizioni.

  Quando ci si connette inizialmente al database, il director di partizione configura le informazioni di routing e memorizza nella cache le informazioni per le richieste successive, ignorando il director di partizione. Dopo aver stabilito la sessione con una partizione, tutte le query SQL e le DML sono supportate ed eseguite nell'ambito della partizione specificata. Questo routing è veloce e viene usato per tutti i carichi di lavoro OLTP che eseguono transazioni all'interno della partizione. È consigliabile usare il routing diretto per tutti i carichi di lavoro OLTP che richiedono le prestazioni e la disponibilità più elevate. La cache di routing viene aggiornata automaticamente quando una partizione diventa non disponibile o si verificano modifiche alla topologia di partizionamento orizzontale.

  Per il routing dipendente dai dati ad alte prestazioni, Oracle consiglia di usare un pool di connessioni quando si accede ai dati nel database partizionato. I pool di connessioni Oracle, le librerie specifiche del linguaggio e i driver supportano il partizionamento orizzontale di Oracle. Per altre informazioni, vedere Panoramica del partizionamento orizzontale di Oracle.

• Servizio globale. Il servizio globale è simile al normale servizio di database. Oltre a tutte le proprietà di un servizio di database, un servizio globale dispone di proprietà per i database partizionati. Queste proprietà includono l'affinità tra i client e la partizione e la tolleranza di ritardo della replica. È necessario creare un solo servizio globale per leggere/scrivere dati da e verso un database partizionato. Quando si usa Active Data Guard e si configurano repliche di sola lettura delle partizioni, è possibile creare un altro servizio globale per carichi di lavoro di sola lettura. Il client può usare questi servizi globali per connettersi al database.

• Database di partizione. I database di partizione sono i database Oracle. Ogni database viene replicato usando Oracle Data Guard in una configurazione broker con FSFO abilitato. Non è necessario configurare il failover e la replica di Data Guard in ogni partizione. Questo aspetto viene configurato e distribuito automaticamente quando viene creato il database condiviso. Se una determinata partizione ha esito negativo, La condivisione Oracle esegue il failover delle connessioni di database dal database primario al standby.

È possibile distribuire e gestire database partizionati Oracle con due interfacce: Oracle Enterprise Manager Cloud Control GUI e l'utilità della GDSCTL riga di comando. È anche possibile monitorare le diverse partizioni per la disponibilità e le prestazioni usando il controllo cloud. Il GDSCTL DEPLOY comando crea automaticamente le partizioni e i rispettivi listener. Inoltre, questo comando distribuisce automaticamente la configurazione di replica usata per la disponibilità elevata a livello di partizione specificata dall'amministratore.

Esistono diversi modi per partizionare un database:

• Partizionamento orizzontale gestito dal sistema: distribuisce automaticamente tra partizioni usando il partizionamento
• Partizionamento orizzontale definito dall'utente: consente di specificare il mapping dei dati alle partizioni, che funziona correttamente in caso di requisiti normativi o di localizzazione dei dati
• Partizionamento orizzontale composito: combinazione di partizionamento orizzontale gestito dal sistema e definito dall'utente per spazi partizioni diversi
• Sottopartizioni tabella: simile a una normale tabella partizionata

Per altre informazioni, vedere Metodi di partizionamento orizzontale.

Un database partizionato è simile a un database singolo per applicazioni e sviluppatori. Quando si esegue la migrazione a un database partizionato, pianificare attentamente la comprensione delle tabelle duplicate rispetto al partizionamento orizzontale.

Le tabelle duplicate vengono archiviate in tutte le partizioni, mentre le tabelle partizionate vengono distribuite tra partizioni diverse. È consigliabile duplicare tabelle piccole e dimensionali e distribuire/partizionare le tabelle dei fatti. I dati possono essere caricati nel database partizionato usando il catalogo partizioni come coordinatore centrale o eseguendo Data Pump in ogni partizione. Per altre informazioni, vedere Migrazione dei dati a un database partizionato.

Partizionamento orizzontale oracle con Data Guard

Oracle Data Guard può essere usato per il partizionamento orizzontale con metodi di partizionamento orizzontale gestiti dal sistema, definiti dall'utente e compositi.

Il diagramma seguente è un'architettura di riferimento per il partizionamento orizzontale oracle con Oracle Data Guard usato per la disponibilità elevata di ogni partizione. Il diagramma dell'architettura mostra un metodo di partizionamento orizzontale composito. Il diagramma dell'architettura è probabilmente diverso per le applicazioni con requisiti diversi per la località dei dati, il bilanciamento del carico, la disponibilità elevata e il ripristino di emergenza. Le applicazioni possono usare metodi diversi per il partizionamento orizzontale. Il partizionamento orizzontale oracle consente di soddisfare questi requisiti e di ridimensionare orizzontalmente ed in modo efficiente fornendo queste opzioni. È anche possibile distribuire un'architettura simile usando Oracle GoldenGate.

Il partizionamento orizzontale gestito dal sistema è il più semplice da configurare e gestire. Il partizionamento orizzontale definito dall'utente o il partizionamento orizzontale composito è adatto per scenari in cui i dati e l'applicazione sono distribuiti geograficamente o in scenari in cui è necessario avere il controllo sulla replica di ogni partizione.

Nell'architettura precedente, il partizionamento orizzontale composito viene usato per geodistribuire i dati e aumentare orizzontalmente i livelli dell'applicazione. Il partizionamento orizzontale composito è una combinazione di partizionamento orizzontale gestito dal sistema e definito dall'utente e offre quindi il vantaggio di entrambi i metodi. Nello scenario precedente, i dati vengono prima partizionati in più spazi partizioni separati dall'area. I dati vengono quindi ulteriormente partizionati usando hash coerente tra più partizioni nello spazio partizioni.

Ogni shardspace contiene più shardgroup. Ogni shardgroup ha più partizioni ed è un'unità di replica. Ogni shardgroup contiene tutti i dati nello spazio partizioni. I gruppi di partizioni A1 e B1 sono shardgroup primari, mentre gli shardgroup A2 e B2 sono standby. È possibile scegliere di avere singole partizioni come unità di replica, anziché uno shardgroup.

Nell'architettura precedente, un global service manager (GSM)/shard director viene distribuito in ogni zona di disponibilità per la disponibilità elevata. È consigliabile distribuire almeno un director GSM/partizioni per data center/area. Inoltre, un'istanza del server applicazioni viene distribuita in ogni zona di disponibilità che contiene un shardgroup. Questa configurazione consente all'applicazione di mantenere bassa la latenza tra il server applicazioni e il database/shardgroup. Se un database ha esito negativo, il server applicazioni nella stessa zona del database di standby può gestire le richieste quando si verifica la transizione del ruolo del database. app Azure lication Gateway e il director di partizione tengono traccia della latenza della richiesta e della risposta e instradano le richieste di conseguenza.

Dal punto di vista dell'applicazione, il sistema client effettua una richiesta di app Azure lication Gateway o di altre tecnologie di bilanciamento del carico in Azure, che reindirizza la richiesta all'area più vicina al client. app Azure lication Gateway supporta anche sessioni permanenti, pertanto tutte le richieste provenienti dallo stesso client vengono instradate allo stesso server applicazioni. Il server applicazioni usa il pool di connessioni nei driver di accesso ai dati. Questa funzionalità è disponibile nei driver, ad esempio JDBC, ODP.NET e OCI. I driver possono riconoscere le chiavi di partizionamento orizzontale specificate come parte della richiesta. Il pool di connessioni universali Oracle per i client JDBC può consentire ai client applicazioni non Oracle, ad esempio Apache Tomcat e IIS, di usare il partizionamento orizzontale oracle. Per altre informazioni, vedere Panoramica del pool condiviso ucp per il partizionamento orizzontale del database.

Durante la richiesta iniziale, il server applicazioni si connette al server delle partizioni nella relativa area per ottenere informazioni di routing per la partizione a cui deve essere instradata la richiesta. In base alla chiave di partizionamento orizzontale passata, il server applicazioni viene instradato alla rispettiva partizione. Il server applicazioni memorizza queste informazioni nella cache creando una mappa e per le richieste successive ignora il server di partizione e instrada le richieste direttamente alla partizione.

Partizionamento orizzontale di Oracle con GoldenGate

Il diagramma seguente è un'architettura di riferimento per il partizionamento orizzontale oracle con Oracle GoldenGate per la disponibilità elevata in area di ogni partizione. Anziché l'architettura precedente, questa architettura rappresenta solo la disponibilità elevata all'interno di una singola area di Azure, con più zone di disponibilità. È possibile distribuire un database con disponibilità elevata in più aree, simile all'esempio precedente, usando Oracle GoldenGate.

L'architettura di riferimento precedente usa il metodo di partizionamento orizzontale gestito dal sistema per partizionare i dati. Poiché la replica Oracle GoldenGate viene eseguita a livello di blocco, metà dei dati replicati in una partizione può essere replicata in un'altra partizione. L'altra metà può essere replicata in una partizione diversa.

Il modo in cui i dati vengono replicati dipende dal fattore di replica. Con un fattore di replica di due, sono disponibili due copie di ogni blocco di dati tra le tre partizioni nel gruppo di partizioni. Analogamente, con un fattore di replica di tre e tre partizioni nel gruppo di partizioni, tutti i dati in ogni partizione vengono replicati in ogni altra partizione del gruppo di partizioni. Ogni partizione nel shardgroup può avere un fattore di replica diverso. Questa configurazione consente di definire in modo efficiente la progettazione di disponibilità elevata e ripristino di emergenza all'interno di uno shardgroup e in più gruppi di partizioni.

Nell'architettura precedente, shardgroup A e shardgroup B contengono entrambi gli stessi dati, ma risiedono in zone di disponibilità diverse. Se sia lo shardgroup A che lo shardgroup B hanno lo stesso fattore di replica di tre, ogni riga/blocco della tabella partizionata viene replicato sei volte tra i due shardgroup. Se shardgroup A ha un fattore di replica di tre e shardgroup B ha un fattore di replica di due, ogni riga/blocco viene replicato cinque volte tra i due gruppi di partizioni.

Questa configurazione impedisce la perdita di dati se si verifica un errore a livello di istanza o di zona di disponibilità. Il livello applicazione è in grado di leggere e scrivere in ogni partizione. Per ridurre al minimo i conflitti, il partizionamento orizzontale Oracle definisce un blocco master per ogni intervallo di valori hash. Questa funzionalità garantisce che le richieste di scrittura per un determinato blocco vengano indirizzate al blocco corrispondente. Inoltre, Oracle GoldenGate fornisce il rilevamento e la risoluzione automatici dei conflitti per gestire eventuali conflitti che potrebbero verificarsi. Per altre informazioni e limitazioni sull'implementazione di GoldenGate con oracle Sharding, vedere Uso di Oracle GoldenGate con un database partizionato.

Nell'architettura precedente, un director GSM/shard viene distribuito in ogni zona di disponibilità per la disponibilità elevata. È consigliabile distribuire almeno un director GSM/partizioni per data center o area. Un'istanza del server applicazioni viene distribuita in ogni zona di disponibilità che contiene un shardgroup. Questa configurazione consente all'applicazione di mantenere bassa la latenza tra il server applicazioni e il database/shardgroup. Se un database non riesce, il server applicazioni nella stessa zona del database standby può gestire le richieste dopo la transizione del ruolo del database. app Azure lication Gateway e il director di partizione tengono traccia della latenza della richiesta e della risposta e instradano le richieste di conseguenza.

Dal punto di vista dell'applicazione, il sistema client effettua una richiesta di app Azure lication Gateway o di altre tecnologie di bilanciamento del carico in Azure, che reindirizza la richiesta all'area più vicina al client. app Azure lication Gateway supporta anche sessioni permanenti, pertanto tutte le richieste provenienti dallo stesso client vengono instradate allo stesso server applicazioni. Il server applicazioni usa il pool di connessioni nei driver di accesso ai dati. Questa funzionalità è disponibile nei driver, ad esempio JDBC, ODP.NET e OCI. I driver possono riconoscere le chiavi di partizionamento orizzontale specificate come parte della richiesta. Il pool di connessioni universali Oracle per i client JDBC può consentire ai client applicazioni non Oracle, ad esempio Apache Tomcat e IIS, di usare il partizionamento orizzontale oracle.

Durante la richiesta iniziale, il server applicazioni si connette al server delle partizioni nella relativa area per ottenere informazioni di routing per la partizione a cui deve essere instradata la richiesta. In base alla chiave di partizionamento orizzontale passata, il server applicazioni viene instradato alla rispettiva partizione. Il server applicazioni memorizza queste informazioni nella cache creando una mappa e per le richieste successive ignora il server di partizione e instrada le richieste direttamente alla partizione.

Applicazione di patch e manutenzione

Quando si distribuiscono i carichi di lavoro Oracle in Azure, Microsoft si occupa di tutte le patch a livello di sistema operativo host. Microsoft comunica in anticipo qualsiasi manutenzione pianificata a livello di sistema operativo ai clienti. Due server di due zone di disponibilità diverse non vengono mai applicate contemporaneamente alle patch. Per altre informazioni sulla manutenzione e l'applicazione di patch alle macchine virtuali, vedere Opzioni di disponibilità per Azure Macchine virtuali.

L'applicazione di patch al sistema operativo della macchina virtuale può essere automatizzata usando Automazione di Azure Gestione aggiornamenti. L'applicazione di patch e la gestione del database Oracle possono essere automatizzate e pianificate usando Azure Pipelines o Automazione di Azure Gestione aggiornamenti per ridurre al minimo i tempi di inattività. Per altre informazioni sul recapito continuo e sulle distribuzioni blu/verde, vedere Tecniche di esposizione progressiva.

Considerazioni sull'architettura e sulla progettazione

• Prendere in considerazione l'uso di una macchina virtuale ottimizzata per la memoria iperthreading con vCPU core vincolati per la macchina virtuale del database Oracle per risparmiare sui costi di licenza e ottimizzare le prestazioni. Usare più dischi Premium o Ultra (dischi gestiti) per prestazioni e disponibilità.
• Quando si usano dischi gestiti, il nome del disco/dispositivo potrebbe cambiare al riavvio. È consigliabile usare l'UUID del dispositivo anziché il nome per assicurarsi che i montaggi siano persistenti nello sprite del riavvio. Per altre informazioni, vedere Aggiungere il nuovo file system a /etc/fstab.
• Usare le zone di disponibilità per ottenere disponibilità elevata nell'area.
• Prendere in considerazione l'uso di dischi Ultra quando sono disponibili o premium per il database Oracle.
• Valutare la possibilità di configurare un database Oracle di standby in un'altra area di Azure usando Oracle Data Guard.
• Prendere in considerazione l'uso di gruppi di posizionamento di prossimità per ridurre la latenza tra l'applicazione e il livello di database.
• Le macchine virtuali di Azure hanno una larghezza di banda di rete massima (in genere) superiore alla velocità effettiva massima del disco nello stesso SKU. È possibile ottenere una velocità effettiva più elevata nello stesso SKU di macchina virtuale o usare uno SKU di macchine virtuali di dimensioni inferiori usando un'archiviazione di rete a bassa latenza e ad alte prestazioni, ad esempio Azure NetApp Files. per il database.
• Configurare Oracle Enterprise Manager per la gestione, il monitoraggio e la registrazione.
• Prendere in considerazione l'uso di Oracle Automatic Storage Management per una gestione semplificata dell'archiviazione per il database.
• Introduzione a Oracle Data Guard
• Modificare il codice dell'applicazione per aggiungere modelli nativi del cloud che potrebbero aiutare l'applicazione a essere più resilienti. Prendere in considerazione modelli come il modello di ripetizione dei tentativi, il modello di interruttore e altri definiti nella guida Modelli di progettazione cloud.

Passaggi successivi

Esaminare gli articoli di riferimento oracle seguenti che si applicano allo scenario.

• Introduzione a Oracle Data Guard
• Concetti relativi a Oracle Data Guard Broker
• Configurazione di Oracle GoldenGate per la disponibilità elevata attiva
• Panoramica del partizionamento orizzontale di Oracle