Monitoring e loadbalancing dei servizi Grid

Presentazione sul tema: "Monitoring e loadbalancing dei servizi Grid"— Transcript della presentazione:

1 Monitoring e loadbalancing dei servizi Grid
D.Dongiovanni (INFN-CNAF) D.Cesini (INFN-CNAF)

2 Monitoring servizi grid
MONITORING GENERALE DI SITI e ROC: NAGIOS – vedi presentazione “Nagios di sito e Nagios di ROC” GSTAT SAM, GRIDMAP GRIDICE MONITORING SPECIFICO DI SERVIZI CENTRALI: HLRMON – vedi presentazione “Accounting e HLRMON” FTSMON, FTM WMSMON

3 WMSMON : gLiteWMS/LB service
and Job flow monitor Monitora un pool di istanze gLite WMS/LB distribuite Rileva fallimenti dei servizi e stato HW, supportando l'amministratore nella fault prevention Monitora il Job Flow su ogni istanza permettendo di analizzare la complessa dinamica interna del WMS/LB Le statistiche di utilizzo delle varie istanze vengono aggregate secondo due chiavi: per WMS e per VO su intervalli di tempo configurabili Offre statistiche di utilizzo delle computing resource Offre statistiche di utilizzo delle istanze per utente Notifica a NAGIOS in caso di failure detection VO view WMS view

4 WMSMON : WMS instance details page

5 WMSMON : Resource usage N.B. : Non Visibile a utenti non iscritti
and user statistics N.B. : Non Visibile a utenti non iscritti

6 Load Balancing e Failover (1/2)
BDII: DNS Alias di 5 istanze (3 cnaf, 1 pd, 1 ferrara) round robin semplice, ripartisce il carico Failover dato da controlli nagios: toglie un ip dal dns se fallisce test VOMS: Server readwrite al cnaf,  replica readonly a pd.  Non c'e' load balancing. Ma al momento non serve. Il failover e' lato UI, se correttamente configurata, se fallisce un server il client prova ad utilizzare l’altro NAGIOS monitora le porte del server per ciascuna VO e manda sms se falliscono entrambe

7 Load Balancing e Failover (2/2)
FTS: FRONT END: BDII e WEBSERVICE sono replicati con dns alias Failover dato da controlli nagios, se una macchina non risponde viene tolta da alias. AGENTS: repliche in dns alias + controlli nagios, la macchina viene tolta dall’alias, ma i canali a quel punto non sono piu' disponibili BACKEND su cluster oracle, la ridondanza e' intrensica nel cluster oracle STORM: front end ridondato con macchine in alias DNS Gridftp server ridondati con macchine in alias DNS LFC: esiste replica readonly replica di atlas, readwrite replica di LHCB

8 WMS load balancing e failover
- Implementato sistema di loadbalancing basato su DNS N wms in loadbalancing ciascuno pubblica una metrica di stato funzionalita' e carico Metrica = M1(stato demoni, drain) * M2(load, dischi, memoria, traversal time)‏ Metrica: < 0 per problemi demoni, drain ; > 0 altrimenti gli N wms vengono ordinati per metrica crescente, quelli con metrica <0 vengono esclusi gli L <= N-1 wms piu' scarichi e funzionanti vengono pubblicati in round robin dietro un alias ogni 15 min viene il ciclo e aggiornato il DNS - Test con CMS ripetuto sistema funziona ed e' robusto, pero'... necessita' di integrare un test di sottomissione nella metrica - Job submission Test Implementato utilizzo status dei job di latency test per CMS Implementato utilizzo status dei job submission test nagios di sito

9 WMS load balancing e failover
Working on e Problemi Aperti integrazione di arbiter in WMSMonitor definizione standard per job submission tests: url con pubblicazione risultati ? e' opportuno inglobare nella metrica pubblicata dal servizio dei test esterni ? Load Balancing di LB ancora tutto da implementare anche se esite gia’ la possibilita di utilizzare piu’ LB per un WMS

10 Problema Sincronizzazione
Se le istanze nel pool dns non sono sincronizzate sia a livello di versione di m/w che di configurazione possono sorgere problemi veramente difficili da debuggare - Es. BDII con glue schema differenti perche’ un istanza non era stata aggiornata – anche se il servizio era up ci sono stati parecchi problemi Possibile soluzione – gestione centralizzata delle istanze anche quelle remote - Quattor? - altri tool di gestione istanze remote?