Progettare una topologia Pilot-Light Disaster Recovery (DR)

Se un'indisponibilità su larga scala influisce sulle applicazioni di produzione, è necessario ripristinare rapidamente i carichi di lavoro. Il piano di continuità aziendale dovrebbe includere una strategia DR che soddisfi i tuoi obiettivi di recupero, recupero e budget. Una topologia a luce pilota offre un equilibrio tra i requisiti di costo e recupero.

Il termine luce pilota si riferisce a una piccola fiamma che viene sempre accesa in dispositivi come riscaldatori a gas, e può essere utilizzato per avviare rapidamente i dispositivi quando necessario. Nel contesto di DR, un ambiente a luce pilota contiene i componenti di base di un determinato carico di lavoro, con le più recenti configurazioni e dati critici, in esecuzione su scala minima in una posizione remota dal sito primario. In caso di disastro nel sito primario, è possibile utilizzare i componenti a luce pilota nella posizione remota per ripristinare rapidamente un ambiente su scala di produzione.

Oracle Cloud Infrastructure fornisce infrastrutture e servizi altamente disponibili e scalabili che consentono di progettare una topologia DR con luce pilota.

Architettura

Questa architettura mostra una topologia a più livelli con risorse ridondanti distribuite in due aree di Oracle Cloud Infrastructure.

Il seguente diagramma illustra questa architettura di riferimento.

Segue una descrizione dell'immagine x-region-pilot-light-topology.png
Descrizione dell'illustrazione x-region-pilot-light-topology.png

