Che cos'è il disaster recovery?

Il Disaster Recovery (DR) è uno degli aspetti dei piani generali di continuità aziendale ideati e gestiti dalle diverse linee di business all'interno di un'organizzazione. Un piano efficace di disaster recovery mitiga l'impatto che le interruzioni non pianificate, o addirittura pianificate, dei sistemi mission-critical e business-critical hanno sulla capacità di un'azienda di operare e continuare a generare ricavi.

A tale scopo, un piano di DR offre alle organizzazioni una struttura flessibile che consente loro di operare in modo unificato e collaborativo per ripristinare, riqualificare e revitalizzare i propri sistemi e creare un'infrastruttura più resiliente.

Perché è importante il disaster recovery?

Per quanto tempo un'azienda potrebbe continuare a operare se dovesse perdere il suo sistema di retribuzione subito prima che il pagamento venga calcolato e gli account vengano finanziati? Quali sanzioni riceverebbe un'azienda a causa del ritardo nel pagamento delle imposte federali, statali e locali? Quali conseguenze dovrebbe affrontare l'azienda per non aver pagato in tempo i dipendenti e quanto a lungo questi continuerebbero a lavorare?

Effettuare o non effettuare il disaster recovery? Questo non è più il dilemma. La vera domanda è quanto costerebbe davvero perdere minuti, giorni o settimane di dati importanti e la fiducia costruita negli anni in un solo istante?

Il disaster recovery non può più continuare a essere solo un ripensamento o qualcosa considerato solo quando c'è un budget sufficiente, perché le organizzazioni di oggi sono tenute a reagire prontamente a eventi dannosi e a rimanere operative. Piuttosto che essere scoraggiate dal costo di implementazione di un piano di resilienza, le organizzazioni devono andare più a fondo e valutare il costo reale comportato dal non avere alcun piano. Ad esempio, esaminare i service level agreements (SLA) che non potrebbero essere soddisfatti o le sanzioni e la perdita di ricavi che deriverebbero da un'interruzione. Confronta il costo dell'implementazione del DR con le penali, la perdita di ricavi e la perdita di fiducia dei clienti e la scelta da fare ti sembrerà chiara.

L'immagine è intitolata "Ricavi, produttività e fidelizzazione persa". In questa immagine sono visualizzate tre statistiche chiave. Queste statistiche derivano da uno studio commissionato da Forrester Consulting per conto di IBM nel 2019. La domanda posta agli intervistati era "Quali dei seguenti costi viene affrontato dalla tua organizzazione a causa di tempi di inattività pianificati e non pianificati?"
Sul lato sinistro, la statistica visualizzata mostra che il 53% degli intervistati ha risposto "perdita di ricavi". Nel mezzo, la statistica mostra che il 47% ha risposto "perdita di produttività". Sul lato destro, la statistica mostra che il 41% ha risposto "perdita di fiducia o valore del brand".

Interruzioni non pianificate

Indipendentemente dal fatto che l'indisponibilità sia causata da un disastro naturale, da errori dell'operatore IT/fornitore di servizi, da corruzioni dei dati o da attacchi ransomware, un'organizzazione deve essere in grado di proteggersi dalle interruzioni delle operazioni aziendali che causano perdite catastrofiche, l'essere sostituiti da competitor opportunisti e la perdita di reputazione e clientela.

Sebbene questi risultati sembrino drammatici, riflettono le esperienze recenti di molte note organizzazioni che non sono riuscite a recuperare in modo tempestivo e hanno perso grandi quantità di dati transazionali critici, informazioni sui clienti e fiducia.

Una vasta gamma di scenari e cause profonde possono danneggiare le operazioni aziendali.

Questa immagine è intitolata "Cause principali dei tempi di inattività non pianificati". Nell'immagine viene visualizzato un grafico a barre che mostra le cause delle interruzioni non pianificate. Il grafico a barre è suddiviso in tre categorie: guasti operativi, disastri naturali ed eventi causati dall'uomo. I guasti operativi sono raggruppati nella parte più a sinistra del grafico a barre, i disastri naturali sono al centro e gli eventi causati dall'uomo sono raggruppati nella parte più a destra. La fonte di questo grafico è Forrester Research, Inc.

Interruzioni pianificate

Il disaster recovery as a service (DRaaS) nel cloud offre alle aziende opzioni senza precedenti per la flessibilità operativa. Le organizzazioni utilizzano più frequentemente le soluzioni di disaster recovery per le interruzioni pianificate che per il ripristino da eventi catastrofici.

