Grid nelle sezioni:
Milano
Luca Vaccarossa
INFN – Sezione di Milano
[email protected]
Workshop sulle Problematiche di Calcolo e Reti
nell'INFN
24-28 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)
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 (<nomehost>.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)
LCFGng: come funziona (2)
 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
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