Il Disaster Recovery (DR) è un argomento che, in molte aziende italiane, è sottovalutato. Spesso, quando parlo con i clienti di nuove infrastrutture o aggiornamenti, uno dei punti nella lista delle richieste è “prevedere la possibilità di DR”.


L’affermazione di cui sopra non significa nulla in se ma, in pratica, nel lessico dei clienti, è la possibilità di creare una infrastruttura che, in un futuro più o meno lontano (di solito nell’intorno del “mai”), possa essere replicata remotamente con l’auspicio di creare un sito di DR… ma anche questo, purtroppo, non significa nulla se non correttamente supportato da un piano per il Disaster Recovery che ne preveda il corretto utilizzo!

L’obiettivo di questa breve serie di articoli (qui, qui e qui i precedenti) è quindi quello di spiegare nel modo più semplice possibile alcuni aspetti di base del “recupero da disastri” e fare un po di luce in modo da fornire alcuni semplici strumenti e terminologie per una miglior valutazione sull’argomento.

partire? non è sempre come dirlo

Una delle problematiche da affrontare quando si parla di DR è proprio la partenza della sincronizzazione del sito di DR. Per sincronizzazione intendo tutte quelle pratiche necessarie per far si che, al momento del verificarsi di un disastro, il sito secondario sia pronto a partire nel rispetto degli RPO e RTO prefissati.
Se i volumi di dati sono piccoli i problemi sono minori ma è sempre buona norma verificare i tempi e i modi con cui i dati vengono replicati sul sito di DR.
Esistono diversi sistemi per gestire la  replica dei dati e dipendono molto dall’infrastruttura che ho a disposizione, gli esempi possono essere i più vari: dalla movimentazione delle cassette di un full backup (e relativo ripristino sul secondo sito) fino a sistemi di replica hardware (magari con deduplica). Mentre per il trasporto “manuale” dei dati esistono delle problematiche legate al tempo di eseguire un backup e un ripristino sulla seconda sede, facilmente gestibili, nel caso di una copia di dati eseguita fra gli storage (o in alcuni casi a livello host) è necessario sempre tener conto della disponibilità di banda (e in alcuni casi della latenza) a disposizione.
Infatti, la banda costa e nel 99% dei casi viene dimensionata per gestire la replica dei dati a regime (quindi quella necessaria per gestire l’RPO). Quello che ho appena scritto significa che, effettuare la prima sincronizzazione, può comportare un tempo molto lungo (anche nell’ordine delle settimane!).
Per aggirare l’ostacolo esistono diversi “trucchi” che aiutano a mitigare il problema. In alcuni casi, l’unica via è quella di installare i sistemi di DR a fianco di quelli primari, duplicare tutto,  creare un punto di consistenza,smantellare, re-installare sul secondo sito, riprendere la replica! (sembra folle ma è così). In altri casi, i vendor hanno iniziato a proporre soluzioni alternative capaci di gestire in modo molto più smart la prima copia (qui un esempio): in pratica sistemi che permettono di prendere una copia dei dati consistente e spostarla con nastri o dischi rigidi sulla seconda sede, dove è pronto il sistema di DR per riceverli e ripartire con la sincronizzazione.
Anche in questo caso, come per tutte le scelte fatte in precedenza, è necessario quindi prioritizzare le copie: prima si da inizio alla copia dei dati più importanti per poi continuare con quelli meno critici. Eseguire la copia parallela di tutti i dati non darebbe nessun vantaggio e allungherebbe i tempi per mettere in sicurezza quelli più critici.

mai sottovalutare il failback

Quello che ho scritto sopra riguardo la prima copia è un problema che si può verificare anche quando, dopo un disastro, sia necessario ripristinare il sito primario. Se il tempo intercorso fra lo switch sul secondario e lo switch back è troppo lungo, il sistema di storage non sarà più in grado di mantenere allineati i diversi volumi e sarà necessario ripetere la sincronizzazione iniziale all’indietro, con tutti i problemi che questo può comportare!
Ancora di più, se il DR è fatto con i nastri, sarà necessario un fermo importante delle attività di produzione proprio per permettere di fare un backup e un ripristino sul sito principale.

l’infrastruttura di DR

Molti clienti cercano di abbattere, almeno parzialmente, i costi dell’infrastruttura di DR spostando su di essa alcune attività secondarie (come ad esempio sviluppo e test) oppure crea due siti che si bilanciano come carico ed applicazioni durante le normali attività.
Negli ultimi tempi, diversi vendor, hanno anche realizzato soluzioni che permettono di spostare attività da un sito all’altro con pochi click (qui due esempi: 1, 2) e che quindi possono facilmente bilanciare il carico in caso di necessità (o muovere tutto il carico su una delle infrastrutture in previsione del fermo di un sito). Ovviamente, anche in questo caso, il tutto ha un costo che si traduce in una infrastruttura più costosa e una maggiore disponibilità di banda (e bassa latenza), quindi sono soluzioni che spesso si possono utilizzare solo se i due siti sono ad una distanza limitata fra loro.

perchè virtualizzare aiuta

Un problema che affligge tutti i progetti di DR è l’hardware! Teoricamente, nel sito di DR, dovrebbero essere presenti macchine analoghe a quelle del sito primario (in molti casi identiche). Ovviamente, il problema dell’hardware, sono le differenze (chipset, CPU, drivers, ecc) che potenzialmente possono impedire di duplicare i sistemi in modo semplice. In alcuni casi è necessario addirittura mantenere due sistemi separati e copiare solo i dati complicando notevolmente ogni attività.
Virtualizzando, invece, è tutto molto più semplice perchè è possibile replicare non solo i dati ma i contenuti delle VM stesse ed essere sicuri di abbattere tempi e costi. Inoltre, le VM possono ripartire su infrastrutture diverse da quelle originali permettendo quindi, in alcuni casi, dei risparmi notevoli.
Un ulteriore vantaggio nell’uso della virtualizzazione deriva dall’uso di soluzioni preconfezionate che i produttori di hypervisor mettono a disposizione: Site Recovery Manager di VMware è la più collaudata ma anche Citrix e Microsoft stanno lavorando per portare sul mercato soluzioni simili. 

DR e cloud

Un ultimo paragrafo di questa serie di articoli va dedicato al cloud. Il DR sul cloud è possibile, economico e, a volte, più facile da realizzare che con altri modalità.
Non è per tutti, intendiamoci, ma esistono alcuni servizi che possono essere replicati su un provider esterno in grado di fornire servizi e SLA adeguati a costi contenuti. Esempi di “DR as a Service” sono diversi: alcuni forniti da provider di caratura internazionale altri sono di carattere più locale e molti System integrator, come ad esempio Cinetica, si stanno proponendo per fornire questo tipo di servizi ai loro clienti.
Con questo ho concluso la serie di articoli sul DR, spero che la lettura sia stata utile per capire meglio alcuni dei tanti aspetti che ruotano intorno a queste problematiche.
Ogni commento e punto di vista è il benvenuto!