Il servizio di Calcolo scientifico dell' INFN è stato sviluppato negli anni in stretta collaborazione con il Dipartimento di Fisica, che ha contribuito ampiamente e contribuisce tuttora alla sua realizzazione e gestione. Il Servizio si basa su un' infrastruttura virtualizzata su base XEN4, dove l'implementazione base è un cluster Scientific Linux CERN 5.
La composizione hardware è la seguente:
CPUs:
job execution:
150 core - 64 bit
30 core - 32 bit
20 core 64 bit per la gestione dello storage, backup e sviluppo
Storage:
40 TB su filesystem distribuito dcache e NFS (users e data hosting)
10 TB backup
10 TB su filesystem parallelo (sviluppo)
Links:
Il cluster è interconnesso a 1/10 Gbps, mentre è connesso verso l'esterno a 11 Gbps su loop GARR-x
Accesso:
Tramite 2 “User Interface”, il cluster risponde alle esigenze dei gruppi di ricerca teorici e sperimentali. È in grado di rispondere a migliaia di richieste eterogenee di esecuzione giornaliere.
farms-pic1 farms-pic2
Il cluster viene utilizzato principalmente per attività di calcolo legate alle esigenze dei gruppi di ricerca locale.
L'attività di sviluppo e ricerca, legata alle risorse IT, può essere divisa principalmente in 3 settori:
Sviluppo in High Energy Physics
Distributed data analysis tool
Workload management e data management
Farming
Scientific computing
GRID middleware
Integrazione di servizi
Sviluppi Futuri
Sviluppo in High Energy Physics
Distributed data analysis tool
Il computing model di LHC è basato su un' architettura multi-tiers, appoggiata sull' infrastruttura GRID (WLCG).
CMS Remote Analysis Builder (CRAB) è un' applicazione indirizzata ai bisogni della comunità sperimentale CMS; fornisce al fisico un' interfaccia semplice per fare data-analysis ad LHC in GRID.
CRAB interagisce con l'ambiente locale dell' utente, il Data Management Service e con il middleware GRID, alleggerendo l'utente di tutti i dettagli tecnici necessari all' interazione.
farms-pic3 farms-pic4
Workload management e data management
Il Workload Management System (WMS) è un toolkit python. L'utente sottomette il suo workflow di analisi al WMS tramite un Client leggero.
I task legati all'uso di database sono gestiti tramite MySQL, Oracle e CouchDB.
L'accesso a GRID è gestito tramite agenti strutturati in componenti.
Gli output degli utenti sono gestiti tramite l'agente di AsyncStageOut basato su soluzione FTS in gLite.
farms-pic1
Farming
il cluster è una soluzione mista per servire:
le esigenze di diversi gruppi di fisica sperimentale e teorica
diverse esigenze di calcolo (MPI, sequenziali, simulazioni...),
implementando un' unica soluzione (SL di base + gLite/EMI + ...)
middleware GRID
primo sviluppo di un nodo GRID completamente su rete privata (integrato in gLite)
implementazione di una "transparent-grid" (job locali come grid-job)
servizi di virtualizzazione
sistema completamente virtualizzato su base XEN
soluzioni di managing dinamico delle risorse
farms-pic2
batch system
Maui come sistema "Advanced Fair-share" (scalabilità, numero utenti e algoritmica)
uso non convenzionale del tagging finalizzato al monitoring
monitoring
locale (hardware e software via metrix)
GRID (strumenti di Grid - nagios test)
attività in HEP (monitoring per strumenti di data-transfer e data-storage)
farms-pic7
Sviluppi futuri
Dove siamo ora:
filesystem distribuiti (HDFS) con MapReduce in HEP
messaggistica (Apache ActiveMQ)
WNodes (Worker Nodes on Demands Service)
Andiamo verso una:
FARM atomica (unità = nodo + storage)
integrazione con Cloud: EaaS (Everything as a Service) anche attraverso una virtualizzazione completa dei servizi GRID
Alto livello di controllo attraverso:
maggior uso combinato di strumenti di monitor avanzato con una gestione dinamica delle risorse
maggior feedback continuo da data-mining complesso integrando servizi di messaggistica e DB.
Calcolo Scientifico
- Dettagli
- Scritto da Super User
- Categoria: Non categorizzato