Implementa il disaster recovery con standby multiregionale su Oracle Database@Azure

Garantire una continuità aziendale ininterrotta è fondamentale per avere successo durante la progettazione delle applicazioni. Per raggiungere questo obiettivo è necessaria una solida strategia di disaster recovery progettata per ripristinare rapidamente le funzionalità in caso di interruzioni.

Per anni, le organizzazioni si sono affidate a Oracle Exadata Database Service, la più importante tecnologia di disaster recovery di Oracle per supportare applicazioni mission-critical, sia on-premise che all'interno di Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure su Oracle Database@Azure offre le stesse prestazioni, il set di funzioni e la stessa parità di prezzo leader del settore di Exadata su OCI. Sfrutta le zone di disponibilità (AZ) e le aree geografiche di Microsoft Azure per fornire bassa latenza alle applicazioni di Azure oltre a funzionalità di alta disponibilità e disaster recovery senza pari, garantendo operazioni senza interruzioni durante la manutenzione e in caso di interruzioni.

Architettura

Questa architettura mostra Oracle Exadata Database Service on Dedicated Infrastructure su Oracle Database@Azure in una topologia di disaster recovery multi-region che utilizza due database di standby remoto.

Il seguente diagramma illustra questa architettura di riferimento.


Descrizione di multi-region-standby-dr-db-azure-arch.png
Descrizione dell'immagine multi-region-standby-dr-db-azure-arch.png

multiregione-standby-dr-db-azure-arch-oracle.zip

Oracle Database viene eseguito in un cluster di virtual machine (VM) Exadata nell'area primaria. Per la protezione dei dati e il recupero da errori irreversibili, Oracle Active Data Guard replica i dati in due database di standby in esecuzione su cluster VM Exadata in due diverse aree di standby. Un'impostazione del database di standby remoto garantisce la protezione dei dati dagli errori regionali e può essere utilizzata anche per scaricare l'elaborazione delle query di sola lettura. Replica l'applicazione tra le varie aree per evitare una latenza più elevata dopo il passaggio a un database in standby.

È possibile instradare il traffico di Active Data Guard tramite la rete di Azure. Tuttavia, questa architettura si concentra sul traffico di rete Active Data Guard attraverso la rete OCI per ottimizzare il throughput e la latenza della rete.

La rete di Oracle Exadata Database Service on Dedicated Infrastructure su Oracle Database@Azure è connessa alla subnet del client Exadata utilizzando un gateway di instradamento dinamico (DRG) gestito da Oracle. Un DRG è inoltre necessario per creare una connessione peer tra le reti cloud virtuali (VCN) in aree diverse. Poiché è consentito un solo DRG per ogni VCN in OCI, è necessaria una seconda VCN che funge da VCN hub con il proprio DRG per connettere le VCN primarie e in standby in ogni area. In questa architettura:

  • Il cluster VM Exadata primario viene distribuito in Region 1 in VCN1 con CIDR 10.10.0.0/16.
  • La VCN hub nella Region 1 primaria è HubVCN1 con CIDR 10.11.0.0/16.
  • Il primo cluster VM Exadata di standby viene distribuito in Region 2 in VCN2 con CIDR 10.20.0.0/16.
  • La VCN hub nella prima standby region è HubVCN2 con CIDR 10.22.0.0/16.
  • Il secondo cluster VM Exadata di standby viene distribuito in Region 3 nella directory VCN3 con CIDR 10.30.0.0/16.
  • La VCN hub nella seconda standby region è HubVCN3 con CIDR 10.33.0.0/16.

Per abilitare l'instradamento del transito, per le VCN dell'hub non è necessaria alcuna subnet. Pertanto, queste VCN possono utilizzare intervalli CIDR IP molto piccoli. Le reti VCN nel sito figlio OCI vengono create dopo la creazione dei cluster VM Oracle Exadata Database Service on Dedicated Infrastructure su Oracle Database@Azure per i database primari e in standby.

