1 STATO DELLINTEGRAZIONE TRA I 4 PROGETTI AVVISO 1575/2004 Riunione del Comitato Tecnico sullInteroperabilità MUR, 28/02/2008 S.Pardi
2 STATO INTEROPERABILITA CRESCO HA COMPLETATO LINSTALLAZIONE DEI SERVIZI CORE DI PRIMO LIVELLO ESEGUITA LABILITAZIONE DELLA VO CRESCO SU TUTTI I PROGETTI ESEGUITI I PRIMI TESTI DI FUNZIONAMENTO
3 GARR PI2S2 GARR Altri Enti e realtà Strategia di Interoperabilità COMPLETATA
4 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. ACCOUNTING 8. GESTIONE DOWNTIME E SISTEMA DI TICKET 9. SERVICE LEVEL AGREEMENT 10. ABILITAZIONE DELLE VO COMUNI 11. INTEROPERABILITA CON ALTRE INFRASTRUTTURE Documento Tecnico Operativo 5.0
5 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. ACCOUNTING 8. GESTIONE DOWNTIME E SISTEMA DI TICKET 9. SERVICE LEVEL AGREEMENT 10. ABILITAZIONE DELLE VO COMUNI 11. INTEROPERABILITA CON ALTRE INFRASTRUTTURE OK
6 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
7 Nome CodaTIPOCPUTIME (minuti)WALLTIME (minuti)PRIORITY jobmanager- -poncert Coda di Certificazione Prioritaria jobmanager- -crescocert Coda di Certificazione Prioritaria jobmanager- -cybrcert Coda di Certificazione Prioritaria jobmanager- -pi2s2cert Coda di Certificazione Prioritaria jobmanager- -scopecert Coda di Certificazione Prioritaria jobmanager- -cresco_short Coda Job Cresco15120Alta jobmanager- -cresco_long Coda Job Cresco Media jobmanager- -cresco_infinite Coda Job Cresco Bassa jobmanager- -cybr_short Coda Job Crybersar15120Alta jobmanager- -cybr_long Coda Job Crybersar Media jobmanager- -cybr_infinite Coda Job Crybersar Bassa jobmanager- -pi2s2_short Coda Job PI2S215120Alta jobmanager- -pi2s2_long Coda Job PI2S Media jobmanager- -pi2s2_infinite Coda Job PI2S Bassa Tutti i progetti implementano tre code job per ogni progetto, short, long e infinite più la coda poncert (per la certificazione dei sw) con differenti policies di CPUTIME e WALLTIME e differenti priorità. JOB QUEUE
8 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
9 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
10 Monitoraggio GSTAT SAM – CYBERSAR DOWN-TIME - PI2S2 GRIDICE
11 Soluzione tecnica: Realizzare tool-kit di applicazione Pubblicare nella variabile di RUNTIME Installare il software tramite utenti SGM (Software Grid Manager ) ISTALLAZIONE SOFTWARE APPLICATIVO
12 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 linteroperabilità dai progetti utilizzeranno interfaccia SRM supportando srmv1.1 e 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 INTERFACCE E PROTOCOLLI PER LO STORAGE
13 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 linteroperabilità, 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
14 Ogni progetto utilizzerà il proprio sistema di ticketing locale. Per la gestione dei ticket interprogetto, se un utente del progetto X riscontra problemi sul sito del 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 ecc. APPLICATION – per il supporto delle applicazioni. GESTIONE DOWNTIME E SISTEMA DI TICKET
15 SCOPE TICKET TICKET PI2S2 TICKET-CYBERSAR TICKET CRESCO
16 E stato preparato un documento per definire il livello di servizi che i progetti si impegnano a garantire. Ci si basa sullesperienza del Regional Operation Center (ROC) italiano di EGEE. SERVICE LEVEL AGREEMENT
17 corso la discussione E in corso la discussione dei seguenti punti principali: DURATA DELLAGREEMENT RESPONSABILITA SUPPORTO DI SECONDO LIVELLO HARDWARE E CRITERI DI CONNETTIVITA DESCRIZONE DEI SERVIZI MINIMI OFFERTI (Numero di CPU e di spazio disco) SERVICE HOURS DOWNTIME SUPPORTO VO
18 Ogni Progetto coinvolto nellinfrastruttura interoperabile dovrà : Periodo di validità 6 mesi Fornire risorse di calcolo, storage e servizi: numero di CPU pari al 25% delle forniture del progetto avviso 1575 in best- effort. ……………………… Garantire man power sufficiente per linteroperabilità: 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 allinteroperabilità: tempo massimo di risposta: 48 ore dal lunedì al venerdì. Memorandum of Understanding Progetti Avviso 1575 Definizione del Service Level Agreement per linteroperabilità tra i quattro progetti dellAvviso 1575 (IN DISCUSSIONE)
19 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.
20 E attualmente in corso unindagine per individuare aree applicative di interesse comune ai 4 progetti con lobiettivo di creare VO tematiche trasversali. Tali VO costituiranno un valore aggiunto per lintegrazione e la coesione tra le infrastrutture nascenti ed avranno, tra le altre attività, lobiettivo di individuare e manutenere il software applicativo di interesse specifico. Le soluzioni tecniche fin ora adottate sono adeguate per realizzare le-infrastruttura dellItalia meridionale e per lintegrazione nell e-infrastruttura Grid italiana ed europea. ABILITAZIONE DELLE VO COMUNI INTEROPERABILITA CON ALTRE INFRASTRUTTURE
21 ATTUAZIONE Proposta: Far partire il Service Level Agreement: Far partire le riunioni telefoniche tecniche operative a partire da Marzo. Far partire la gestione dei ticket entro fine Marzo. Aggiungere le risorse man mano che entrano a regime.
22 ATTUAZIONE CALENDARIO RIUNIONI TELEFONICHE 14 Marzo 28 Marzo 11 Aprile 24 Aprile 2 Maggio 16 Maggio
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 24/01/08 29/02/2008
24 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 24/01/08 28/02/08 29/02/2008