Appunti

 

Osservando le tendenze 2010 nella definizione dei piani di Disaster Recovery  è diventato chiaro che la virtualizzazione è un elemento chiave. Una indagine condotta  da Symantec  ha  provato che buona parte delle organizzazioni sta rivalutando i piani di DR in funzione della virtualizzazione. Ma perché? Il vantaggio della virtualizzazione in tema di DR è ovvio:  consolidare più server virtuali su un solo server fisico riduce il numero dei server da acquistare per i siti alternativi abbattendone gli investimenti in conto capitale e mitigando in tal modo uno dei punti dolenti dei piani di DR ovvero il costo dei beni inattivi.

Tuttavia, la riduzione degli acquisti in conto capitale è solo uno dei vantaggi che la virtualizzazione porta al DR; la virtualizzazione, introducendo un livello di ulteriore astrazione della piattaforma hardware  separandola dal sistema operativo delle macchine virtuali, può anche aiutare a semplificare il processo di failover e ripristino, può abbreviare i tempi di recupero, ridurre i rischi e permettere l’introduzione di  procedure di test e verifica più complete e frequenti.

La virtualizzazione può ridurre o eliminare le dipendenze di hardware e questo va nella direzione della semplificazione eliminando la necessità di avere infrastrutture hardware analoghe sia nel sito primario che in quello secondario. 

Tuttavia, al fine di massimizzare i vantaggi della virtualizzazione, il DR delle architetture virtualizzate richiede una qualche forma di spostamento o copia delle immagini delle macchine virtuali (VM) e dei dati verso i siti di DR.

Virtualizzazione o meno, una recente indagine di Aberdeen Group dimostra che le organizzazioni più efficienti in termini di DR tendono ad implementare tecnologie di salvataggio fisico delle immagini che promettono tempi di ripristino estremamente rapidi; questo vale soprattutto per le infrastrutture virtualizzate.

Tuttavia, se si desidera minimizzare i tempi di recupero (RTO),  sarà necessario esplorare anche qualche tecnologia  di replicazione dei dati. Gli approcci possibili sono fondamentalmente due: storage-based oppure host-based. Le organizzazioni di dimensioni maggiori tendono a replicare i dati direttamente tra i sottosistemi di storage e qualche tecnologia di virtualizzazione (vedi VMware's Site Recovery Manager (SRM)) è progettata per supportare specificamente questo approccio.  Se la replicazione via storage-array non è gradita o non adatta si può ricorrere a tecnologie di replicazione basate su host (via software) con prodotti tipo Vizioncore, Double-Take oppure CA XOsoft.

Una funzionalità aggiuntiva dei prodotti host-based è la possibilità di creare infrastrutture di DR ibride  fisico-virtuali molto utili in tutte le situazioni in cui il sistema informativo primario non sia completamente virtualizzato; anche se erroneamente (forse!)  molti non sono disposti a virtualizzare le applicazioni di supporto al core business aziendale nel sito primario ma possono ritenere accettabile una virtualizzazione sul sito secondario. I prodotti citati hanno la capacità di convertire e migrare da fisico a virtuale (P2V) e quindi di nuovo a fisico (V2P) supportando in tal modo il modello ibrido.

I prodotti citati costituiscono una minima parte delle tecnologie a disposizione per l’implementazione di  una architettura di replicazione basata su immagini e molte sono in fase di rilascio; tutte hanno un paio di caratteristiche in comune: il consumo di banda e storage. Entrambi i fattori stanno diventando rapidamente  punti chiave nelle analisi di fattibilità di qualsiasi implementazione. Se il problema dell'occupazione di storage può essere mitigato mediante l'uso di tecnologie di deduplicazione dei dati non altrettando si può dire dell'occupazione di banda in rete soprattutto nell'archiviazione di immagini di backup per un DR.

Lo schema seguente normalmente usato per  stimare i requisiti minimi per installazioni Double-Take evidenzia come i requisiti di banda aumentino molto rapidamente anche per installazioni in cui sia prevista una replicazione asincrona. Spendere un capitale in upgrade di banda è l'unica soluzione del problema?

In alcune situazioni possono venire in aiuto le tecnologie di replicazione implementate a livello applicativo come la replicazione dei database basate sull'invio dei log delle transazioni implementate in quasi tutte le piattaforme di database (Oracle, Mysql, MS Sql Server, IBM DB2 le implementano di sicuro) oppure la replicazione di Exchange 2010 basata su DAG; anche se un pò più complicate da configurare e gestire, in generale queste tecnologie sono più efficienti delle controparti basate su storage array o host se non altro perchè disegnate per supportare in modo specifico le operazioni di Disaster Recovery.

A titolo di esempio prendiamo in considerazione la replicazione di una banca dati Oracle. In caso di inserimento di una riga in un tabella con due indici (qualsiasi anagrafica ha almeno una ricerca per codice ed una per descrizione) nel caso migliore l'operazione richiede la modifica di 5 blocchi dati: tabella, UNDO tablespace,  LEAF Node del primo indice, LEAF Node del secondo indice, REDO log. Una qualsiasi tecnologia di buon livello per replicazione delle immagini che operi in modo sincrono o includa un qualche algoritmo di deduplicazione invierebbe i 5 blocchi modificati al sito secondario; in una installazione basata su Oracle Dataguard verrebbe inviato il solo blocco di REDO, un rapporto 5:1 di riduzione sugli impegni di banda. Questo vale ovviamente per le attività di aggiornamento successive alla prima che dovrà prevedere l'invio dell'immagine completa della banca dati.

La replicazione applicativa può ovviamente coesistere con le tecnologie operanti per immagini. Anzi, le implementazioni più efficienti si basano su un modello ibrido in cui le macchine virtuali vengono replicate per immagini ed i dati critici vengono sincronizzati in modalità applicativa; in questo caso assume una importanza vitale la corretta separazione su volumi diversi di sistema operativo, dati destrutturati e banche dati.

E' comunque importante ricordare (anche se superfluo) che la sottovalutazione del fattore "occupazione di banda" può avere forti impatti negativi su qualsiasi progetto di DR con ambizioni obiettivi di RTO e RPO.