L'architettura ha i seguenti componenti:

  • Aree

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

  • Domini di disponibilità

    I domini di disponibilità sono data center indipendenti e autonomi all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità vengono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono un'infrastruttura come l'alimentazione o il raffreddamento oppure la rete interna del dominio di disponibilità. È improbabile che l'eventuale guasto di un dominio di disponibilità influenzi gli altri domini di disponibilità della regione.

    Il diagramma di architettura non mostra i domini di disponibilità. Ma nelle aree con più domini di disponibilità, è possibile distribuire le risorse in ogni area tra i domini di disponibilità, per un'elevata disponibilità.

  • Domini di errore

    Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità ha tre domini di guasto con alimentazione e hardware indipendenti. Quando si distribuiscono risorse su più domini di errore, le applicazioni possono tollerare errori fisici del server, la manutenzione del sistema e gli errori di alimentazione all'interno di un dominio di errore.

    Il diagramma di architettura non mostra domini di errore. Ma per proteggersi da errori all'interno di un dominio di errore, è possibile distribuire le risorse in ogni disponibilità nei domini di errore.

  • Reti VCN (Virtual Cloud Network) e subnet

    Un VCN è una rete customizzabile e definita dal software impostata in un'area Oracle Cloud Infrastructure. Come le reti di data center tradizionali, offre controllo completo sull'ambiente di rete. Un VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo la creazione di VCN. È possibile segmentare un 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 in VCN. È possibile modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.

    In questa architettura di riferimento, tutte le risorse in ogni area sono associate a un singolo VCN.

  • Host bastion

    L'host bastion è un'istanza di calcolo che funge da punto di accesso sicuro e controllato alla topologia dall'esterno del cloud. L'host bastione viene eseguito in genere in una zona demilitarizzata (DMZ). Consente di proteggere le risorse sensibili inserendole in reti private a cui non è possibile accedere direttamente dall'esterno del cloud. La topologia dispone di un singolo punto di accesso noto che è possibile monitorare e controllare regolarmente. Così, è possibile evitare di esporre i componenti più sensibili della topologia senza compromettere l'accesso a loro.

  • Load balancer

    Il servizio Oracle Cloud Infrastructure Load Balancing fornisce la distribuzione automatica del traffico da un singolo punto di accesso a più server nel backend.

  • Gateway Internet

    Il gateway Internet consente il traffico tra le subnet pubbliche in un VCN e Internet pubblico.

  • Istanze di computazione

    L'area principale include due istanze di calcolo per il livello applicazione.

    L'area in standby dispone di un'istanza di calcolo per il MOUNT della memoria file replicata. Le altre due istanze di calcolo nell'area in standby rappresentano server che è possibile creare utilizzando volumi di boot replicati e volumi a blocchi, in caso di disastro nell'area primaria.

  • Volumi a blocchi

    Con volumi di storage a blocchi, è possibile creare, collegare, connettere e spostare volumi di storage e modificare le prestazioni dei volumi per soddisfare i requisiti di storage, prestazioni e applicazioni. Dopo aver collegato e collegato un volume a un'istanza, è possibile utilizzare il volume come un normale disco rigido. È inoltre possibile scollegare un volume e collegarlo a un'altra istanza senza perdere dati.

    L'architettura mostra i volumi di avvio e i volumi a blocchi nell'area primaria da replicare nell'area in standby. Con questa progettazione, in caso di disastro nell'area primaria, è possibile ripristinare rapidamente il livello dell'applicazione nell'area in standby eseguendo il provisioning delle istanze di calcolo utilizzando i volumi di avvio e blocco replicati.

  • Storage file

    Il servizio Oracle Cloud Infrastructure File Storage fornisce un file system di rete durevole, scalabile, sicuro e di livello enterprise. È possibile connettersi a un file system del servizio di memorizzazione file da qualsiasi istanza bare metal, virtual machine o container in un VCN. È inoltre possibile accedere a un file system esterno a VCN utilizzando Oracle Cloud Infrastructure FastConnect e IPSec VPN.

    L'architettura mostra la memorizzazione dei file nell'area primaria da replicare nell'area in standby utilizzando uno script.

  • Storage degli oggetti

    Lo storage degli oggetti consente un accesso rapido a grandi quantità di dati strutturati e non strutturati di qualsiasi tipo di contenuto, inclusi backup del database, dati analitici e contenuti avanzati quali immagini e video. Puoi memorizzare e quindi recuperare i dati direttamente da Internet o dall'interno della piattaforma cloud. È possibile scalare perfettamente lo storage senza compromettere le prestazioni o l'affidabilità dei servizi. Utilizzare lo storage standard per lo storage "hot" necessario per accedere rapidamente, immediatamente e di frequente. Utilizzare lo storage di archivio per lo storage "freddo" che si conserva per lunghi periodi di tempo e raramente o raramente si accede.

    L'architettura mostra la memorizzazione degli oggetti nell'area primaria da replicare automaticamente nell'area in standby utilizzando un criterio di replica tra aree.

  • Application Server

    Gli Application Server utilizzano un peer secondario che, come il database, acquisirà l'elaborazione in caso di emergenza. I server applicazioni utilizzano la configurazione e i metadati memorizzati sia nel database che nel file system. Il clustering di Application Server fornisce protezione nell'ambito di una singola area, ma le modifiche in corso e le nuove distribuzioni devono essere replicate nella posizione secondaria su base continuativa per un disaster recovery coerente.

  • Database

    L'architettura include un database in ogni area. Oracle Data Guard viene utilizzato per la replica dei dati e garantisce che il database in standby sia una copia coerente a livello transazionale del database primario.

    Data Guard mantiene automaticamente la sincronizzazione tra i database trasmettendo e applicando i redo data dal database primario al database in standby. In caso di disastro nell'area primaria, Data Guard viene eseguito automaticamente il failover nel database in standby.

  • Gateway di instradamento dinamico (DRG)

    DRG è un router virtuale che fornisce un percorso per il traffico di rete privata tra un VCN e una rete al di fuori dell'area, ad esempio un VCN in un'altra area Oracle Cloud Infrastructure, una rete in locale o una rete in un altro provider cloud.

  • Gateway NAT

    Il gateway NAT consente alle risorse private di un VCN di accedere agli host su Internet, senza esporre tali risorse alle connessioni Internet in entrata.

  • Gateway del servizio

    Il gateway del servizio fornisce l'accesso da un VCN ad altri servizi, ad esempio Oracle Cloud Infrastructure Object Storage. Il traffico da VCN al servizio Oracle viaggia attraverso il fabric di rete Oracle e non passa mai attraverso Internet.