Tasti dolenti comuni

• Gli approcci tradizionali al disaster recovery richiedono investimenti nell'automazione.
• Anche i sistemi aziendali nei data center di livello 1 possono essere influenzati da interruzioni di corrente, che sono troppo frequenti. Quante volte un incidente comune come un'interruzione di corrente ha causato una perdita di produttività di un giorno o due? Il personale IT finisce per dedicare ore o molti giorni alle conference call nel tentativo di rendere nuovamente operativi i sistemi utilizzando soluzioni stopgap. • Alcune aziende spendono porzioni significative dei propri budget IT sviluppando l'automazione in-house per gestire il disaster recovery solo per avere poi paura di usarlo, o anche di testarlo periodicamente per garantire che continui a funzionare come previsto. • Spesso ci si impiega un giorno o più per ripristinare da una finestra di manutenzione pianificata. • Anche i piani di DR o i runbook ben documentati possono comportare giorni di perdita di produttività, mentre il personale delle operazioni IT fa di tutto per far funzionare di nuovo le cose.

Obiettivi principali del disaster recovery

I due obiettivi principali del disaster recovery sono quello di riportare i sistemi interessati allo stato operativo il più velocemente possibile e di farlo con la minima perdita di dati possibile dopo un evento catastrofico o un'interruzione pianificata. I parametri per questi due obiettivi principali sono universalmente noti come recovery time objective (RTO) e recovery point objective (RPO).

Ogni sistema aziendale avrà requisiti diversi per questi due parametri a seconda del service level agreement tra le operations IT e i proprietari dell'azienda.

L'immagine è intitolata "Terminologia relativa alla protezione dei dati". La tolleranza per la perdita di dati e la tolleranza per i tempi di inattività sono rappresentate su una linea retta che si estende in direzioni opposte dal centro dell'immagine. A sinistra hai "perdita di dati" e a destra hai "tempi di inattività".

Recovery time objective

Il recovery time objective è il tempo necessario per ripristinare un sistema aziendale riportandolo a uno stato completamente operativo dopo le interruzioni pianificate o non pianificate.

Recovery point objective

Un recovery point objective è la quantità massima di dati che possono essere persi prima di causare danni a un determinato sistema aziendale. L'RPO viene generalmente misurato in tempo dal delta dell'ultimo backup, dall'ultima replica o dall'ultimo snapshot di dati.

Differenze tra disaster recovery e high availability

Normalmente, l'high availability (HA) protegge dai single point of failure, mentre il disaster recovery protegge dai multiple point of failure. Nel cloud computing, la protezione da singoli punti di errore a livello di infrastruttura fisica, tra cui alimentazione, raffreddamento, storage, reti e server fisici, viene astratta completamente nell'architettura generale tramite domini di disponibilità e di errore.

L'high availability in questo caso è scalabile e altamente resiliente alla perdita dei dati o alla perdita delle prestazioni di elaborazione. Quasi tutti i provider cloud di livello aziendale creano high availability nella loro offerta.

Le soluzioni di disaster recovery con high availability che forniscono una protezione dei database con perdita di dati e tempi di inattività pari a zero per i database diventano costose quando è coinvolta una tecnologia di replica e mapping dei dati complessa. Queste soluzioni non forniscono protezione dai ransomware, che viene raggiunta attraverso un backup completo con un recovery point objective point-in-tempo e uno storage immutabile.

Le soluzioni HA tradizionali funzionano bene insieme a una soluzione cloud DR (CDR) a basso costo. La tecnologia CDR aggiuntiva fornisce un ulteriore livello di protezione per i database che hanno bisogno di una perdita di dati pari a zero, di tempi di inattività HA pari a zero e di protezione dai ransomware con rollback incrementale a lungo termine.

Il DR on-premise è una soluzione non flessibile e costosa, a causa degli elevati costi legati alla duplicazione dell'infrastruttura IT in una posizione di origine e in una posizione di data center di destinazione fissa. Non può funzionare sulla WAN o migrare server tra ambienti diversi, quindi richiede un circuito dedicato tra i data center di origine e di destinazione per funzionare come un unico ambiente LAN interconnesso. Inoltre, il DR tradizionale non può eseguire la migrazione dei server tra ambienti eterogenei , come tra un ambiente on-premise e una piattaforma cloud o tra due piattaforme cloud diverse.