Microsoft Azure fornisce i seguenti componenti:

  • Area di Azure

    Un'area di Azure è un'area geografica in cui risiedono uno o più data center fisici di Azure, denominati zone di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (tra paesi o addirittura continenti).

    Azure e le region OCI sono aree geografiche localizzate. Per Oracle Database@Azure, un'area di Azure è connessa a un'area OCI, con zone di disponibilità (AZ) in Azure connesse ai domini di disponibilità (AD) in OCI. Le coppie di aree Azure e OCI vengono selezionate per ridurre al minimo distanza e latenza.

  • Area di disponibilità di Azure

    Le zone di disponibilità di Azure sono posizioni fisicamente separate all'interno di un'area di Azure, progettate per garantire alta disponibilità e resilienza fornendo alimentazione, raffreddamento e rete indipendenti.

  • Rete virtuale di Azure (VNet)

    Azure Virtual Network (VNet) è la base fondamentale per la tua rete privata in Azure. VNet consente a molti tipi di risorse di Azure, come le macchine virtuali (VM) di Azure, di comunicare in modo sicuro tra loro, Internet e reti on-premise.

  • Subnet delegata Azure

    Una subnet delegata consente di inserire un servizio gestito, in particolare un servizio platform-as-a-service (PaaS), direttamente nella rete virtuale come risorsa. Hai la gestione completa dell'integrazione dei servizi PaaS esterni all'interno delle tue reti virtuali.

  • Azure Virtual Network Interface Card (VNIC)

    I servizi nei data center di Azure dispongono di schede di interfaccia di rete fisiche (NIC). Le istanze delle virtual machine comunicano utilizzando le schede NIC (VNIC) virtuali associate alle schede NIC fisiche. Ogni istanza dispone di una VNIC primaria creata e collegata automaticamente durante l'avvio ed è disponibile durante la durata dell'istanza.

