Se vuoi approcciare un progetto di DRaaS, cioè di Disaster Recovery As A Service, la prima (e più importante) domanda che ti devi fare è :
In caso di disastro ai miei sistemi, quanti dati sono disposto a perdere ?
A nessuno piace perdere i propri dati e la risposta naturale che ognuno di noi vorrebbe dare ad una risposta simile è : non voglio perdere neanche un dato !
Bellissimo obiettivo ma francamente difficile da raggiungere, a meno che tu non abbia un budget veramente molto cospicuo.
Ma se desideri affrontare un progetto di Cloud Disaster Recovery, vuoi probabilmente sfruttare il principale vantaggio che deriva dall’utilizzo di infrastrutture Cloud.
Il principale vantaggio dell’utilizzo del Cloud Computing per creare un sito di Disaster Recovery sta nell’ottenere un ambiente sicuro e scalabile a costi decisamente più contenuti e tempi di messa in opera molto più limitati rispetto a quanto sarebbe avvenuto nell’era pre-cloud.
Prima della possibilità di utilizzare le tecnologie di Cloud computing, il Disaster Recovery era alla portata solo del budget e delle competenze delle grandi corporate o delle grandi banche.
Iniziamo a trattare l’argomento facendo prima alcune premesse :
- Cosa significa DRaaS
- Cos’è un disastro
DRaaS : la salvaguardia del tuo business, grazie al Cloud.
Ritorniamo sul concetto che sta dietro al termine di Disaster Recovery As A Service.
Significa utilizzare un ambiente Cloud già attivo presso un qualsiasi Cloud Provider, ritagliarsi all’interno di esso un spazio virtualmente riservato, ed utilizzarlo per creare una replica dei propri sistemi informatici.
Quindi tutte le macchine virtuali ed i dati contenuti nello storage del tuo CED avranno un loro replica in un ambiente Cloud.
Nessun investimento, nessun hardware da installare e da manutenere; pagherai solo in relazione al servizio che ricevi (As A Service appunto…).
E’ evidente che le piccole aziende avranno poco da replicare e quindi pagheranno poco per il servizio.
Le grandi aziende pagheranno sicuramente di più, ma avranno comunque il vantaggio di non dover fare investimenti, di poter scalare l’infrastruttura quando vogliono e di avere tempi di messa in opera decisamente limitati.
Cos’è il “Disastro” e quali sono le cause.
Il disastro è il verificarsi di un fattore scatenante in grado di compromettere in tutto o in parte la normale operatività dei tuoi sistemi informatici.
Può essere una grave calamità naturale (terremoti, alluvioni…), oppure un incendio, oppure motivi di natura tecnologica, come un’improvvisa mancanza di corrente (hai controllato di recente che il tuo UPS funzioni a dovere ?), oppure un processo di aggiornamento finito male che possa corrompere in tutto o in parte un database ed altri sistemi.
E poi c’è il fattore umano.
Quest’ultimo è a mio parere il più “interessante”, ed anche il più difficile da preventivare : un dipendente infedele o semplicemente un errore umano, oppure noncuranza o ignoranza del pericolo.
DRaaS: i 4 aspetti fondamentali per il tuo progetto
Dopo queste doverose premesse, affrontiamo il core del problema.
Riprendiamo la domanda iniziale :
In caso di disastro ai miei sistemi, quanti dati sono disposto a perdere ?
Per rispondere a questa domanda, e di conseguenza strutturare e dimensionare correttamente il tuo progetto di di Disaster Recovery, dovremo tenere presente i punti seguenti.
#1 : Quanto lavoro puoi perdere.
Non sarai contento di dover fare questo ragionamento, ma il corretto dimensionamento di un DraaS si gioca tutto su di un valido compromesso tra questi due antipodi :
- Nessun dato perso = alti costi per il Disaster Recovery
- Tutti i dati persi = nessun Disaster Recovery !
Per esempio: potrebbe essere accettabile per la tua Azienda perdere 6-8 ore di fatture generate dal gestionale ? oppure di lead o di contatti inseriti dai tuoi commerciali nel CRM ? oppure perdere 6-8 ore di archivio delle mail ?
Questo è il primo punto da chiarire : con quale frequenza il sito primario dovrà essere replicato presso il sito secondario.
Con questo ragionamento definiamo ciò che in gergo tecnico viene chiamato RPO (Recovery Point Objective), cioè il tempo che è trascorso dall’ultima replica fino al presentarsi del disastro.
#2 Tipologia e dimensionamento del collegamento dati.
Questo elemento è fortemente correlato con il punto sopra: dipendentemente dal numero di repliche nell’arco della giornata necessarie per mettere al sicuro i tuoi sistemi, dovrai dimensionare la banda e la tipologia del collegamento tra il tuo CED ed il sito di DR.
Facciamo alcuni esempi :
Ogni giorno, i tuoi sistemi generano un volume di dati incrementali di 30 GB.
Se hai un accesso ad Internet can banda di 20 Mbps up/down, il tempo di trasferimento di questa quantità di dati è di circa 4 ore.
Se decidi di replicare una sola volta in 24 ore, facendo partire la replica alle 10 di sera, potrai in questo caso sfruttare il fatto che il tuo accesso ad Internet sarà probabilmente scarico durante le ore notturne: avrai sia il tempo di effettuare tutta la replica oltre ad avere un margine per permettere al software che effettua la replica di fare il proprio lavoro.
Ovviamente, (e questo è praticamente un obbligo in caso di progetti di DRaaS), dovrai disporre di una connessione performante, utilizzando link in fibra ottica di FTTH dedicata.
Se invece per esigenze di business continuity hai bisogno di replicare 10 GB di volume dati i dati ogni 3 ore, considera che il tempo necessarie alla replica in questi casi è di circa 1-1,5 ore, ai quali devi sommare i tempi di gestione del software.
Probabilmente durante le ore diurne, con tutti gli utenti al lavoro, il tuo accesso ad Internet sarà piuttosto carico.
Utilizzarlo anche per le repliche vuol dire allungarne i tempi, oltre che a rallentare l’accesso ed il lavoro dei tuoi utenti.
In questo caso allora meglio dedicare un accesso dati alle sole funzioni di disaster recovery.
#3 Quanto tempo è necessario per il ripristino.
E’ successo ciò che nessuno si augura.
Per un evento improvviso, il tuo CED non può più erogare i normali servizi.
Ecco la prima decisione che devi prendere: è proprio necessario dichiarare il disastro ?
Magari si tratta “solo” della perdita di uno storage o di un DB corrotto, in questo caso potrebbe essere sufficiente ripristinare i dati prelevandoli dal sito secondario.
Quindi, in caso di danno limitato, i tempi di riparazione saranno probabilmente contenuti ed inferiori al tempo necessario di ripristino dal sito secondario: in questo caso allora non sarà necessario dichiarare il disastro e sarà quindi preferibile procedere al ripristino in modo più “convenzionale”.
Per un valido progetto di Business Continuity, Il tempo di ripristino necessario (RTO Recovery Time Objective) è il parametro che a questo punto influenza tutto il processo.
Innescare una procedura di Disaster Recovery significa fare in modo che il sito secondario diventi operativo ed eroghi i servizi ai tuoi utenti, e per farlo c’è bisogno di tempo.
Quanto ? dipende anche dalla tipologia di collegamento che dovrai utilizzare.
Potrai trovarti davanti ad uno (oppure ad entrambi) di questi scenari :
- Accesso al sito secondario tramite accesso ad Internet
- Accesso al sito secondario tramite rete privata MPLS o altro.
Di questo aspetto parliamo al prossimo punto…
#4 Modalità di accesso al sito secondario
Il tuo CED è down.
I tempi di riparazione sono lunghi e difficilmente quantificabili con precisione.
Hai deciso quindi di dichiarare il disastro, attivando il sito secondario che sarà stato replicato con la frequenza che avrai precedentemente deciso.
Il sito secondario è stato attivato, le VM accesse, i collegamenti stabiliti.
Come fare a far arrivare i tuoi utenti sul sito secondario ?
Se i tuoi utenti accedono tramite MPLS, i tempi di redirect saranno piuttosto brevi.
La questione cambia invece se utilizzi servizi ai quali devi accedere tramite Internet, come ad esempio i servizi Amazon AWS, in questo caso sarà necessario riconfigurare i DNS, con tempi di propagazione anche piuttosto lunghi, sopratutto se dovranno accedere sedi, agenti o filiali estere delle tua azienda.
Chiudo…
Il tema DRaaS è particolarmente complesso… partendo da questi 4 punti potrai però iniziare a costruire una valida strategia e sfruttare a pieno i vantaggi di utilizzare il Cloud per avere un sito di DR sempre aggiornato e pronto a soccorrere il tuo business in caso di necessità.
Posso aiutarti a raggiungere questo obiettivi, contattami qui.
