Preservare i dati è la prima, e più importante forma di business continuity per le moderne organizzazioni: per questo è fondamentale un corretto approccio al disaster recovery.
Ne abbiamo quindi discusso con Alberto Fidanza, Cloud Storage & Data Services Sales Leader di Red Hat.
Secondo Fidanza, nelle aziende moderne, le cui attività sono basate sui dati e non conoscono interruzioni e poiché sempre più organizzazioni passano da data center on premise a Cloud privati, pubblici o ibridi, è importante comprendere che l’high availability (HA) non è la stessa cosa del disaster recovery (DR).
Disaster recovery, i rischi di sottovalutare la gestione della sicurezza dei dati
I costi per i periodi di inattività sono enormi e la perdita dei dati può mettere a serio rischio l’esistenza stessa delle aziende.
Fidanza spottolinea che la perdita dei dati non è causata soltanto da calamità naturali, blocchi di corrente, guasti all’hardware o errori commessi dagli utenti ma è sempre più spesso la conseguenza di problemi riscontrati con il software ed eventi nefasti correlati alla sicurezza informatica.
È quindi fondamentale adottare strategie di sicurezza e business continuity intese a ridurre al minimo i rischi di perdita dei dati e tempi di inattività per le aziende moderne.
Si tratta di un’esigenza di estrema attualità, perché i data center sono sempre più di tipo software-defined.
Inoltre, i cloud, hybrid, private o public, sono sempre più soggetti a questo tipo di minacce.
Il manager di Red Hat ha affermato che la maggior parte delle soluzioni di business continuity e disaster recovery è ancora basata su entità, appliance e array fisici.
Che non offrono la capacità di scalare in base alla quantità dei dati attualmente prodotti dalle aziende.
Per superare queste difficoltà, è necessario adottare soluzioni di BC/DR ideate appositamente per gli ambienti cloud.
Il disaster recovery deve essere visto dalle aziende come una strategia di business
Poiché la perdita dei dati e i tempi di inattività hanno un impatto diretto sulle aziende, il disaster recovery è una problematica che andrebbe discussa basandosi su criteri e obiettivi di business strategico.
A domande quali “Quanto tempo di inattività un’azienda è in grado di sopportare?” e “Quanti dati possono essere persi?” prima di causare danni irreversibili (impostando RTO e RPO) è impossibile rispondere soltanto da una prospettiva tecnica.
In breve, poiché sono coinvolte numerose tecnologie, il disaster recovery rappresenta un elemento chiave per soddisfare appieno gli obiettivi di business.
L’importanza di un adeguato piano di disaster recovery
La pianificazione del disaster recovery (DR) è necessaria per ripristinare i sistemi quando disastri naturali o causati dall’uomo colpiscono il data center principale/Region.
Recenti interruzioni del cloud pubblico suggeriscono che si deve disporre di un piano di DR, nonostante l’elevata disponibilità fornita dai fornitori di Cloud pubblico.
La pianificazione del disaster recovery dovrebbe far parte delle discussioni iniziali sulla progettazione delle applicazioni, consentendo al deployment dell’architettura di adattarsi ad eventi imprevisti.
Bisogna consentire ai team di sviluppo delle applicazioni di prendere in considerazione il DR sin da subito e non solo se vi è un audit interno o un’escalation che identifica questa lacuna fondamentale per l’azienda.
Lasciare il DR come un ripensamento successivo potrebbe portare a sfide sulla gestione delle manutenzioni delle applicazioni e non conformità con gli standard normativi e di sicurezza.
L’assenza di un piano DR può portare a perdite di fatturato e problemi di compliance nonchè potrebbe portare perdita di fiducia da parte dei clienti.
Red Hat rileva che identificare il livello di DR appropriato, fare buone scelte architetturali e utilizzare strumenti di automazione indipendenti dall’infrastruttura può ridurre i costi di manutenzione di un ambiente di DR, fornendo al contempo la resilienza per recuperare rapidamente in caso di disastro.
È inoltre importante allocare budget IT adeguati per soddisfare le aspettative di DR.
Decidere cosa è realmente business-critical.
Quando si tratta di sviluppare una strategia di DR, è importante tenere presente che non tutti i sistemi, applicazioni e dati hanno lo stesso valore critico per un’azienda.
Nella pianificazione del DR, è assolutamente necessario assegnare priorità a ciò che è più importante. È necessario stabilire quanto tempo di inattività può essere tollerato per ogni applicazione discutendone con i responsabili delle linee di business.
In questo modo, sarà possibile sapere quanto prima quali sono quelle che devono garantire una maggiore availability con minime perdite di dati. È molto probabile, infatti, che vi siano applicazioni di cui un’azienda può fare a meno per diverse ore. In questa fase, è essenziale stabilire i livelli di servizio su tutti i fronti, in modo da evitare brutte sorprese in una situazione di emergenza.
Un Piano di BC/DR è una decisione finanziaria.
Quindi le considerazioni iniziali nella definizione di un piano DR efficace sono identificare l’RPO e l’RTO di ogni singola applicazione in base ai requisiti aziendali, ai requisiti di compliance e al costo (revenue loss) di downtime.
E’ particolarmente importante sapere quando un’interruzione di un’applicazione causerà un’interruzione totale o parziale del servizio.
Un piano di DR di livello aziendale aiuterà a identificare queste dipendenze e ad assegnare i livelli DR corretti alle applicazioni.
Il ruolo chiave dell’automazione nel DR
Al fine quindi di minimizzare i costi di DR, sebbene i Cloud pubblici forniscano una flessibilità intrinseca per aumentare o diminuire la scalabilità su richiesta, riducendo la spesa in conto capitale, è importante comprendere che il DR non è integrato e che i team delle applicazioni devono implementare essi stessi un piano di DR.
L’automazione gioca un ruolo chiave nel successo di un’implementazione di DR perché, quando si verifica un disastro, il tempo di ripristino è più breve. Il tempo per ripristinare il servizio è direttamente proporzionale al potenziale revenue loss e può comportare sanzioni per il mancato rispetto dei requisiti di conformità.
L’automazione può abilitare più componenti di un sistema per l’ambiente DR in un diverso data center o Cloud region utilizzando framework IaC (Infrastructure as Code). Ciò consente di ridurre al minimo i costi e di soddisfare gli SLA di ripristino richiesti.
Peraltro, l’automazione può mettere in funzione più rapidamente l’ambiente DR secondo necessità. Può ridimensionarlo quando la regione primaria è disponibile, controllando strettamente i costi. L’automazione fornisce anche sicurezza per l’eliminazione degli interventi manuali durante le fasi di DR.
Includere il disaster recovery e l’automazione come parte iniziale della progettazione e dello sviluppo delle applicazioni aiuterà a inserire i modelli di progettazione e le Dev Ops “practice” alla creazione di applicazioni cloud native resilienti, riducendo i costi operativi e garantendo una availability costante all’applicazione.
La soluzione di Red Hat: implementare una configurazione serverless
Il Serverless è un modello di elaborazione relativamente nuovo utilizzato per la creazione e l’esecuzione di applicazioni. Senza dover gestire i server su cui viene eseguita l’applicazione. Le applicazioni in un ambiente serverless sono set di una o più funzioni eseguite su richiesta e ridimensionate dinamicamente per soddisfare la domanda senza la necessità di pianificazione della capacità.
Un modello di elaborazione Serverless può essere un modello di scelta per workloads stateless, altamente dinamici, asincroni o concorrenti.
Inoltre, il serverless si adatta bene a carichi di lavoro sporadici in cui il traffico delle richieste è imprevedibile e necessita di capacità di elaborazione dinamica. Elimina il sovraccarico della manutenzione del server e le aziende pagano solo per il tempo di elaborazione consumato.
