Grid nelle sezioni: Milano Luca Vaccarossa INFN – Sezione di Milano Workshop sulle Problematiche di Calcolo e Reti nell'INFN Maggio 2004 Sant' Elmo Beach Hotel, Castiadas (CA)

Introduzione Possibili aree di sovrapposizione, collaborazione sono gli strumenti e/o servizi di gestione (installazione, configurazione, ecc.) delle macchine di grid e di quelle di sezione.

Grid a Milano (persone) Personale assunto su fondi EU 1 FTE DataGrid 2 FTE DataTAG : gestione di tutto l’hw dei progetti Grid.

Breve storia di Grid a Milano Tutto iniziò con 10 biprocessori (Dell 1 GHz) per il testbed di EDG (Inizio 2002) Adesso gestione di n > 60 biprocessori (Intel 1 GHz – 2.8 GHz) e ~ 10 TB lordi di storage (NAS low cost). Ad esclusione dei server NAS di storage (e dei server LCFG), tutte le macchine sono state installate e vengono gestite con LCFG(ng)

Grid a Milano (risorse) Sito del TB di EDG Macchine di sviluppo/test per WP1 Qualche risorsa per i TB di EDT (WorldGrid, CMS-LCG0, ecc.) Tier2 di LCG (Atlas)

pagina web sito LCG Milano

Deployment di Grid Installazione/Gestione con LCFG(ng) Sistema Operativo : RH 7.3 (CERN) Molti pacchetti aggiuntivi (sul CE > 100 rpm su 700 rpm installati) Macchine dedicate

LCFGng: cos’è  Sistema per l'installazione e la gestione di farm adottato da Datagrid e' basato su LCFGng, un tool sviluppato all’Università di Edinburgo  Caratteristiche:  architettura client-server  installazione automatizzata (floppy/CDROM/PXE)  modulare: su ogni nodo agisce un insieme di agenti (componenti), ognuno dei quali attua la configurazione di un servizio  uno dei componenti effettua l'aggiunta/ upgrade/ downgrade/ rimozione dei pacchetti software su quel nodo(RPM-based)

Server LCFGng  Un server mantiene le configurazioni dei clients: o descritte mediante coppie nome-valore in files detti sorgenti o tali files sono compilati ottenendo i profili (files XML)  Ogni client e' descritto da 1 profilo (.xml)  I profili sono letti dai clients via HTTP  Normalmente oltre ad HTTP sul server sono attivi i servizi (ma potrebbero essere attivi su altre macchine): o DHCP (installazione) o TFTP (se si utilizza il boot PXE) o NFS (distribuzione packages RPM + prima installazione)

 Una volta cambiati i sorgenti, lanciando un opportuno comando dal server le modifiche sono propagate ai clients: o sono ricompilati i profili XML o viene inviata una notifica ai demoni in esecuzione sui clients (UDP) o ogni demone preleva (se necessario) il profilo via HTTP e lo salva in una cache locale (DBM) o il demone attiva solo i componenti la cui configurazione e' mutata o i componenti aggiornano la configurazione del nodo  Uno dei componenti (updaterpms) e' responsabile dell'installazione del software e ha un comportamento leggermente diverso: o e' eseguito solo al boot della macchina oppure via cron o sincronizza la lista di pacchetti indicata nel profilo del client con i pacchetti installati. NB: pacchetti installati manualmente non presenti nella lista sono rimossi! o ovviamente RPM based LCFGng: come funziona (2)

Ultimi sviluppi Scelta di inserire nuovi WN sotto rete privata Da LCFG a PBS in rete privata Tentativo di far coesistere servizi (es. DHCP, NFS, LCFG) su entrambe le reti Soluzione: inserire nel DNS della sezione i nodi in rete privata.

Installazione in sezione Installazione tramite kickstart “esteso” Script di post-installazione ~ 400 PC Linux gestiti (server, desktop, portatili) Release supportate : RH 7.3, 9.0, Fedora 1.0 Aggiornamenti + alcuni pacchetti extra (Condor, Cernlib, openafs, printmi, ecc.)

LCFG o Altro ? Al momento LCFG è indispensabile per installare/gestire macchine Grid Altre strade: KS + APT + LCFGcomponents (Napoli) A Milano vogliamo sperimentare qualcosa di analogo C’è futuro per LCFG ?

Due attività compatibili? GRID: Online 24x7, QoS, “roles & rules” (Report stato dei siti quotidiano, aggiornamento lista security contact settimanale) Sezione: C’è l’ “expertise” visione dei servizi di tipo locale