OCI fornisce i seguenti componenti:

  • Area

    Un'area geografica Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, che ospitano domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (tra paesi o addirittura continenti).

  • Domini di disponibilità

    I domini di disponibilità sono data center standalone e indipendenti all'interno di un'area geografica. Le risorse fisiche in ciascun dominio di disponibilità sono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio alimentazione o raffreddamento, o la rete interna del dominio di disponibilità. Pertanto, un errore in un dominio di disponibilità non dovrebbe influire sugli altri domini di disponibilità nell'area.

  • Rete cloud virtuale (VCN) e subnet

    Una VCN è una rete personalizzabile e definita dal software configurata in un'area Oracle Cloud Infrastructure. Come le tradizionali reti di data center, le reti VCN consentono di controllare l'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo aver creato la VCN. Puoi segmentare una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. È possibile modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.

  • Tabella di instradamento

    Le tabelle di instradamento virtuali contengono regole per instradare il traffico dalle subnet alle destinazioni esterne a una VCN, in genere attraverso i gateway.

  • Peering locale

    Il peering locale ti consente di eseguire il peer di una VCN con un'altra VCN nella stessa area. Peering significa che le VCN comunicano utilizzando indirizzi IP privati, senza il traffico che attraversa Internet o l'instradamento tramite la rete on premise.

  • Gateway di instradamento dinamico (DRG)

    Il gateway DRG è un router virtuale che fornisce un percorso per il traffico di rete privato tra le reti VCN nella stessa area, tra una rete VCN e una rete esterna all'area, ad esempio una rete VCN in un'altra area Oracle Cloud Infrastructure, una rete on premise o una rete in un altro provider cloud.

  • Storage degli oggetti

    Lo storage degli oggetti OCI fornisce accesso a grandi quantità di dati strutturati e non strutturati di qualsiasi tipo di contenuto, inclusi backup del database, dati analitici e contenuti avanzati come immagini e video. Puoi archiviare i dati direttamente da Internet o dalla piattaforma cloud in tutta sicurezza. Puoi ridimensionare lo storage senza alcun deterioramento delle prestazioni o dell'affidabilità del servizio.

    Utilizza lo storage standard per lo storage "caldo" a cui è necessario accedere rapidamente, immediatamente e frequentemente. Utilizza lo storage di archivio per lo storage "freddo" che conservi per lunghi periodi di tempo e a cui accedi raramente o raramente.

  • Data Guard

    Oracle Data Guard e Oracle Active Data Guard offrono un set completo di servizi che creano, mantengono, gestiscono e monitorano uno o più database di standby e che consentono ai database Oracle di produzione di rimanere disponibili senza interruzioni. Oracle Data Guard gestisce questi database di standby come copie del database di produzione utilizzando la replica in-memory. Se il database di produzione non è più disponibile a causa di un'indisponibilità pianificata o non pianificata, Oracle Data Guard può passare qualsiasi database di standby al ruolo di produzione, riducendo al minimo i tempi di inattività associati all'indisponibilità. Oracle Active Data Guard offre la possibilità aggiuntiva di scaricare i carichi di lavoro in lettura, principalmente sui database in standby e offre inoltre funzioni avanzate di protezione dei dati.

  • Oracle Database Autonomous Recovery Service

    Oracle Database Autonomous Recovery Service è un servizio Oracle Cloud che protegge i database Oracle. L'automazione del backup e le funzionalità avanzate di protezione dei dati per i database OCI consentono di scaricare tutti i requisiti di elaborazione e storage del backup su Oracle Database Autonomous Recovery Service, riducendo i costi dell'infrastruttura di backup e il sovraccarico manuale dell'amministrazione.

  • Exadata Database Service on Dedicated Infrastructure

    Oracle Exadata Database Service on Dedicated Infrastructure ti consente di sfruttare la potenza di Exadata nel cloud. Oracle Exadata Database Service offre funzionalità Oracle Database comprovate su un'infrastruttura Oracle Exadata ottimizzata e appositamente creata nel cloud pubblico. L'automazione cloud integrata, la scalabilità elastica delle risorse, la sicurezza e le prestazioni rapide per tutti i carichi di lavoro di Oracle Database ti aiutano a semplificare la gestione e a ridurre i costi.

  • Oracle Database@Azure

    Oracle Database@Azure è il servizio Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure e Oracle Autonomous Database Serverless) in esecuzione su Oracle Cloud Infrastructure (OCI), distribuito nei data center Microsoft Azure. Il servizio offre funzioni e parità di prezzo con OCI. Acquistare il servizio su Azure Marketplace.

    Oracle Database@Azure integra le tecnologie Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) e Oracle Data Guard nella piattaforma Azure. Gli utenti gestiscono il servizio sulla console di Azure e con gli strumenti di automazione di Azure. Il servizio viene distribuito in Azure Virtual Network (VNet) e integrato con il sistema di gestione delle identità e degli accessi di Azure. Le metriche generiche e i log di audit di OCI e Oracle Database sono disponibili in modo nativo in Azure. Il servizio richiede agli utenti di disporre di una sottoscrizione Azure e di una tenancy OCI.

    Autonomous Database è basato sull'infrastruttura Oracle Exadata, è self-managing, self-securing e self-repairing e aiuta a eliminare la gestione manuale del database e gli errori umani. Autonomous Database consente lo sviluppo di applicazioni scalabili basate sull'intelligenza artificiale con qualsiasi dato utilizzando funzionalità AI integrate utilizzando il modello di linguaggio di grandi dimensioni (LLM) e la posizione di distribuzione.

    Sia Oracle Exadata Database Service che Oracle Autonomous Database Serverless vengono forniti facilmente tramite il portale nativo di Azure, consentendo l'accesso all'ecosistema Azure più ampio.

Suggerimenti