Il DRaaS utilizza una patchwork di soluzioni di backup fornite dal fornitore e strumenti di migrazione open source per creare un ambiente strettamente controllato e altamente specifico. L'utente finale può recuperare solo i carichi di lavoro nell'ambiente tradizionale di hosting del provider DRaaS dal proprio ambiente VMware on-premise. Queste soluzioni fornite dai fornitori possono essere costose e limitate nella gamma di carichi di lavoro che possono proteggere e negli ambienti di calcolo che possono supportare.

Flussi di lavoro, runbook e piani di DR

Oracle generalmente si riferisce a un flusso di lavoro di DR come piano DR. Un piano o un runbook di DR è un elenco di passi o attività predeterminati che devono essere completati per effettuare la transizione dell'istanza di calcolo, della piattaforma, del database e delle applicazioni a una region di ripristino predeterminata nel cloud. Sono inclusi tutti i task o i singoli passi eseguiti da individui o da qualche tipo di automazione durante un'operazione di disaster recovery, come uno switchover o un failover. I termini piano DR, runbook DR e flusso di lavoro DR sono intercambiabili.

Operazioni di DR (switchover vs. failover)

Per operazione di disaster recovery si intende il processo di esecuzione di ogni passo o task predeterminato in un piano DR necessario per ripristinare l'infrastruttura, il database e le applicazioni a uno stato completamente operativo. Per descrivere la transizione di uno stack di applicazioni a una posizione diversa vengono utilizzati due termini diversi: failover e switchover.

Failover

Un failover implica un'interruzione non pianificata in cui si è verificato un arresto anomalo di applicazioni, database e virtual machine e tutte le risorse, storage, dati e sistemi operativi guest compresi, sono in uno stato incoerente. In questo caso si presume che la region cloud primaria sia completamente inaccessibile e non disponibile, cosa che indica che è necessario attivare una vera operazione di disaster recovery.

Di conseguenza, tutti i task di disaster recovery in un piano DR possono essere eseguiti solo nella standby region. È fondamentale che la soluzione DRaaS di un provider cloud sia progettata per l'high availability nella standby region per garantire che sia accessibile e funzionale quando succede un disastro catastrofico.

Switchover

Lo switchover implica tempi di inattività pianificati che includono un arresto ordinato di applicazioni, database e virtual machine o server. In questo caso, sia le standby region primarie che quelle standby funzionano normalmente ed è probabile che il personale IT si concentri sullo "spostamento" di uno o più sistemi da una region all'altra per la manutenzione o il completamento degli aggiornamenti in sequenza.

Strategia di implementazione cloud

Le aziende moderne possono trarre vantaggio da uno o più dei seguenti modelli di implementazione cloud per vari motivi, compresi costi, prestazioni e requisiti di continuità aziendale. Una strategia solida di implementazione cloud sta diventando sempre più diffusa man mano che le aziende continuano a spostare le operations nel cloud.

Soluzioni DR cross-regional

Le soluzioni di disaster recovery cross-regional proteggono le organizzazioni da interruzioni complete che potrebbero influire sull'accesso ai sistemi aziendali ospitati nell'infrastruttura cloud di un unico provider cloud. Come suggerisce il nome, un intero stack di applicazioni per qualsiasi sistema aziendale specifico, virtual machine, database e applicazioni comprese, può essere trasferito su richiesta a una region cloud completamente diversa in un altro luogo.

Le soluzioni DRaaS devono essere in grado di eseguire la transizione di un intero sistema aziendale, come un portale per le risorse umane, un portale per i servizi finanziari o un'applicazione di gestione delle risorse aziendali, a una region cloud completamente diversa. Il DRaaS dovrebbe essere in grado di soddisfare i recovery time objective e i recovery point objective richiesti dai service level agreement per ogni singola applicazione.

Le soluzioni DR cross-regional, come Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery, proteggono tutte le applicazioni aziendali dalla perdita catastrofica di accesso a un'intera region cloud, compresa la perdita di tutti i domini di disponibilità presenti in tale region.

Soluzioni DR di cloud ibrido

Il DR di cloud ibrido è una soluzione molto diffusa che consente alle aziende di eseguire la transizione dei carichi di lavoro e delle virtual machine dai propri data center all'infrastruttura cloud. Il cloud ibrido viene spesso utilizzato come soluzione di disaster recovery per proteggere i dati e la realizzabilità dei sistemi aziendali più importanti di un'azienda.

