CMS 1 M. Biasotto – Bologna 20/01/2005 Infrastruttura di calcolo per CMS-Italia M.Biasotto – INFN Legnaro e i gestori dei centri CMS Italia

CMS 2 M. Biasotto – Bologna 20/01/2005 Outline Infrastruttura: risorse e servizi che permettano di accedervi e condividerle I centri di calcolo italiani Quali servizi per soddisfare i requisiti degli utenti? servizi locali e servizi distribuiti (Grid) Grid.it: struttura e modalita' per entrare in Grid configurazione minima e configurazione raccomandata farm in configurazione “ibrida” (locale + grid) Situazione attuale dei siti CMS

CMS 3 M. Biasotto – Bologna 20/01/2005 Ruolo dei Tiers nel Computing Model Tier-1: Storage e custodia (MSS) di parte dei dati ufficiali di CMS Storage e custodia di dati simulati Re-processing dei dati in custodia Processamento dei dati con codice dei Physics Groups Processamento dei dati con codice degli utenti Limitato supporto locale ad utenti singoli Tier-2: Risorse di calcolo per produzione dati simulati Supporto locale a Physics Groups e utenti singoli Storage di limitate quantita’ di dati (non in custodia) Tier-3 : Supporto locale a utenti singoli

CMS 4 M. Biasotto – Bologna 20/01/2005 Attivita' correnti Data Storage Gestione MSS e storage locale Produzioni locali Production manager locale, utilizzo di un local resource manager e di storage locale, nodo principale di PhedEx R&D Sviluppo tool di analisi per CMS Condivisione risorse e dati utilizzando i tools di LCG Supporto locale Accesso al local resource manager e storage locale ma anche accesso a cataloghi e risorse su grid

CMS 5 M. Biasotto – Bologna 20/01/2005 Risorse hardware Valori approssimati (estate 2004 e stime 2005) CPU (KSI2000)Disk (TB) CNAF164,0204,060,072,0 LNL127,0 46,050,0 PI16,850,85,013,0 BA13,621,64,06,0 BO13,221,25,8 PD35,0 3,85,8 RM12,416,45,09,0 CT10,8 1,03,0 FI7,211,25,2 MI12,4 1,0 NA6,0 1,03,0 PV0,04,00,02,0 PG14,4 2,4 TO10,4 2,84,0 Totale443,2545,2143,0182,2

CMS 6 M. Biasotto – Bologna 20/01/2005 Risorse hardware

CMS 7 M. Biasotto – Bologna 20/01/2005 Centri di calcolo italiani Ruoli attuali: Tier-1 (data storage, produzioni locali, R&D) CNAF Tier-2++ (produzioni locali, R&D, supporto locale) LNL (anche data storage), Pisa Tier-2 (R&D, supporto locale) Bari, Bologna, Padova, Roma Tier-3 (supporto locale) Catania, Firenze, Milano, Napoli, Pavia, Perugia, Torino Considerazione: Non c'e' una grossa distinzione tra T2 e T3; visti gli obblighi dei T2 verso la comunita’ CMS, potrebbe aver senso considerare come T2 solo LNL e Pisa

CMS 8 M. Biasotto – Bologna 20/01/2005 Supporto agli utenti Partendo da quello che vuole vedere l’utente finale, in ordine di priorita’: 1.accedere a risorse di calcolo per sviluppo codice e analisi 2.conoscere i dati disponibili localmente 3.analizzare i dati disponibili localmente (sa interattivamente che in modo batch) 4.conoscere i dati disponibili globalmente 5.copiare localmente i dati necessari 6.analizzare dati remoti 7.condividere con utenti remoti i risultati prodotti localmente 8.dare accesso ad utenti remoti ai dati locali 9.dare accesso ad utenti remoti alle risorse locali

CMS 9 M. Biasotto – Bologna 20/01/2005 Servizi locali A.L'accesso alle risorse locali avviene tramite un tradizionale login B.Sulle macchine di login sono disponibili l'ambiente di sviluppo ed il software applicativo 1. e' soddisfatto (accesso a risorse per sviluppo codice) C.Localmente e' disponibile un database contenente cataloghi POOL di dati 2. e' soddisfatto (elenco dati locali) D.Localmente e' disponibile un batch system che da' accesso ai nodi di calcolo E.Le aree di storage locali ed il software applicativo sono visibili dalle macchine di login e dai nodi batch 3. e' soddisfatto (analisi dati locali) Fin qui sono stati utilizzati solamente tool e servizi locali...

