Frascati, October 5th, Accounting in DataGrid Preliminary Proposal and basis for discussion Stefano Barale Frascati, October 5th, 2001

Accounting approaches Existing accounting systems follow basically two approaches: passive (the system only reports the resource usage) and active (the system reports the resource usage and actively uses these information to simplify workload management). Advantages of the active approach are: A tighter integration with the resource allocation system that simplifies workload management. An active resource control that can prevent uncontrolled usage and, consequently, system saturation.

Frascati, October 5th, Computational economy In the context of an active accounting system, we chose an economical approach. According to this approach the resource usage is regulated by the exchange of a kind of “virtual money” (Grid Credits) The user “pays” the resource for its usage The resource earns Grid Credits when it is used

Frascati, October 5th, Price-setting policies Different price-setting mechanisms can be adopted in this framework Ranging from a flat model with constant price to pure supply & demand some “pricing authority” can be set up to help reaching and keeping equilibrium A good price-setting policy should avoid “virtual” inflation, speculation and “price wars”

Frascati, October 5th, Job cost computation In an economical approach every job has a “computational cost”. The job cost is computed in three steps: Every resource must have a well defined “value”, depending on its real capabilities. This value should be estimated via a proper benchmark suite. The value is then used to set the resource price according to the price-setting mechanism adopted. The job cost is computed using resource prices and the job resource usage.

Frascati, October 5th, Elements to be charged It is important to define which elements should be charged, a minimum set should be: Priority in a queue (if any) CPU time Memory usage Disk and tape storage usage Network Other elements should be considered too, but the definition of the full set is still an open issue.

Frascati, October 5th, Working scheme Our system has to manage economical interactions between producers and consumers of a service. To address this problem the GSM mobile phone system uses a so-called “Home Location Register” to store info about the user (identity, “resource usage”, policies...). We applied this concept to our accounting model. In this model the HLR of a user pays to the resource HLR the credits due for a job.

Frascati, October 5th, The HLR working scheme Every user and resource belongs to an HLR The User (HLR_A) submits a job The Resource (HLR_B) runs the job HLR_A pays HLR_B for the resource usage HLRs are distributed entities whose number and location and are still to be defined (one per organization, site, experiment) ?

Frascati, October 5th, Open issues In our model HLRs use standalone databases. We have to check whether the SQLDataBaseService approach is a feasible one, too. We have to understand who is in charge for: Developing a system for mapping Grid users onto local Unix accounts. We have been positively impressed by the ‘template accounts’ proposed within GGF Developing per-job sensors to provide the necessary information to the accounting system Is it a need to inject real money into the Grid?

Frascati, October 5th, Conclusions A document covering all the aspects of the problem in full detail is available at: We developed a proof-of-principle prototype of the proposed architecture in preparation for the integration with the project architecture. No show-stoppers found so far. We hope to start a fruitful communication with the other WPs. Feedback is welcome.