Monitoraggio server e infrastrutture per una reale business continuity

Argomento spesso sottovalutato, il monitoraggio è un importante capitolo della Business Continuity, sia per intercettare malfunzionamenti, sia per prevedere possibili saturazioni che potrebbero causare un blocco del servizio o, nel peggiore dei casi, perdita di dati. Qualsiasi sia la condizione che si verifichi, questi danni comportano anche delle spese dal punto di vista economico. 
Cosa significa monitoraggio

In campo informatico il monitoraggio è quella procedura con la quale si controllano aspetti dell’infrastruttura informatica, principalmente sotto due aspetti: stato e andamento.
Con stato indichiamo una condizione che teoricamente prevede due valori, uno positivo e uno negativo: per esempio il server è acceso o spento, il servizio web funziona o non funziona, la banda usata è al di sopra o al di sotto di un limite. Il monitoraggio continuo dello stato di vari punti di un’infrastruttura, se emette un allarme, genera una notifica ed esegue un’azione quando la condizione verificata diventa critica. Con il tempo, i sistemi di monitoraggio si sono evoluti sempre più, consentendo una più precisa gestione nella verifica dello stato, permettendo di prevedere più stati divergenti dalla condizione normale (ad esempio la saturazione di un disco può raggiungere una soglia di attenzione e, se non gestito, arrivare a superare una soglia di criticità).

L’andamento, invece tiene traccia continua di metriche registrate sui servizi, come ad esempio l’utilizzo complessivo della memoria di un server, permettendo di capire quando si verificano picchi di consumo risorse nei momenti di pieno carico, o più in generale il consumo di banda di una Web Farm. Questo tipologia di monitoraggio è in grado di fornire quindi uno storico dati, utile a valutazioni non solo legate al momento, ma riferite anche a un periodo più ampio. Riprendendo l’esempio del consumo di banda di una Web Farm, tramite il monitoraggio è possibile verificare l’andamento nel corso della settimana, degli ultimi trenta giorni, o dei sei mesi precedenti, aiutandoci in definitiva a capire se sia necessario un ampliamento della stessa oppure se sia sufficiente acquistare  banda aggiuntiva solo quando questa viene richiesta.

Architetture dei sistemi di monitoraggio

Attualmente si possono individuare due tipologie di architetture di monitoraggio: centralizzata e distribuita.
Oltre a questi due modelli, esistono anche delle soluzioni ibride, tuttavia meno diffuse.

Per architettura centralizzata, si intende normalmente un server, o più di uno in configurazione cluster, da cui partono tutte le attività di analisi direttamente verso l’oggetto che si sta monitorando. Questa architettura è quella più semplice e maggiormente implementata nella maggioranza dei casi, soprattutto se l’ambiente da monitorare è di dimensioni modeste e/o concentrate in un unico luogo (medesimo data center, stessa località, stessa infrastruttura di rete). Il server di monitoraggio ha libero accesso senza limitazioni ad ogni aspetto dell’architettura e di norma risiede all’interno dell’infrastruttura che tiene sotto controllo.

L’architettura distribuita prevede più server master che coordinano delle zone di controllo, e svariati server minori che operano come agent di monitoraggio nelle stesse. Questa architettura è di norma implementata in situazioni in cui sono presenti più ambienti distinti da monitorare distribuiti in ambito geografico (diversi data center) e il numero di oggetti è alto, rendendo quindi la gestione da un singolo server più complessa.
In questa soluzione solo i server minori hanno pieno accesso alla zona che monitorano, e di norma sono questi stessi ad effettuare i vari controlli, riportando al server master esclusivamente le condizioni complessive e le relative metriche. Il sistema consente inoltre dai server master di accedere alle informazioni puntuali dei vari ambienti, salvati nei server minori.

Nella scelta di un ambiente, bisogna considerare che la maggior parte dei software che monitorano l’andamento non sono facilmente implementabili in architetture distribuite. Questo limite nasce dal fatto che il monitoraggio degli andamenti non è facilmente eseguibile in remoto riportando i dati verso un altro server, quindi se prevedete di implementare un’architettura distribuita, assicuratevi che il software che andrete ad utilizzare per il monitoraggio degli andamenti sia in grado d’interagire in modalità agent remoto o che esista una modalità per gestire l’esecuzione remota della raccolta dati.