Utilizza i seguenti suggerimenti come punto di partenza per eseguire il ripristino di emergenza per Oracle Exadata Database Service on Dedicated Infrastructure su Oracle Database@Azure. Le vostre esigenze potrebbero differire dall'architettura descritta qui.
  • Utilizza Active Data Guard per prevenire il danneggiamento completo dei dati con la riparazione automatica dei blocchi, gli aggiornamenti e le migrazioni online e l'offload del carico di lavoro in standby con la lettura, principalmente lo scale-out.
  • Abilita la continuità delle applicazioni per mascherare le interruzioni del database durante gli eventi pianificati e non pianificati dagli utenti finali e garantire applicazioni ininterrotte.
  • Impostare il backup automatico in Oracle Database Autonomous Recovery Service (in Azure o OCI) anche se i dati sono protetti da Oracle Data Guard per ridurre al minimo il carico di lavoro di backup sul database implementando la strategia di backup incrementale per sempre che elimina i backup completi settimanali. In alternativa, i clienti possono utilizzare lo storage degli oggetti OCI per i backup automatici.
  • Abilita i backup da standby per ottenere la replica dei backup in tutte le aree.
  • Utilizza OCI Full Stack DR per orchestrare le operazioni di switchover e failover del database.
  • Utilizzare OCI Vault per memorizzare le chiavi Transparent Data Encryption (TDE) del database utilizzando le chiavi gestite dal cliente.

Considerazioni

Quando si esegue il ripristino di emergenza multiregionale per Oracle Exadata Database Service on Dedicated Infrastructure su Oracle Database@Azure, tenere presente quanto riportato di seguito.

  • Quando i cluster VM Exadata vengono creati nel sito figlio Oracle Database@Azure, ogni cluster VM viene creato all'interno della propria VCN OCI. Oracle Data Guard richiede che i database comunichino tra loro per spedire i dati redo. Eseguire il peer delle VCN per abilitare questa comunicazione. Pertanto, le VCN del cluster VM Exadata non devono condividere intervalli CIDR IP sovrapposti.
  • La preparazione di uno scenario di emergenza richiede un approccio completo che consideri diversi requisiti aziendali e architetture di disponibilità e che includa tali considerazioni in un piano attuabile, ad alta disponibilità e di disaster recovery. Lo scenario descritto qui fornisce linee guida per selezionare l'approccio più adatto alla distribuzione dell'applicazione utilizzando un failover semplice ma efficace per la configurazione di disaster recovery negli ambienti OCI e Microsoft Azure.
  • OCI è la rete preferita per ottenere prestazioni migliori, misurate in base a latenza e throughput e per ottenere costi ridotti, inclusi i primi 10 TB/mese di uscita gratuitamente.
  • Puoi creare fino a sei database di standby per un database primario tramite Cloud Tooling.
  • La creazione di un database di standby associato a un altro database di standby (standby a catena) non è supportata mediante Cloud Tooling.

Distribuire

Per configurare la comunicazione di rete tra le aree visualizzate nel diagramma dell'architettura, attenersi alla procedura riportata di seguito.

