Failover e failback: differenze fondamentali nel ripristino di emergenza
< & & Nel mondo moderno, qualsiasi azienda può subire di tanto in tanto la corruzione dei dati e l'interruzione delle operazioni mission-critical. Tuttavia, anche una breve interruzione dei servizi può minare la fiducia dei clienti e portare alla fine a perdite significative. Le aziende, in particolare quelle che gestiscono i propri servizi su VM, devono creare un piano di ripristino di emergenza (DR) per le VM per garantire un’elevata disponibilità e la continuità operativa. Questo post del blog descrive il ruolo del failover e del failback nel processo di DR e spiega come è possibile utilizzare queste strategie per proteggere la propria attività.
Che cos’è il ripristino di emergenza delle VM?
Il ripristino di emergenza delle VM è il processo di ripristino dell’infrastruttura aziendale a uno stato normale dopo un disastro. Per disastro si intende qualsiasi evento che metta a rischio le operazioni di un’organizzazione, compresi i pericoli naturali e quelli causati dall’uomo. Essenzialmente, il ripristino di emergenza delle VM ha lo scopo di ripristinare l’ambiente virtualizzato di un’organizzazione. L’obiettivo finale di qualsiasi processo di ripristino di emergenza è quello di riprendere quasi istantaneamente le operazioni aziendali e proteggere i dati più critici per garantire la continuità operativa.
Le misure di DR si dividono in tre tipi. Le misure preventive hanno lo scopo di impedire il verificarsi di un evento. Le misure correttive mirano a riparare un sistema in caso di disastro. Le misure investigative sono utilizzate per identificare i possibili rischi e mitigarli.
Differenza tra failover e failback
Gli scenari di emergenza si verificano quasi sempre in modo imprevisto. In caso di DR, è fondamentale ripristinare l’infrastruttura virtualizzata della vostra azienda il più rapidamente possibile, prima che si verifichino danni significativi. Il failover e il failback possono contribuire a garantire il corretto funzionamento della vostra azienda, anche se il sito di produzione è colpito da un disastro.
Che cos’è il failover?
Il failover è il processo di trasferimento dei carichi di lavoro mission-critical da un centro di produzione primario e di ripristino del sistema in una ubicazione remota. L’obiettivo principale del failover è mitigare l’impatto negativo di un disastro o di un’interruzione del servizio sui servizi aziendali e sui clienti. In caso di guasto software o hardware, è possibile ripristinare rapidamente una VM interessata eseguendo il failover sulla sua replica.
Failover utilizzando repliche di VM
Durante il failover, una replica della VM in un sito remoto viene accesa per sostituire la VM originale nel sito di produzione. È possibile eseguire il failover all’ultimo punto di ripristino, che rappresenta essenzialmente una VM in un determinato momento. L’esecuzione di processi di replica il più frequentemente possibile consente di creare più punti di ripristino, garantendo una perdita minima di dati in caso di disastro. Il failover alla replica è una soluzione conveniente adatta al ripristino di emergenza in caso di guasto hardware o software.
Failover Clustering
Un cluster di failover rappresenta un gruppo di computer indipendenti che lavorano insieme per garantire l’alta disponibilità di applicazioni e servizi. Un cluster di failover è costituito da due o più server (o nodi) interconnessi, sui quali sono in esecuzione le VM, e da uno storage condiviso, dove sono conservati i file delle VM. Se uno dei server si guasta, le VM vengono ripristinate su un altro server. Un cluster di failover protegge le VM solo dai guasti hardware. Il clustering di failover è più costoso del failover alla replica. Tuttavia, garantisce un tempo di inattività quasi nullo, poiché le VM vengono automaticamente accese nella posizione secondaria quando si verifica un disastro.
Che cos’è il failback?
Una volta ripristinato il sito primario dopo un disastro e risolti eventuali problemi associati, è possibile trasferire le operazioni aziendali alla VM di origine.
Il failback consente di ripristinare la VM originale sull’host di origine (o in una nuova ubicazione a scelta) e di riportare i carichi di lavoro dalla replica della VM alla VM originale. Tuttavia, dal momento del failover potrebbero essere state apportate alcune modifiche alla replica della VM. Pertanto, prima di eseguire il failback è necessario sincronizzare la VM originale e la replica della VM, in modo da non perdere informazioni critiche. Nel failback, solo i dati modificati vengono rinviati al sistema originale.
Il processo di failover e failback come parte del ripristino di emergenza
Durante un evento di ripristino di emergenza, vengono avviate le operazioni di failover e failback. Il processo viene eseguito come segue:
- La VM di origine nel sito di produzione viene replicata nel sito di DR. I dati sui dischi virtuali della replica della VM sono identici ai dati sul disco virtuale della VM di origine al momento della replica. In caso di disastro (o se si prevede un disastro), viene avviato il failover alla replica della VM.
- Durante il failover, i carichi di lavoro del sistema vengono trasferiti al sito DR. Tuttavia, potrebbero verificarsi alcune modifiche nella replica della VM mentre le operazioni continuano. È importante salvare tali dati perché il sistema originale è offline e non registra alcuna delle modifiche apportate. Pertanto, tutte le modifiche vengono scritte solo sul disco virtuale della replica della VM.
- Una volta risolte le conseguenze negative di un disastro (o una volta superata la possibile minaccia), il sito primario può funzionare come al solito. Pertanto, viene eseguita l’operazione di failback; tutti i carichi di lavoro vengono rinviati dall’ubicazione DR al sito di produzione e i dati aggiornati vengono ricevuti dalla VM di origine. La VM originale e la replica della VM vengono sincronizzate.
Procedure consigliate per il failover e il failback nel ripristino di emergenza delle VM
- Garantire la conformità alle normative. Alcune organizzazioni operano con dati molto sensibili e riservati e è obbligatorio per loro rispettare normative quali HIPAA o PCI DSS. Se questo è il vostro caso, dovete verificare che le vostre strategie di DR per il failover e il failback soddisfino gli standard di sicurezza applicabili.
- Verificate le licenze. Esaminate la documentazione del software e determinate se esistono limitazioni di licenza nei vostri stack di applicazioni. In tal caso, è necessario risolvere preventivamente eventuali problemi e assicurarsi che tutti i requisiti siano soddisfatti.
- Definire l’ambito del piano di DR. L’ambito di un piano di DR per VM determina quali sistemi devono essere protetti e identifica i risultati attesi e le eventuali limitazioni. Assicuratevi che il vostro ambiente virtuale abbia una capacità tecnica adeguata a coprire tutti gli aspetti del vostro piano.
- Scegliete una soluzione affidabile per la protezione dei dati. L’installazione di una soluzione di protezione dei dati con licenza adeguata nel vostro ambiente virtuale è fondamentale per garantire prestazioni efficienti e un’integrazione perfetta. Ai fini della pianificazione della DR, è necessario stabilire il tempo necessario al prodotto per ripristinare l’infrastruttura virtuale e riportare tutte le operazioni al sito di produzione.
- Decidete chi è responsabile del failover e del failback. La gestione dovrebbe designare i membri di un team di ripristino e assegnare responsabilità specifiche a ciascun membro del team. Stabilire chi è responsabile del monitoraggio delle operazioni di failover e failback, in modo da evitare confusione in uno scenario di ripristino reale quando è importante.
- Formare il personale IT sulle operazioni di failover e failback. In linea con il punto precedente, assicurarsi che il personale IT disponga delle conoscenze e delle qualifiche necessarie per eseguire operazioni di failover e failback. I dipendenti responsabili devono essere pienamente preparati nel caso in cui qualcosa non vada come previsto; devono avere una solida comprensione delle operazioni per essere in grado di adattarsi di conseguenza e affrontare eventuali problemi che dovessero sorgere.
- Rivedere gli accordi sul livello di servizio (SLA). Un accordo sul livello di servizio è un contratto tra un fornitore di servizi e i suoi clienti che determina i requisiti e gli standard di servizio che il fornitore è tenuto a soddisfare. Assicurarsi quindi che gli SLA siano aggiornati e che la loro applicabilità si estenda all’ambiente DR.
- Definire RTO e RPO. A obiettivo di tempo di ripristino RTO (periodo di tempo durante il quale le operazioni aziendali devono essere ripristinate dopo un disastro, al fine di prevenire danni significativi e perdite critiche). L’obiettivo di punto di ripristino (RPO) indica la quantità di dati (misurata in tempo) che può essere persa senza causare danni inaccettabili alla vostra attività. Un RPO è essenzialmente il punto più lontano nel tempo a cui le vostre VM potrebbero essere ripristinate in caso di disastro. Gli RTO e gli RPO devono essere stabiliti principalmente in base alle priorità dell’organizzazione in caso di disastro. Sebbene aumentare la frequenza dei lavori di backup e replica possa essere un’operazione dispendiosa in termini di tempo e risorse, migliora notevolmente gli RPO. Gli RTO più brevi devono essere assegnati ai componenti con la massima priorità, che devono essere ripristinati per primi. Si noti che gli RTO e gli RPO devono essere stabiliti separatamente per le applicazioni e le VM.
- Considerate la possibilità di trasformare il vostro sito DR in un sito permanente. La vostra azienda potrebbe essere colpita da un grave disastro che rende impossibile ripristinare il vostro data center principale. Pertanto, valutate la possibilità di trasformare il vostro sito DR in un sito permanente, in modo da essere preparati in anticipo a un evento di questa portata. Ovviamente, si tratta di una soluzione costosa che richiede notevoli risorse e comporta costi elevati per attrezzature, software e strutture. Può essere utile considerare cosa sarebbe necessario fare, anche se non si intende procedere immediatamente con il piano.
- Testare le operazioni di failover. Testando la procedura di failover, è possibile verificare se l’infrastruttura virtuale può essere ripristinata correttamente nel sito di DR e se le applicazioni preinstallate possono funzionare correttamente anche quando il sito di produzione è disabilitato.
- Testare le operazioni di failback. In questo modo, potrete garantire che le operazioni della vostra azienda possano essere ripristinate con successo dal sito DR al sito originale.
- Testate il vostro piano DR nella sua interezza. Vale anche la pena testare l’intero piano DR; ciò può aiutare a identificare i punti deboli del piano simulando un evento DR. Di conseguenza, potrete migliorare e adattare le strategie di DR applicate dalla vostra organizzazione. Un piano di DR imperfetto e obsoleto può compromettere in modo significativo la continuità operativa della vostra organizzazione.
Failover e Failback in NAKIVO Backup & >
NAKIVO Backup & Replication offre un’esclusiva funzionalità di ripristino del sito che consente di creare flussi di lavoro (o attività) di ripristino automatizzati di qualsiasi complessità. I flussi di lavoro di ripristino del sito (SR) prevedono sequenze personalizzate di azioni, quali failover, failback, avvio/arresto di macchine virtuali, esecuzione/arresto di attività, collegamento/scollegamento di repository, ecc. Queste azioni possono essere organizzate in qualsiasi ordine per l’automazione e l’orchestrazione totale del processo di DR. Inoltre, è possibile modificare, integrare o testare facilmente i propri lavori SR in qualsiasi momento senza interrompere l’ambiente di produzione. Pertanto, anche il piano di DR più sofisticato può essere creato, testato e quindi implementato senza problemi utilizzando i flussi di lavoro SR.
Ripristino di emergenza
L’azione di failover è parte integrante della maggior parte dei flussi di lavoro SR. Il ripristino dell’ambiente che comporta il failover può essere eseguito solo se sono state precedentemente create repliche delle VM di origine che si desidera proteggere; queste vengono utilizzate come destinazioni per il failover in caso di disastro. Il carico di lavoro viene trasferito dalla VM di origine nel sito di produzione interessato a una replica della VM nel sito di DR.
NAKIVO Backup & Replication ha presentato tre tipi di failover:
- Il failover pianificato viene utilizzato per la protezione preventiva dei sistemi in caso di potenziali minacce o se si prevede un disastro. Se è stata segnalata una situazione di pericolo meteorologico o se è prevista un’interruzione di corrente nella zona, è possibile avviare il failover pianificato. In questo caso, la soluzione sincronizza i dati tra la VM di origine e la sua replica prima di trasferire il carico di lavoro alla replica, evitando così completamente la perdita di dati.
- Il test di failover aiuta a determinare se le strategie di failover hanno funzionalità e se possono essere considerate affidabili in caso di evento DR. Il test di failover viene eseguito in modo simile al failover pianificato, tranne per il fatto che tutte le modifiche apportate in modalità di test vengono immediatamente ripristinate in modo da non causare interruzioni nell’ambiente primario. Inoltre, è possibile verificare se il flusso di lavoro funziona in modo sufficientemente rapido in caso di evento di DR. NAKIVO Backup & Replication consente di impostare un RTO per il processo di ripristino del sito. Se il processo richiede più tempo del previsto per essere completato, il test viene considerato fallito. Un rapporto di test/esecuzione viene inviato via e-mail, che è possibile esaminare per identificare le carenze nel piano di DR e risolverle.
- Il failover di emergenza viene eseguito immediatamente dopo che un disastro ha colpito il sito di produzione e la VM di origine non è raggiungibile. Con NAKIVO Backup & Replication & Replication, è possibile spostare il carico di lavoro dal sito primario al sito DR con un solo clic. In questo modo, è garantito un tempo di inattività minimo, anche se alcuni dati potrebbero andare persi.
Riprotezione delle VM nel sito DR
Una volta eseguito il failover, è necessario assicurarsi che le repliche delle VM in esecuzione nel sito DR siano protette. Anche le repliche delle VM possono subire danni e, se non esistono altre copie, sarebbe impossibile ripristinarle immediatamente.
Tuttavia, NAKIVO Backup & Replication garantisce che l’infrastruttura virtuale sia nuovamente protetta dopo un evento DR. È sufficiente replicare le VM in esecuzione nel sito DR in un’altra ubicazione. In questo modo, è possibile eseguire facilmente il failover sulla nuova replica della VM in caso di imprevisti. È possibile configurare i flussi di lavoro SR per avviare automaticamente la replica delle VM in esecuzione nel sito DR non appena il failover è completato, garantendo così livelli elevati di protezione.
Failback nel Ripristino di emergenza
Il failback può essere eseguito solo dopo che si è verificato il failover in un flusso di lavoro SR. Dopo un po’ di tempo, quando il sito primario è nuovamente operativo, è possibile riprendere le operazioni sulla VM di origine originale. A tal fine, è possibile eseguire il failback su questa VM da una replica della VM che ha sostituito la VM originale. Se i carichi di lavoro della VM non possono essere trasferiti nuovamente al sito di produzione primario (ad esempio perché non è possibile ripristinarli), possono essere trasferiti in qualsiasi altra nuova ubicazione a scelta per una soluzione a più lungo termine rispetto al sito DR.
Il failback può essere eseguito in modalità di produzione o in modalità di test.
- Il failback in modalità di test ha lo scopo di determinare se il processo SR può essere eseguito correttamente, senza che si verifichino problemi durante il processo di failback effettivo. In questo caso, la replica incrementale o completa dalla replica della VM alla VM di origine viene eseguita una sola volta, il che è sufficiente ai fini del test. Assicurarsi che l’indirizzo IP e le impostazioni di rete siano corretti. La VM di origine e la replica della VM vengono sincronizzate in modo da evitare la perdita di dati, quindi la VM di origine viene accesa. Si noti che tutte le modifiche apportate alle VM durante il processo di failback vengono eliminate al termine del test e l’ambiente virtuale viene riportato allo stato precedente al failback. In modalità di test, un lavoro di ripristino dell’ambiente può essere eseguito on demand o in base alla pianificazione.
- Il failback in modalità produzione viene eseguito quando si desidera ripristinare l’ambiente di produzione dopo il failover DR. In modalità produzione, un lavoro di ripristino dell’ambiente può essere eseguito solo su richiesta. Il failback in modalità produzione segue essenzialmente gli stessi passaggi del failback in modalità test. Tuttavia, la replica dalla replica VM alla VM di origine viene eseguita due volte in modo da garantire zero perdite di dati durante il processo. Una volta completata l’operazione di replica, la VM di origine originale (nel sito di produzione) viene accesa e la replica della VM nel sito DR viene spenta. (Si noti che quest’ultimo passaggio, ovvero lo spegnimento delle repliche della VM DR, si verifica solo in modalità di produzione).
Conclusione
Comprendere la tecnologia alla base del failover e del failback e integrarla nel piano di ripristino di emergenza delle VM può proteggere l’ambiente virtuale da qualsiasi evento imprevisto. Il failover garantisce la sicurezza dei dati mission-critical e il trasferimento rapido di tutti i carichi di lavoro a un sito di DR. Il failback consente di tornare dal sito di DR al sito di produzione con pochi clic. Insieme, queste operazioni aiutano a garantire una perdita di dati minima e a ridurre i tempi di inattività.
