1 STATO DELLINTEGRAZIONE TRA I 4 PROGETTI AVVISO 1575/2004 Riunione del Comitato Tecnico sullInteroperabilità MUR, 29/11/2007 S.Pardi.

Presentazione sul tema: "1 STATO DELLINTEGRAZIONE TRA I 4 PROGETTI AVVISO 1575/2004 Riunione del Comitato Tecnico sullInteroperabilità MUR, 29/11/2007 S.Pardi."— Transcript della presentazione:

1 1 STATO DELLINTEGRAZIONE TRA I 4 PROGETTI AVVISO 1575/2004 Riunione del Comitato Tecnico sullInteroperabilità MUR, 29/11/2007 S.Pardi

2 2 Documento tecnico E stato creato di un Documento Operativo a cura del gruppo tecnico al fine di attuare le direttive fornite dal documento di interoperabilità. Tale documento contiene le specifiche prettamente tecniche proponendo delle soluzioni che dovranno comunque essere approvate dal comitato di interoperabilità.

3 3 Documento tecnico 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 11. INTEROPERABILITA CON ALTRE INFRASTRUTTURE

4 4 Documento tecnico 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 11. INTEROPERABILITA CON ALTRE INFRASTRUTTURE

5 5 TAG DI RUNTIME I TAG sono parole chiave utilizzate per descrivere le caratteristiche delle risorse sia hardware che software, i servizi offerti dai singoli siti, informazioni geografiche e tutto ciò che serve a descrivere delle risorse. Tali parole chiave vengono utilizzate dagli utenti per individuare le risorse che possiedono i requisiti per le proprie applicazioni, dai tools di monitoraggio e da altre applicazioni.

6 6 TAG DI RUNTIME 1. TAG DI RUNTIME DEFINIZIONE DELLE REGOLE PER LA PUBBLICAZIONE DEI TAG TAG MIDDLEWARE TAG SOFTWARE APPLICATIVO TAG PON TOOL KIT TAG SISTEMI OPERATIVI ED ARCHITETTURE Tabella delle variabili dambiente dei CE Tabella delle variabili dambiente di tipo SITE

7 7 TAG DI RUNTIME 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 PON TOOL KIT CRESCO-TOOL-KIT-x.ySupporto per il tool kit del progetto CRESCO CYBERSAR-TOOL-KIT-x.ySupporto per il tool kit del progetto CYBERSAR PI2S2--TOOL-KIT-x.ySupporto per il tool kit del progetto PI2S2 SCOPE--TOOL-KIT-x.ySupporto per il tool kit del progetto SCOPE

8 8 TAG DI RUNTIME TAGSPECIFICA ARCHITETTURE SI00MeanPerCPU=xxxxValore medio del Benchmartk SI00 tra tutti i WN SF00MeanPerCPU=yyyyValore medio del Benchmartk SF00 tra tutti i WN i386Architettura i386 i686Architettura i686 X86_64Architettura a 64 bit x86_64 IA64Architettura Itanium a 64 PowerPC_G4Architettura G4 PowerPC_G5Architettura G5 NETWORK INFINIBAND-1XRete in infiniband tra i Worker Node 1X INFINIBAND-4XRete in infiniband tra i Worker Node 4X

9 9 TAG DI RUNTIME http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_the_OS_name

10 10 JOB QUEUE Nome CodaCPUTIME (minuti) WALLTIME (minuti) PRIORITY jobmanager- -cresco_short 15120Alta jobmanager- -cresco_long 7201440Media jobmanager- -cresco_inf 28804320Bassa jobmanager- -cybr_short 15120Alta jobmanager- -cybr_long 7201440Media jobmanager- -cybr_infinite 28804320Bassa jobmanager- -pi2s2_short 15120Alta jobmanager- -pi2s2_long 7201440Media jobmanager- -pi2s2_inf 28804320Bassa jobmanager- -scope_short 15120Alta jobmanager- -scope_long 7201440Media jobmanager- -scope_inf 28804320Bassa

11 11 TAG + CODE JOB Le regole sui TAG e le CODE Job sono già state implementate sui prototipi di SCoPE e di PI2S2

12 12 SERVIZI COLLECTIVE CENTRALI E DISTRIBUITI Nel documento di interoperabiltià sono state individuate due classi di servizi collective: Servizi di primo livello: VOMS, BDII, RB/WMS, CE, SE, WN, UI Servizi di secondo livello: Monitoring, LFC, Ticket, Accounting

13 13 Per limplementazione dei servizi collective, i servizi individuati come di primo livello, sono replicati nelle varie sedi come stabilito nel documento di interoperabilità. Per quanto riguarda i servizi di secondo livello tecnicamente appare opportuno centralizzare alcuni di essi per evitare un eccessivo carico sullinfrastruttura Grid. SERVIZI COLLECTIVE CENTRALI E DISTRIBUITI