Per i clienti Oracle, il cloud ibrido è una confederazione libera tra server OCI e fisici, appliance Oracle Cloud o altri sistemi nel data center fisico di un'azienda. Le appliance cloud di Oracle come Oracle Private Cloud Appliance X9-2 e Oracle Exadata Cloud@Customer sono ottimi esempi di sistemi on-premise che si integrano perfettamente con OCI.

Alcuni prodotti dei partner Oracle, ad esempio Rackware, possono essere utilizzati per ottenere il DR tra l'infrastruttura on-premise e OCI. Rackware è disponibile tramite Oracle Cloud Marketplace.

Soluzioni DR multicloud

Le soluzioni DR multicloud proteggono applicazioni e dati distribuendo i vari componenti di uno stack di applicazioni nelle infrastrutture cloud di due o più provider cloud. La partnership stipulata da Oracle con Microsoft Azure è un buon esempio di relazione multicloud.

Il disaster recovery as a service dovrebbe essere in grado di gestire il DR cross-regional, il DR di cloud ibrido e il DR multicloud. OCI attualmente può fornire DRaaS per il DR cross-regional e il DR di cloud ibrido.

Coerenza dei dati per i database

Le soluzioni praticabili di disaster recovery che coinvolgono le banche dati dovrebbero sempre includere i mezzi per garantire la coerenza dei dati. Il recovery point objective è il punto entro cui un database può essere ripristinato per garantire la piena coerenza dei dati, transazioni in esecuzione comprese.

La coerenza dei dati è meno problematica per i database di file serverless o flat, ma il ripristinare sofisticati database relazionali, come Oracle Database o MySQL, a uno stato con coerenza di dati per un determinato point in time è sia molto complesso che fondamentale.

Considerazioni sul disaster recovery per i database MySQL

Quando si utilizza MySQL Database Service in OCI, un sistema di database MySQL è un container logico per una o più istanze MySQL. Fornisce un'interfaccia che consente la gestione di task quali il provisioning, i backup automatici e il ripristino point-in-time.

Le tecnologie di log binario e di replica nativa MySQL consentono il recupero point-in-time, l'high availability e il disaster recovery. MySQL Group Replication normalmente viene utilizzato per creare cluster con tolleranza agli errori locali per l'high availability, mentre la replica asincrona MySQL viene generalmente utilizzata per il disaster recovery distribuito su base geografica.

Un sistema di database con high availability abilitato dispone di tre istanze MySQL posizionate in domini di disponibilità o domini di errore diversi. Il sistema di database garantisce che se un'istanza fallisce, un'altra prende il controllo, evitando così la perdita di dati e minimizzando i tempi di inattività. Per il disaster recovery in region diverse, possono essere creati anche canali di replica in entrata tra due sistemi di database.

Clicca sui link a seguire per scoprire di più sul disaster recovery per MySQL nel cloud.

• Panoramica della continuità aziendale per MySQL
• Panoramica dell'high availability per MySQL
• Panoramica della replica in entrata per MySQL

Considerazioni sul disaster recovery per i database Oracle

Oracle Maximum Availability Architecture (MAA) offre l'architettura, la configurazione e le best practice per il ciclo di vita per i database Oracle, permettendo livelli di servizio ad alta disponibilità per database residenti in configurazioni on-premise, cloud o ibride.

Fai clic sui link a seguire per scoprire di più su Oracle Maximum Availability Architecture per il disaster recovery nel cloud.

• Pagina di destinazione di Oracle Maximum Availability Architecture
• Architetture di riferimento di Oracle Maximum Availability Architecture
• Best practice per Oracle Fusion Middleware di Oracle Maximum Availability Architecture
• Best practice per le applicazioni di Oracle Maximum Availability Architecture

Architetture di implementazione basate sul cloud

L'architettura di implementazione descrive in che modo vari componenti, ad esempio calcolo, piattaforma/database e applicazioni, vengono implementati tra le region cloud per creare strumenti resilienti per eseguire il ripristino dall'avaria totale di un data center. L'architettura di implementazione descrive la posizione di ogni elemento durante il normale funzionamento di una suite di applicazioni e gli elementi da ripristinare nella standby region per permettere una nuova esecuzione.

