Selezionare un metodo DR

In base ai requisiti aziendali e IT, decidere il metodo di disaster recovery (DR) più appropriato per la distribuzione.

Backup e ripristino dei volumi a blocchi

I backup hanno lo scopo principale di supportare la continuità del business, il disaster recovery e l'archiviazione a lungo termine.

Di seguito sono riportati i casi d'uso comuni per i backup dei volumi a blocchi.

• Creazione di più copie dello stesso volume. I backup sono utili quando sono necessarie istanze con molti volumi che devono contenere gli stessi dati.
• Creazione di uno snapshot che sarà possibile ripristinare in un nuovo volume in seguito.
• Assicurati di disporre di una copia affidabile dei dati nel caso in cui si verifichi un problema con il volume primario.

Quando definisci il piano e gli obiettivi di backup, tenere presenti i fattori riportati di seguito.

• Frequenza: con quale frequenza si desidera eseguire il backup dei dati.
• Tempo di recupero: quanto tempo di attesa per il ripristino e l'accesso di un backup alle applicazioni che lo utilizzano. Il tempo necessario per creare un backup dipende da diversi fattori, ad esempio la dimensione dei dati di cui viene eseguito il backup e la quantità di dati che sono stati modificati dall'ultimo backup.
• Numero di backup memorizzati: numero di backup che devono rimanere disponibili e pianificazione dell'eliminazione per i backup non più necessari.

Durante la creazione dei backup e il ripristino da tali backup, tenere presenti le procedure ottimali riportate di seguito.

• Prima di creare un backup, assicurati che i dati siano coerenti: sincronizzare il file system, disattivare il file system se possibile e salvare i dati dell'applicazione. Viene eseguito il backup solo dei dati presenti sul disco. Quando si crea un backup, una volta modificato lo stato del backup da REQUEST_RECEIVED a CREATING, è possibile riprendere la scrittura dei dati nel volume. Durante l'esecuzione di un backup, non è possibile eliminare il volume di cui viene eseguito il backup.
• Se desideri collegare un volume ripristinato all'istanza di computazione a cui è collegato il volume originale, osserva che alcuni sistemi operativi non supportano il ripristino di volumi identici. Per superare questo vincolo, modificare gli ID delle partizioni prima di ripristinare il volume. La procedura per modificare l'ID partizione di un sistema operativo dipende dal sistema operativo. Consulta la documentazione per il sistema operativo dell'istanza di computazione.
• Non eliminare il volume originale prima di aver verificato che il backup sia stato creato correttamente.

Se la tua applicazione utilizza più volumi che si estendono su più istanze di computazione, utilizza i backup dei gruppi di volumi. I gruppi di volumi semplificano il processo di creazione di backup e copie per le applicazioni che utilizzano più volumi in più istanze. Puoi ripristinare un intero gruppo di volumi da un backup del gruppo di volumi, come mostrato nel diagramma riportato di seguito.

Descrizione dell'illustrazione volume-backup-restore.png

Crea una Pilot Light

Il termine luce pilot si riferisce a una piccola fiamma in un riscaldatore tradizionale a gas che è sempre acceso e può essere utilizzato per riavviare rapidamente il riscaldatore quando viene attivato da sensori di temperatura in casa. Nel contesto del DR, una luce pilota è costituita dai componenti essenziali dell'applicazione, distribuiti sul sito DR e contenenti la configurazione più recente dell'applicazione e i dati critici. Questi componenti fondamentali possono quindi essere utilizzati per ripristinare un ambiente di produzione in caso di disastro.

Di seguito sono riportati i componenti critici della luce pilota sul sito DR:

• Livello database

  Il servizio Oracle Cloud Infrastructure Database consente di eseguire il provisioning dell'intero database nel sito DR (dominio di disponibilità, area o entrambi) senza abilitare risorse di produzione. Quando il recupero da errori irreversibili (DR) è attivato, puoi abilitare più risorse con una singola chiamata API REST al servizio senza riavviare il database server.

