Esistono molti servizi che vengono esposti sul web, come ad esempio:
- API
- Siti web
- Software gestionali
- Ecc.
Alcuni di questi servizi svolgono compiti secondari o comunque non vitali e se si dovesse verificare un problema non sarebbe un dramma che il servizio non sia raggiungibile per 15 minuti, nel frattempo, che viene risolto il problema.
Per altri servizi, invece, 15 minuti di down possono causare la differenza tra la chiusura o il successo dell’azienda o addirittura fra la vita e la morte di persone, pensiamo ad esempio ai software utilizzati negli ospedali, magari per gestire macchinari per i pazienti, in questi casi si parla di sistemi mission critical.
È proprio per i sistemi mission critical che nasce l’esigenza di una configurazione al livello di codice e infrastruttura che garantisca un uptime molto vicino al 100% in cui deve essere garantito che in nessun caso il sistema vada offline, questo è quello che chiamiamo sistema in alta disponibilità (High Availability, HA).
Il setup di un sistema di questo tipo è in genere abbastanza complesso e richiede un notevole lavoro architetturale a livello di software e di infrastruttura cloud per far sì che in nessun caso si possa verificare un’interruzione di servizio.
È doveroso specificare che con il termine “in nessun caso” si intende veramente e letteralmente in nessun caso, le casistiche da tenere in considerazione sono molte e includono ad esempio:
- Blackout locali, regionali o nazionali;
- Terremoti o maremoti anche di portata nazionale;
- Malfunzionamento di una macchina server o dell’intero datacenter;
- Incendio del datacenter;
- Ecc.
In sostanza si tratta di sviluppare una strategia che preveda lo switch in live time ad un altro gruppo di macchine poste in un altro datacenter localizzato in un altro continente rispetto al primario in caso di necessità.
In questo modo, come si vede dall’immagine, le pagine web visualizzate dagli utenti verranno dapprima servite da uno o più server situati in un datacenter primario, nel momento in cui si rilevasse un problema o un rallentamento delle macchine in quel datacenter, un bilanciatore di carico (load balencer) inizia a non inoltrare più le richieste a quel datacenter ma al datacenter secondario, in caso ci fosse un problema anche con quello passa al terziario, ecc.
Il datacenter primario, secondario ed eventualmente terziario possono anche essere delle server farm all’interno dello stesso datacenter purché in diversi availability domain (ovvero sezioni isolate nel datacenter stesso).Anche se in questo caso, se l’intero database venisse compromesso, si sarebbe suscettibili a down, non disponendo così di una resilienza al livello continentale ma si otterrebbe solo la resilienza da malfunzionamenti di un singolo server o di una singola server farm.
In estrema sintesi i componenti principali di un’architettura cloud ad alta disponibilità posso essere riassunti quindi in:
- Load balancer
Bilancia il carico e decide in base alla reattività dei vari server e al loro stato di integrità o di carico a quale macchina inviare le richieste
- Server o Server farm
Sono server o gruppi di server che lavorano insieme per servire le pagine web richieste dall’utente, ospitano copie del codice eseguibile dell’applicazione, che ad ogni nuovo deploy deve essere ridistribuita e sincronizzata su tutti i server o le server farm, Possono essere isolati tra loro per aumentare la resilienza in modo locale attraverso la loro suddivisione tra le availability domain dello stesso datacenter o in modo globale, distanziandoli attraverso il loro posizionamento in vari datacenter (tipicamente in continenti diversi)
- Database
Macchina che ospita il database dell’applicazione. Anche questa dovrebbe avere almeno una copia “slave” in cui dovrebbero essere sincronizzati i dati in modo continuo, che possa diventare il database primario nel caso in cui il “master” non sia raggiungibile. Come per i server, il master e lo slave possono essere posizionati in ridondanza locale o globale.
Architettura infrastruttura cloud standard
Architettura infrastruttura cloud in alta disponibilità
CDN
A queste componenti è un’ottima idea aggiungere in modo supplementare un sistema CDN (Content Delivery Network) che è in grado di ridurre i tempi di caricamento delle pagine web memorizzando in cache i contenuti, le immagini, ecc. e servendoli poi dal server situato geograficamente più vicino all’utente finale riducendo la latenza http dovuta al “viaggio” del pacchetto dati.
WAF
Un’altra componente molto utile è un sistema WAF (Web Application Firewall) che aiuta nel filtraggio delle richieste dannose e dei tentativi di attacco.
Entrambe queste due componenti sono ad esempio inclusi nel bilanciatore di carico di Microsoft Azure (Front Door) che con il piano premium dispone di funzionalità CDN e WAF con regole sia gestite dal team di sicurezza di Microsoft che personalizzate dall’amministratore.
Considerazioni sull’implementazione software
Rendere un sistema standard in alta disponibilità non è una mera configurazione al livello di infrastruttura cloud, ma ha ripercussioni anche al livello di codice: non basta scrivere un’applicazione classica per rendere HA, ma è necessario scriverla tenendo in considerazione questo dall’inizio, configurarla per ospitare le stringhe di connessione di entrambi i database (master e slave) e poter passare al livello di codice dall’uno all’altro in caso di problemi.
È quindi fondamentale, qualora ce ne fosse bisogno, iniziare a scrivere un progetto direttamente in vista del fatto che debba essere distribuito in un ambiente ad alta disponibilità o meno.
Considerazioni sui costi
Creare un’architettura ad alta disponibilità costa molto, è necessario considerare più del doppio dei costi rispetto ad un sistema non HA, infatti, per creare la resilienza è necessario avere ogni risorsa duplicata o addirittura triplicata in ridondanza, sono infatti necessari minimo due server, minimo due database e un load balencer (di cui si potrebbe fare a meno in un ambiente non HA).
Pertanto, è necessario valutare bene i benefici derivanti dall’adozione di un’architettura di questo tipo, e se effettivamente ne giustifichino i costi.