Oracle ritiene che le soluzioni DRaaS dovrebbero avere la flessibilità necessaria per incorporare qualsiasi combinazione di architetture di implementazione DR per soddisfare i requisiti dei singoli livelli di servizio per ogni sistema aziendale. I provider di servizi cloud dovrebbero offrire ai propri clienti la libertà di scegliere tutte le soluzioni "riportate sopra" per soddisfare i service level agreement (SLA) relativi alla vasta gamma di sistemi aziendali che le organizzazioni generalmente supportano.

Molti termini vengono utilizzati per descrivere le strategie di DR e le architetture di implementazione. Tuttavia, i vari approcci e modelli usati per descrivere come implementare l'infrastruttura, la piattaforma e le applicazioni per il disaster recovery rientrano in due ampie categorie strategiche: DR attivo/attivo e attivo/standby.

La tabella riportata di seguito analizza i termini utilizzati per descrivere le varie architetture di implementazione che rientrano nelle due ampie strategie di DR.

Strategia	Architettura di implementazione	RPO	RTO
Attivo/standby	Cold standby	Ore	Ore
Attivo/standby	Pilot light	Minuti	Ore
Attivo/standby	Warm standby	Secondi	Ore
Attivo/standby	Hot standby	Secondi	Minuti
Attivo/attivo	Attivo/attivo	Vicino a zero	Vicino a zero

Questa sezione tenta di demistificare alcune variazioni degli approcci attivi/attivi e attivi/standby al disaster recovery. Entrambe le strategie di disaster recovery fanno parte dell'arsenale di armi disponibili per raggiungere la continuità aziendale.

Architetture di implementazione attive/standby

Esistono molte varianti delle architetture di implementazione attive/standby. Le implementazioni attive/standby, a volte chiamate implementazioni attive/passive, sono spesso caratterizzate da implementazioni pilot light, cold, warm e hot.

Gli scenari pilot light, cold standby, warm standby e hot standby rappresentano una qualche versione dello stesso tema in cui il 100% di uno stack di applicazioni è in esecuzione nella region primaria, mentre meno del 100% dello stesso sistema aziendale è attivo nella standby region.

La serie di diagrammi concettuali di alto livello a seguire ha lo scopo di illustrare alcune differenze fondamentali tra architetture di implementazione comuni e non sono intese come architetture di riferimento; non descrivono come implementare il DR per uno stack di applicazioni.

Cold standby

In questo scenario le virtual machine (VM), i database e le applicazioni esistono solo nella region primaria corrente. I gruppi di volumi di storage di file e a blocchi contenenti il disco di avvio e qualsiasi altro disco virtuale per ogni VM vengono replicati nella standby region.

Mostra un'immagine con la region primaria a sinistra e la standby region a destra. La region primaria presenta tre blocchi: applicazione, database e infrastruttura, ciascuno contenente le rispettive icone. Entrambe le region hanno un'icona che rappresenta un load balancer nella parte superiore. L'icona del load balancer nella standby region ha una tonalità più chiara rispetto a quella nella region primaria. La standby region ha tre blocchi: applicazione, database e infrastruttura. Nella standby region, solo il blocco dell'infrastruttura viene popolato con icone, una per ogni storage di oggetti, storage a blocchi e storage di file. I blocchi del database e dell'applicazione nella standby region sono vuoti. Due frecce che rappresentano la replica dello storage degli oggetti e la replica dello storage sono mostrate fra i due blocchi dell'infrastruttura. Queste frecce rappresentano la replica dalla region primaria a quella standby.

Durante un'operazione di DR come uno switchover o un failover, lo storage replicato contenente le stesse VM viene attivato nella standby region e le stesse VM vengono riavviate partendo dal momento in cui sono state arrestate o sono crashate. Le VM sono le stesse identiche virtual machine in esecuzione precedentemente nella region attiva.

Questa architettura di implementazione offre diversi vantaggi, tra cui costi di implementazione, manutenzione e operativi inferiori. Tuttavia, questa soluzione potrebbe non essere la migliore per le applicazioni che si basano su database relazionali per il back-end, poiché l'unico modo per garantire la coerenza dei dati è eseguire periodicamente backup a freddo. Questo approccio va bene per le applicazioni che possono tollerare brevi interruzioni complete e occasionali.

La maggior parte delle operations IT risolve questo problema chiudendo periodicamente il database, eseguendo uno snapshot dello storage a blocchi e ricominciando le normali operazioni. Questo definisce il recovery point objective in quanto puoi eseguire il ripristino solo nel momento in cui è stato completato il backup.