• Livello applicazioni

  È possibile distribuire un solo Application Server nel sito DR (dominio di disponibilità, area o entrambi) contenente tutta la configurazione più recente. È possibile utilizzare la funzione delle immagini personalizzate in Oracle Cloud Infrastructure per eseguire il backup periodico del sistema operativo e delle applicazioni, quindi utilizzare queste immagini per eseguire il provisioning dei nuovi server quando il sito DR è attivato.

  Ad esempio, se un sito di produzione contiene otto Application Server, è possibile distribuire un solo Application Server nel sito DR e mantenerlo sincronizzato con il sito primario utilizzando rsync o un altro strumento. Ogni giorno si crea un'immagine personalizzata da questo server nel sito DR che può essere utilizzata per eseguire il provisioning dei sette server rimanenti quando la funzionalità di DR è attivata.

• Livello di rete
  Utilizzare le seguenti funzioni e servizi di Oracle Cloud Infrastructure nella luce pilota del sito DR

  • indirizzi IP (privati e pubblici)
  • Servizio DNS
  • Servizio di bilanciamento del carico

Usa un database in standby attivo

Un database in standby attivo (versus mount standby) è un database in standby aperto di sola lettura durante il recupero del database. Il database in standby attivo richiede la funzione e la licenza di Active Data Guard.

Grazie a Active Data Guard, è possibile utilizzare il database in standby fisico per le operazioni di lettura e reporting, riducendo il potenziale carico di lavoro sul database primario. Active Data Guard offre una protezione completa dei dati con la riparazione automatica dei blocchi di danneggiamenti fisici dei dati e verifica la presenza di altri tipi di danneggiamenti dei dati, ad esempio la perdita di scritture e il danneggiamento dei blocchi logici. Con il supporto in standby montato, sfrutterai anche molti dei vantaggi della protezione dei dati tranne per la riparazione automatica dei blocchi fisici danneggiati. I tempi di recupero (RTO, Recovery Time) e la perdita di dati (RPO) sono in genere molto bassi in caso di guasto a qualsiasi database in standby, indipendentemente dal fatto che sia aperto in sola lettura o meno.

Quando si seleziona un metodo DR, considerare se si desidera disporre di risorse simmetriche o asimmetriche:

• Risorse simmetriche: si tratta dell'architettura consigliata in modo che il database in standby sia simmetrico al sistema primario per garantire che le prestazioni delle applicazioni e del database siano simili o identiche al momento della transizione del ruolo. Inoltre, tale soluzione garantisce che il database in standby disponga di risorse sufficienti per tenere il passo con il carico di lavoro di produzione in modo da ridurre al minimo la perdita di dati al momento di un errore irreversibile. Se distribuito come database in standby attivo o con l'opzione Active Data Guard, il database in standby è aperto in sola lettura durante la protezione DR. Ciò consente di scaricare report e query.

• Risorse asimmetriche: questa architettura rappresenta una configurazione di scale-down dell'ambiente in standby. Con Active Data Guard, il database in standby può ancora essere di sola lettura e offre gli stessi vantaggi per ridurre il carico di lavoro in standby. Tuttavia, dopo il failover, le prestazioni potrebbero non essere le stesse a meno che non si esegua lo scale up del sistema in modo che corrisponda al database primario.

  I sistemi di standby asimmetrici o di piccole dimensioni costano meno, ma potrebbero avere meno capacità di elaborazione, CPU e memoria per ridurre i costi. Il trade-off è successivo alla transizione dei ruoli o a un evento di failover, devi eseguire lo scale-up (espansione) per far corrispondere il sistema primario precedente oppure accettare prestazioni inferiori o funzionalità ridotte.

Usa un supporto freddo

Il termine in standby in grassetto viene utilizzato per descrivere uno scenario DR in cui una replica ridondante dell'ambiente primario viene distribuita in un sito di DR. L'ambiente in standby freddo viene attivato solo se il sistema primario si guasta. Questo approccio garantisce la continuità della produzione con un tempo di attivazione ben definito per lo switchover.

Oracle Cloud Infrastructure supporta la distribuzione automatizzata (programmatica) di un ambiente in standby freddo che mantiene al minimo i costi di mantenimento di un ambiente di questo tipo. Ti verranno addebitate solo le risorse attive e l'eventuale storage persistente utilizzato all'interno del sito DR.