Il calcolo dell'Availability

In EGEE vengono utilizzate diverse applicazioni per il controllo e la gestione del- l'infrastruttura Grid. Per valutare l'Availability dei siti, ci si avvale dei risultati dei test eettuati attraverso SAM (Service Availability Monitoring [94]), un siste- ma centralizzato composto da un insieme di test sottomessi a intervalli regolari, un database nel quale vengono archiviati i risultati e una interfaccia Web per visua- lizzarli. Questi risultati vengono elaborati dall'applicazione Gridview [95] in modo tale da recuperare i dati necessari alla verica delle metriche denite nella SLA. Per il calcolo dell'Availability totale di un sito, vengono utilizzate le seguenti denizioni:

• istanza di un servizio: rappresenta la singola risorsa in Grid, come per esempio un particolare Computing Element o Storage Element in un sito;

• servizio: è un insieme di istanze di servizi della stessa tipologia. Per esempio, un insieme di istanze di Computing Element di un sito è da considerarsi come il servizio Computing Element di quel sito. Un servizio può quindi essere composto da una o più istanze.

• sito: è rappresentato da un insieme di servizi, come Computing Element, Storage Element, Storage Resource Manager, LCG File Catalog, File Transfer Service.

• stato: lo stato dell'istanza del servizio, del servizio o di un sito è lo stato di quella entità in un dato momento, in accordo con i risultati dei SAM test. Gli stati possibili sono quelli riportati nella tabella 4.3.

Tabella 4.3: Denizione dei possibili stati per le istanze, i servizi e i siti

Stato Signicato

UP L'istanza, il servizio o il sito hanno passato i SAM test con successo

DOWN L'istanza, il servizio o il sito hanno fallito i SAM test

SCHEDULED DOWN L'istanza, il servizio o il sito sono in manuten- zione programmata (informazione contenuta nel GOCDB)

UNKNOWN I SAM test per l'istanza, il servizio o il sito non sono disponibili

DEGRADED Una o più istanze, ma non tutte, componenti un singolo servizio hanno fallito i SAM test

In un dato momento, un sito sarà considerato `UP` se lo saranno tutti i servizi di cui è composto. Un servizio è considerato `UP` se lo sono tutte le singole istanze che lo compongono. Nel caso un servizio sia in stato `DEGRADED`, cioè quando una o più istanze, ma non tutte, componenti un singolo servizio hanno fallito i SAM test, il servizio nel suo insieme sarà considerato `UP`. La SLA di EGEE prevede che un sito debba essere:

1. AVAILABLE almeno per il 70% del tempo su base mensile;

2. RELIABLE, denita dalla formula 4.6, almeno per il 75% del tempo su base mensile;

Reliability = Availability

Availability − Unscheduled Downtime (4.6)

I periodi di indisponibilità di una istanza, servizio o dell'intero sito devono essere inseriti nel GOCDB: i downtime pianicati incidono quindi negativamente sull'Availability, ma non sulla Reliability.

Poiché i SAM test per essere eseguiti necessitano di credenziali, in conformità di quanto discusso nella sezione 3.2.1 sull'autenticazione e l'autorizzazione, occorre tenere presente che i test sono sempre relativi a queste credenziali, in particolare sono sempre relativi alla VO utilizzata per richiedere l'autorizzazione all'uso delle risorse. Può quindi capitare il caso in cui, per esempio, su uno Storage Element

4.5. IL SERVICE LEVEL AGREEMENT DI EGEE 73

Figura 4.7: Availability dei siti componenti l'infrastruttura EGEE nel mese di Gennaio 2009. Fonte [96]

venga eseguito con successo il test utilizzando le credenziali della VO OPS6_{, mentre}

lo stesso test fallisca se si usano credenziali con una VO diversa. SAM e Gridview permettono di calcolare anche le Availability dei siti per VO diverse da OPS: ogni VO può selezionare quali test di SAM debbano essere considerati per il calcolo. Questi risultati possono essere quindi utilizzati nel caso di SLA tra VO e siti. In questa tesi, ove non diversamente specicato, si considererà sempre l'Availability relativa alla VO OPS.