14 14 Possibile soluzione: Servizi di secondo livello distribuiti: LFC, Ticketing Servizi di secondo livello centralizzati: Monitoring, Accounting ??? SERVIZI COLLECTIVE CENTRALI E DISTRIBUITI

15 15 SERVIZI DI MONITORAGGIO Poiché i tool di monitoraggio producono traffico sui serivizi Grid si propone di centralizzarli in linea di massima. Le proposte di tool individuati di interesse per i 4 progetti sono: Web LDAP Browser (da installare in ogni sito) GridICE GStat SAM Real-Time Monitoring HGSM (GOCdb)

16 16 SERVIZI DI MONITORAGGIO Web LDAP Browser Descrizione: Servizio per consultare i BDII di ogni sito via web. Si propone che ogni sito installi un web LDAP Browser sui propri top BDII per consentirne la rapida e semplice consultazione Esempio di servizio web LDAP Browser http://scoperb01.dsf.unina.it

17 17 SERVIZI DI MONITORAGGIO SAM Descrizione: Tool per la certificazione dei servizi Esempio di servizio SAM https://sam-cybr.ca.infn.it/sam/sam.py Le azioni proposte possono essere così riassunte: Tutti i progetti abilitano una coda poncert o 4 code crescocert, cybersarcert, cometacert e scopecert sulle loro macchine, con priorità maggiore delle code job. Si definisce una VO poncert unica su un unico VOMS 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. Si definisce un unico SAM server centrale

18 18 SERVIZI DI MONITORAGGIO GridICE Descrizione: Tool di monitoring distribuito per Grid. Si propone che ogni sito abiliti tutti i servizi per la pubblicazione delle informazioni su GridICE sulla porta ldap 2136. Tali informazioni saranno utilizzate da un servizio GridICE centrale. Esempio di servizio Gridice http://scopegridice01.dsf.unina.it

19 19 SERVIZI DI MONITORAGGIO GStat Descrizione: Tool per la creazione di statistiche e monitoraggio delle installazioni dei siti operativi. Per il servizio GStat si propone di utilizzare il server goc.grid.sinica.edu.tw Esempio ed indirizzo del server http://goc.grid.sinica.edu.tw/gstat/

20 20 SERVIZI DI MONITORAGGIO Real-Time Monitoring Descrizione: Tool di monitoraggio basato su immagini satellitari per la collocazione geografica dei siti distribuiti. Si propone di registrare i siti nel database del servizio RTM dellImperial College (UK) al sito: http://gridportal.hep.ph.ic.ac.uk/rtm/

21 21 SERVIZI DI MONITORAGGIO Possibili installazioni: Web LDAP Browser (Ogni sito) GridICE (Centrale presso SCoPE) GStat (Centrale presso il server goc.grid.sinica.edu.tw ) SAM +VO poncert (Centrale presso CYBERSAR) Real-Time Monitoring (Centrale gestito da PI2S2) HGSM (GOCdb) (Da definire)

22 22 ISTALLAZIONE SOFTWARE APPLICATIVO Si propone che tutti i progetti identifichino una serie di tool e librerie necessarie per il corretto funzionamento dei job dei propri utenti. Tale insieme di software andrà a rappresentare un PON toolkit che dovrà essere installato sugli altri progetti per garantire agli utenti la piena interoperabilità.

23 23 ISTALLAZIONE SOFTWARE APPLICATIVO Questi toolkit potranno essere contraddistinti da un nome con una versione da pubblicare nella variabile CE_RUNTIME: CRESCO_TOOL_KIT_1.0 CYBERSAR_TOOL_KIT_1.0 COMETA_TOOL_KIT_1.0 SCOPE_TOOL_KIT_1.0

24 24 ISTALLAZIONE SOFTWARE APPLICATIVO Il software di progetto che comprende librerie e tool applicativi, verrà installato nelle aree /opt/exp_soft delle singole infrastrutture. Ciascun progetto dovrà abilitare sulle proprie risorse, un numero limitato (uno, al massimo due) di utenti sgm per le VO cresco, cybersar, cometa (pi2s2) e scope, in modo di garantire che ciascun progetto possa installare ed aggiornare i propri toolkit sulle altre infrastrutture.

25 25 ISTALLAZIONE SOFTWARE APPLICATIVO Software proprietario – occorre creare un sistema di distribuzione delle licenze per consentire solo agli utenti autorizzati di eseguire il running di job che utilizzano tali software.

26 26 Riassumendo Tra gli argomenti fin ora trattati appaiono maturi per una scelta: 1. TAG DI RUNTIME 2. JOB QUEUE 3. SERVIZI COLLECTIVE CENTRALI E DISTRIBUITI 4. SERVIZI DI MONITORAGGIO Argomenti ancora da approfondire 5. ISTALLAZIONE SOFTWARE APPLICATIVO

27 27 Prossimi step 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 11. INTEROPERABILITA CON ALTRE INFRASTRUTTURE

28 28 Discussione proposta Prima di affrontare la questione tecnica sembra opportuno discutere il punto 7 ABILITAZIONE DELLE VO COMUNI