1 INTEGRAZIONE TRA I 4 PON ATTIVITA DEL GRUPPO TECNICO OPERATIVO Incontro dei Progetti PON Avviso 1575 con il ROC di INFN Grid Catania 04/07/2008 Silvio Pardi

2 Progetti PON Avviso 1575/2004 TRISAIA 4 PROGETTI FINANZIATI CRESCO - ENEA CyberSar- Consz. COSMOLAB PI2S2- Consz. COMETA SCOPE – UNINA

3 Strategia di Interoperabilità Nel luglio 2007 sono iniziati i lavori del comitato tecnico di interoperabilità promosso dai quatto progetti e sostenuto dal Ministero dell’Università e Ricerca. Obiettivo del Tavolo è rendere i 4 progetti interoperanti come valore aggiunto per l’esperienza 1575 e per creare una infrastruttura di Grid nel meridione

4 Strategia di Interoperabilità L’attività di interoperabilità è stata promossa dal Comitato Tecnico di Interoperabilità composto dagli esponenti dei 4 progetti, rappreentanti del ministero e da esperti. Il gruppo si riunisce una volta al mese ed coordinato dal Prof. Leonardo Merola dell’Università Federico II

5 Strategia di Interoperabilità Sono stati creati alcuni documenti tra cui Documento Strategico di Connettività Documento Strategico di Interoperabilità Documento Tecnico Operativo Service Level Agreement Spunti di Riflessione per la programmazione

6 Naples, Networking Day, La “rete” dei PON estesa

7 IL CONSORTIUM GARR SI E’ DICHIARATO DISPONIBILE PER GARANTIRE DELLE CONNESSIONI PUNTO PUNTO TRA I CENTRI DI CALCOLO. PRONTO A STRETTO GIRO IL COLLEGAMENTO IN FIBRA AD 1Gb TRA SCoPE, CRESCO Connettività

8 GARR PI2S2 GARR Altri Enti e realtà Strategia di Interoperabilità

9 Vantaggi visione unica dell’intera infrastruttura nessuna modifica alla configurazione del RB locale assenza di un servizio centralizzato dedicato alla gestione del Grid Information Service e del Resource Broker implementazione semplice ed immediata Strategia di Interoperabilità

10 VO ATTTIVATE CRESCO CyberSAR COMETA SCoPE PONCERT Le 5 VO sono abilitate ad eseguire job e ad usare storage presso tutte le infrastrutture. Strategia di Interoperabilità

11 Documento tecnico Operativo SOMMARIO 1. TAG DI RUNTIME 2. JOB QUEUE 3. SERVIZI COLLECTIVE CENTRALI E DISTRIBUITI 4. SERVIZI DI MONITORAGGIO 5. ISTALLAZIONE SOFTWARE APPLICATIVO 6. INTERFACCE E PROTOCOLLI PER LO STORAGE 7. ABILITAZIONE DELLE VO COMUNI 8. ACCOUNTING 9. GESTIONE DOWNTIME E SISTEMA DI TICKET 10. SERVICE LEVEL AGREEMENT

12 TAGSPECIFICA MIDDLEWARE LCG-X_Y_ZSupporta versione del middleware LCG-X_Y_Z GLITE-X_Y_ZSupporta versione del middleware GLITE-X_Y_Z ANAGRAFICA CITTA’ (XXXX)Città dove è situato il sito PROJECT-NAME (XXXX)Nome del progetto SITE-NAME (XXXX)Nome del sito LIBRERIE E SOFTWARE MPICHLibreria MPICH MPICH2Libreria MPICH versione 2 MPI_HOME_SHAREDArchitettura MPI con directory Shared tra i worker node MPI_HOME_NOTSHAREDArchitettura MPI con directory NON Shared tra i worker node IDL-X.YSupporto per IDL versione X.Y ABAQUS-X.YSupporto per ABAQUS versione X.Y Sono stati definiti i TAG che descrivono - secondo gli standard europei che si è deciso di adottare - le caratteristiche delle risorse hardware e software. TAG DI RUNTIME

13 E’ stata adottata la seguente organizzazione: Servizi distribuiti: VOMS, BDII, RB/WMS, CE, SE, WN, UI LFC, Ticketing Servizi centralizzati: Monitoring, Accounting SERVIZI “COLLECTIVE” CENTRALI E DISTRIBUITI

14 I servizi di monitoraggio sono stati implementati in maniera centrale e suddivisi tra i progetti in modo da avere molti tools attivi ma senza una eccessiva ridondanza che produrrebbe un eccessivo traffico di interrogazioni. Web LDAP Browser (in ogni sito) GridICE (centralizzato presso SCoPE) GStat (centralizzato presso il server goc.grid.sinica.edu.tw ) SAM +VO poncert (centralizzato presso CYBERSAR) Real-Time Monitoring (centralizzato presso PI2S2) SERVIZI DI MONITORAGGIO

