Tecniche di alta disponibilità con Microsoft Azure

di , in Replica,

Con l'avvento della virtualizzazione e del cloud, il mondo informatico ha subito una grande rivoluzione che ha cambiato le architetture software e ha permesso di ottenere flessibilità e affidabilità nelle soluzioni sviluppate, rendendo tutto questo alla portata di tutti. Indipendente dal dover ospitare un piccolo applicativo o una grande soluzione, a noi sviluppatori è concesso godere di uno standard minimo in termini di sicurezza e qualità dell'ambiente. I data center che sfruttiamo sono posizionati in zone strategiche, sono sorvegliati, dispongono di gruppi di continuità, seguono procedure e si rinnovano nell'hardware, il tutto in maniera del tutto trasparente. Tutte queste comodità hanno consentito di conseguenza di partire da servizi Infrastructure as a Service (IaaS) fino ad arrivare a quelli Platform as a Service (Paas) o Software as a Service (SaaS), quest'ultimi più destinati all'utente finale.

La piattaforma Microsoft Azure offre tutto questo e gode di moltissime certificazioni standard proprio per tutelare il più possibile i nostri dati e i nostri servizi. Quando usiamo i servizi offerti, stipuliamo un Service level agreement (SLA) che a seconda di quello scelto offre una percentuale minima di funzionamento che va in genere dal 99,9% fino al 99,99% di uptime. A questo indirizzo troviamo una lista delle SLA previste e da ciò si evince che i nostri applicativi potrebbero subire un down di pochi minuti fino ad un massimo di 8 ore, in un anno. Microsoft effettua aggiornamenti alle proprie piattaforme con regolarità e non sempre tutto procede correttamente, oppure si presentano disservizi ancora più casuali e imprevedibili. Se la SLA non viene rispettata, inoltre, quindi il downtime prosegue per più tempo, è nostro compito segnalare il problema e, dopo aver fornito adeguatamente le prove, ottenere un rimborso del 10%/25% a seconda del tempo. Purtroppo, come possiamo vedere a questo indirizzo, i problemi si verificano ed in passato si sono verificati down di servizi importanti.

Fault tolerance, fail over e disaster recovery

Indipendentemente dalla causa del disservizio e del tempo, è importante che teniamo in considerazione questo problema e valutare se il business che la nostra soluzione sostiene può subire una perdita economica ben più maggiore rispetto ad un eventuale rimborso fornito da Microsoft e in tal caso prevedere un'architettura che minimizzi o azzeri l'impatto di un disservizio. Parliamo quindi di capacità di fault tolerance quando mettiamo in atto architetture e servizi che sappiamo reggere in parte o totalmente l'avvento di un disservizio. Sebbene gli standard di Microsoft Azure sono notevolmente alti e potrebbero bastare per molti scenari, vi sono situazioni in cui distribuire la nostra soluzione su una sola region non è sufficiente. Si possono verificare situazioni impreviste di bassa gravità che possono coinvolgere l'hardware, in termini di rete o del parco macchine, o che possono coinvolgere il software: un update della piattaforma che non va a buon fine o un errore umano, per citare un esempio già verificatosi. Per mitigare problemi che possono derivare dalla normale evoluzione della piattaforma, tutto l'ecosistema di farm è composto da paired region, cioè da region contrapposte in una certa area geografica, dove siamo certi che Microsoft non effettua mai aggiornamenti contemporanei. Nel caso dell'Europa, per esempio, West Europe e North Europe sono due paired region.

Di fronte a queste possibili problematiche è chiaro che l'unico modo per alzare il livello di affidabilità consiste nel distribuire le nostre soluzioni su più regioni, almeno tra due paired. Nel momento in cui adottiamo questa strategia possiamo dividere il carico di lavoro tra più regioni o applicare un fail over in caso di necessità, cioè uno switch che ridiriga tutto il carico di lavoro da una regione primaria ad una secondaria, invertendone i ruoli. Questa apparente facile soluzione nasconde in realtà problematiche in parte impossibili da risolvere. Se nel lato computazionale che in genere lavora in modo stateless è facile poter mandare utenti su un altro App Service, non è altrettanto banale la questione della persistenza dei dati. È raro poter dividere i dati in regioni senza che questi debbano essere condivisi tra di esse e siamo quindi obbligati a scegliere una regione che svolge un ruolo primario replicando costantemente i dati sul secondario. Data la distanza fisica è inevitabile, per quanto possa essere efficiente l'infrastruttura, perdere qualche dato in caso di problemi.

Nelle valutazioni da fare quindi dobbiamo valutare il Recovery Time Objective (RTO), cioè quanto tempo di disservizio parziale o totale siamo disposti ad accettare in modo da capire quando tempo abbiamo a disposizione per ristabilire la situazione. Potrebbe essere sufficiente, grazie a script e a ARM (Azure Resource Manager) un semplice installazione, automatica o manuale, verso una seconda regione. Oltre a questo dobbiamo valutare il Recovery Point Objective (RPO), cioè quanti dati siamo disposti a perdere tra un backup e il loro recupero. Alla ovvia risposta "nessuna perdita" occorre rispondere obiettivamente perché una soluzione a tolleranza zero potrebbe costare molto.

L'autore di questo articolo vuole tranquillizzare il lettore sul fatto che la perdita di dati è una possibilità che si può presentare solo in caso di calamità naturali, sebbene le server farm siano già poste in posizioni strategiche da questo punto di vista. Fino ad ora non si è mai presentato un caso di questo tipo e i dati sono sempre stati recuperabili. Ad ogni modo è bene sempre avere un piano di disaster recovery che preveda una procedura manuale o automatizzata, sulla base dei due indici indicati in precedenza, per il recupero dei dati e il ripristino della nostra soluzione.

Nei prossimi paragrafi vogliamo affrontare, a seconda dei servizi PaaS Azure più comuni offerti, quali strumenti abbiamo a disposizione per ottenere alta affidabilità e fail over permettendoci di ottenere down di servizi prossimi allo zero.

5 pagine in totale: 1 2 3 4 5
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

Tecniche di alta disponibilità con Microsoft Azure
| Condividi su: Twitter, Facebook, LinkedIn, Google+

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti