Presente e futuro.

 Introduzione  Funzionalità  Modello

 DGAS è un software di accounting particolarmente adatto alle esigenze di una grid nazionale.  La sua struttura flessibile permette molti schemi di deployment.

 Le funzionalità fornite derivano tutte da richieste ricevute dagli utenti: Server, Client e Sensori sono disponibili per SL4 ed SL5, 32 e 64 bit Sensori per LSF, PBS, Condor (SGE in sviluppo) Supporto per CE LCG e CREAM Accesso locale ai dati di accounting per i site manager Architettura distribuita e dalla provata scalabilità Utilizzabile come sistema di accounting nazionale o di una Virtual Organization Policy di accesso alle informazioni configurabile Interfacce CLI e WEB (HLRmon) Gestione di job grid e locali Possibilità di implementare procedure di storage accounting

Il modello base di deployment prevede che un sito usi i sensori forniti con DGAS per raccogliere e inviare gli Usage Record dei job eseguiti (locali o grid) a un server dedicato all’accounting del sito, noto come HLR di sito, dove rimangono accessibili al site manager. DGAS attualmente utilizza per tutte le comunicazioni un meccanismo di trasporto di tipo push, implementato con GSS over TCP ed un protocollo proprietario per la definizione degli UR. Site Batch farm (LSF,PBS,Condor) Batch farm (LSF,PBS,Condor) CE (LCG,CREAM) HLR node Site HLR (DGAS server) Site HLR (DGAS server) DGAS sensors Site Manager

EGEE- Grid 9/22/ National grid Site 2 Site HLR Site 1 Site HLR National grid manager EGEE Central DB Site 3 Site HLR Site 2 Site HLR HLR 2 hlrMon Grid jobs

 Stabilità  Efficienza  Ridondanza  Utilizzazione

 Sia la parte client che server sono provatamente stabili. Le fonti di instabilità riscontrate in passato dagli utenti sono state aggiustate. Il sistema opera senza necessità di grossi bug fix ormai da circa due anni. Ogni demone responsabile di parti chiave del workflow è monitorato da un watchdog ed il sistema può far fronte autonomamente a malfunzionamenti che dovessero presentarsi. Ad esempio un demone che si blocchi a causa di un file di log pieno, verrebbe restartato automaticamente al liberarsi delle risorse. Questo, il più delle volte, permette di indagare i problemi senza fretta, garantendo il servizio.

 La corrispondenza tra i dati grezzi disponibili nei log dei CE ed i record archiviati nei database è stata più volte verificata.  In alcuni casi, ad esempio al T1 il controllo viene fatto continuamente in modo automatico.

 Circa 80 siti raccolgono dati per più di 18 milioni di record all’anno. In figura si vede la distribuzione del numero di record accountati dai siti maggiori negli ultimi due anni.  Recenti test condotti sul testbed di D-Grid con l’ultima versione (3.4.0) di DGAS riportano un throughput, nel trasferimento CE -> HLR, di 100k record / giorno.

 Il sistema garantisce molti sistemi di ridondanza, implementabili sia a livello di middleware che di database backend.  La ridondanza del sistema non riguarda solo l’infrastruttura dei server. In fase di progettazione e sviluppo si è sempre cercato di avere abbastanza ridondanza nei dati e nelle procedure di comunicazione per evitare perdita di informazioni.  In caso di incidenti è possibile recuperare i dati anche a distanza di tempo dal malfunzionamento.

Grid Regional grid 2 12 Regional grid 1 Site 2 Site HLR Grid Manager Site 1 Site HLR HLR 2 Regional grid manager HLR 2 VO 1 HLR 2 VO HLR 2 Site 3 Site HLR

