Tecniche di alta disponibilità con Microsoft Azure
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.
Contenuti dell'articolo
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Eseguire query manipolando le liste contenute in un oggetto mappato verso una colonna JSON
Utilizzare EF.Constant per evitare la parametrizzazione di query SQL
Eseguire operazioni sui blob con Azure Storage Actions
Sfruttare al massimo i topic space di Event Grid MQTT
Utilizzare Azure AI Studio per testare i modelli AI
Cambiare la chiave di partizionamento di Azure Cosmos DB
Potenziare Azure AI Search con la ricerca vettoriale
Migrare una service connection a workload identity federation in Azure DevOps
Utilizzare la versione generica di EntityTypeConfiguration in Entity Framework Core
Applicare un filtro per recuperare alcune issue di GitHub
Modificare i metadati nell'head dell'HTML di una Blazor Web App
Definire stili a livello di libreria in Angular
Top Ten Articoli
- Realizzare una Progressive Web Application con Blazor e ASP.NET Core
di Giampaolo Tucci - Gestire le chiamate a servizi esterni in ASP.NET Core e Blazor tramite Polly
di Morgan Pizzini - Usare gRPC come infrastruttura per i nostri servizi web
di Morgan Pizzini - Abilitare e gestire il prerendering nelle applicazioni Blazor WebAssembly
di Marco De Sanctis - Creare API GraphQL con ASP.NET Core e HotChocolate
di Moreno Gentili - Le novità di Blazor in .NET 6.0
di Morgan Pizzini - Blazor e il pattern Model-View-ViewModel
di Giampaolo Tucci - Le novità in ASP.NET Core e Blazor con .NET 7
di Morgan Pizzini - Introduzione a Blazor WebAssembly
di Marco De Sanctis, Moreno Gentili - Le novità di ASP.NET Core 5
di Marco De Sanctis
Articoli via e-mail
Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!
In primo piano
I più letti di oggi
In evidenza
- Recuperare App Service cancellati su Azure
- Utilizzare la classe Lock per acquisire un lock
- Escludere alcuni file da GitHub Secret Scanning
- Creare una libreria CSS universale - Rotazione degli elementi
- Aggiornare a .NET 9 su Azure App Service
- Gestire eccezioni nei plugin di Semantic Kernel in ASP.NET Core Web API
- Utilizzare il metodo CountBy di LINQ per semplificare raggruppamenti e i conteggi
- Eseguire script pre e post esecuzione di un workflow di GitHub