CMS 10 M. Biasotto – Bologna 20/01/2005 Servizi grid F.Dalle macchine di login si puo' accedere ad un sistema che conosce i dati di CMS (RefDB/Phedex) 4. e' soddisfatto (elenco dati remoti) G.Le macchine di login sono User Interfaces di LCG 5. e' soddisfatto, se i dati sono su server opportuni (import dati) 6. e' soddisfatto (analisi dati remoti) 7. e' soddisfatto, posto che si possa scrivere sui server (condivisione dati locali) H.Le aree di storage locali sono servite da uno Storage Element di LCG e i dati sono registrati nel servizio F) 7. e 8. sono soddisfatti (condivisione e accesso ai dai locali) I.Il sistema batch locale e' visto da un Computing Element di LCG 9. e' soddisfatto (accesso da remoto alle risorse locali) L'aggiunta dei tools grid non elimina le funzionalita' locali

CMS 11 M. Biasotto – Bologna 20/01/2005 Configurazione minimale I servizi A.-E. sono la richiesta base per qualsiasi sito, in quanto senza di essi sarebbe preclusa la possibilita’ di analizzare dati (requisiti 1.-3.) C richiede l’installazione di un server MySQL Il servizio F. e’ fornito da CMS Il servizio G. e’ implementato semplicemente rendendo disponibile sulle macchine di login il software di UI di LCG (nessun server e’ necessario!) Sono quindi soddisfatti i requisiti cioe’ la possibilita’ di analizzare tutti i dati di CMS Per CMS-Italia la configurazione minimale per qualsiasi sito e’ quella che fornisce i servizi A)-G), cioe’ che soddisfa i requisiti (accesso a dati e risorse locali e globali).

CMS 12 M. Biasotto – Bologna 20/01/2005 Configurazione raccomandata I siti che ospitano dati di CMS devono fornire anche il servizio H. (SE) in modo da consentire la copia dei dati ad altri siti. E’ raccomandato che i siti che ospitano i dati implementino anche il servizio I. (CE) in modo che utenti di altri siti possano soddisfare il requisito 6. (analisi remota dei dati). Implementare il servizio I. paradossalmente potrebbe semplificare la vita ai gestori locali l’installazione del software applicativo potrebbe essere fatta da remoto (software manager) la gestione del sito puo’ essere affidata ad un servizio calcolo non necessariamente CMS-specific (che e’ forse piu’ semplicemente disponibile in sezione!)

CMS 13 M. Biasotto – Bologna 20/01/2005 Produzioni e Data Storage I siti che garantiscono la possibilita’ di fare produzioni locali (CNAF, LNL, PI) non sono influenzati dal fatto di essere configurati con tutti i servizi LCG (CE, SE, UI). La presenza di servizi SE semplifica la configurazione del sito come nodo PhedEx garantendo quindi la possibilita’ di trasferire dati in input/output al sistema di distribuzione di dati di CMS (vedi talk D. Bonacorsi) La presenza di servizi di CE rende i dati prodotti immediatamente disponibili per l’analisi remota da parte di tutti i fisici di CMS-Italia (vedi talk S. Lacaprara) Tutti gli altri siti, se configurati con CE ed SE, possono essere utilizzati per produzioni distribuite. Il Tier-1 e i Tier-2++ devono fornire tutti i servizi di CE ed SE. Si raccomanda che almeno gli altri Tier- 2 lo facciano. CMS-Italia partecipera' al deployment di un sistema di produzioni distribuite basato su LCG (Grid.it).

CMS 14 M. Biasotto – Bologna 20/01/2005 La struttura di Grid.it Dal punto di vista organizzativo, gerarchia di diversi organismi per i vari compiti previsti: Coordinamento operazioni, supporto ai servizi, supporto agli utenti, gestione release e documentazione, ecc. Gestione di una release del middleware specifica per Grid.it e' in pratica un super-set di LCG: alla release base di LCG si aggiungono customizzazioni specifiche per la grid italiana e alcune funzionalita' in piu' (ad es. VOMS, DAG jobs) Deployment di servizi specifici per la grid italiana: Resource Brokers, Information Index, Monitoring, ecc. Buon livello di supporto sia per i site admin che per gli utenti finali: Sito web con documentazione, knowledge base, sistema di ticketing per gestione dei problemi

