1. Accounting in DataGrid HLR software demo Andrea Guarise Milano, September 11, 2001

2. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it Introduction To show the capabilities of the economical accounting model, we produced a simple prototype of the software system.

3. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it Prototype schema HLR BHLR A Payment Request Job cost computation Job submission Via globus software Job run And information gathering Payment: From user account On HLR_A To resource account On HLR_B Fund earned are Periodically Redistributed to The HLR_B users.

4. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it Main schema (1) HLR BHLR A

5. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it Main schema (2)

6. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it Computing nodes On the computing nodes there is a little daemon written in PERL. The daemon waits for a job launched by globus; once the job has started it gathers information about the user who owns the job, and then takes the URL of his HLR from a file ( gridhlr_file) in $GLOBUS_DEPLOY_PATH/etc/ The job is then monitored and when it is done all the information gathered are sent to the user HLR as a payment request.

7. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it Computing nodes Features: The client part of the software doesn’t require any change to the globus source code. The same job has equal cost on different machine, differences in the resource costs may be set up fixing some user defined coefficients. The pricing algorithm used in the demo is: Where b is a generic resource benchmark ( I.e. bogomips) u is the amount of resource used by the job and w is the weight factor for that benchmark.

8. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it Computing nodes Known limitations Due to the demonstrative purpose of the client software, there are many known (and maybe unknown) limitations: Only job launched vie the fork jobmanager are currently accounted correctly. The system can’t manage job that fork children. Only the CPU time consumed by the job is accounted.

9. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it HLR Server On the server (the HLR) there is a daemon that listen for incoming connections. Once a job payment request arrives, the server computes the price for that job, insert a record in a log table and update the user account information. At this time the computed amount of funds are transferred to the resource HLR. Users and resources are organized in groups, and groups belong to funds.

10. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it HLR Server The server part is not a demo software, I.e. : it’s ready to become ( after a bug fixing phase, and a code restyling) a production software. The software is written in C++, and it is structured as a lower level MySQL DataBase, which is managed by an upper level set of API’s, that are used both by the server deamon and by the user level applications used to manage the database. A demonstrative WEB interface has also been implemented but has still many limitations.

11. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it HLR Server Known limitations: Informations from resource to HLR and from HLR to HLR are clear and not authenticated (NO GSI used). Line command interface only for inserting user informations. Still no consistency checking of the accounts data. Authorization feedback not implemented yet (but feasible in short time).

12. Milano, September 11th, 2001 Andrea.Guarise@to.infn.it TO DO Before GGF3: Improve the user interface (both WEB and command line). Implement the authorization feedback mechanism. After GGF3: Bug fixing, Code restyling. Documentation production. Security implementation via GSI. Integration with WP1 PM9 release. Pricing algorithm and job information gathering improvement.