Arda Solutions s.r.l. | The Informal Blog

DisasterRecovery-300x265

Scegliere di prendere in considerazione il cloud nel processo di definizione del piano di Disaster Recovery può portare con se molti vantaggi: resilienza e affidabilità intrinseca in primis, oltre a storage a “basso costo” e potenza computazionale su richiesta, ma anche svantaggi di varia natura, la maggior parte dei quali devono essere ben analizzati e mitigati con l’adozione di una strategia su misura. Applicazioni resilienti, sincronizzazioni dei dati, affidabilità della connettività etc… Sono solo alcuni degli aspetti da considerare nell’analisi

La domanda è sempre la stessa: Quanto vale costa riprendersi da un disastro inaspettato? Sia esso un interruzione di corrente oppure un colpo maldestro durante un aggiornamento, come posso eliminare mitigare molto la possibilità di riprendere in tempi “certi” il mio business? In passato, la necessità portava prima o poi ad acquistare dei server in housing su cui definire le proprie politiche di DR oppure, per i più fortunati, a creare un nuovo sito di DR su cui poter contare. Il Cloud ha cambiato e sta cambiando i giochi in molti modi: Non sono più obbligato ad un investimento molto grande e calibrato nel tempo ma posso acquistare solo “quello che mi serve quando mi serve”, delego la gestione dell’infrastruttura secondaria (leggi: il sito di Disaster Recovery) al mio partner che ha una partnership con uno o più CSP che mi garantiscono uno SLA alto, un operatività “decente”, e un “assicurazione” al mio business competitiva.

Tutto bello sulla carta ma, all’atto pratico, è necessario definire bene la strategia e partire dal presupposto che il cloud non è la panacea di tutti i mali e che, per una strategia ben riuscita, ci vuole un buon piano.

Innanzitutto, è necessario definire “quanto siamo disposti a perdere” perché l’RPO (la differenza di tempo fra il dato creato e il dato replicato) esprime proprio questa nostra disponibilità. Una connettività scarsa può essere mitigata da un sito di staging, cosi come una DML che muove parecchi dati può essere gestita non solo tramite log shipping ma anche con altri sistemi che limitino il trasferimento e ottimizzino riducano il più possibile il gap fra il sito di produzione e quello di DR.

L’altro aspetto fondamentale da considerare riguarda la tolleranza accettabile per “tornare operativi”. Questa tolleranza, espressa dall’RTO (Recovery Time Objective), ci da una misura comparabile di quanto ci costa “restare fermi” (business down) e ci da un ottima unità di misura riguardo all’investimento corretto per mitigare il più possibile questo tempo. Individuare le macchine critiche che devono essere replicate sul sito di DR, i database di cui avere immediata disponibilità etc

Avere il tutto in cloud da un ottimo vantaggio: Non devo ridondare il “ferro” da gestire in casa, non devo comprare il doppio della roba quando me ne serve la metà della metà (cioè: la metà del mio sito produttivo), posso ripristinare e collocare il mio DR in tutti i datacenter in cui il vendor me ne da disponibilità (il DR del DR?) …

Dall’altra parte però c’è “il costo occulto”: se non configurato bene il mio DR in cloud crescerà con estensioni simili al mondo reale che però, nel mondo cloud, si pagano e anche salate (tenere acceso un server in replica con 200G di dati quando viene alimentato poche volte al giorno e lo spazio reale sono 20G è un ottimo esempio di come far costare molto un DR in cloud). Quindi, è bene fornirsi di politiche di spegnimento programmato e sync con espansione dei dischi a necessità (ormai ogni vendor ha le sue API con cui giocare). Un altro aspetto da tenere sotto controllo è: “portare fuori la nostra infrastruttura”: ne avevamo già parlato di quanto, per il cloud, la sicurezza la facesse da padrona, e ci aggiungo anche che, se la vostra connettività non brilla (e in Italia normalmente non brilla) questo è un costo che dovrete tenere sotto controllo.

In fine, la vostra infrastruttura (dai server, allo storage arrivando fino alle applicazioni) deve essere in grado di “estendersi” verso il cloud, e la definizione della corretta strategia passa anche dalla selezione delle componenti interdipendenti per avere una replica corretta e riprendere il vostro business direttamente dal cloud mentre voi risolvete i disastri che vi sono successi.

Annunci
%d blogger hanno fatto clic su Mi Piace per questo: