1 / 21

Infrastruttura di calcolo per CMS-Italia M.Biasotto – INFN Legnaro

Infrastruttura di calcolo per CMS-Italia M.Biasotto – INFN Legnaro e i gestori dei centri CMS Italia. Outline. Infrastruttura: risorse e servizi che permettano di accedervi e condividerle I centri di calcolo italiani Quali servizi per soddisfare i requisiti degli utenti?

nyx
Download Presentation

Infrastruttura di calcolo per CMS-Italia M.Biasotto – INFN Legnaro

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Infrastruttura di calcolo per CMS-ItaliaM.Biasotto – INFN Legnaro e i gestori dei centri CMS Italia

  2. 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

  3. 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

  4. 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

  5. Risorse hardware Valori approssimati (estate 2004 e stime 2005)

  6. Risorse hardware

  7. 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

  8. Supporto agli utenti • Partendo da quello che vuole vedere l’utente finale, in ordine di priorita’: • accedere a risorse di calcolo per sviluppo codice e analisi • conoscere i dati disponibili localmente • analizzare i dati disponibili localmente (sa interattivamente che in modo batch) • conoscere i dati disponibili globalmente • copiare localmente i dati necessari • analizzare dati remoti • condividere con utenti remoti i risultati prodotti localmente • dare accesso ad utenti remoti ai dati locali • dare accesso ad utenti remoti alle risorse locali

  9. Servizi locali • L'accesso alle risorse locali avviene tramite un tradizionale login • Sulle macchine di login sono disponibili l'ambiente di sviluppo ed il software applicativo1. e' soddisfatto (accesso a risorse per sviluppo codice) • Localmente e' disponibile un database contenente cataloghi POOL di dati2. e' soddisfatto (elenco dati locali) • Localmente e' disponibile un batch system che da' accesso ai nodi di calcolo • Le aree di storage locali ed il software applicativo sono visibili dalle macchine di login e dai nodi batch3. e' soddisfatto (analisi dati locali) Fin qui sono stati utilizzati solamente tool e servizi locali...

  10. Servizi grid • Dalle macchine di login si puo' accedere ad un sistema che conosce i dati di CMS (RefDB/Phedex)4. e' soddisfatto (elenco dati remoti) • Le macchine di login sono User Interfaces di LCG5. 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) • 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) • Il sistema batch locale e' visto da un Computing Element di LCG9. e' soddisfatto (accesso da remoto alle risorse locali) L'aggiunta dei tools grid non elimina le funzionalita' locali

  11. 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 4.-7. 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 1.-7. (accesso a dati e risorse locali e globali).

  12. 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!)

  13. 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).

  14. 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 • http://grid-it.cnaf.infn.it

  15. Grid.it: struttura organizzativa

  16. 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

  17. 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

  18. 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

  19. 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

  20. N24 N24 N24 N1 N1 N1 SE3 GW SE2 SE1 S1 Sn Configurazione farm “ibrida” Computing Nodes Computing Nodes FastEth FastEth FastEth SWITCH SWITCH SWITCH GE backbone To WAN CE UI G1 LocalGateway LocalLogin LocalServers Grid StorageElements

  21. Situazione attuale dei siti CMS

More Related