Questa architettura avrà un tempo di ripristino leggermente più lungo e c'è un rischio molto maggiore di perdita di dati, ma è una soluzione valida per il carico di lavoro giusto. Ad esempio, questa soluzione potrebbe essere eccellente per le applicazioni che si affidano a un database di file flat, a un database serverless o a nessun database o per i clienti che desiderano semplicemente rendere mobile un set di virtual machine tra le region per una maggiore flessibilità.

Esempi di flussi di lavoro DR per questa architettura di implementazione

I due scenari riportati di seguito descrivono il progresso del flusso di processo per le operations di DR per le implementazioni cold standby.

Nel caso di uno switchover, le attività indicate di seguito vengono eseguite sia nella region primaria che in quella standby.

• Le applicazioni primarie sono sospese.
• I database primari vengono sospesi e sincronizzati nella standby region.
• Le virtual machine primarie vengono arrestate in modo ottimale.
• Lo storage primario viene sincronizzato con la standby region.
• Lo storage replicato viene messo online, la replica viene invertita e diventa primaria nella standby region.
• Le copie replicate delle virtual machine primarie vengono avviate e qualsiasi applicazione o strumento di sistema richiesto dallo stack di applicazioni viene avviato e diventa principale nella standby region.
• Le copie replicate dei database primari vengono recuperate nella standby region utilizzando il backup a freddo o la transazione più recente e i log di ripristino dallo storage replicato.
• Le copie replicate dei database primari vengono avviate e caricate e diventano principali nella standby region.
• Le copie replicate delle applicazioni primarie vengono avviate e convalidate e diventano principali nella standby region.
• Qualsiasi modifica al DNS e ai load balancer viene apportata per consentire l'accesso all'applicazione tramite la rete che interagisce con il pubblico.

Nel caso di failover, i task riportati di seguito vengono eseguiti solo nella standby region.

• Lo storage replicato viene messo online, la replica viene invertita e diventa primaria nella standby region.
• Le copie replicate delle virtual machine primarie vengono avviate e qualsiasi applicazione o strumento di sistema richiesto dallo stack di applicazioni viene avviato e diventa principale nella standby region.
• Le copie replicate dei database primari vengono recuperate nella standby region utilizzando il backup a freddo o la transazione più recente e i log di ripristino dallo storage replicato.
• Le copie replicate dei database primari vengono avviate e caricate e diventano principali nella standby region.
• Le copie replicate delle applicazioni primarie vengono avviate e convalidate e diventano principali nella standby region.
• Qualsiasi modifica al DNS e ai load balancer viene apportata per consentire l'accesso all'applicazione tramite la rete che interagisce con il pubblico.

Warm standby

In questo scenario le virtual machine esistono sia nella region primaria che in quella standby, ma sono completamente indipendenti l'una dall'altra e hanno nomi host univoci e indirizzi IP preassegnati. Le VM nella standby region esistono e possono essere arrestate o in esecuzione a seconda delle preferenze del cliente.

Mostra un'immagine con la region primaria a sinistra e la standby region a destra. La region primaria presenta tre blocchi: applicazione, database e infrastruttura, ciascuno contenente le rispettive icone. Entrambe le region hanno un'icona che rappresenta un load balancer nella parte superiore. L'icona del load balancer nella standby region ha una tonalità più chiara rispetto a quella nella region primaria. La standby region ha tre blocchi: applicazione, database e infrastruttura. Nella standby region, il blocco dell'infrastruttura viene popolato con icone, una per ogni storage di oggetti, storage a blocchi e storage di file. A livello di infrastruttura è presente anche un'icona per le virtual machine, ma ha una sfumatura più chiara. Anche le icone del database e l'icona dell'applicazione nella standby region sono più chiare. Due frecce che rappresentano la replica dello storage degli oggetti e la replica dello storage sono mostrate fra i due blocchi dell'infrastruttura. Queste frecce rappresentano la replica dalla region primaria a quella standby.

I database devono essere in esecuzione sia nella region primaria che in quella standby.

Per i database Oracle, consigliamo di utilizzare Oracle Data Guard per replicare i database primari e standby. Per maggiori dettagli, consulta la nostra architettura di riferimento Gold MAA.

Per i database non Oracle, verranno utilizzate le rispettive tecnologie di replica native per mantenere sincronizzati i database tra le region primarie e standby.

Le applicazioni esistono anche nella region cloud standby, ma non sono né in esecuzione né accessibili.

