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

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

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

4 Stato Interoperabilità E stata conclusa con successo la prima fase di interoperabiltià dei servizi di primo livello tra i prototipi dei progetti: CYBERSAR,PI2S2 e SCoPE CRESCO ha installato i servizi di primo livello con imminente integrazione con gli altri 3 progetti

5 Esperienza di Interoperabilità Nellambito del Progetto SCoPE il gruppo VO-Neural sta lavorando allinterfacciamento tra ASTROGRID e la GRID gLite Based. In particolare è stata svolta unesperienza di interoperabilità.

6 Rete Neurale per il riconscimento di nuclei galattici attivi (AGN). Problema: Addestrare una rete neurale con differenti parametri, al fine di individuare il setup ottimale. Il software utilizzato (SVM) già compilato. Requirement: SL 4 Esperienza di Interoperabilità

7 Sono stati sottomessi 110 job della durata minima di 1 ora ciascuno sulle risorse di calcolo di Cybersar e PI2S2 che utilizzano SL 4. I Job sono partiti dalla UI del progetto SCoPE utilizzando altresì il servizio di myproxy del progetto SCoPE per il rinnovo automatico del certificato. Esperienza di Interoperabilità

8 DIAGRAMMA DI FLUSSO UI-SCoPE RB-SCoPE VOMS-SCoPE SE WN CE YAIM SE WN CE YAIM SE WN CE YAIM SCoPE SITE CYBERSAR SITE PI2S2 SITE LFC My Proxy Resource Dont Match the Requirements

9 ASTROFISICA I risultati ottenuti hanno permesso di individuare I parametri ottimali per la rete neurale.

10 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. GESTIONE DOWNTIME E SISTEMA DI TICKET 8. ABILITAZIONE DELLE VO COMUNI 9. ACCOUNTING 10. SERVICE LEVEL AGREEMENT 11. INTEROPERABILITA CON ALTRE INFRASTRUTTURE

11 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. GESTIONE DOWNTIME E SISTEMA DI TICKET 8. ABILITAZIONE DELLE VO COMUNI 9. ACCOUNTING 10. SERVICE LEVEL AGREEMENT 11. INTEROPERABILITA CON ALTRE INFRASTRUTTURE

12 Monitoraggio Strategia di Distribuzione. Web LDAP Browser (Ogni sito) GridICE (Centrale presso il PON SCoPE) GStat (Centrale presso il server goc.grid.sinica.edu.tw ) SAM +VO poncert (Centrale presso il PON CYBERSAR) Down-Time (Centrale gestito da PON PI2S2)

13 Monitoraggio GSTAT SAM – CYBERSAR DOWN-TIME - PI2S2 GRIDICE – SCoPE

14 Interfacce e protocolli per lo Storage Protocolli di trasferimento Per mantenere il sistema di autenticazione basato sui certificati, si propone che i progetti abilitino il protocollo di trasferimento griftp per il trasferimento dati. Interfacce SRM e configurazioni Per garantire piena compatibilità ed interoperabilità con le altre strutture internazionali si propone che gli Storage Element impiegati per linteroperabilità dai progetti utilizzino interfaccia SRM supportando srmv1.1 ed srmv2.2. Ogni progetto abiliterà sugli storage element impegnati nellinteroperabilità, una quantità di spazio disco da definire creando le seguenti aree logiche: /home/cresco, /home/cyersar, /home/pi2s2, /home/scope.

15 Sistemi di ticket Si propone che ogni progetto utilizzi il proprio sistema di ticketing locale con il requirement che gli utenti possano accedere via certificato. Per la gestione dei ticket interprogetto, se un utente del progetto X riscontra problemi con il progetto Y, può aprire una segnalazione direttamente sul sistema di ticketing del progetto Y. I sistemi di ticketing devono prevedere almeno 3 aree per la suddivisione dei ticket: SITE – per i problemi tecnici di installazione VO – per le questioni relative alla singola virtual organization, certificazioni etc. APPLICATION – per il supporto delle applicazioni.

16 Sistemi di ticket Progetto CRESCO– Basato su Xoops Progetto CYBERAR– Basato su Xoops Progetto PI2S2 – Basato su Xoops Progetto SCoPE – Basato sul sistema del contact center ufficiale della Federico II

17 SCOPE TICKET TICKET PI2S2 TICKET-CYBERSAR

18 Software Applicativo Soluzione tecnica: Organizzazione in tool-kit di applicazione con pubblicazione nella variabile di RUNTIME Installazione del software tramite utenti SGM. Restano da definire quali tool-kit organizzare e quali applicazioni supportare.

19 Abilitazione delle VO Comuni Per approcciare le soluzioni tecniche, occorre stabilire quali VO si intende supportare.

20 Accounting Verrà trattato prossimamente dal gruppo degli operativi per le soluzioni tecniche. Alcuni degli strumenti da valutare: Dgas HLR

21 Service Level Agreement Attualmente in corso la discussione anche in EGEE per la definizione del Service Level Description I punti analizzati sono: DURATA DEL AGREEMENT SCOPO RESPONSABILITA SUPPORTO DI SECONDO LIVELLO HARDWARE E CRITERI DI CONNETTIVITA DESCRIZONE DEI SERVIZI MINIMI OFFERTI (Numero di CPU e di spazio disco) SERVICE HOURS (24/7 ?) DOWNTIME SUPPORTO SUPPORTO VO

22 Interoperabilità con altre infrastrutture Le soluzioni tecniche fin ora adottate sono adeguate per una prossima integrazione nei circuiti Italian ed Europei LCG/gLite based

23 Tempistica 01/09/07 25/10/07 AZIONI 1-4 NEI SITI PROVVISTI DI SERVIZI COLLETTIVI IMPLEMENTAZIONE DEI SERVIZI COLLETTIVI NEI SITI ANCORA SPROVVISTI INIZIO DEL TESTBED INTEGRAZIONE DEI 4 PON INTEGRAZIONE DEI 4 PON TESTBED SU TUTTA LA NUOVA GRIGLIA 30/01/ /12/07 29/11/07 SPECIFICHE DEI SERVIZI DI PRIMO LIVELLO SPECIFICHE SERVIZI DI SECONDO LIVELLO E SERVICES LEVEL AGREEMENT