Per configurare l'area Principale, effettuare le operazioni riportate di seguito.

  1. Aggiungere le seguenti regole di entrata alla lista di sicurezza della subnet client di VCN1 per consentire il traffico in entrata da VCN2 e VCN3.
    Senza conservazione dello stato Origine Protocollo IP Intervallo porte di origine Intervallo di porte di destinazione Consente Descrizione
    N. 10.20.0.0/16 TCP 1521 1521 Traffico TCP per le porte: 1521 Consenti entrata da VCN2
    N. 10.30.0.0/16 TCP 1521 1521 Traffico TCP per le porte: 1521 Consenti entrata da VCN3
  2. Creare una rete cloud virtuale HubVCN1 con CIDR 10.11.0.0/16.
  3. Creare Local Peering Gateway HubLPG1 nella rete cloud virtuale HubVCN1.
  4. Creare Local Peering Gateway LPG1R nella rete cloud virtuale VCN1.
  5. Stabilisce la connessione peering locale tra LPG1R e HubLPG1.
  6. Aggiungere regole di instradamento alla tabella di instradamento della subnet client di VCN1 per inoltrare il traffico di destinazione per VCN2 e VCN3 a LPG1R.
    Obiettivo Tipo di destinazione Obiettivo Tipo di instradamento Descrizione
    10.20.0.0/16 Local Peering Gateway LPG1R Statica Traffico a VCN2
    10.30.0.0/16 Local Peering Gateway LPG1R Statica Traffico a VCN3
  7. Creare la tabella di instradamento HubLPG1rt in HubVCN1.
  8. Associare la tabella di instradamento HubLPG1rt al Local Peering Gateway HubLPG1.
  9. Creare il gateway di instradamento dinamico DRG1.
  10. Creare la tabella di instradamento DRG1rt in HubVCN1.
  11. Aggiungere una regola di instradamento alla tabella di instradamento DRG1rt per inoltrare il traffico di destinazione per VCN1 a HubLPG1.
    Obiettivo Tipo di destinazione Obiettivo Tipo di instradamento Descrizione
    10.10.0.0/16 Local Peering Gateway HubLPG1 Statica Traffico a VCN1
  12. Per allegare DRG1 a HubVCN1:
    1. Selezionare Tabella di instradamento Drg generata automaticamente per i collegamenti VCN.
    2. Selezionare la tabella di instradamento esistente DRG1rt.
    3. Selezionare i blocchi CIDR VCN.
  13. Creare due connessioni peering remoto in DRG1, denominate RPC1a e RPC1b.
  14. Aggiungere due regole di instradamento a HubLPG1rt per inoltrare il traffico di destinazione per VCN2 e VCN3 a DRG1.
    Obiettivo Tipo di destinazione Obiettivo Tipo di instradamento Descrizione
    10.20.0.0/16 Gateway di instradamento dinamico DRG1 Statica Traffico a VCN2
    10.30.0.0/16 Gateway di instradamento dinamico DRG1 Statica Traffico a VCN3

Per creare la prima area in standby (regione 2), procedere come segue.

  1. Aggiungere le seguenti regole di entrata alla lista di sicurezza della subnet client di VCN2 per consentire il traffico in entrata da VCN1 e VCN3.
    Senza conservazione dello stato Origine Protocollo IP Intervallo porte di origine Intervallo di porte di destinazione Consente Descrizione
    N. 10.10.0.0/16 TCP 1521 1521 Traffico TCP per le porte: 1521 Consenti entrata da VCN1
    N. 10.30.0.0/16 TCP 1521 1521 Traffico TCP per le porte: 1521 Consenti entrata da VCN3
  2. Creare una rete cloud virtuale HubVCN2 con CIDR 10.22.0.0/16.
  3. Creare Local Peering Gateway HubLPG2 nella rete cloud virtuale HubVCN2.
  4. Creare Local Peering Gateway LPG2R nella rete cloud virtuale VCN2.
  5. Stabilisce la connessione peering locale tra LPG2R e HubLPG2.
  6. Aggiungere regole di instradamento alla tabella di instradamento della subnet client di VCN2 per inoltrare il traffico di destinazione per VCN1 e VCN3 a LPG2R.
    Obiettivo Tipo di destinazione Obiettivo Tipo di instradamento Descrizione
    10.10.0.0/16 Local Peering Gateway LPG2R Statica Traffico a VCN1
    10.30.0.0/16 Local Peering Gateway LPG2R Statica Traffico a VCN3
  7. Creare la tabella di instradamento HubLPG2rt in HubVCN2.
  8. Associare la tabella di instradamento HubLPG2rt al Local Peering Gateway HubLPG2.
  9. Creare il gateway di instradamento dinamico DRG2.
  10. Creare la tabella di instradamento DRG2rt in HubVCN2.
  11. Aggiungere una regola di instradamento a DRG2rt per inoltrare il traffico di destinazione per VCN2 a HubLPG2.
    Obiettivo Tipo di destinazione Obiettivo Tipo di instradamento Descrizione
    10.20.0.0/16 Local Peering Gateway HubLPG2 Statica Traffico a VCN2
  12. Per allegare DRG1 a HubVCN2:
    1. Selezionare Tabella di instradamento Drg generata automaticamente per i collegamenti VCN.
    2. Selezionare la tabella di instradamento esistente DRG2rt.
    3. Selezionare i blocchi CIDR VCN.
  13. Creare due connessioni peering remoto in DRG2, denominate RPC2a e RPC2c.
  14. Stabilire una connessione peering remoto tra RPC1a (regione 1) e RPC2a (regione 2).
  15. Aggiungere due regole di instradamento a HubLPG2rt per inoltrare il traffico di destinazione per VCN1 e VCN3 a DRG2.
    Obiettivo Tipo di destinazione Obiettivo Tipo di instradamento Descrizione
    10.10.0.0/16 Gateway di instradamento dinamico DRG2 Statica Traffico a VCN1
    10.30.0.0/16 Gateway di instradamento dinamico DRG2 Statica Traffico a VCN3