Esempi di flussi di lavoro DR per questa architettura di implementazione

I due scenari riportati di seguito descrivono l'avanzamento del flusso di processo per le operazioni DR per le implementazioni di warm standby.

Nel caso di uno switchover, le attività indicate di seguito vengono eseguite sia nella region primaria che in quella standby.

• Le applicazioni primarie sono sospese.
• I database primari vengono sospesi e sincronizzati nella standby region.
• Le virtual machine primarie vengono arrestate in modo ottimale.
• Lo storage primario viene sincronizzato con la standby region.
• Lo storage replicato viene messo online, la replica viene invertita e diventa primaria nella standby region.
• Le virtual machine standby vengono avviate se non sono già in esecuzione e qualsiasi applicazione o strumento di sistema richiesto dallo stack di applicazioni viene avviato e diventa primario nella standby region.
• I database standby sono modificati per consentire un accesso completo di lettura/scrittura e diventano primari nella standby region.
• Le applicazioni standby vengono avviate e convalidate e diventano primarie nella standby region.
• Qualsiasi modifica al DNS e ai load balancer viene apportata per consentire l'accesso all'applicazione tramite la rete che interagisce con il pubblico.

Nel caso di failover, i task riportati di seguito vengono eseguiti solo nella standby region.

• Lo storage replicato viene messo online, la replica, se possibile, viene invertita e diventa primaria nella standby region.
• Le virtual machine standby vengono avviate se non sono già in esecuzione e qualsiasi applicazione o strumento di sistema richiesto dallo stack di applicazioni viene avviato e diventa primario nella standby region.
• I database standby vengono recuperati utilizzando la transazione e i log di ripristino più recenti dallo storage replicato.
• I database standby sono modificati per consentire un accesso completo di lettura/scrittura e diventano primari nella standby region.
• Le applicazioni standby vengono avviate e convalidate e diventano primarie nella standby region.
• Qualsiasi modifica al DNS e ai load balancer viene apportata per consentire l'accesso all'applicazione tramite la rete che interagisce con il pubblico.

Hot standby

In questo scenario le virtual machine esistono e sono in esecuzione sia nella region primaria che in quella standby e hanno nomi host univoci e indirizzi IP preassegnati.

Mostra un'immagine con la region primaria a sinistra e la standby region a destra. La region primaria presenta tre blocchi: applicazione, database e infrastruttura, ciascuno contenente le rispettive icone. Entrambe le region hanno un'icona che rappresenta un load balancer nella parte superiore. L'icona del load balancer nella standby region ha una tonalità più chiara rispetto a quella nella region primaria. La standby region ha tre blocchi: applicazione, database e infrastruttura. Sia le region primarie che quelle standby hanno icone nei blocchi di applicazioni, database e infrastruttura. Il blocco dell'infrastruttura dispone di icone per le virtual machine, lo storage di file, lo storage degli oggetti e lo storage a blocchi sia nelle region primarie che in quelle standby. Solo le icone del database nella standby region sono più chiare. Due frecce che rappresentano la replica dello storage degli oggetti e la replica dello storage sono mostrate fra i due blocchi dell'infrastruttura. Queste frecce rappresentano la replica dalla region primaria a quella standby.

I database devono essere in esecuzione sia nella region primaria che in quella standby.

Per i database Oracle, consigliamo di utilizzare Oracle Data Guard per replicare i database primari e standby. Per maggiori dettagli, consulta la nostra architettura di riferimento Gold MAA.

Per i database non Oracle, verranno utilizzate le rispettive tecnologie di replica native per mantenere sincronizzati i database tra le region primarie e standby.

Le applicazioni sono in esecuzione nella region cloud standby, ma non sono accessibili tramite la rete che interagisce con il pubblico.

Esempi di flussi di lavoro DR per questa architettura di implementazione

I due scenari riportati di seguito descrivono il progresso del flusso di processo per le operations di DR per le implementazioni hot standby.

Nel caso di uno switchover, le attività indicate di seguito vengono eseguite sia nella region primaria che in quella standby.