13 Key concepts Physical separation between services and data. Logical separation between read and write data flow. Benefits Improved fault tolerance. If a service crashes, information is preserved, allowing easier and faster system recovery. Clean data management, replica dedicated engine for reads and writes. Key concepts Physical separation between services and data. Logical separation between read and write data flow. Benefits Improved fault tolerance. If a service crashes, information is preserved, allowing easier and faster system recovery. Clean data management, replica dedicated engine for reads and writes. write 2LHLR host read 2LHLR host Site HLRS Clients [HLRMON] Db master host Db replica host hlrd Send Data insert records read records get info

 DGAS è attualmente utilizzato su tutta l’infrastruttura INFNgrid, ad oggi 57 siti di produzione. Oltre a questi forniamo il servizio di accounting ad alcuni siti internazionali, ad esempio a siti afferenti ad e-NMR ed in passato EU- INDIA.  L’ultima release (3.4.0), dopo un’attenta fase di test, sta entrando in produzione in Germania su tutta l’infrastruttura D-GRID, dove i 9 resource centres che la compongono contano di finire l’upgrade per marzo  HellasGrid ha installato un testbed di valutazione di DGAS+HLRmon composto da due siti di cui prendono i dati da Novembre 2009 In questi giorni gli stessi siti stanno ampliando il supporto dato a DGAS, integrando nei database anche i dati relativi a job eseguiti prima dell’inizio dei test.

 Significative sono le motivazioni che hanno spinto D- Grid all’adozione di DGAS: “ The Distributed Grid Accounting System (DGAS) was choosen as the D-Grid accounting system because of scalability and the possible adaptation to account the usage of the three middleware packages Globus Toolkit, gLite and UNICORE” “DGAS is the accounting system of choice for the D-Grid infrastructure because it is extensible to account the resource usage independant from the middleware, which was chosen to submit the job. The conducted extension to DGAS decouples the accounting system widely from the gLite middleware, so that deployments at sites without gLite support are possible.” La possibilità di mappare gli utenti alla relativa VO anche per i siti che non adottano gLite.

Utilizzazione (3)  Dopo l’ultima fase di consolidamento del software, per rimanere competitivi e aumentare l’appetibilità di DGAS al di fuori della grid Italiana, si rendono necessarie nuove funzionalità quali: Adattamento dell’HLR in modo da poter importare dati non solo tramite il sistema di comunicazione nativo di DGAS ma anche con messaging (in modo ad importare dati da siti che usano sensori APEL) Adattamento del protocollo di comunicazione attuale con il DB centrale di EGEE (mysql insertion) per poter pubblicare UR tra diversi domini amministrativi tramite messaging Adattamento HLRmon in modo da poter importare dati (UR consumer) attraverso messaging, e quindi essere utilizzabile come portale di accounting nazionale per NGI basate su altri sistemi di accounting es. APEL  Raccolta di nuove metriche: consolidare la parte di storage accounting  Possibilità di utilizzare varie metriche di normalizzazione (SI2k, HEPSPEC, Spec INT 2006, etc.)  Possibilità di visualizzare i dati di accounting in HLRmon aggregando dati per gruppi/ruoli VOMS

Sensori installati su 80 siti (di cui 57 di produzione). 12 HLR di sito per T1,T2 e i siti maggiori. 2 HLR Multi-sito (PD,CT) per i siti minori. Una HLR di Secondo Livello (logico) responsabile di raccogliere dati da tutta l’infrastruttura. I dati vengono poi resi disponibili al GOC e ad HLRmon. Circa 18 milioni di record all’anno. GOC

 Altrimenti detto: perchè noi usiamo DGAS? APEL è sicuramente il MW di accounting più diffuso sull’infrastruttura EGEE ed è supportato direttamente da gLite. DGAS permette l’accounting di workload locale, con possibilità di assegnarlo alla giusta VO. DGAS contiene più informazioni nel suo Usage Record, garantendo analisi semplicemente non possibili con APEL. L’infrastruttura è notevolmente più flessibile, grazie al meccanismo delle HLR di secondo livello. DGAS non ha bisogno di aggiustamenti per essere usato da una grid nazionale. In DGAS il dataflow garantisce di non perdere dati in caso di malfunzionamenti, problemi di rete o periodi di downtime di uno qualsiasi dei servizi coinvolti.

 Altrimenti detto: perchè noi usiamo DGAS (cont.)? In DGAS le informazioni sono accessibili, con le dovute restrizioni, a tutti i livelli. Dall’utente all’amministratore dell’intera infrastruttura. DGAS fornisce gli strumenti per estendere i suoi campi di utilizzo. Ad esempio per implementare storage ed economic accounting. E’ sempre possibile effettuare verifiche incrociate tra i dati in DGAS ed i dati grezzi sui batch system. DGAS è la fonte di dati di HLRmon. Molte delle cui funzionalità avanzate dipendono dalla ricchezza di informazioni presente nello Usage Record di DGAS.

APEL RecordIdentity ExecutinSite LocalJobID LocalUserID LCGUserID LCGUserVO ElapsedTime BaseCpuTime ElapsedTimeSeconds BaseCpuTimeSeconds StartTime StopTime StartTimeUTC StopTimeUTC StartTimeEpoch StopTimeEpoch ExecutingCE MemoryReal MemoryVirtual SpecInt2000 SpecFloat2000 EventDate EventTime MeasuramentDate MeasuramentTime DGAS dgJobId date gridResource gridUser userFqan userVo cpuTime wallTime pmem vmem amount start end iBench iBenchType fBench fBenchType acl id lrmsId localUserId hlrGroup localGroup endDate siteName urSourceServer hlrTid accountingProcedure voOrigin GlueCEInfoTotalCPUs executingNode uniqueChecksum UR comparison - 1