CMS 15 M. Biasotto – Bologna 20/01/2005 Grid.it: struttura organizzativa

CMS 16 M. Biasotto – Bologna 20/01/2005 Come entrare in Grid.it (I) Livello minimo: solo User Interface Installazione middlware UI su una macchina: download di un tar con script di setup, disponibile per RH7.3 e SL, richiede java Certificato personale + registrazione alla VO di CMS Condividere la farm locale CMS con un sito Grid.it gia' presente in sezione La gestione sistemistica della farm potrebbe essere demandata ad altri, occupandosi solo della parte CMS- specific locale Naturalmente si vuole tenere un certo livello di controllo sulle proprie risorse: Gateway con home locali e sw applicativo custom gestito in proprio Area storage locale oltre a quella su SE Coda batch locale con priorita' sui propri nodi di calcolo

CMS 17 M. Biasotto – Bologna 20/01/2005 Come entrare in Grid.it (II) Diventare a tutti gli effetti un sito Grid.it Maggiore controllo ma ovviamente maggiore impegno Al momento (release 2.3) supportata solo installazione con LCFG, dalla prossima release e' prevista solo l'installazione manuale del middleware (in buona parte automatizzata da script), senza tool sofisticati come LCFG (o il suo successore Quattor) Notevole lo sforzo richiesto inizialmente per partire, ma una volta avviati la gestione non e' particolarmente onerosa, anzi c'e' il vantaggio di trovarsi tante cose gia' pronte (security updates, sw applicativo, ecc.) Farm in configurazione “ibrida” per poter essere usata anche localmente come prima

CMS 18 M. Biasotto – Bologna 20/01/2005 Configurazione farm “ibrida” (I) La macchina “gateway” della farm locale viene mantenuta, con le home degli utenti locali e un'area con il software applicativo “locale” (codice CMS custom, ecc.), entrambe esportate via NFS Si aggiunge una macchina nuova a fare da CE (gateway per la grid) Almeno un server viene reinstallato come SE, l'area di storage puo' essere partizionata come si vuole: parte dedicata a grid e parte ad uso esclusivamente locale ma in teoria e' anche possibile non avere un SE o puntare verso un SE remoto in un altro sito I nodi di calcolo sono reinstallati col middleware di grid e montano via NFS sia le aree grid (da CE ed SE) che quelle locali (dal vecchio gateway e da SE o server locali): possono runnare sia in modo grid che locale

CMS 19 M. Biasotto – Bologna 20/01/2005 Configurazione farm “ibrida” (II) Nel batch system si crea una coda riservata agli utenti locali, dove si possono dinamicamente cambiare priorita', uso esclusivo di certe macchine, ecc. Dal punto di vista pratico la cosa richiede una certa customizzazione della configurazione di default fornita dalle release di Grid.it Un punto importante e' che la migrazione da farm locale a grid si puo' fare in maniera graduale: Creazione di una piccola farm grid-only (cioe' configurata come da default) con un pool minimo di macchine (CE, SE, 1-2 WN), senza modificare la farm locale Si prova poi ad applicare le modifiche per la configurazione ibrida e solo quando si e' certi che tutto funziona si procede via via a reinstallare i nodi di calcolo come WN di grid

CMS 20 M. Biasotto – Bologna 20/01/2005 Configurazione farm “ibrida” FastEth GE backbone GE backbone SWITCH N1FastEth SWITCHS1 SE1 N24FastEth SWITCHSn To WAN SE2 SE3 ComputingNodes ComputingNodes Local Servers Grid Storage Elements GWG1 UI Local Gateway Local Login CE N1 N24

CMS 21 M. Biasotto – Bologna 20/01/2005 Situazione attuale dei siti CMS Stato GridServizi SitoSito LCGSito Grid.itfarm condivisaUser InterfacePhedExPubDB CNAFX XXX LNLX X-/ PIX X-- BA X XXX BO X X-X PD X X-X Roma --- CT --- FI ?--- MI --- NA --- PV --- PG --- TO ---