1. DGAS Distributed Grid Accounting System INFN Workshop 11-15 /05/1009, Palau Giuseppe Patania Andrea Guarise 6/18/20161

2. Description The Distributed Grid Accounting System (DGAS) is a full featured distributed grid accounting software. DGAS can be used to account classic Computational Usage Records like CPU Time, memory usage and so on. DGAS can also be used as an Economic Accounting system, managing information about the cost of the jobs executed by each Grid User on the single Grid Resources. 6/18/20162

3. Key functionalities Sensors available for PBS,LSF and Condor batch systems. Works with LCG and CREAM CEs. Local Site manager has full access to the Usage Records (up to single job record), archived in an RDBMS. Optional pricing of computing resources. Distributed architecture, ready for regional grids and VO accounting. Flexible deployment. Authorization policies highly customizable, with both static and VOMS based roles. CLI and WEB interface are available. 6/18/20163

4. Present status Actually DGAS is deployed among the INFN production grid. A regular support to all the site managers and a mailing list are provided : dgas- support@infn.itdgas- support@infn.it A regular check of accounting functionality is performed Data have been validated several times 6/18/20164

5. Present status Thanks to the activities described in the previous slides and the site manager’s feedbacks, we can say that now DGAS has become a reasonably robust, well known by the INFN users and mature software. It is also used as the base backend for the hlrmon web interface. 6/18/20165

6. Basic site deployment Site Batch farm (LSF,PBS,Condor) Batch farm (LSF,PBS,Condor) CE (LCG,CREAM) HLR node Site HLR (DGAS server) Site HLR (DGAS server) PA (optional) DGAS sensors Site Manager 6/18/20166

7. DGAS @ INFNGrid ROC Manager T2 site HLR nodes TORINO MILANO LEGNARO PISA FRASCATI ROMA 1-2-3 NAPOLI BARI CATANIA T2 site HLR nodes TORINO MILANO LEGNARO PISA FRASCATI ROMA 1-2-3 NAPOLI BARI CATANIA Site Manager 6/18/20167

8. Grid Regional grid 2 Distributed architecture ready for regional grids and VO accounting Regional grid 1 Site 2 Site HLR Grid Manager Site 1 Site HLR Site 3 Site HLR HLR 2 Regional grid manager HLR 2 VO 1 VO 2 HLR 2 VO1 Records VO2 Records ALL VOs Records 6/18/20168

9. Flexibility Sites VO VO HLR 2 (Vo specific records) VO HLR 2 (Vo specific records) HLR 2 Record for all VOs HLR 2 Record for all VOs VO Manager VO managers can perform queries on both general purpose or VO specific HLRs. Authorization levels are highly customizable. Static or VOMS based mappings are available. Little VOs do not need to have dedicated accounting servers. 6/18/20169

10. Grid Regional grid 2 Possibility to deploy accounting servers in order to ensure redundancy Regional grid 1 Site 2 Site HLR Grid Manager Site 1 Site HLR HLR 2 Regional grid manager HLR 2 VO 1 HLR 2 Site 3 Site HLR 6/18/201610

11. Pricing DGAS optionally allows to deploy pricing servers, known as Price Authorities, which can be used to assign prices to the grid Computing Resources. Prices can be statically assigned by the resource managers or dynamically (price varies according to the CE load for example). A ‘virtual cost’ can thus be assigned to jobs executed on Computing Elements where economic accounting is activated. This cost will then be part of the Job’s Usage Record. The system allows for flexible implementation of different economic models, such as, as an example: Pay per access: a fixed cost is assigned to each job, without taking care of the amount of resource consumed. Pay per usage: the job cost is computed taking care of the amount of resources (e.g. wall clock time ) consumed by the job. DGAS does not provide any automatic charging mechanism. It is up to the site to eventually bill (if this is the case) the user. It just provides the needed information to the site manager. 6/18/201611

12. Pricing workflow 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 6/18/201612

13. DGAS 3.4 A new version of DGAS is undergoing our internal pre-release tests. It will provide new functionalities and bug fixes. The most important feature of this new release however is one that you won’t see: The code has been almost completely rewritten and simplified. The DB schema has been revised. The overall performances and system reliability have been greatly increased. Internal checks to avoid record duplication completely re-designed. Improved and enhanced regression suites for both HLR and sensors. Many enhancements and new features are present as well: The administrative interface has been simplified (e.g. A single command to add a resource to the system). More powerful querying mechanisms. Support for Condor as LRMS. Support for CE benchmarks other than current si2k,sf2k. 6/18/201613

14. Open technical issues There are a set of technical issues which are in discussion about dgas accounting: Punctual normalization Messaging protocol Storage accounting 6/18/201614

15. Open issues: Normalization Requirement: provide a mechanism to store the punctual value of worker node benchmark instead of the average value of the entire farm Issue: – server side dgas provides this mechanism – client side sensors need is a defined location where to find data source and defined publication schema. 6/18/201615

16. Open issues: messaging system Requirement: implement a different dataflow schema, activeMQ. ActiveMQ could ease the interoperation of different accounting systems. Issues: – reported a more possible server load then the actual solution (direct mysql insertion in the go DB) – Scalability problems ?

17. Open issue: storage accounting Requirement: implement a storage accounting integrated with the actual accounting system Issue: at the moment no development plan has been defined. 6/18/201617

18. Accounting evolution in EGI/IGI/UMD Problem: three active concurrent accounting systems: Apel, Sgas, Dgas If we are going to ask for european funds for accounting this will not be sustainable anymore because both of the costs of the software maintenance and the time waste of human resources. 6/18/201618

19. Accounting evolution in EGI/IGI/UMD Three scenarios are growing in the offing to solve the problem (any other idea?): 1. Developing a new system which includes the best know- how of what now is up and running (almost impossible). 2.Only one of the three systems survives and the other ones will be disused (dangerous). 3.All systems continues to be used and the effort moves to a definition of standard interfaces which have to be exploited to permit interoperability. 6/18/201619

20. Conclusions The overall work (both development and operation activities ) that has been done until now shows that DGAS is working well. We need to define a strategy for the future and plans for the medium-long term activities 6/18/201620