APEL RecordIdentity ExecutinSite LocalJobID LocalUserID LCGUserID LCGUserVO ElapsedTime BaseCpuTime StartTime StopTime ExecutingCE MemoryReal MemoryVirtual SpecInt2000 SpecFloat2000 EventDate+EventTime MeasuramentDate+MeasuramentTime DGAS dgJobId date gridResource gridUser userVo+userFqan cpuTime wallTime pmem vmem amount start end iBench+BenchType fBench+BenchType acl id lrmsId localUserId hlrGroup localGroup endDate siteName urSourceServer hlrTid accountingProcedure+voOrigin (local or grid job?) GlueCEInfoTotalCPUs executingNode uniqueChecksum UR comparison - 2

APEL RecordIdentity ExecutinSite LocalJobID LocalUserID LCGUserID LCGUserVO ElapsedTime BaseCpuTime StartTime StopTime ExecutingCE MemoryReal MemoryVirtual SpecInt2000 SpecFloat2000 EventDate+EventTime DGAS dgJobId date gridResource gridUser userVo+userFqan cpuTime wallTime pmem vmem amount start end iBench+BenchType fBench+BenchType acl lrmsId localUserId hlrGroup localGroup endDate siteName accountingProcedure+voOrigin (local or grid job?) GlueCEInfoTotalCPUs executingNode UR comparison - 3

 Problemi aperti Come archiviare gli Usage Record con benchmark multipli  Richieste degli utenti Normalizzazione “puntuale” basata sulla potenza del Worker Node che ha eseguito il job Estendere le funzionalità di storage accounting Riprendere il discorso sull’economic accounting Migliorare il supporto per l’accounting di job MPI  Esigenze tecnologiche Uso di un sistema di messaging (ActiveMQ?) per il trasporto dei dati verso il GOC Adozione di standard di esportazione e importazione di Usage Record, minimizzando gli impatti in termini di prestazioni Rendere più flessibile schema e protocollo di trasporto degli Usage Record.

 Requirement : poter utilizzare valori di benchmark relativi ai singoli worker node per normalizzare le misure di utilizzo della CPU.  Lato server non servono modifiche al codice (informazione relativa al worker node che ha eseguito il job disponibile nello usage record).  Tabelle e metriche definibili dall’utente potrebbero essere una soluzione.  Punto aperto: come organizzare il database per i valori dei benchmark? Può essere gestito all’interno dell’information system? Può essere un database relazionale installato da qualche parte? Deve gestire i singoli worker node o delle classi? E’ necessario mantenere uno storico dei valori?  Uno studio di fattibilità (G.Guizzanti,F.Rosso,P.Solagna) indica che l’uso di un database relazionale, sull’HLR server, popolato in automatico da sonde sui WN dovrebbe permettere di risolvere il problema, garantendo piena integrazione con DGAS e HLRmon. 9/22/

9/22/ Site CE (LCG,CREAM) HLR node DGAS sensors Site Manager 1. Plain Usage Record to HLR server. 2Sys manager fills the WN database with up-to-date benchmark metrics 3. Joning the info on the Usage Records and WN databases results in the per- WN normalization requested. HLR database WN database Usage records DB WN Normalized records

 DGAS provides a storage accounting functionality which enables the site to keep track of VO space consumption on their storage elements.  Due to the highly heterogeneous environment in which Storage Accounting has to be operated, DGAS just provides a toolkit that sites can leverage to implement their accounting sensors. The whole storage accounting toolkit has been designed to be as simple as possible and highly customizable.  Plugins, provided by Site Managers, can been produced for dCache, StoRM, DPM and Castor. 9/22/

HLR-listener RDBMS Ping Query getRecor d dgas- sendRecord DGAS Monitoring DGAS Monitoring UR- forward Hlr::voStorageRecords Hlr::sysDef* Hlr::voStorageRecords Hlr::sysDef* HAD Site HLR node Storage Element Storage Element Storage Usage Sensor

28 Site CE (LCG,CREAM) HLR node Site HLR (DGAS server) Site HLR (DGAS server) PA DGAS sensors Site Manager 1. Plain Usage Record to HLR server. 2. HLR asks the valid CE price to the PA. 3. The HLR computes the job Cost using the algorithm provided by the site manager. 4. The Usage Record containing the assigned job cost is inserted in the HLR database. HLR database