Suggerimenti

Utilizzare i suggerimenti riportati di seguito come punto di partenza per progettare la topologia DR con luce pilota. Le vostre esigenze potrebbero differire dall'architettura descritta qui.

  • VCN

    Quando si crea ogni VCN, determinare il numero di indirizzi IP necessari per le risorse cloud in ogni subnet. Utilizzando la notazione CIDR (Classless Inter-Domain Routing), specificare una maschera subnet e un intervallo di indirizzi di rete sufficientemente grande per gli indirizzi IP richiesti. Utilizzare un intervallo di indirizzi all'interno dello spazio degli indirizzi IP privati standard.

    Selezionare blocchi CIDR che non si sovrappongono a nessun'altra rete (in Oracle Cloud Infrastructure, nel data center in locale o in un altro provider cloud) a cui si intende impostare connessioni private.

    Dopo aver creato un VCN, è possibile modificare, aggiungere e rimuovere i blocchi CIDR.

    Quando si progettano le subnet, prendere in considerazione il flusso di traffico e i requisiti di sicurezza. Allegare tutte le risorse all'interno di uno specifico livello o ruolo alla stessa subnet, che può fungere da limite di sicurezza.

    Utilizzare subnet regionali.

  • Liste di sicurezza

    Per consentire la replica tra aree del database e della memorizzazione dei file, configurare le liste di sicurezza richieste. Tenere presente che la replica dei volumi di boot e dei volumi a blocchi non richiede comunicazione tra gli host a cui sono collegati i volumi.

  • Criterio di backup dei volumi a blocchi

    Configurare un criterio per eseguire i backup dei volumi a blocchi con la frequenza necessaria per soddisfare l'RPO.

  • Server applicazioni e applicazioni personalizzate in esecuzione su Oracle Platform as a Service (PaaS)

    I servizi PaaS, come Oracle SOA Cloud Service e Oracle WebLogic Server for Oracle Cloud Infrastructure, utilizzano la maggior parte delle risorse citate internamente (compute, volumi a blocchi, storage di file, networking, database). Richiedono strategie specifiche di recupero da errori irreversibili che proteggono tutti i diversi livelli in modo coerente. Oracle fornisce best practice dettagliate per creare architetture con disponibilità massima (MAA) e proteggere questo tipo di sistemi da errori irreversibili. Per consultare la documentazione specifica sul recupero da errori irreversibili (DR) per PaaS.

Considerazioni

Quando si implementa la configurazione DR con luce pilota, prendere in considerazione i seguenti fattori:

  • Prestazioni

    Durante la pianificazione dell'RPO e dell'RTO, prendere in considerazione il tempo necessario per copiare i backup dei volumi in tutte le aree.

  • Disponibilità

    È possibile utilizzare la gestione dello sterzo DNS per reindirizzare il traffico client all'area di produzione corrente dopo un failover.

    Se si utilizzano forme di calcolo che forniscono dispositivi NVMe collegati localmente, è possibile eseguire il backup dei dati su questi dispositivi utilizzando soluzioni di backup tradizionali che utilizzano la memorizzazione degli oggetti.

  • Costo

    In caso di failover dall'area primaria a quella in standby, è possibile eseguire rapidamente il provisioning dell'infrastruttura richiesta utilizzando gli script Terraform. È possibile ridimensionare i sistemi di database dopo averli sottoposti a provisioning, quindi specificare la forma minima richiesta inizialmente e passare a una forma più grande dopo il failover.