1. Giuseppe Patania 2007 5-9 Nov, Martina Franca (Ta)‏
DGAS infrastructure
Giuseppe Patania
Nov, Martina Franca (Ta)‏

2. Overview
In a distributed computing environment people want to know who used the resources and how many resource have been used. VO managers : how many resources is my VO using ? Site Managers : who is using my resources ? A good accounting system should be able to answer these questions taking care of all the security and privacy issues.
DGAS gives answer to the above questions. Is an acronym for Distributed Grid Accounting System and is able to perform a resource usage metering.
It is based on a client/server infrastructure in which communication among components are managed by dedicated engines.
Martina Franca (TA) 2007 Nov 5-9

3. DGAS Features Granularity Scalability Hierarchical Design
Resource accounting at single job level or in aggregate form per user, per VO, per resource (site)
Scalability
Arbitrary number of Resource/VO HLRs can be deployed.
Hierarchical Design
HLRs can be interconnected across a tree structure, so multiple levels of aggregation are possible.

4. DGAS Features Completeness
Capability of collecting information both for grid and local jobs.
Designed to perform pricing ( but not used)
Possibility to assign “computing credits” (something similar to quotas) that can be used as a basis for billing the resources consumption.

5. Security and Privacy
Information confidentiality is guaranteed by the use of different authorization levels to access the Usage Records.
Site Managers (Can access their own site detailed records and aggregates)
VO Managers (Can access detailed records and aggregates of all VO members)

6. Security and Privacy
Full VOMS integration in query authorization is available (now on L2 HLR, on every HLR in future releases)
(e.g. /atlas/Role=vomanager/Group=NULL)
Integrity of the data flow is guaranteed by the use of GSI and data encryption.
No private information is sent in clear text

7. DGAS Components
The deployment of DGAS packages, actually involves several grid elements: CE
HLR
Second level HLR
User interface CLI (common line interface)
Recently an HLR-MON web inteface, which mainly substitutes the service offered by the previous CLI, has been implemented.

8. SENSORS on CE The CE is the grid element on which run DGAS sensors
glite-dgas-urcollector: collects usage records (urs) and other info into a text file, retrieved from LRMS (PBS or LSF) and gatekeeper log files.
glite-dgas-pushd: sends urs to the predefined HLR, using the atmClient() function.
The status of sensors is continuosly checked by a demon called: glite-dgas-ceServerd-had

9. CE: data flow CE HLR LRMS log HAD urCollector Pushd Gatekeeper log
atmClient()
urCollector
Pushd
Gatekeeper
log
File A B C
File A’ B’ C’
urBox
Err
Job

10. Services on HLR
The HLR grid element provide DGAS services through the following daemons:
Home location register server:
glite-dgas-hlr-listener: it is the main hlr service
glite-dgas-hlr-qmgr: it is responsible for processing pending accounting informations received from CE
glite-dgas-ur-forward: when activated, send data to the second level HLR.
Such as the had for CE, glite-dgas-hlr-had preserves hlr services from eventual crashes. It behave like a supervisor of daemons activity.

11. HLR data flow HLR data HLR 2L HAD ur-forward qmgr listener hlr_tmp db
hlr db CE

12. General data flow L2 HLR fwd B fwd A job B Site HLR A Site HLR B urs B
urs A
farm 1
farm 2
job A

13. Stored data types Different kind of data Usage quantities: Timestamps:
cpu time,
wall clock time,
phisical memory used
virtual memory used,
spec benchmark units
Timestamps:
job execution start and end,
job creation on LRMS,
job insertion in the last LRMS queue, etc.
Local and clients are included in different packages.

14. Stored data types User related: Job related Host related: localUserId
localGroup
userVo
userFqan (example “/ops/Role=lcgadmin/Capability=NULL”)
Job related
dgJobId,
lrmsId
Host related:
Resource HLR destination address
Default user HLR address, if available
Resource Grid Id
siteName (example “INFN-TORINO”)
Local and clients are included in different packages.

15. Checking the server status
With DGAS a ping command is available.
It checks the server status and report the available HLR engines.
The following snapshot shows an example of usage

16. Remote and local clients for queryng HLR are provided
Client tools
Remote and local clients for queryng HLR are provided
Actually, because there are not HLR user installed, remote clients are allowed only for two categories:
HLR admins
VO admins

17. Clients tools: glite-dgas-query
Once an administrator has been mapped to an HLR, he can exploit the tools that DGAS make available for retrieving data.
The main tool is:
glite-dgas-hlr-query (HLR remote interface)
glite-dga-hlr-localquery (HLR local interface )
This is a complex but powerful tool that permits to implement several query types. The following slides show an example of usage.

18. Clients tools: glite-dgas-query
Here are shown two query types esecuted from a remote UI on the “t2-hlr-01.to.infn.it” HLR1L.-

19. Clients tools: glite-dgas-query
The first query output prompts number of jobs, cpuTime/hour, wallTime/hour esecuted on “t2-ce- 01.to.infn.it” resource, related to the “alice” vo and grouped by month
The second one is like the first above, but results are grouped by month VO.

20. HLRMON HLRMON is the new web interface on all italian sites.
The requirements to using it are:
a valid x509 personal certificate installed in the browser
a registration that can be done by contacting the HLRMON developers (Stefano Dalpra, Federico Pescarmona, Giuseppe Misurelli)
Many of the features available with the CLI tools, are now available with HLRMON and moreover is possible to see whenever a site is not sending data to the determined HLR (maybe because it’s down ).

21. The end