• Le applicazioni primarie sono sospese.
• I database primari vengono sospesi e sincronizzati nella standby region.
• Le virtual machine primarie vengono arrestate in modo ottimale.
• Lo storage primario viene sincronizzato con la standby region.
• Lo storage replicato viene messo online, la replica viene invertita e diventa primaria nella standby region.
• Le virtual machine standby vengono sono già in esecuzione e qualsiasi applicazione o strumento di sistema richiesto dallo stack di applicazioni viene avviato e diventa primario nella standby region.
• I database standby sono modificati per consentire un accesso completo di lettura/scrittura e diventano primari nella standby region.
• Le applicazioni standby vengono avviate e convalidate e diventano primarie nella standby region.
• Qualsiasi modifica al DNS e ai load balancer viene apportata per consentire l'accesso all'applicazione tramite la rete che interagisce con il pubblico.

Nel caso di failover, i task riportati di seguito vengono eseguiti solo nella standby region.

• Lo storage replicato viene messo online, la replica, se possibile, viene invertita e diventa primaria nella standby region.
• Le virtual machine standby vengono avviate se non sono già in esecuzione e qualsiasi applicazione o strumento di sistema richiesto dallo stack di applicazioni viene avviato e diventa primario nella standby region.
• I database standby vengono recuperati utilizzando la transazione e i log di ripristino più recenti dallo storage replicato.
• I database standby sono modificati per consentire un accesso completo di lettura/scrittura e diventano primari nella standby region.
• Le applicazioni standby vengono avviate e convalidate e diventano primarie nella standby region.
• Qualsiasi modifica al DNS e ai load balancer viene apportata per consentire l'accesso all'applicazione tramite la rete che interagisce con il pubblico.

Architettura di implementazione attiva/attiva

In questo scenario, l'intero stack di applicazioni è completamente funzionale e gestisce un carico di lavoro sia nella region primaria che in quella standby.

Mostra un'immagine con la region primaria a sinistra e la standby region a destra. Sia region primaria che la region standby presentano tre blocchi: applicazione, database e infrastruttura, ciascuno contenente le rispettive icone. Entrambe le region hanno un'icona che rappresenta un load balancer nella parte superiore. Nessuno dei due è in grigio. Le icone nei blocchi dell'applicazione, del database e dell'infrastruttura sia nella region primaria che in quella standby sono visualizzate a colori. Viene mostrata una freccia che rappresenta la replica dello storage opzionale tra i due blocchi dell'infrastruttura. Questa freccia rappresenta la replica dalla region primaria a quella standby.

I database devono essere in esecuzione sia nella region primaria che in quella standby.

Per i database Oracle, è consigliabile utilizzare Oracle GoldenGate per avere una configurazione dell'applicazione attiva/attiva. Inoltre, consigliamo di avere database standby locali in ogni region utilizzando Oracle Data Guard per ottenere dei RTO e RPO quasi pari a zero. Per maggiori dettagli, consulta la nostra architettura di riferimento MAA platinum.

Per i database non Oracle, verranno utilizzate le rispettive tecnologie di replica native e attive/attive per mantenere sincronizzati i database tra le region primarie e standby.

Le applicazioni sono in esecuzione e accessibili tramite la rete che interagisce con il pubblico nella region cloud standby e hanno un carico di lavoro in esecuzione.

Automazione delle attività di disaster recovery con DRaaS

I team Oracle hanno fatto di tutto per dare high availability ai loro prodotti, compresa la stragrande maggioranza dei database e delle applicazioni di livello aziendale di Oracle, e spesso elaborano best practice e architetture di implementazione per avere un disaster recovery tanto nelle impostazioni tradizionali on premise che nel cloud. Ogni linea di prodotti prevede un approccio DR per le singole applicazioni che passi accoppiati in modo approssimativo per recuperare tutti i componenti necessari per supportare la loro applicazione.

Il disaster recovery as a service basato su cloud può collegare tutti i passaggi accoppiati in modo approssimativo ideati da sviluppatori, architetti cloud e architetti di soluzioni di prodotto, in un unico flusso di lavoro impeccabile che può essere avviato con un solo clic. OCI offre una soluzione DRaaS chiamata Full Stack Disaster Recovery che è flessibile, altamente scalabile e altamente estensibile.

OCI Full Stack Disaster Recovery gestisce la transizione dell'infrastruttura, dei database e delle applicazioni tra le region OCI in tutto il mondo con un solo clic. I clienti possono implementare ambienti di disaster recovery senza riprogettare o reimplementare l'infrastruttura, i database o le applicazioni esistenti, eliminando allo stesso tempo il bisogno di server di gestione o conversione specializzati.

• Scopri di più su OCI Full Stack Disaster Recovery
• Scopri di più sul disaster recovery per OCI