Availability e Reliability su base oraria, giornaliera, settimanale e mensile pos- sono essere visualizzate attraverso l'applicazione GridMap [96]: l'applicazione rag- gruppa i siti, rappresentati da rettangoli di dimensioni proporzionali al numero di slot disponibili, nei rispettivi ROC di appartenenza. Il colore rappresenta il grado di Availability totale dei siti, per ogni sito è possibile evidenziare l'Availability di ogni servizio: in gura 4.7 è riportata la visualizzazione dell'Availability del mese di Gennaio 2009, con il dettaglio dell'Availability dei servizi oerti dal sito INFN-T1.

6_{La VO OPS deve essere supportata in tutti i siti e su tutti i servizi, è la VO utilizzata per}

Capitolo 5

Tecniche di High Availability per

servizi Grid

That's not a bug, that's a feature! The canonical rst parry in a debate about a purported bug. All'aumentare del grado di complessità e della scala della rete, dei sistemi di cal- colo e di archiviazione e dell'infrastruttura informatica in generale, anche le attività più semplici di controllo possono diventare problematiche. Ad esempio, per sapere se un determinato gruppo di servizi è regolarmente in funzione, o se il livello di carico è tanto alto da pregiudicarne il normale funzionamento, non è certo eciente control- lare su tutti gli host che compongono il servizio lo stato del sistema autonomamente e in modo pro attivo. Sono dunque necessari sistemi di monitoraggio più sosticati in grado di fornire una `istantanea` dello stato dei servizi e in generale delle risorse, mantenendo uno storico e fornendo strumenti di correlazione tra cause ed eetti, importanti per esempio quando un servizio è costituito da diverse componenti.

Dunque in Grid, i sistemi di monitoring uniti ad un sistema di notica (o al- larmistica), sono necessari per consentire la rilevazione tempestiva di anomalie e per intraprendere le opportune azioni correttive, eventualmente anche in modalità automatica ove possibile, indagando nel contempo sulle cause. Non tutti i servizi presenti nel middleware gLite sono però `disegnati` in modo tale da permettere che l'applicazione di tecniche di High Availability abbia come risultato una gestione dei fallimenti delle istanze dei servizi trasparente agli utenti. Per alcuni servizi, data la loro semplicità, ciò è possibile (per esempio nel caso del servizio BDII). Altre applicazioni sviluppate recentemente, come FTS e StoRM, hanno una architettura

modulare che permette l'applicazione di diverse tecniche di fault tolerance ai sin- goli componenti del servizio: generalmente questi servizi sono gestibili in maniera completamente trasparente agli utenti. Il servizio VOMS può essere congurato in modo tale da prevedere un intrinseco meccanismo di failover: in caso di più istanze di servizi VOMS disponibili per una data VO, se l'istanza primaria non dovesse essere disponibile, si ottiene un messaggio di errore, ma la richiesta viene automaticamente reindirizzata ad eventuali istanze secondarie. Il WMS è invece un esempio di ser- vizio nel quale la gestione dei fallimenti al momento non è trasparente agli utenti per motivi architetturali del servizio stesso. Nel seguito di questo capitolo vengono illustrate le strategie di fault tolerance applicate a diversi servizi del middleware gLite.

In questa tesi è stato preso in considerazione Nagios [97], uno degli strumenti di monitoraggio e allarmistica open source più diusi, conosciuto in ambito aziendale ed utilizzato in molte delle più grandi società ed organizzazioni in tutto il mondo. In particolare se ne presenterà l'architettura, il funzionamento, e l'applicazione in Grid per le attività di controllo, allarmistica e recovery automatico di numerosi servizi del middleware gLite.

5.1 Un sistema di monitoring e allarmistica: Nagios