Le notifiche: troppo è male, poco è male

Nel momento in cui abbiamo il nostro sistema di monitoraggio, uno dei problemi maggiori che si riscontra fin da subito è la qualità dei messaggi di notifica. Un monitoraggio che notifichi in modo eccessivo porta a sottovalutare le notifiche stesse, tra cui anche notifiche di problemi importanti; mentre un sistema di monitoraggio che notifichi raramente potrebbe essere stato configurato con soglie di problema troppo elevate, falsando in questo modo gli effettivi problemi. Soprattutto per quanto riguarda gli stati, come la raggiungibilità di un server o la banda disponibile su un link, una delle regole d’oro per la corretta configurazione delle notifiche è calcolare l’impatto economico che queste avranno: tutto ciò che rientra in una condizione fallace e di conseguenza con degli oneri economici, deve essere prontamente notificato. Ad esempio, nel caso del monitoraggio di un link, è inutile notificare se la banda risulta ⅓ del totale, certamente è utile avere una prima notifica di possibile problema se l’occupazione di banda è superiore ad un 70-80%, in secondo luogo si renderà necessaria la notifica se questa supera il 90% della banda complessiva, perché si è vicini alla saturazione completa e quindi all’impossibilità di usufruire del servizio.

Esistono comunque delle tecniche e dei metodi che permettono di ridurre considerevolmente la quantità di notifiche, rendendo anche più semplice la diagnosi di un problema. Di seguito i principali parametri utilizzati:

 

• Parentela:

quando si configura il proprio sistema di monitoraggio, si dichiarano vari oggetti da monitorare. Per com’è costruita la nostra infrastruttura dovrebbe essere chiaro che esistono delle parentele tra i vari oggetti. Guardando il tutto come fosse una struttura ad albero, alla cui cima si trova il server che opera il monitoraggio, è evidente che nel momento in cui un oggetto diventa irraggiungibile, anche gli oggetti che “dipendono” da tale oggetto risulteranno irraggiungibili a loro volta. Nel caso si verifichi questa condizione, interviene la capacità del software di monitoraggio che, sfruttando il parametro delle parentele, non invia notifiche riguardanti gli altri oggetti irraggiungibili perchè dipendenti. 
Nell’immagine seguente, gli switch di core diventano irraggiungibili. Dal disegno è chiaro che i due switch d’accesso e i due server risulteranno irraggiungibili dal punto in cui si trova il server di monitoraggio. In questo scenario la maggior parte dei software di monitoraggio segnaleranno l’irraggiungibilità solo dei due switch di core, ma la segnalazione sarà notificata come un grave disservizio, perché sono coinvolti anche altri oggetti. Nel caso in cui il software non fosse in grado di gestire le dipendenze, invece di due messaggi di notifica, se ne riceverebbero sei.

 

• Instabilità:

in un sistema informatico ci sono momenti in cui un peggioramento delle prestazioni porta il monitoraggio a riscontrare una variabilità del servizio monitorato, che oscilla tra due o più stati: per ciascuna variazione di stato, ci sarebbe una notifica. Un esempio potrebbe essere quello di un server molto carico che fatica a rispondere ai controlli del monitoraggio, risultando quindi quindi a volte irraggiungibile, altre perfettamente raggiungibile. In tal caso un sistema di monitoraggio limitato notificherebbe in sequenza tutte le variazioni, generando una sovra-segnalazione.

Fortunatamente la quasi totalità dei software prevede un sistema per intercettare il momento in cui si viene a creare una situazione d’instabilità e di conseguenza notificare esclusivamente una situazione di variabilità, bloccare tutte le notifiche normali di cambio stato ed attendere che sia trascorso un certo periodo di tempo prima di riabilitare le notifiche; oppure, nei sistemi più raffinati, considerare l’instabilità finita e riprendere le normali modalità di notifica dopo che il tasso di variazione è sceso ad un livello percentuale-temporale accettabile.

 

