|Main||Roadmap and Innovation||Technology||For Users||For Resource Providers||Media|
Scenario 4: Accounting across Resource Providers
Leader: Alison Packer and John Gordon, STFC
|Scenario leader||STFC||Alison Packer|
To account for resource usage across multiple resource providers we need to define:
- the elements to be accounted for and how accounting data may be gathered. (This relates to the statement “Resource providers agree and follow the same rules for accounting the resource usage”.)
- how accounting data will be published
- what is required from this data (for VM users, Resource Providers, VO Managers, others?)
Draft Usage Record
To help define what we will account for the existing Compute Accounting Record could be extended.
The following table is an updated version of the draft Usage Record as a result of the feedback from our F2F meeting on 24th November, 2011 (previous version can be reviewed here File:Draft-CloudAccountingUsageRecord-v1.pdf).
Some assumptions related to the version below:
- Many of the properties defined in the Usage Record may be set to NULL, this is based on the assumption that different Resource Providers may want to publish different sets of data, but we want only one Usage Record, usable by all.
- The "Charge" property is no longer included in the Cloud Accounting Usage Record as it is for accounting for a VM and its usage. It may be used by Resource Providers to charge for their service, but the charging mechanism would be Resource Provider specific and should therefore be separated from accounting.
- The fields for GlobalUserName, VirtualOrganization, Projectname and Group relate to an existing method of authorizing grid users, if this authorization mechanism were to be used for cloud usage as well then these would provide a method of associating VM usage with a user and then querying usage in a portal could be based on user, VO etc.
- A VM might be in one of three states: started, stopped and suspended. I think we would expect to gather many VM records whilst a VM is running, so I propose using the existing UR “Status” property for this – it may be possible to extend the implementation of this property to include some VM-specific statuses if these existing ones are not deemed appropriate.
- We need a method of identifying where a specific running VM is – there are many ways to do this, I suggest that the RecordIdentity might contain a concatenation of some of the other fields in the record – e.g. TimeStamp SiteName MachineName ImageID - other suggestions welcome.
- We have job accounting and storage accounting systems and their related usage records already - we therefore account for jobs and storage using these existing records/methods.
The following table shows what might be used and some additional elements required for cloud accounting:
|Cloud Usage Record Property||Definition|
|RecordIdentity||Unique identifier of a record (String)|
|SiteName||GOCDB SiteName - extend service types in GOCDB to include cloud resource providers|
|MachineName||VM Hostname (String)|
|LocalUserID||Local user name|
|LocalGroupID||Local group name|
|GlobalUserName||Global identity of user (certificate DN) (String)|
|VirtualOrganization||All three may be retrieved from FQAN - use if VOs part of authorization mechanism|
|Status||Completion status (String) completed, started or suspended|
|StartTime||Must be set if Status = started (Timestamp)|
|EndTime||Set to NULL until Status = completed (Timestamp)|
|MeasurementTime||Set to amount of time used so far (Timestamp)|
|SuspendTime||Set when Status = suspended (Timestamp)|
|WallDuration||WallClock time - actual time used|
|CPUDuration||CPU time consumed (Duration)|
|CPUCount||Number of CPUs|
|CPUPower||Power of CPUs|
|Memory||Memory allocated to the VM|
|ImageID||Every image has a unique ID associated with it|
|StorageRecordIdentity||Link to associated storage record|
Feedback from Resource Providers
|VM||What is measured|
|Oxford/Eucalyptus (no longer running)||Number of VM instantiated - Type of VM - Amount of time each VM has been running - Number of Elastic Block Storage volumes created - Amount of time the EBS volumes have been owned - Times the EBS volumes have been mounted - Binding between EBS volumes and VMs - Number of OS images loaded in the S3 repository - Amount of time the OS images have been loaded into the S3 repository|
|OpenNebula||(Have reviewed UR)|