Nagios funziona in ambiente Linux/Unix e permette di integrare diversi sistemi per la notica degli eventi: email, messaggistica istantanea, SMS. L'architettura di Nagios è composta da varie componenti.

1. Il nucleo principale ha il compito di eseguire i controlli che sono stati deniti con una certa frequenza temporale, di noticare il cambiamento di stato di un servizio e, in caso di fallimento, di eseguire le procedure di escalation e di re- covery eventualmente predenite, attraverso l'esecuzione di azioni predisposte (event handler), come per esempio la rimozione di un IP dal DNS.

2. Una interfaccia Web in grado di visualizzare lo stato degli host, dei servizi controllati e del sistema Nagios in generale. Inoltre è possibile visualizzare la schedula dei controlli, inserire downtime (e quindi sospendere temporanea- mente un controllo) o forzare l'esecuzione immediata di un check. Vista la

5.1. UN SISTEMA DI MONITORING E ALLARMISTICA: NAGIOS77

sensibilità delle informazioni accessibili e manipolabili tramite questa inter- faccia, è possibile limitarne l'accesso ad un ristretto gruppo di utenti locali mediate l'uso del certicato digitale personale.

3. Un insieme di plugin, cioè applicazioni e script, che permettono da linea di comando di controllare lo stato di un servizio. Nagios propone un insieme di plugin generici, ma è molto semplice crearne di nuovi utilizzando un qualsiasi linguaggio di programmazione.

Tabella 5.1: Corrispondenza tra i valori di ritorno dei plugin di Nagios e i corrispondenti stati dei servizi e degli host

Valore di ritorno

del plugin Stato del Servizio Stato dell'host

0 OK UP

1 WARNING UNREACHABLE

2 CRITICAL DOWN/UNREACHABLE

3 UNKNOWN DOWN/UNREACHABLE

Nagios determina lo stato di un host o di un servizio valutando il valore di ritorno del plugin eseguito: nella tabella 5.1 sono mostrati i valori con i corrispondenti stati per i servizi e gli host.

Oltre al valore di ritorno (obbligatorio), i plugin possono avere come risultato altri due elementi:

• _{una stringa testuale, utilizzata generalmente per riportare dettagli sul risultato}

del controllo, come per esempio un messaggio di errore;

• _{una stringa numerica, che può essere per esempio utilizzata per riportare i}

tempi di risposta o esecuzione del plugin al ne di rilevare anche problemi di congestione o carico elevato del servizio.

Nagios permette di denire delle dipendenze tra servizi e host. Questa proprietà è molto utile in particolare per denire due tipi di relazioni:

• host-host: questo tipo di relazione permette di descrivere le dipendenze tra i server e gli apparati di rete a cui sono connessi. In questo modo vengono rappresentate in Nagios le connessioni di rete così come si presentano nella

realtà e di conseguenza si riescono meglio a correlare tra loro diversi eventi. Per esempio, nel caso di rottura di uno switch, Nagios rileverà l'irraggiungibilità di tutti i server collegati, ma noticherà solo l'indisponibilità dello switch, in quanto causa del problema. Inoltre tutti i controlli dei server coinvolti verranno di conseguenza interrotti.

• _{servizio-servizio: questo tipo di relazione ha il pregio di aggiungere una logica}

per denire correlazioni causa/eetto. Si pensi per esempio ad un sito Web il cui funzionamento si basa su un database, come nei moderni CMS1_{. Nel}

caso in cui il database diventasse indisponibili, i contenuti del sito Web non sarebbero più fruibili, mentre l'applicazione Web potrebbe o meno essere ope- rativa. Congurando opportunamente una relazione tra il servizio database e il server Web, Nagios sospenderà i controlli sullo stato del server Web, no a quando il database non viene ripristinato, noticando solo l'indisponibilità di quest'ultimo.

Entrambe queste relazioni sono utilizzate per ottimizzare i controlli e le notiche per i servizi gLite.