Una considerazione da fare sui servizi da proteggere riguarda la necessità di condurre una preventiva ed accurata fase di analisi per determinare i livelli di servizio desiderati e poi adeguare di conseguenza la propria infrastruttura e le proprie procedure operative.

I livelli di operatività sono sintetizzati da due indicatori:

• Recovery Time Objective (RTO) – massimo tempo di indisponibilità del servizio, ovvero il tempo entro il quale il servizio da proteggere deve essere ripristinato
• Recovery Point Objective (RPO) – perdita dati sostenibile, in termini di distanza temporale tra il verificarsi dell’emergenza e l’ultimo salvataggio utile e ripristinabile dei dati

I nastri magnetici sono ancora oggi i supporti più utilizzati sia per l’elevata capacità di immagazzinamento che per la semplicità del loro trasporto. Questa tecnologia permette di fare copie dati al più basso dei costi possibili e soddisfa le esigenze di continuità operativa aventi tempi di ripristino (RTO) di ore o giorni e con valore di RPO dipendente dalla granularità temporale con cui sono effettuati i backup. (Esistono anche librerie di nastri virtuali: unità di storage disco che simulano il comportamento di una libreria a nastri).

La data replication, sincrona o asincrona, aumenta il grado di protezione dei dati introducendo ridondanza e permette di ridurre i tempi ripristino, a patto ovviamente di un adeguamento delle infrastrutture e con costi conseguenti.

In figura è rappresentato un tipico schema di data replication ottenuta a livello di storage array (in questo caso allocati su due sedi geograficamente separate). Questo tipo di soluzione prevede l’utilizzo di un hardware gemello, di un software di replica certificato dal produttore dello storage e di un link con adeguata ampiezza di banda. Le caratteristiche del link ed il protocollo utilizzato sono un compromesso tra modalità di replica (sincrona/asincrona), livello di servizio ed ampiezza di banda disponibile.

Un’altra soluzione, a mio parere molto interessante anche per i costi inferiori rispetto a quella “storage based”, prevede l’impiego di un software in esecuzione sul server che intercetta tutte le richieste di scrittura e le trasmette ad un sistema remoto attraverso la rete. Un prodotto di questo tipo è Geographic Logical Volume Manager di IBM dalla cui documentazione tecnica ho tratto gli esempi riportati.

Nella precedente figura è riportato lo schema di un server (Node A) connesso a due dischi fisici (PV1 e PV2) componenti un unico gruppo di volumi (VG datavg) su cui risiedono i dati. Questa configurazione base è assolutamente non ridondante e ciascuno dei due dischi è potenzialmente un punto di fallimento. In caso di guasto, pertanto, tutti i dati contenuti saranno inutilizzabili e dovranno essere ripristinati da nastro, con l’ovvia conseguenza che tutte le modifiche apportate dopo l’ultimo backup saranno irrimediabilmente perse.

Una strategia utile per migliorare il grado di resistenza ai guasti dell’architettura di cui sopra è quella di aggiungere altri due dischi fisici e realizzare un gruppo di volumi in configurazione RAID-1 (mirror).

Tuttavia anche questa soluzione, certamente più robusta della precedente, non mette al riparo dalle catastrofiche conseguenze di un incendio o di un allagamento del sito di produzione. Se ciò dovesse accadere, infatti, andrebbero persi sia il server che tutte le copie dei dati e l’unica alternativa sarebbe ancora una volta il restore da nastro, questa volta con alcune complicazioni aggiuntive: dover reinstallare il server, applicare gli aggiornamenti, modificare le configurazioni, personalizzare il software applicativo.

Una soluzione ancora migliore è ottenuta spostando una parte dei dischi costituenti il mirror in una sede geograficamente separata (il sito di disaster recovery) e connettendoli ad un altro server (Node B) con funzioni di “spare”. In questo modo è possibile creare un gruppo di volumi “distribuito”, sempre in configurazione RAID-1, costituito da dischi locali e dischi “remoti” (RPV).

Il Logical Volume Manager del sito di produzione comunica con i dischi fisici locali in modo diretto e con i dischi remoti attraverso un driver (RPV device driver) . In particolare, il client RPV in esecuzione sul nodo A di produzione, invia le richieste di lettura/scrittura alla propria controparte (RPV server) in esecuzione sul nodo B del sito di disaster recovery, realizzando così un real time geographic data mirroring su rete standard TCP/IP.

Alcuni riferimenti utili: