<\/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\nRTO <\/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? <\/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<\/p>\n\n\n
\n
Courtesy of AWS (https:\/\/aws.amazon.com\/it\/blogs\/architecture\/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud\/)<\/figcaption><\/figure><\/div>\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
\nBackup and Restore: questa \u00e8 una delle tecniche pi\u00f9 comuni di disaster recovery. Coinvolge il regolare backup dei dati critici e dei sistemi, che vengono successivamente ripristinati in caso di interruzione. Si creano copie dei dati e delle applicazioni su un supporto separato, come dischi rigidi esterni o servizi di archiviazione cloud. Nel caso di un disastro, i dati vengono recuperati dal backup e ripristinati sui sistemi riparati o sostituiti.<\/li>\n\n\n\n Pilot Light: la tecnica del “Pilot Light” coinvolge la creazione di un’infrastruttura di base, essenziale per far funzionare le applicazioni critiche. Si tratta di avere un ambiente di backup parzialmente configurato, che pu\u00f2 essere rapidamente scalato e attivato in caso di emergenza. Di solito, vengono replicati solo i componenti chiave del sistema, mentre il resto dell’infrastruttura viene creato al momento del ripristino.<\/li>\n\n\n\n Warm Standby: la tecnica del “Warm Standby” coinvolge la creazione di una replica dell’ambiente di produzione, in modo che sia pronto per essere attivato in caso di emergenza. L’ambiente di standby viene mantenuto aggiornato con i dati e le configurazioni pi\u00f9 recenti, ma i servizi non vengono eseguiti in tempo reale. Quando si verifica un disastro, il sistema di produzione viene interrotto e il sistema di standby viene attivato per riprendere le operazioni.<\/li>\n\n\n\n Multi-site: la tecnica del “Multi-site” coinvolge la distribuzione dei sistemi e dei dati su pi\u00f9 sedi geograficamente distinte. Le sedi possono essere situate in aree separate, consentendo di evitare che un singolo evento danneggi tutte le infrastrutture contemporaneamente. In caso di disastro, il traffico e i servizi possono essere reindirizzati verso le sedi alternative per mantenere la continuit\u00e0 delle operazioni.<\/li>\n<\/ol>\n\n\n\n<\/p>\n\n\n
\n
Courtesy of AWS (https:\/\/aws.amazon.com\/it\/blogs\/architecture\/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud\/)<\/figcaption><\/figure><\/div>\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
\nLatenza: la latenza \u00e8 il ritardo temporale tra la scrittura dei dati nel sistema di produzione e la loro replica nel sito di ripristino. \u00c8 importante valutare la latenza per garantire che i dati siano replicati in modo tempestivo e che non si verifichino perdite di dati significative in caso di interruzione.<\/li>\n\n\n\n Consistenza: \u00e8 essenziale garantire che i dati replicati siano coerenti<\/strong> e integri<\/strong>. Ci\u00f2 significa che i dati devono essere replicati in un ordine coerente e che le operazioni di scrittura devono essere applicate in modo consistente su entrambi i siti. La mancanza di coerenza dei dati potrebbe portare a risultati imprevisti o alla perdita di dati.<\/li>\n\n\n\nScalabilit\u00e0: durante la replica dei dati, \u00e8 importante considerare la capacit\u00e0 di gestire volumi di dati crescenti nel tempo. La soluzione di replica dovrebbe essere in grado di scalare in modo efficiente per gestire l’aumento delle dimensioni dei dati senza compromettere le prestazioni complessive.<\/li>\n\n\n\n Sicurezza: la sicurezza dei dati \u00e8 fondamentale durante la replica per il disaster recovery. I dati replicati devono essere protetti da accessi non autorizzati e da minacce alla sicurezza. Ci\u00f2 pu\u00f2 richiedere l’implementazione di meccanismi di crittografia, controlli di accesso adeguati e misure di protezione fisica sia nel sito di produzione che in quello di ripristino.<\/li>\n\n\n\n Test e verifica: \u00e8 importante eseguire regolarmente test e verifiche per garantire che il processo di replica dei dati funzioni correttamente e che i dati siano ripristinabili in modo efficace. I test di ripristino dei dati possono aiutare a identificare eventuali problemi o lacune nel processo e consentono di apportare le necessarie correzioni.<\/li>\n\n\n\n Automazione: l\u2019automazione della replica dei dati pu\u00f2 semplificare il processo e ridurre gli errori umani. L’implementazione di strumenti e processi automatizzati pu\u00f2 consentire di gestire in modo efficiente la replica dei dati, migliorando la coerenza e l’affidabilit\u00e0 complessiva.<\/li>\n\n\n\n Capacit\u00e0 di ripristino: durante la replica dei dati, \u00e8 importante valutare la capacit\u00e0 di ripristinarli nel sito di destinazione. Ci\u00f2 pu\u00f2 richiedere l’implementazione di procedure di ripristino adeguate, la disponibilit\u00e0 di risorse hardware e software consone e la capacit\u00e0 di testare e verificare il processo di ripristino.<\/li>\n<\/ul>\n\n\n\nOvviamente 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 Teaorema CAP<\/h3>\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\nCoerenza (Consistency): la coerenza dei dati nel contesto del DR si riferisce alla garanzia che i dati replicati siano coerenti tra il sito di produzione e il sito di ripristino. In altre parole, i dati replicati dovrebbero riflettere le ultime modifiche effettuate nel sistema di produzione. Tuttavia, durante un evento di interruzione e durante il ripristino, potrebbe essere accettato un breve periodo di inconsistenza dei dati tra i due siti per garantire la continuit\u00e0 operativa. Pertanto, il DR potrebbe sacrificare temporaneamente la coerenza a breve termine per garantire la disponibilit\u00e0 e la tolleranza alla partizione.<\/li>\n\n\n\n Disponibilit\u00e0 (Availability): l’obiettivo principale del DR \u00e8 garantire la disponibilit\u00e0 dei servizi e dei dati critici in caso di interruzione. Ci\u00f2 significa che il sistema di ripristino dovrebbe essere in grado di fornire servizi essenziali in modo tempestivo, anche se il sito di produzione \u00e8 compromesso. La disponibilit\u00e0 nel contesto del DR pu\u00f2 essere ottenuta sacrificando la coerenza dei dati a breve termine o utilizzando tecniche come il ripristino da backup o l’utilizzo di risorse di ripristino dedicate.<\/li>\n\n\n\n Tolleranza alla partizione (Partition tolerance): la tolleranza alla partizione nel contesto del DR \u00e8 fondamentale. Si riferisce alla capacit\u00e0 del sistema di continuare a funzionare anche quando si verificano interruzioni o partizioni nella comunicazione tra il sito di produzione e il sito di ripristino. La replica dei dati e delle risorse in siti separati geograficamente contribuisce a garantire la tolleranza alla partizione. In caso di interruzione della comunicazione tra i siti, il sistema di ripristino dovrebbe essere in grado di operare autonomamente fino a quando la comunicazione viene ripristinata.<\/li>\n<\/ol>\n\n\n\nQuando 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\nAnche 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\nNon 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\nPer 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
Conclusioni<\/h2>\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\nAbout Proud2beCloud<\/h4>\n\n\n\n Proud2beCloud \u00e8 il blog di beSharp<\/a>, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione pi\u00f9 all’avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!<\/p>\n","protected":false},"excerpt":{"rendered":"Leggi Parte 2 | Leggi Parte 3 Ormai non \u00e8 pi\u00f9 una citazione, ma un mantra: \u201cEverything fails, all the […]<\/p>\n","protected":false},"author":5,"featured_media":5905,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[650,654],"yoast_head":"\n
Disaster Recovery in Cloud: tecniche efficaci per la Business continuity - Proud2beCloud Blog<\/title>\n \n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n \n \n \n \n \n \n\t \n\t \n\t \n