Sistemi High Availability, Disaster Recovery Plan e Cluster. Ripristino immediato del server dei servizi e delle applicazioni ovvero come evitare i fermi del server aziendale e come prevenire i guasti e i danni al server dell'azienda - Servizi e Strutture offerti da FAsTec
Quanto tempo potete lavorare con il server rotto o bloccato? Quanto tempo potete restare senza il vostro server?
ATTENZIONE: state per leggere un articolo di approfondimento. Se non siete esperti cliccate qui per un infarinatura su Virtualizzazione Server, High Availability Cluster e Alta Disponibilita', altrimenti, buona lettura
Quando ci troviamo ad affrontare questo argomento con i nostri clienti, facciamo una piccola provocazione e diciamo al nostro interlocutore di porsi una domanda del tipo "se mi si ferma il server, quanto tempo posso attendere perchè venga ripristinato?" e attendiamo la sua risposta. Se la risposta è "massimo qualche giorno", allora non è il caso di spiegare cosa siano High Availability o HA, Disaster Recovery Plan, Cluster o i concetti di Virtualizzazione e Macchine Virtuali. Per cui, se anche voi potete restare giorni col server fermo, allora siete nella pagina sbagliata. A riguardo dell'argomento Disaster Recovery Plan qui abbiamo aperto una discussione.
Neanche 1 minuto, figuriamoci 1 ora
se invece la risposta è neanche 1 ora o meno, sicuramente vi interesseranno i servizi che FAsTec puo' offrirvi e che sono l'applicazione dei concetti che discutiamo in questa pagina. Per darvi una prospettiva piu ampia, abbiamo scritto una lettera aperta che agevola riflessioni e approfondimenti sulle sviste che si commettono nella gestione del server e che vi illuminera' sui vantaggi della nostra proposta.
High-Availability riorganizzare il server per creare un sistema ad alta disponibilità
Cosa significa? Si tratta di reimpostare l'utilizzo del server per ottenere elevata ridondanza e ridurre al minimo il rischio di "fermo-impianto", sia esso programmato per manutenzione o aggiornamento del software o del sistema operativo o imprevisto: un guasto. Un sistema dove oltre ad essere ridondante il sistema di dischi... diventa ridondante anche l'intero server.
Guasto al server, affidabilità, prevenire è meglio che curare: ma bisogna pensare a tutto...
Diamo per scontato che effettuiate back up e salvataggi ogni giorno...
... e iniziamo ad analizzare. Per prevenire i danni di un guasto al server, si tende a demandare la prevenzione al sistema di dischi raid e all'alimentatore doppio e ridondante: concettualmente, ciò è sbagliato. I dischi e gli alimentatori è vero, possono essere piu stressati, ma lo è altrettanto la CPU o microprocessore che dir si voglia. Scarsa manutenzione (polvere all'interno del pc) e stress termici, fanno il resto... e quindi?
Se si guasta il processore? Se si guasta la scheda madre? Se si guastano le memorie RAM? Se si ferma qualche ventola e il server è troppo economico per avere un sistema che ci avvisa? Se si guastano le schede rete?
Ci avevate mai pensato? Sentite un senso di preoccupazione?
Allora siete pronti a capire perchè l'unica soluzione per restare fermi pochissimo tempo, sia
Applicare pienamente il concetto di High Availability
Diamo per scontato che al fine di ridurre le possibilità di fermo imprevisto è bene dotarsi di servers con componenti ridondanti a livello di alimentazione, processori, schede rete e unità di memoria di massa (dischi in modalità raid). Addirittura, in alcuni casi anche le memorie RAM possono essere ridondate (tecnologie del tipo memory-sparing , memory-mirroring o memory-raid possono tollerare uno o più banchi di memoria guasti senza comportare un crash di sistema) e parecchi di questi componenti oltre ad altri citati sopra, posso essere sostituiti a caldo (hot-plug) riducendo quindi il fermo macchina ai soli casi estremi. Non la scheda madre però... (ne riparleremo sotto)
I tempi di fermo macchina schedulati o programmati sono imposti da manovre di manutenzione ordinaria quali ad esempio aggiornamenti su software applicativi o sistemi operativi, variazioni di configurazione che comportino in ogni caso l'interruzione del servizio.
Chiarito il concetto di base, al fine di ridurre i rischi risulta evidente e importante una corretta analisi e pianificazione dell'impianto prima della sua implementazione (necessità operative, valutazione delle criticità, eliminazione dei "single point of failure" e progetto dell'impianto stesso)
Le attuali tecnologie consentono di ridurre i rischi dovuti a guasti hardware in vari modi (alcuni sommariamente sopra descritti). Ma visto che non esistono servers con due schede madri ridondanti... l'unico metodo che consenta di mantenere un "servizio" in esecuzione anche durante le fasi di manutenzione (salvo rare eccezioni in ogni caso gestibili e pianificabili per tempo) o in caso di "guasto grave", è la creazione di un impianto clusterizzato.
Per impianto clusterizzato, si intende un certo numero di servers (minimo 2) opportunamente dimensionati e configurati, che garantiscano l'erogazione dei servizi agli utenti di una rete aziendale (funzioni di file server o database gestionale) anche nel caso in cui uno dei servers si spenga.
L'impianto clusterizzato può garantire la continuità di servizio e puo' ripartire il carico istantaneo di lavoro garantendo una erogazione più "fluida" del servzio stesso. Sintetizzando i due concetti: Load Balancing e Fault Tolerant.
La condivisione dei dati tra i nodi del cluster può essere realizzata in diverse maniere, alcune richiedono la presenza di spazi di archiviazione condivisi tra i vari nodi (strutture tipo S.A.N. alle spalle dell'impianto), altre un sistema di replica dei dati realizzato in modo sincrono tra le macchine su sistemi di archiviazione "locali" e gestiti "alle spalle" del sistema (concetto di "Muletto")
Virtualizzazione e Macchine Virtuali: Risparmio Energetico per l'Azienda e loro applicazione per High-Availability
A differenza dei concetti di clustering, le virtual machine, nei casi opportuni, permettono di gestire i fermi macchina riducendoli a tempi minimi, giusto il tempo di migrare la macchina virtuale ( letteralmente un computer nel computer ) e di avviarla su un server di scorta o su un muletto.
La migrazione può essere di tipo automatico o manuale.
La potenza dei processori nei computer contemporanei e l'abbondanza di giga, sia nei dischi che per le memorie RAM, permette di installare configurare e collocare in maniera distinta ed indipendente diversi "computer" all'interno di una sola macchina, generalmente un server multiprocessore e di farli lavorare contemporaneamente. Abbiamo virgolettato il termine computer riferendoci alla possibilità di far girare piu sistemi operativi contemporaneamente. A seguire, un video per capire meglio la virtualizzazione:
Computer aziendali: come risparmiare sulla bolletta dell'energia elettrica
con il concetto espresso sopra, è evidente come ne consegua che si può risparmiare sulla bolletta elettrica. Se per tenere in funzione vari servizi, nella rete e infrastruttura informatica dell'azienda, si tengono in funzione piu server, diciamo 4 (2 windows e due linux) per fare un esempio, ebbene, si consumeranno 200W x 4 x 24 = 19,2 Kw al giorno che x 365gg sono 7000 Kw all'anno. Se grazie alle macchine virtuali, i 4 server ve li facciamo girare in un solo computer... il consumo scenderà aritmeticamente da 7000 Kw a 1750 Kw: un notevole risparmio energetico ed economico.
n.d.r. La virtualizzazione non era oggetto di questa pagina, ma essendo pertinente all'high-availability, abbiamo divagato volentieri.
La tabella sotto riportata illustra i tempi di downtime per anno/mese/settimana rispetto all'indice di "disponibilità" indicato in percentuale (fonte: Wikipedia)
Availability % |
Downtime per year |
Downtime per month |
Downtime per week |
90.00% |
36.5 days |
72 hours |
16.8 hours |
95.00% |
18.25 days |
36 hours |
8.4 hours |
98.00% |
7.30 days |
14.4 hours |
3.36 hours |
99.00% |
3.65 days |
7.20 hours |
1.68 hours |
99.50% |
1.83 days |
3.60 hours |
50.4 minutes |
99.80% |
17.52 hours |
86.23 minutes |
20.16 minutes |
99.9% ("three nines") |
8.76 hours |
43.2 minutes |
10.1 minutes |
99.95% |
4.38 hours |
21.56 minutes |
5.04 minutes |
99.99% ("four nines") |
52.6 minutes |
4.32 minutes |
1.01 minutes |
99.999% ("five nines") |
5.26 minutes |
25.9 seconds |
6.05 seconds |
99.9999% ("six nines") |
31.5 seconds |
2.59 seconds |
0.605 seconds |
Va comunque sottolineato che uptime e disponibilità non sono affatto sinonimi, il sistema potrebbe essere normalmente acceso ed operativo e non essere disponibile per cause "esterne" al sistema stesso (es. mancanza di connettività).