Nel mondo reale, ci possono essere situazioni in cui un calo delle prestazioni dei vostri server potrebbe verificarsi a causa di eventi che vanno da un improvviso picco di traffico può portare a un’improvvisa interruzione di corrente. Può essere molto peggio e i vostri server possono essere paralizzati, indipendentemente dal fatto che le vostre applicazioni siano ospitate nel cloud o in una macchina fisica. Queste situazioni sono inevitabili. Tuttavia, piuttosto che sperare che non si verifichino, quello che dovreste fare è attrezzarvi in modo che i vostri sistemi non vadano incontro a guasti.
La risposta al problema è l’uso di una configurazione o architettura ad alta disponibilità (HA). L’architettura ad alta disponibilità è un approccio di definizione dei componenti, dei moduli o dell’implementazione dei servizi di un sistema che garantisce prestazioni operative ottimali, anche in tempi di carichi elevati. Anche se non ci sono regole fisse per l’implementazione di sistemi HA, ci sono generalmente alcune buone pratiche che si devono seguire in modo da ottenere il massimo dalle minori risorse.
Perché ne avete bisogno?
Definiamo il tempo di inattività prima di andare avanti. Il downtime è il periodo di tempo in cui il vostro sistema (o rete) non è disponibile per l’uso, o non risponde. I tempi di inattività possono causare enormi perdite a un’azienda, poiché tutti i loro servizi sono messi in attesa quando i loro sistemi sono fuori uso. Nell’agosto del 2013, Amazon è rimasto inattivo per 15 minuti (sia i servizi web che quelli mobili), e ha finito per perdere oltre 66000 dollari al minuto. Questi sono numeri enormi, anche per una società delle dimensioni di Amazon.
Ci sono due tipi di tempi di inattività – programmati e non programmati. Un tempo di inattività programmato è il risultato della manutenzione, che è inevitabile. Questo include l’applicazione di patch, l’aggiornamento del software o anche i cambiamenti nello schema del database. Un tempo di inattività non programmato è, invece, causato da qualche evento imprevisto, come un guasto hardware o software. Questo può accadere a causa di interruzioni di corrente o di un guasto di un componente. I tempi di inattività programmati sono generalmente esclusi dai calcoli delle prestazioni.
L’obiettivo principale dell’implementazione dell’architettura di alta disponibilità è quello di assicurarsi che il sistema o l’applicazione siano configurati per gestire diversi carichi e diversi guasti con tempi di inattività minimi o nulli. Ci sono più componenti che aiutano a raggiungere questo obiettivo, e li discuteremo brevemente.
Come si misura la disponibilità?
Le organizzazioni che hanno intenzione di utilizzare pienamente un’infrastruttura cloud devono anche essere in grado di soddisfare le richieste di disponibilità 24/7. La disponibilità può essere misurata come la percentuale di tempo in cui i sistemi sono disponibili.
x = (n – y) * 100/n
Dove n è il numero totale di minuti in un mese solare e y è il numero totale di minuti in cui il servizio non è disponibile nel mese solare dato. L’alta disponibilità si riferisce semplicemente a un componente o sistema che è continuamente operativo per un periodo di tempo desiderabile. Lo standard di disponibilità di un prodotto o di un sistema, ampiamente sostenuto ma quasi impossibile da raggiungere, viene definito “cinque 9” (99,999%) di disponibilità. L’alta disponibilità è un requisito per qualsiasi impresa che spera di proteggere il proprio business dai rischi causati da un’interruzione del sistema. Questi rischi possono portare a milioni di dollari di perdita di entrate.
Vale davvero la pena spendere quei soldi?
Il fatto che andare per un’architettura ad alta disponibilità vi dia prestazioni più elevate va bene, ma ha anche un costo elevato. Dovete chiedervi se pensate che la decisione sia giustificata dal punto di vista finanziario.
Si deve decidere se l’uptime extra vale veramente la quantità di denaro che deve essere investita. Dovete chiedervi quanto possano essere dannosi i potenziali tempi di inattività per la vostra azienda e quanto siano importanti i vostri servizi nella gestione del vostro business.
Come si ottiene?
Ora che avete deciso di farlo, discutiamo i modi per implementarlo. Non intuitivamente, aggiungere più componenti a un sistema non aiuta a renderlo più stabile e a raggiungere un’alta disponibilità. In realtà può portare all’opposto, poiché più componenti aumentano la probabilità di guasti. I design moderni consentono la distribuzione dei carichi di lavoro su più istanze come una rete o un cluster, che aiuta a ottimizzare l’uso delle risorse, massimizzando l’output, minimizzando i tempi di risposta ed evitando il sovraccarico di qualsiasi sistema nel processo noto come bilanciamento del carico. Comporta anche il passaggio a una risorsa di riserva come un server, un componente o una rete in caso di guasto di uno attivo, noto come sistemi di Failover.
Uso di più server applicativi:
Immaginate di avere un singolo server per rendere i vostri servizi e un improvviso picco di traffico porta al suo guasto (o lo blocca). In una tale situazione, finché il vostro server non viene riavviato, non possono essere servite più richieste, il che porta a un tempo di inattività.
La soluzione ovvia qui è quella di distribuire la vostra applicazione su più server. È necessario distribuire il carico tra tutti questi, in modo che nessuno di essi sia sovraccaricato e l’output sia ottimale. Puoi anche distribuire parti della tua applicazione su server diversi. Per esempio, ci potrebbe essere un server separato per la gestione della posta elettronica o uno separato per l’elaborazione di file statici come le immagini (come un Content Delivery Network).
Scalare i database:
I database sono i più popolari e forse uno dei modi concettualmente più semplici per salvare i dati degli utenti. Bisogna ricordare che i database sono altrettanto importanti per i vostri servizi quanto i vostri server applicativi. I database girano su server separati (come Amazon RDS) e sono soggetti a crash. Ciò che è peggio è che i crash dei database possono portare a una perdita di dati utente, che può rivelarsi costosa.
La ridondanza è un processo che crea sistemi con alti livelli di disponibilità raggiungendo la rilevabilità dei guasti ed evitando guasti di causa comune. Questo può essere ottenuto mantenendo degli slave, che possono intervenire se il server principale si blocca. Un altro concetto interessante di scalare i database è lo sharding. Uno shard è una partizione orizzontale in un database, dove le righe della stessa tabella vengono eseguite su un server separato.
Posizioni geografiche diversificate:
Scalare le vostre applicazioni e quindi i vostri database è davvero un grande passo avanti, ma cosa succede se tutti i server sono nella stessa posizione fisica e qualcosa di terribile come un disastro naturale colpisce il centro dati in cui si trovano i vostri server? Questo può portare a tempi di inattività potenzialmente enormi.
È, quindi, imperativo mantenere i vostri server in luoghi diversi. La maggior parte dei moderni servizi web vi permette di selezionare la posizione geografica dei vostri server. Dovreste scegliere saggiamente per assicurarvi che i vostri server siano distribuiti in tutto il mondo e non localizzati in un’area.
In questo post, ho cercato di toccare le idee di base che formano l’idea di architettura ad alta disponibilità. In ultima analisi, è evidente che nessun sistema singolo può risolvere tutti i problemi. Quindi, è necessario valutare attentamente la propria situazione e decidere quali opzioni sono più adatte. Speriamo che questo vi abbia introdotto al mondo dell’architettura ad alta disponibilità e vi abbia aiutato a decidere come procedere per raggiungere questo obiettivo per voi stessi.
Quali sono le migliori pratiche?
Al fine di frenare i guasti del sistema e tenere a bada i tempi di inattività pianificati e non, l’uso di un’architettura ad alta disponibilità (HA) è altamente raccomandato, specialmente per applicazioni mission-critical. Gli esperti di disponibilità insistono sul fatto che per qualsiasi sistema per essere altamente disponibile, le sue parti dovrebbero essere ben progettate e rigorosamente testate. La progettazione e la successiva implementazione di un’architettura ad alta disponibilità può essere difficile data la vasta gamma di software, hardware e opzioni di implementazione. Tuttavia, uno sforzo di successo inizia tipicamente con requisiti di business ben definiti e compresi a fondo. L’architettura scelta dovrebbe essere in grado di soddisfare i livelli desiderati di sicurezza, scalabilità, prestazioni e disponibilità.
L’unico modo per garantire che gli ambienti di calcolo abbiano un livello desiderabile di continuità operativa durante le ore di produzione è progettarli con alta disponibilità. Oltre a progettare correttamente l’architettura, le imprese possono mantenere online le applicazioni cruciali osservando le migliori pratiche raccomandate per l’alta disponibilità.
- Backup dei dati, recupero e replica
Il segno distintivo di un buon piano di protezione dei dati che protegge dai guasti del sistema è una solida strategia di backup e recupero. I dati di valore non dovrebbero mai essere conservati senza backup adeguati, replica o capacità di ricreare i dati. Ogni centro dati dovrebbe pianificare in anticipo la perdita o la corruzione dei dati. Gli errori dei dati possono creare problemi di autenticazione dei clienti, danneggiare i conti finanziari e di conseguenza la credibilità della comunità aziendale. La strategia raccomandata per mantenere l’integrità dei dati è la creazione di un backup completo del database primario e poi il test incrementale del server di origine per la corruzione dei dati. La creazione di backup completi è all’avanguardia nel recupero da un guasto catastrofico del sistema.
- Clustering
Anche con la più alta qualità di ingegneria del software, tutti i servizi applicativi sono destinati a fallire ad un certo punto. L’alta disponibilità consiste nel fornire servizi applicativi indipendentemente dai guasti. Il clustering può fornire servizi applicativi di failover istantaneo in caso di guasto. Un servizio applicativo che è “cluster aware” è in grado di chiamare risorse da più server; ricade su un server secondario se il server principale va offline. Un cluster ad alta disponibilità include più nodi che condividono informazioni attraverso griglie di memoria dati condivise. Questo significa che qualsiasi nodo può essere disconnesso o spento dalla rete e il resto del cluster continuerà a funzionare normalmente, finché almeno un singolo nodo è completamente funzionante. Ogni nodo può essere aggiornato individualmente e ricongiunto mentre il cluster funziona. L’alto costo dell’acquisto di hardware aggiuntivo per implementare un cluster può essere mitigato impostando un cluster virtualizzato che utilizza le risorse hardware disponibili.
- Bilanciamento del carico di rete
Il bilanciamento del carico è un modo efficace per aumentare la disponibilità delle applicazioni critiche basate sul web. Quando vengono rilevate istanze di guasto del server, queste vengono sostituite senza soluzione di continuità quando il traffico viene ridistribuito automaticamente ai server che sono ancora in funzione. Non solo il bilanciamento del carico porta all’alta disponibilità, ma facilita anche la scalabilità incrementale. Il bilanciamento del carico di rete può essere realizzato tramite un modello “pull” o “push”. Facilita livelli più alti di tolleranza ai guasti all’interno delle applicazioni di servizio.
- Fail Over Solutions
L’architettura ad alta disponibilità consiste tradizionalmente in un insieme di server liberamente accoppiati che hanno capacità di failover. Il failover è fondamentalmente una modalità operativa di backup in cui le funzioni di un componente del sistema sono assunte da un sistema secondario nel caso in cui quello primario vada offline, a causa di un guasto o di un tempo di fermo pianificato. Un “failover freddo” si verifica quando il server secondario viene avviato solo dopo che il primario è stato completamente spento. Un “failover a caldo” si verifica quando tutti i server sono in esecuzione contemporaneamente, e il carico è diretto interamente verso un singolo server in qualsiasi momento. In entrambi gli scenari, i compiti sono automaticamente scaricati su un componente del sistema standby in modo che il processo rimanga il più possibile senza soluzione di continuità per l’utente finale. Il failover può essere gestito via DNS, in un ambiente ben controllato.
- Ridondanza geografica
La georidondanza è l’unica linea di difesa quando si tratta di prevenire il fallimento del servizio di fronte a eventi catastrofici come i disastri naturali che causano interruzioni del sistema. Come nel caso della georeplicazione, più server sono distribuiti in siti geografici distinti. I siti dovrebbero essere distribuiti a livello globale e non localizzati in una zona specifica. È fondamentale eseguire stack di applicazioni indipendenti in ciascuna delle sedi, in modo che in caso di guasto in una sede, l’altra possa continuare a funzionare. Idealmente, queste sedi dovrebbero essere completamente indipendenti l’una dall’altra.
- Pianificare il fallimento
Nonostante il fatto che applicare le migliori pratiche per l’alta disponibilità sia essenzialmente pianificare il fallimento; ci sono altre azioni che un’organizzazione può intraprendere per aumentare la propria preparazione in caso di un guasto del sistema che porti a tempi morti. Le organizzazioni dovrebbero conservare i dati sui guasti o sul consumo di risorse che possono essere utilizzati per isolare i problemi e analizzare le tendenze. Questi dati possono essere raccolti solo attraverso il monitoraggio continuo del carico di lavoro operativo. Un help desk di recupero può essere messo in atto per raccogliere informazioni sui problemi, stabilire la storia dei problemi e iniziare a risolverli immediatamente. Un piano di recupero non solo dovrebbe essere ben documentato, ma anche testato regolarmente per assicurare la sua praticità quando si ha a che fare con interruzioni non pianificate. La formazione del personale sull’ingegneria della disponibilità migliorerà le loro competenze nel progettare, distribuire e mantenere architetture ad alta disponibilità. Le politiche di sicurezza dovrebbero anche essere messe in atto per frenare le incidenze di interruzioni del sistema dovute a violazioni della sicurezza.
Esempio: Architettura di Alta Disponibilità di FileCloud
Il seguente diagramma spiega come i server FileCloud possono essere configurati per l’Alta Disponibilità per migliorare l’affidabilità del servizio e ridurre i tempi di fermo. Clicca qui per maggiori dettagli.