• Quantità e livelli di notifica:

un server di monitoraggio deve prevedere più livelli di notifiche e dev’essere configurabile in merito alla quantità di notifiche da inviare relative al medesimo problema.
Ipotizziamo che un servizio vada in errore e che il monitoraggio intercetti il problema, facendo partire la prima notifica. Deve essere possibile decidere se e quando notificare nuovamente un servizio in errore dopo un certo lasso di tempo in cui il problema non venga preso in carico e persista la condizione di errore.
Può accadere per esempio che l’email o l’sms inviato non sia stato visualizzato e che quindi una nuova notifica possa riportare la giusta attenzione sulla problematica.
Un’altra funzione garantisce la possibilità di impostare i livelli di notifica, che prevedono di poter notificare una problematica a un diverso gruppo di persone nel caso rimanga ingestita per più di un determinato tempo prestabilito.
Questa modalità è utile soprattutto in caso di servizi che necessitano monitoraggio continuo (ad esempio il monitoraggio di infrastrutture che ospitano e-commerce) e che se non risolti, possono causare un’escalation verso l’alto nel livello della problematica.

Scegliere un sistema di monitoraggio

Nel panorama informatico esistono molti programmi di monitoraggio progettati per controllare lo stato e/o l’andamento dei sistemi. I programmi che cercano di controllare entrambi gli aspetti potrebbero avere delle limitazioni in una o in entrambe le caratteristiche.
L’importante è scegliere un sistema che si adatti il più possibile al proprio sistema informatico e che permetta di crescere grazie a semplici interventi di manutenzione programmata.
L’unico modo per verificare questi aspetti è testare tale programma prima di un possibile acquisto/implementazione, quindi dovrete prevedere un tempo ragionevole per effettuare delle prove pratiche.
E’ possibile anche affidarsi a servizi esterni (as a service) per il monitoraggio, ma di norma questi hanno una flessibilità più limitata e una minor numero di oggetti monitorabili.
Riteniamo in ogni caso questi servizi utili da un punto di vista commerciale/marketing per una certificazione effettuata da terze parti indipendenti sull’andamento dei sistemi entro i parametri pre-configurati; da un punto di vista tecnico possono fornire inoltre un secondo livello di monitoraggio, utile nel caso il sistema principale di monitoraggio sia guasto o in manutenzione.

Il monitoraggio neen

Consci dell’importanza di avere una infrastruttura costantemente monitorata su tutti i livelli, da quelli di core alle risorse del singolo server/nodo, neen ha implementato da diversi anni un’architettura di monitoraggio basata su strumenti e programmi riconosciuti come i migliori nel panorama tecnico informatico (tra cui Nagios, Cacti, Munin), personalizzati per adattarsi alle peculiari caratteristiche del servizio fornito ai propri clienti, come la possibilità di personalizzare gli allarmi per singolo cliente in funzione di determinati KPI concordati.
Sfruttando le qualità di un’architettura di monitoraggio centralizzata, è stata implementata una forma di monitoraggio ibrida, rendendo ogni server un possibile agent remoto come in una soluzione distribuita.
Oltre al proprio sistema di monitoraggio, neen utilizza anche servizi esterni, al fine di garantire un secondo livello di affidabilità nel monitoraggio, e la possibilità di certificazione indipendente della qualità del servizio fornito ai propri clienti.

Conclusione

Sottovalutare la necessità di utilizzare un sistema monitoraggio, in molti casi può portare ad un vero e proprio danno infrastrutturale, con alti costi di gestione. 
La capacità di prevenire i problemi o di agire prontamente al verificarsi degli stessi, garantisce un maggiore tasso di affidabilità dell’infrastruttura informatica stessa, permettendo di individuare colli di bottiglia strutturali o presenti solo in determinate fasce temporali/orarie o in determinate situazioni d’uso. In definitiva, un buon sistema di monitoraggio è un’importante supporto necessario a garantire l’adeguata affidabilità e qualità ai propri servizi.