Utilizzando Aws le aziende possono implementare soluzioni avanzate di Business Continuity e Disaster Recovery, offrendo alle loro applicazioni livelli di protezione e disponibilità difficilmente realizzabili nelle tradizionali infrastrutture on-premises.
A raccontarci nel dettaglio l’articolato e approfondito approccio di Aws su questa fondamentale tematica è Antonio D’Ortenzio, Manager Solutions Architecture Aws.
L’approccio di AWS si basa su due livelli: la sicurezza e la protezione con le quali i data center vengono costruiti e operati e la possibilità che i clienti hanno di fare leva su queste caratteristiche per costruire soluzioni personalizzate e sofisticate, raggiungendo così i livelli desiderati di recupero del loro dato e di tempo di ripristino del loro servizio.
Questo secondo aspetto è ulteriormente rafforzato dal fatto che molti servizi Aws sono disegnati, realizzati e operati per raggiungere elevati livelli di disponibilità; per esempio, AWS applica ogni possibile best practice operativa per far sì che il servizio Amazon EC2 (ovvero il servizio che opera le macchine virtuali su Aws) sia disponibile in ogni Aws Region con una percentuale di uptime mensile del 99,99% come minimo.
Descriviamo innanzitutto il primo livello: al fine di offrire la massima resilienza contro i disservizi, AWS costruisce i suoi data center posizionandoli in molte regioni geografiche (le AWS Regions) e molte Availability Zones all’interno di ciascuna Region.
Nel caso della Region Aws in Italia, si tratta di tre Availability Zone.
Una Availability Zone (AZ) consiste di uno o più data center provvisti di alimentazione, rete e connettività ridondati. Tutte le AZ in una Aws Region sono interconnesse tramite una rete a elevata ampiezza di banda, bassa latenza e traffico crittografato. Le AZ sono fisicamente separate tra loro da una distanza significativa di molti chilometri, pur restando nel raggio di 100 km l’una dall’altra.
Pertanto le AZ di una Aws Region hanno profili di rischio diversi fra loro e permettono ai nostri clienti di partizionare le proprie applicazioni raggiungendo isolamento e protezione da problemi come blackout, fulmini, terremoti, allagamenti o incendio.
Aws usa consistentemente gli stessi hardware e software per costruire ed operare ognuna delle Region; in questo modo tutti i clienti del globo beneficiano di una piattaforma Cloud la cui offerta di servizi è ritenuta sufficientemente sicura per eseguire carichi di lavoro ad alta sensibilità (si pensi a banche globali, associazioni governative internazionali, organizzazioni militari).
La costruzione e la operatività quotidiana di una Aws Region e delle sue Availability Zones sono caratterizzate da un insieme di aspetti di fondamentale importanza: la progettazione sicura, piani di Business Continuity e Disaster Recovery, la regolamentazione degli accessi fisici, il monitoraggio e l’archiviazione dei log, la sorveglianza e il rilevamento, la gestione dei dispositivi, i sistemi operativi di supporto, la manutenzione dell’infrastruttura, la governance e la gestione dei rischi. Questi aspetti sono tutti documentati in dettaglio a questo link.
Parliamo ora del secondo livello: sulla base di una piattaforma costruita e operata con le caratteristiche di sicurezza e disponibilità sopra descritte, ogni cliente può definire procedure che abilitino, in caso di disastro, il recupero veloce dei dati persi in modo da assicurare continuità al proprio business.
In particolare per applicazioni critiche, minimizzare il tempo di recupero e la perdita dei dati e, allo stesso tempo, ottimizzare le spese capitali on-premises è una sfida complessa. Con l’obiettivo di andare incontro a questo trade-off in base alle esigenze specifiche di ciascuna azienda (e di ciascuna applicazione), Aws offre una gamma di possibilità per implementare soluzioni di Disaster Recovery e Business Continuity.
Tale gamma si muove lungo l’asse crescente dei benefici ottenibili in termini di riduzione del tempo di recupero e di perdita del dato e, conseguentemente, dei costi associati.
In tema di responsabilità, business continuity e disaster recovery Aws suggerisce alle aziende italiane che sono nel cloud o che stanno pensando di adottarlo di seguire una sequenza di passi tanto lineare quanto efficace, di seguito descritta.
Si parte dal definire, per ogni carico di lavoro, gli obiettivi di recupero dal disservizio e gli obiettivi di recupero del dato. Questi concetti sono rispettivamente definiti come Recovery Time Objective (RTO) e Recovery Point Objective (RPO).
Ovvero, le aziende determinano per i loro workload il tempo massimo accettabile fra l’interruzione e il ripristino del servizio (RTO) e il tempo massimo accettabile fra l’ultimo timestamp in cui il dato è ritenuto consistente e l’interruzione del servizio (RPO).
Il secondo passo è quello di strategie di recovery che puntino a realizzare gli obiettivi di RTO e RPO definiti nel passo precedente.
Aws propone le seguenti strategie che possono essere tutte implementate sia in modalità Multi-Region (ovvero utilizzando più di una Aws Region) che, più frequentemente, Multi-AZ (ovvero utilizzando le AZ di una stessa Region, soprattutto in casi in cui ci siano requisiti di residenza del dato su uno specifico territorio).
Le strategie vengono di seguito elencate in ordine crescente di complessità e costo e decrescente di RTO e RPO.
La prima tipologia di soluzioni fa leva su approcci di “Backup & Restore” che si avvalgono delle caratteristiche di disponibilità e durevolezza dei servizi Storage AWS quali Amazon S3 e Amazon Storage Gateway; è adatta a casi d’uso a bassa priorità, è associata a quantità di dati persi (RPO) e tempi di ripristino (RTO) stimabili nell’ordine di ore e ha costi bassi.
La seconda tipologia è solitamente etichettata come “Pilot Light”, si basa sulla possibilità di tenere online sulla Region o AZ di Disaster Recovery soltanto le risorse necessarie alla replica del dato (tipicamente Storage) e far partire e scalare le risorse di tipo Compute soltanto a fronte di un evento di disastro; questa strategia può offrire RPO nell’ordine dei minuti e RTO nell’ordine di ore a fronte di costi lievemente più alti che nel caso precedente.
La terza tipologia è riferita al paradigma del “Warm StandBy”, utilizza una combinazione di risorse Compute e Storage Aws (caratterizzate dai loro aspetti intrinseci di affidabilità e scalabilità) mantenute online ma dimensionate con specifiche inferiori a quelle della Produzione, pronte a effettuare uno scale-up in caso di disastro; questa strategia può offrire RPO nell’ordine dei secondi e RTO nell’ordine di minuti.
L’ultimo livello è rappresentato dalle soluzioni di tipo “Hot StandBy” o “Multi-site Active-Active” che si adattano ad applicazioni Business Critical, implementano logiche di replica sincrona del dato, mantengono il sito di DR online e dimensionato in maniera identica alla Produzione, in modo da realizzare un Auto-Failover Multi-Site su piattaforma Aws a fronte del disastro; questa strategia offre RPO near-zero e RTO potenzialmente molto vicino allo zero.
Una volta definito il modello ideale per ogni workload, la sequenza di passi proposta da Aws propone di testare l’implementazione del Disaster Recovery al fine di validarne la funzionalità e il rispettivo degli obiettivi prefissati.
Un ulteriore step che può essere percepito come insidioso è la gestione dei cambiamenti di configurazione delle immagini dei server sul sito primario e della necessità di riflettere tali cambiamenti sul sito di DR: Amazon Web Services offre un valido aiuto anche in questo, attraverso l’utilizzo combinato di servizi quali Aws Config e CloudFormation che hanno la capacità di monitorare continuamente e registrare di conseguenza i cambiamenti rilevati.
L’ultimo step è quello che consiste nell’automazione del recovery: sono disponibili tool Aws e di terze parti che aiutano in questo.
Ad esempio, a supporto dei vari scenari di implementazione delle soluzioni di Disaster Recovery e Business Continuity, Awsmette a disposizione un potente strumento: CloudEndure Disaster Recovery.
Le aziende possono utilizzare CloudEndure Disaster Recovery per proteggere i database più importanti, tra cui Oracle, MySQL e SQL Server, o anche applicazioni enterprise come SAP. CloudEndure Disaster Recovery replica continuamente le macchine virtuali e il loro storage (compresi sistema operativo, configurazione dello stato di sistema, database, applicazioni e file) in un’area di staging a basso costo di un account Aws di proprietà del cliente e nella Regione da essi designata. In caso di disastro, si richiederà a CloudEndure Disaster Recovery di lanciare automaticamente tutte le macchine necessarie (anche migliaia) e queste verranno istanziate nell’arco di pochi minuti.
Grazie alla capacità di replicare le macchine in un’area di staging a basso costo e alla possibilità di lanciare on-demand le macchine necessarie in caso di disastro, CloudEndure Disaster Recovery è in grado di ridurre sensibilmente i costi delle infrastrutture destinate al Disaster Recovery.
Non vanno infine trascurate le possibilità di customizzazione offerte dalle soluzioni dei nostri Partner e disponibili sull’Aws Marketplace.