15 SAM, installato presso CyberSar Descrizione: Tool per la certificazione dei servizi tutti i progetti attivano sui propri CE delle code privilegiate con priorità maggiore delle altre, per l’esecuzione di Job di test da eseguire mediante il servizio SAM. SERVIZI DI MONITORAGGIO

16 SERVIZI DI MONITORAGGIO Deployement Tutti i progetti abilitano una coda poncert sulle loro macchine, ed una coda di certificazione specifica del progetto: crescocert, cybrcert, pis2scert e scopecert, tali code avranno priorità maggiore delle restanti code job. Si definisce una VO poncert unica sul server VOMS del progetto cybersar, server centrale nel quale vengono registrati un numero limitato di utenti privilegiati dei vari progetti. Tali utenti vengono mappati su utenti locali di tipo poncert01, poncert02 e cosi via su tutti i progetti. La coda poncert sarà accessibile solo agli utenti registrati alla VO poncert e verrà utilizzata per la sottomissione dei job di certificazione comuni, che dovranno essere stabiliti anche in funzione del Service Level Agreement. Le code di certificazione di progetto, verranno utilizzate per l’esecuzione di job di certificazione specifici creati dai singoli progetti.

17 CE LFC SRM RB SRM SERVIZI DI MONITORAGGIO

18 GSTAT Monitoraggio SAM – CYBERSAR DOWN-TIME - PI2S2 GRIDICE

19 Soluzione tecnica:  Realizzare tool-kit di applicazione  Pubblicare nella variabile di RUNTIME  Installare il software tramite utenti SGM (Software Grid Manager ) SOFTWARE APPLICATIVO

20 Supporto Applicazioni Comuni Sono stati individuati alcuni software di interesse su cui si sta lavorando per fornire un interfaccia comune: IDL - COMMERCIALE FLUENT - COMMERCIALE OpenFOAM SOFTWARE APPLICATIVO

21 IDL CRESCO: 80 licenze RunTime, 20 licenze sviluppo CyberSar: No licenze ma può installare il softeware per eseguire Job PI2S2: 18 licenze RunTime e alcune licenze sviluppo distribuite SCoPE: Licenza per creare eseguibili SOFTWARE APPLICATIVO

22 Considerare le licenze come patrimonio delle VO. In questo caso è possibile che un utente di una VO possa utilizzare la propria licenza su risorse di altre infrastrutture. SOFTWARE APPLICATIVO

23 Attività del Gruppo Tecnico Operativo

24 Eseguire il deployment sui 4 Progetti del Prodotto GRIDFLEX. Indagare sulla possibilità di creare dei nuovi job- type per il RB di tipo IDL, FLUENT o altro. I feedback dei 4 progetti e l’esperienza sui supporto di software commerciale essere di interesse anche nel contesto di EGEE III o IGI. SOFTWARE APPLICATIVO

25 Protocolli di trasferimento Per mantenere il sistema di autenticazione basato sui certificati, i progetti abiliteranno il protocollo di trasferimento griftp per il trasferimento dati. Interfacce SRM (Storage Resource Manager) e configurazioni Per garantire piena compatibilità ed interoperabilità con le altre strutture internazionali gli Storage Element impiegati per l’interoperabilità dai progetti utilizzeranno interfaccia SRM supportando srmv1.1 e srmv2.2. Ogni progetto abiliterà sugli storage element impegnati nell’interoperabilità una quantità di spazio disco da definire creando le seguenti aree logiche: /home/cresco, /home/cyersar, /home/pi2s2, /home/scope INTERFACCE E PROTOCOLLI PER LO STORAGE

26 Soluzioni storage attualemte attuate: CRESCO: DPM Cybersar: GPFS+DPM PI2S2: GPFS+DPM SCoPE: DPM sul prototipo, probabile implementazione di Lustre+SToRM o Lustre+DPM sulle nuove forniture. INTERFACCE E PROTOCOLLI PER LO STORAGE

