{"id":5882,"date":"2023-05-26T09:00:00","date_gmt":"2023-05-26T07:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=5882"},"modified":"2023-06-23T17:39:53","modified_gmt":"2023-06-23T15:39:53","slug":"disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/disaster-recovery-in-cloud-tecniche-efficaci-per-la-business-continuity\/","title":{"rendered":"Disaster Recovery in Cloud: tecniche efficaci per la Business continuity"},"content":{"rendered":"\n
Leggi Parte 2<\/a> | Leggi Parte 3<\/a><\/p>\n\n\n\n Ormai non \u00e8 pi\u00f9 una citazione, ma un mantra:<\/p>\n\n\n\n \u201cEverything fails, all the time\u201d – Werner Vogels<\/p>\n\n\n\n Questo principio ha condizionato la metodologia con cui si progetta infrastrutture in Cloud. Bisogna valutare le diverse tipologie di fallimento prima di progettare. Non tutti i disastri, per\u00f2, sono uguali. Proviamo a darne una classificazione:<\/p>\n\n\n\n Per rispondere in maniera efficace a queste tre tipologie di disastro bisogna progettare e pianificare in tre maniere diverse:<\/p>\n\n\n\n In questa serie di articoli ci concentreremo in particolare sul Disaster Recovery, dalla sua definizione, fino alle tecniche di ripristino e come l\u2019ecosistema di servizi AWS ci pu\u00f2 aiutare a garantire la continuit\u00e0 del business in qualunque situazione.<\/p>\n\n\n\n Il Disaster Recovery (DR) \u00e8 un processo fondamentale per garantire la continuit\u00e0 delle operazioni aziendali in caso di disastri informatici. Esistono diverse tecniche di DR, e tutte mirano a ripristinare le applicazioni, i dati e le infrastrutture IT il pi\u00f9 rapidamente possibile dopo un evento avverso.<\/p>\n\n\n\n In ambito Cloud, il DR \u00e8 ancora pi\u00f9 importante, poich\u00e9 le applicazioni e i dati sono ospitati in remoto su server e infrastrutture che possono essere soggette a interruzioni di servizio a causa di problemi di connettivit\u00e0, guasti hardware, attacchi informatici o disastri naturali.<\/p>\n\n\n\n Ogni volta che si affronta questo argomento e per garantire un DR efficace \u00e8 necessario partire da due acronimi che sono fondamentali per la selezione della miglior strategia di DR:<\/p>\n\n\n\n RTO <\/strong>(Recovery Time Objective<\/strong>), in questo caso la domanda a cui dobbiamo rispondere \u00e8: per quanto tempo possiamo lasciare i nostri sistemi non funzionanti prima di tornare operativi? <\/p>\n\n\n <\/p>\n\n\n\n In sintesi, il DR \u00e8 un processo fondamentale per garantire la continuit\u00e0 delle operazioni aziendali in caso di disastri informatici, e la sua efficacia dipende dall’obiettivo RTO\/RPO e dal giusto equilibrio tra consistenza, disponibilit\u00e0 e tolleranza ai guasti.<\/p>\n\n\n\n Esistono diversi approcci per il Disaster Recovery, e la scelta dipende da fattori come il budget, la criticit\u00e0 dei dati e delle applicazioni, il tempo di ripristino accettabile (RTO) e il punto di ripristino accettabile (RPO).<\/p>\n\n\n\n Tra i metodi pi\u00f9 comuni per il DR troviamo:<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Per quanto riguarda l’applicazione delle tecniche di DR in realt\u00e0 di diverse dimensioni, possiamo dire che ogni organizzazione deve scegliere il metodo pi\u00f9 adatto alle proprie esigenze e risorse. Le aziende di grandi dimensioni spesso hanno budget pi\u00f9 elevati e possono permettersi di investire in infrastrutture costose come repliche attive e in costante sincronizzazione.<\/p>\n\n\n\n Le piccole e medie imprese, invece, possono optare per soluzioni pi\u00f9 economiche e flessibili, come la replica dei dati nel cloud.<\/p>\n\n\n\n In sintesi, la scelta del metodo di Disaster Recovery dipende dalle esigenze dell’organizzazione, dal budget e dalla criticit\u00e0 dei dati e delle applicazioni.<\/p>\n\n\n\n Fin qui sembra tutto chiaro e lineare. Durante la replica dei dati per il disaster recovery, per\u00f2, ci sono diversi fattori tecnici che devono essere presi in considerazione e che possono condizionare RPO\/RTO. Tra i principali si annoverano:<\/p>\n\n\n\n Ovviamente la coperta \u00e8 sempre troppo corta e dobbiamo essere consapevoli che il disaster recovery deve necessariamente essere un compromesso. A sostegno di questo vorrei riportare un teorema fondamentale per i sistemi distribuiti: il CAP theorem.<\/p>\n\n\n\n Il teorema CAP<\/strong> (Consistency, Availability, Partition tolerance)<\/strong>, che riguarda normalmente i sistemi di database distribuiti, pu\u00f2 essere applicato in modo analogo al contesto del Disaster Recovery (DR), sebbene con alcune considerazioni aggiuntive. Noto anche come teorema di Brewer, afferma che \u00e8 impossibile per un sistema informatico distribuito fornire simultaneamente tutte e tre le seguenti garanzie:<\/p>\n\n\n\n Quando si applica il teorema CAP al DR, spesso si fa una scelta consapevole per bilanciare la coerenza, la disponibilit\u00e0 e la tolleranza alla partizione in base alle esigenze specifiche del business e alle conseguenze delle interruzioni. Ad esempio, in un ambiente di ripristino prioritario, si potrebbe dare priorit\u00e0 alla disponibilit\u00e0, sacrificando temporaneamente la coerenza dei dati. Al contrario, in un ambiente altamente sensibile alla coerenza, si potrebbe priorizzare la coerenza sacrificando temporaneamente la disponibilit\u00e0.<\/p>\n\n\n\n Tutto questo solo per capire come si fa disaster recovery, come si passa da produzione al nostro sito secondario. Ma c\u2019\u00e8 un punto della questione che \u00e8 essenziale e che viene trascurato sempre da tutti, ovvero progettare come si torna in produzione dopo che l\u2019evento disastroso \u00e8 rientrato<\/strong>. Insomma, ci si dimentica sempre di definire come si \u201ctorna indietro\u201d.<\/p>\n\n\n\n Anche in questo caso \u00e8 importante seguire un processo ben pianificato per garantire una transizione sicura e senza intoppi. <\/p>\n\n\n\n Prima di tutto bisogna fare una valutazione del ripristino. Prima di tornare alla produzione normale, \u00e8 necessario valutare attentamente lo stato del sistema e dell’ambiente di produzione. Verificare che il problema o l’evento di interruzione sia stato risolto completamente e che l’ambiente sia pronto per il ripristino.<\/strong> In questo caso \u00e8 fondamentale avere dei buoni sistemi di monitoring per rilevare eventuali anomalie o problemi. L\u2019utilizzo di strumenti di monitoraggio e avvisi \u00e8 utile per identificare e risolvere tempestivamente qualsiasi problema che possa verificarsi durante la transizione al ritorno in produzione. Repetita iuvant: il monitoring<\/strong> \u00e8 fondamentale anche post-ripristino<\/strong> per consentirci di individuare eventuali problemi residui o effetti collaterali che potrebbero emergere e intervenire tempestivamente per risolverli.<\/p>\n\n\n\n Non basta che l\u2019ambiente di produzione sia finalmente disponibile, ma vanno eseguiti test e convalide. Ci\u00f2 pu\u00f2 includere test funzionali, test di carico e altri test appropriati per garantire che tutto funzioni correttamente come previsto. Verificare che i dati siano coerenti e integri.<\/p>\n\n\n\n In alcuni casi, potrebbe essere necessario eseguire un rollback delle modifiche apportate durante il processo di DR. Questo pu\u00f2 coinvolgere il ripristino delle configurazioni, delle modifiche applicative o delle versioni precedenti dei dati. \u00c8 importante pianificare il rollback in modo da minimizzare l’impatto sulle operazioni e garantire la coerenza dei dati.<\/p>\n\n\n\n Da non sottovalutare nelle situazioni emergenziali \u00e8 la comunicazione con gli utenti e gli stakeholder coinvolti<\/strong>. Le persone coinvolte devono essere rese consapevoli delle modifiche apportate e dei passaggi necessari per tornare alla produzione normale. <\/p>\n\n\n\n Per rendere edotte le persone coinvolte \u00e8 necessario documentare le nostre procedure, ovvero registrare tutti i passaggi, le modifiche apportate e le azioni intraprese durante il processo di DR. Ci\u00f2 aiuter\u00e0 a ricostruire l’evento di interruzione e ad analizzare in seguito per migliorare le future strategie di DR.<\/p>\n\n\n\n Siamo giunti al termine della prima tappa del nostro viaggio nel Disaster Recovery in Cloud. Dopo averne definito i macro concetti e averne compreso la dinamiche, \u00e8 il momento di entrare nel vivo dell\u2019implementazione delle tecniche di DR in scenari aziendali complessi.<\/p>\n\n\n\n Cominceremo approfondendo nel prossimo articolo le migliori tecniche di DR per i contesti di tipo ibrido on-prem to Cloud per poi parlare di DR per la Business Continuity in ambito Cloud-to-Cloud nel terzo articolo della nostra mini-serie.<\/p>\n\n\n\n Pronti?<\/p>\n\n\n\n Ci vediamo tra 14 giorni su Proud2beCloud!<\/p>\n\n\n\n Leggi Parte 2<\/a> | Leggi Parte 3<\/a><\/p>\n\n\n\n\n
\n
\n
<\/strong>RPO definisce ogni quanto tempo replicare i dati per assicurarsi il giusto lasso di tempo tra l\u2019ultima replica e l\u2019evento disastroso. Pi\u00f9 \u00e8 frequente \u00e8 la replica meno sar\u00e0 l\u2019eventuale perdita massima di dati.<\/li>\n<\/ul>\n\n\n\n
<\/strong>Il concetto di RTO si riferisce quindi al tempo che intercorre tra il disastro e il completo ripristino dei sistemi.<\/p>\n\n\n\n\n
\n
Il Teaorema CAP<\/h3>\n\n\n\n
\n
Conclusioni<\/h2>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n