Architetture per il database Oracle in macchine virtuali di Azure
Si applica a: ✔️ macchine virtuali di 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
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:
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%.
Nota
È possibile avere un obiettivo di tempo di attività molto superiore al contratto di servizio del tempo di attività fornito da Microsoft.
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.
Se l'applicazione consente la latenza, è consigliabile configurare l'istanza di Data Guard Far Sync in una zona di disponibilità diversa rispetto al database primario Oracle. Testare accuratamente la configurazione. Usare una modalità di disponibilità massima per configurare il trasporto sincrono dei file di rollforward nell'istanza di Far Sync. Questi file vengono quindi trasferiti in modo asincrono al database di standby.
L'applicazione potrebbe non consentire la perdita di prestazioni durante la configurazione dell'istanza di Far Sync in un'altra zona di disponibilità in modalità disponibilità massima (sincrona). In caso contrario, è possibile configurare un'istanza di Sincronizzazione lontano nella stessa zona di disponibilità del database primario. Per una maggiore disponibilità, è consigliabile configurare più istanze di Sincronizzazione lontano vicino al database primario e almeno un'istanza vicina al database di standby, se il ruolo passa.
Quando si usano database Oracle edizione Standard, sono disponibili soluzioni ISV che consentono di configurare la disponibilità elevata e il ripristino di emergenza, ad esempio DBVisit Standby.
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. Se il database primario non è disponibile a causa di un'interruzione pianificata o non pianificata, Data Guard può passare qualsiasi database di standby al ruolo primario, riducendo al minimo i tempi di inattività.
Quando si usa Oracle Data Guard, è anche possibile aprire il database secondario per scopi di sola lettura. Questa configurazione è denominata Active Data Guard. Oracle Database 12c ha introdotto una funzionalità denominata Istanza di sincronizzazione Far Sync di Data Guard. Questa istanza consente di configurare una configurazione senza perdita di dati del database Oracle senza compromettere le prestazioni.
Nota
Active Data Guard richiede licenze aggiuntive. Questa licenza è necessaria anche per usare la funzionalità Di sincronizzazione lontano. Contattare il rappresentante Oracle per discutere le implicazioni delle licenze.
Oracle Data Guard con failover fast-start
Oracle Data Guard con failover FSFO (Fast-Start Failover) può offrire maggiore resilienza configurando il broker in un computer separato. Il broker di Data Guard e il database secondario eseguono l'osservatore e osservano il database primario per i tempi di inattività. Questo approccio consente anche la ridondanza nella configurazione dell'osservatore di Data Guard.
Con Oracle Database versione 12.2 e successive, è anche possibile configurare più osservatori con una singola configurazione del broker Oracle Data Guard. Questa configurazione offre disponibilità aggiuntiva, nel caso in cui un osservatore e il database secondario riscontrino tempi di inattività. Data Guard Broker è leggero e può essere ospitato in una macchina virtuale relativamente piccola. Per altre informazioni su Data Guard Broker e sui relativi vantaggi, vedere Concetti relativi a Oracle Data Guard Broker.
Il diagramma seguente è un'architettura consigliata per l'uso di Oracle Data Guard in Azure con zone di disponibilità. Questa architettura consente di ottenere un contratto di servizio con tempo di attività della macchina virtuale del 99,99%.
Nel diagramma precedente il sistema client accede a un'applicazione personalizzata con back-end Oracle usando il Web. Il front-end Web è configurato in un servizio di bilanciamento del carico. Il front-end Web effettua una chiamata al server applicazioni appropriato per gestire il lavoro. Il server applicazioni esegue una query sul database Oracle primario. 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. Per prestazioni e disponibilità elevata vengono usati più dischi Premium o Ultra (Managed Disks).
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 vengono configurati in due zone di disponibilità per avviare e eseguire il failover del database nel database secondario quando si verifica un'interruzione.
È possibile configurare altri osservatori o database di standby in una zona di disponibilità diversa, AZ 1, in questo caso, rispetto alla zona illustrata nell'architettura precedente. Infine, Oracle Enterprise Manager (OEM) monitora i database Oracle per il tempo di attività e le prestazioni. OEM ti permette anche di generare diversi report sulle prestazioni e sull'utilizzo.
Nelle aree in cui le zone di disponibilità non sono supportate, è possibile usare i set di disponibilità per distribuire il database Oracle in modo a disponibilità elevata. I set di disponibilità consentono di ottenere un tempo di attività della macchina virtuale del 99,95%. Il diagramma seguente è un'architettura di riferimento di questo utilizzo:
Nota
- Poiché è in corso la distribuzione di una sola istanza dell'OEM, non è necessario inserire la macchina virtuale Oracle Enterprise Manager in un set di disponibilità.
- I dischi Ultra non sono attualmente supportati in una configurazione del set di disponibilità.
Oracle Data Guard Far Sync
Oracle Data Guard Far Sync offre zero funzionalità di protezione dalla perdita di dati per i database Oracle. Questa funzionalità consente di proteggersi dalla perdita di dati in caso di errore del computer di database. Oracle Data Guard Far Sync deve essere installato in una macchina virtuale separata. Far Sync è un'istanza Oracle leggera che include solo un file di controllo, un file di password, uno spfile e log di standby. Non sono presenti file di dati o file di log di rollforward.
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 Far Sync ha esito negativo, Data Guard usa automaticamente il trasporto asincrono nel 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 a disponibilità elevata con Oracle Data Guard Far Sync:
Nell'architettura precedente è disponibile un'istanza di Far Sync distribuita nella stessa zona di disponibilità dell'istanza del database per ridurre la latenza tra i due. Nei casi in cui l'applicazione è sensibile alla latenza, valutare la possibilità di distribuire il database e l'istanza o le istanze di Far Sync in un gruppo di posizionamento di prossimità.
Il diagramma seguente è un'architettura che usa Oracle 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. 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à.
Nota
È possibile configurare un'architettura simile usando i set di disponibilità nelle aree in cui le zone di disponibilità non sono attualmente disponibili.
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. Oracle Universal Connessione Ion Pool (UCP) 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. I client Oracle Universal Connessione ion Pool (UCP) per i client JDBC possono abilitare client di applicazioni non Oracle, ad esempio Apache Tomcat e IIS, per lavorare con 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 Archiviazione Management per una gestione semplificata dell'archiviazione per il database.
- Usare Azure Pipelines per gestire l'applicazione di patch e gli aggiornamenti al database senza tempi di inattività.
- 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.