A breve termine il sistema permetterà di ridefinire a livello di configurazione il contenuto dello Usage Record. Questo permetterà agli amministratori di sistema di implementare nuove metriche nei record ed eventualmente ridefinire quelle esistenti. Questo aumenterà notevolmente la flessibilità, permettendo di soddisfare molti nuovi use cases senza dovere necessariamente modificare il codice.

 Sviluppo  Test  Certificazione  Supporto  Man power

 Per quasi tutto il ciclo di vita del software, il codice è stato sviluppato da due programmatori a tempo pieno. Nell’ultimo anno e mezzo il numero si è ridotto a uno, con l’aggiunta di alcuni contributi esterni sporadici.  Il codice è archiviato sul CVS del CERN.  Per ogni “Release” sia major che minor viene creato un branch CVS.  Ogni set di RPM rilasciati corrisponde comporta la creazione del rispettivo Tag CVS.  Solitamente sono presenti contemporaneamente tre branch di codice attivi: Branch della release di produzione (in questo momento 3_2_12). Branch della release in fase di test (in questo momento 3_4_0). Branch di sviluppo (in questo momento 3_4_1).  Il software process è gestito tramite ETICS.

 Il software è dotato di un set di unit test e di una regression suite. Lo sviluppo è sempre accompagnato dalla scrittura di opportuni moduli della suite di regressione. Ove possibile si usano anche tecniche di code coverage per avere una misura della quantità di codice effettivamente coperto dai test. Scrivere I test insieme con il codice rallenta l’attività di sviluppo, ma ripaga con gli interessi in fase di test e certificazione. Anche la fase di bug fix prevede la scrittura di opportuni test di regressione, per assicurarsi che un bug non si ripresenti in altri branch o in future versioni del codice.  Ogni release candidate viene quindi collaudata in automatico dalla regression suite prima di essere rilasciata alla fase di smoke-test test manuali e alla certificazione.

 Una suite di regressione automatica che copra completamente il funzionamento del codice è nella pratica impossibile.  è quindi sempre necessaria una fase di test manuali di una release candidate prima di rilasciarla alla certificazione e di seguito alla produzione.  Le modalità con cui si svolgono i test manuali, vengono decise di volta in volta sulla base delle funzionalità che è necessario collaudare. Di solito coinvolgono una o due persone del team di sviluppo, che alla fine dei test passano il software al release team di INFNGrid per la certificazione finale e l’inserimento nella release. Nei casi più complessi, che possono richiedere anche settimane di test, le prove vengono effettuate in sinergia dal team di DGAS e dal release team.

 Il supporto al software è di norma garantito tramite due canali:  Una mailing list cui afferiscono sia gli sviluppatori che il personale di supporto vero e proprio.  Ticketing system di INFN Grid.  Normalmente i problemi vengono prima affrontati dal personale di supporto e, se necessario, vengono coinvolti gli sviluppatori per il supporto di secondo livello.  Questa procedura viene però ribaltata nei periodi in cui una nuova release è in fase di test manuali o di certificazione. Dato che il personale che di solito si occupa del supporto è anche quello responsabile dei test manuali e di parte della certificazione, nel periodo in cui una release candidate è in fase di test finali, gli sviluppatori si occupano di supporto di primo e secondo livello.

 Attualmente il manpower è così suddiviso: Sviluppo: 1 Persona 100% + 1 Persona 50% Supporto: 1 Persona 100% + 2 Persone 50%  Nel corso degli ultimi sei mesi abbiamo inoltre iniziato una collaborazione con il team di D-Grid che si occupa di accounting. Questa dovrebbe rivelarsi molto utile per il futuro.

 Proposte di progetti inerenti all’accounting a cui INFN contribuisce: EGI-InSPIRE:  (TJRA1.4) Economic Accounting. Accounting of capacity and cloud computing (Italy 9 PM/Year)  (TJRA1.4) Accounting of data usage (D-Grid 6 PM/Year) EMI:  Storage accounting, UR standardization, porting of sensors to messaging IGI:  Idee di sviluppo emerse dalla TF progettazione di IGI (Accounting economico, Accounting HPC, HLR di VO, maggior controllo sulle HLR di sito).  Finanziamenti IGI attualmente in negoziazione con il MIUR  Una stima precisa del personale necessario per il proseguimento delle attività di DGAS, soprattutto per la parte di sviluppo, dipende chiaramente da quante e quali nuove funzionalità dovranno essere implementate (tra quelle richieste)