Per creare la seconda area in standby (regione 3), procedere come segue.

  1. Aggiungere le seguenti regole di entrata alla lista di sicurezza della subnet client di VCN3 per consentire il traffico in entrata da VCN1 e VCN2.
    Senza conservazione dello stato Origine Protocollo IP Intervallo porte di origine Intervallo di porte di destinazione Consente Descrizione
    N. 10.10.0.0/16 TCP 1521 1521 Traffico TCP per le porte: 1521 Consenti entrata da VCN1
    N. 10.20.0.0/16 TCP 1521 1521 Traffico TCP per le porte: 1521 Consenti entrata da VCN2
  2. Creare una rete cloud virtuale HubVCN3 con CIDR 10.33.0.0/16.
  3. Creare Local Peering Gateway HubLPG3 nella rete cloud virtuale HubVCN3.
  4. Creare Local Peering Gateway LPG3R nella rete cloud virtuale VCN3.
  5. Stabilisce la connessione peering locale tra LPG3R e HubLPG3.
  6. Aggiungere regole di instradamento alla tabella di instradamento della subnet client di VCN3 per inoltrare il traffico di destinazione per VCN1 e VCN2 a LPG3R.
    Obiettivo Tipo di destinazione Obiettivo Tipo di instradamento Descrizione
    10.10.0.0/16 Local Peering Gateway LPG3R Statica Traffico a VCN1
    10.20.0.0/16 Local Peering Gateway LPG3R Statica Traffico a VCN2
  7. Creare la tabella di instradamento HubLPG3rt in HubVCN3.
  8. Associare la tabella di instradamento HubLPG3rt al Local Peering Gateway HubLPG3.
  9. Creare il gateway di instradamento dinamico DRG3.
  10. Creare la tabella di instradamento DRG3rt in HubVCN3.
  11. Aggiungere una regola di instradamento a DRG3rt per inoltrare il traffico di destinazione per VCN3 a HubLPG3.
    Obiettivo Tipo di destinazione Obiettivo Tipo di instradamento Descrizione
    10.30.0.0/16 Local Peering Gateway HubLPG3 Statica Traffico a VCN3
  12. Per allegare DRG1 a HubVCN3:
    1. Selezionare Tabella di instradamento Drg generata automaticamente per i collegamenti VCN.
    2. Selezionare la tabella di instradamento esistente DRG3rt.
    3. Selezionare i blocchi CIDR VCN.
  13. Creare due connessioni peering remoto in DRG3, denominate RPC3b e RPC3c.
  14. Stabilire una connessione peering remoto tra RPC1b (regione 1) e RPC3b (regione 3).
  15. Stabilire una connessione peering remoto tra RPC2c (regione 2) e RPC3c (regione 3).
  16. Aggiungere due regole di instradamento a HubLPG3rt per inoltrare il traffico di destinazione per VCN1 e VCN2 a DRG3.
    Obiettivo Tipo di destinazione Obiettivo Tipo di instradamento Descrizione
    10.10.0.0/16 Gateway di instradamento dinamico DRG3 Statica Traffico a VCN1
    10.20.0.0/16 Gateway di instradamento dinamico DRG3 Statica Traffico a VCN2

Visualizza altro

Scopri di più su Oracle Database@Azure e Oracle Data Guard.

Esaminare le risorse aggiuntive riportate di seguito.

conferme

  • Autori: Sinan Petrus Toma, Sebastian Solbach, Julien Silverston
  • Collaboratore: Sreya Dutta