27 DGAS (Distributed Grid Accounting System ) Si utilizzerà per le informazioni di accounting il sistema DGAS (ref. installando il sensore DGAS Gianduia sui Computing Element. HLR (Home Location Register ) Ogni sito installerà un HLR_RESOURCE ed un HLR_USER Server sul quale verranno registrate tutte le risorse disponibili per l’interoperabilità, in termini di code job. Sarà possibile individuare un HLR di secondo livello per raccogliere le informazioni dei differenti progetti in un unico punto, utilizzando il tool grafico HLR MON. ACCOUNTING

28 SISTEMI DI TICKET Ogni progetto utilizza il proprio sistema di ticketing locale Strategia di interoperabilità Ogni sistema di ticket comunica con tutti gli altri, ed è ingrado di far migrate I ticket. Se un utene CyberSar ha problemi con SCoPE manda un ticket dal sistema locale di CyberSar che verrà automaticamente migrato sul sistema di SCoPE. AREE · SITE – per i problemi tecnici di installazione · VO – per le questioni relative alla singola virtual organization, certificazioni etc. · APPLICATION – per il supporto delle applicazioni. SISTEMI DI TICKET Progetto CRESCO– Basato su Xoops Progetto CYBERSAR – Basato su Xoops Progetto PI2S2 – Basato su Xoops Progetto SCoPE – Basato su sistema proprietario HDA della PATH

29 SISTEMI DI TICKET Per far si che un utente possa aprire un ticket dal proprio sistema locale verso gli altri sistemi e possa altresì seguirne via WEB lo sviluppo è stata effettuata una modifica di xHelp. La comunicazione tra i 4 sistemi (3 Xoops/xHelp ed HDA) avviene tramite le mail portando nel campo oggetto l’id del ticket che consente di seguire negli step successivi del supporto

30 SCOPE TICKET TICKET PI2S2 TICKET-CYBERSAR TICKET CRESCO

31 E’ stato preparato un documento per definire il livello di servizi che i progetti si impegnano a garantire. Ci si basa sull’esperienza del Regional Operation Center (ROC) italiano di EGEE. SERVICE LEVEL AGREEMENT

32 Ogni sito coinvolto nell’infrastruttura interoperabile dovrà :  Fornire risorse di calcolo, storage e servizi: numero di CPU pari al 25% delle forniture ………………………  Garantire man power sufficiente per l’interoperabilità: almeno 2 persone, per un totale minimo di 1 FTE  Gestire efficacemente le risorse del sito: a) effettuare gli aggiornamenti relativi al software applicativo per le applicazioni di interoperabilità. b) modificare le configurazioni coordinandosi durante le riunioni telefoniche.  Prendere in carico e aggiornare i ticket relativi all’interoperabilità: tempo massimo di risposta: 48 ore dal lunedì al venerdì. Memorandum of Understanding Progetti Avviso 1575 Definizione del Service Level Agreement per l’interoperabilità tra i quattro progetti dell’Avviso 1575

33  Monitorare “proattivamente” il sito, controllando periodicamente lo stato delle risorse e dei servizi mediante tools di monitoraggio concordati: GridICE, Gstat, SFT, ecc.  Garantire continuità al supporto ed alla gestione del sito; durante i periodi unattended, si dovrà mettere in down-time il sito chiudendo le code.  Garantire la partecipazione dei tecnici operativi dell’ interoperabilità alle phone conference quindicinali.  Compilare i pre-report settimanali: entro il venerdì.  Supportare le VO di test e controllo (coda poncert) con priorità maggiore rispetto alle altre VO. Questo MoU dovrà essere sottoscritto dal responsabile del progetto e potrà essere aggiornato in base ai feedback ottenuti durante la sperimentazione. Memorandum of Understanding Progetti Avviso 1575 Definizione del Service Level Agreement per l’interoperabilità tra i quattro progetti dell’Avviso 1575

34 E’ attualmente in corso un’indagine per individuare aree applicative di interesse comune ai 4 progetti con l’obiettivo di creare VO tematiche trasversali. Tali VO costituiranno un valore aggiunto per l’integrazione e la coesione tra le infrastrutture nascenti ed avranno, tra le altre attività, l’obiettivo di individuare e manutenere il software applicativo di interesse specifico. Le soluzioni tecniche fin ora adottate sono adeguate per realizzare l’e-infrastruttura dell’Italia meridionale e per l’integrazione nell’ e-infrastruttura Grid italiana ed europea. ABILITAZIONE DELLE VO COMUNI INTEROPERABILITA’ CON ALTRE INFRASTRUTTURE

35

36

37 Supporto dei requirements middleware delle nuove comunità. Supporto del Software applicativo delle nuove comunità. Supporto per il Software commerciale. Esigenza di hardware ad elevate prestazioni Razionalizzare l’esperienza Ticket. Razionalizzare l’esperienza Monitoraggio Problema degli Aggiornamenti. Problematiche Osservate Integrazione

38 Personale Coinvolto nella attività di interoperabilità CYBERSAR Daniele Mura Gianmario Mereu CRESCO Giovanni Bracco Carlo Scio PI2S2 Rosanna Catania Giuseppe Platania Gianni Mario Ricciardi Gianluca Passaro Alberto Falzone Rita Ricceri Pietro di Primo SCOPE Gennaro Tortone Silvio Pardi Fulvio Serio Marco Scognamiglio Davide Bottalico Vania Boccia Anita Alicante Fulvio Polito Luca D’onofrio