StARUpdates
Version 4 (Jon Kerr Nilsen, 09/04/2012 09:08 AM)
1 | 1 | Jon Kerr Nilsen | h1. StAR updates |
---|---|---|---|
2 | 1 | Jon Kerr Nilsen | |
3 | 1 | Jon Kerr Nilsen | h2. Comments to StAR during the public comment period |
4 | 1 | Jon Kerr Nilsen | |
5 | 1 | Jon Kerr Nilsen | --- |
6 | 1 | Jon Kerr Nilsen | |
7 | 1 | Jon Kerr Nilsen | h3. SITE field required by EGI and WLCG |
8 | 1 | Jon Kerr Nilsen | |
9 | 1 | Jon Kerr Nilsen | The key site identifier in the EGI and WLCG e-infrastructures is the SiteName as defined by GOCDB. This should be added to the StAR definition. |
10 | 1 | Jon Kerr Nilsen | |
11 | 1 | Jon Kerr Nilsen | While the storage element fqdn could possibly be resolved to a site name by software using the accounting data, the definition should be under the control of the site when publishing, not subject to later action by other parties. |
12 | 1 | Jon Kerr Nilsen | |
13 | 1 | Jon Kerr Nilsen | h3. StorageResourceCapacityAllocated proprty to be added |
14 | 1 | Jon Kerr Nilsen | |
15 | 1 | Jon Kerr Nilsen | In the StorageUsageBlock the property StorageResourceCapacityAllocated should added alongside StorageResourceCapacityUsed and StorageLogicalCapacityUsed. |
16 | 1 | Jon Kerr Nilsen | |
17 | 1 | Jon Kerr Nilsen | By analogy with wallclock time signifying a cpu resource being blocked from other use and so a reasonable thing to be accounted and charged, storage space allocated is unavailable to other users on many systems. |
18 | 1 | Jon Kerr Nilsen | |
19 | 1 | Jon Kerr Nilsen | It should be an optional property to be used by those who wish to account and charge for space allocated instead of, or as well as, space used. |
20 | 1 | Jon Kerr Nilsen | |
21 | 1 | Jon Kerr Nilsen | An example use case would be a site who allocates whole disk servers or whole instances of storage systems to VOs, not sites who merely give VOs quotas in a bigger storage system. |
22 | 1 | Jon Kerr Nilsen | |
23 | 1 | Jon Kerr Nilsen | This comment is on behalf of EGI and WLCG. |
24 | 1 | Jon Kerr Nilsen | |
25 | 1 | Jon Kerr Nilsen | h3. Comment originally posted by hartdavidl 2012-02-22 |
26 | 1 | Jon Kerr Nilsen | |
27 | 1 | Jon Kerr Nilsen | In addition to the fields listed, for accounting purposes, the record may want to permit the inclusion of a "charge" that is a function of the capacity used, in the same way that HPC job charges are often calculated as core-hours or node-hours modified by a queue or priority factor. In storage accounting, the bytes stored could be modified based on the StorageShare (e.g., slower disk vs. faster disk), StorageClass (e.g. pinned, replicated classes cost more), or MediaType (e.g., disk costs more than tape). |
28 | 1 | Jon Kerr Nilsen | |
29 | 1 | Jon Kerr Nilsen | Second, the record does not permit accounting for storage "activity", i.e. the bytes and/or files read and/or written by respective users, if this is of interest (or available). If such values are supported, the forward-looking ValidDuration field may need to be redefined or replaced as a retrospective TimeDuration field, since the recorded reads/writes would apply in the TimeDuration leading up to the MeasureTime. |
30 | 1 | Jon Kerr Nilsen | |
31 | 1 | Jon Kerr Nilsen | --- |
32 | 1 | Jon Kerr Nilsen | |
33 | 1 | Jon Kerr Nilsen | h2. Suggested new fields |
34 | 1 | Jon Kerr Nilsen | |
35 | 1 | Jon Kerr Nilsen | h3. Site |
36 | 1 | Jon Kerr Nilsen | |
37 | 4 | Jon Kerr Nilsen | This property describes the site at which the resource is located. This property should contain a descriptive name of the group of resources containing the storage system which is accounted for in the record. The Site field value should be constructed in such a way that it is unique within the accounting domain where the record is used (e.g., by using the Glue 2.0 AdminDomain.Name). |
38 | 1 | Jon Kerr Nilsen | * The Site field type MUST be a string. |
39 | 1 | Jon Kerr Nilsen | Example |
40 | 1 | Jon Kerr Nilsen | <pre> |
41 | 3 | Jon Kerr Nilsen | <sr:Site>ACME-University</sr:Site> |
42 | 1 | Jon Kerr Nilsen | </pre> |
43 | 1 | Jon Kerr Nilsen | |
44 | 1 | Jon Kerr Nilsen | h3. ResourceCapacityAllocated |
45 | 1 | Jon Kerr Nilsen | |
46 | 1 | Jon Kerr Nilsen | This property describes the number of bytes allocated on the storage system or storage share where appropriate. Depending on implementation this property may be equal to ResourceCapacityUsed (see section 2.4.19), however this property should only take into account space allocated to the entity described in the record, not resources used for redundancy in RAID setups, tape holes, or similar. |
47 | 1 | Jon Kerr Nilsen | * The ResourceCapacityAllocated field type MUST be a nonnegative integer. |
48 | 1 | Jon Kerr Nilsen | Example |
49 | 1 | Jon Kerr Nilsen | <pre> |
50 | 1 | Jon Kerr Nilsen | <sr:ResourceCapacityAllocated>14624</sr:ResourceCapacityAllocated> |
51 | 1 | Jon Kerr Nilsen | </pre> |
52 | 1 | Jon Kerr Nilsen | |
53 | 1 | Jon Kerr Nilsen | h3. TimeDuration |
54 | 1 | Jon Kerr Nilsen | |
55 | 1 | Jon Kerr Nilsen | Was decided in February to use StartTime and EndTime instead of MeasureTime and {Time,Valid}Duration. |
56 | 1 | Jon Kerr Nilsen | |
57 | 1 | Jon Kerr Nilsen | |
58 | 1 | Jon Kerr Nilsen | h3. StartTime |
59 | 1 | Jon Kerr Nilsen | |
60 | 1 | Jon Kerr Nilsen | This property describes a timestamp indicating the time at which the measured resource consumption started. Together with EndTime (see section 2.4.18) this defines a period over which the resource has been consumed. |
61 | 1 | Jon Kerr Nilsen | * The StartTime field MUST be present in the record. |
62 | 1 | Jon Kerr Nilsen | * The StartTime field type MUST be an ISO timestamp. |
63 | 2 | Jon Kerr Nilsen | * The time zone may be specified as Z (UTC) or (+|-)hh:mm. Time zones that aren't specified are considered undetermined. |
64 | 1 | Jon Kerr Nilsen | Example |
65 | 1 | Jon Kerr Nilsen | <pre> |
66 | 1 | Jon Kerr Nilsen | <sr:StartTime>2010-10-11T09:31:40Z</sr:StartTime> |
67 | 1 | Jon Kerr Nilsen | </pre> |
68 | 1 | Jon Kerr Nilsen | Implementation note: The period defined by EndTime-StartTime could define the period over which the storage system measured a storage integral. In a simpler case, EndTime is the current time of mesasurment and StartTime the preceding measurement. |
69 | 1 | Jon Kerr Nilsen | |
70 | 1 | Jon Kerr Nilsen | h3. EndTime |
71 | 1 | Jon Kerr Nilsen | |
72 | 1 | Jon Kerr Nilsen | This property describes a timestamp indicating the time at which the measured resource consumption ended. Together with StartTime (see section 2.4.17) this defines a period over which the resource has been consumed. |
73 | 1 | Jon Kerr Nilsen | * The EndTime field MUST be present in the record. |
74 | 1 | Jon Kerr Nilsen | * The EndTime field type MUST be an ISO timestamp. |
75 | 2 | Jon Kerr Nilsen | * The time zone may be specified as Z (UTC) or (+|-)hh:mm. Time zones that aren't specified are considered undetermined. |
76 | 1 | Jon Kerr Nilsen | Example |
77 | 1 | Jon Kerr Nilsen | <pre> |
78 | 1 | Jon Kerr Nilsen | <sr:EndTime>2010-10-12T09:29:42Z</sr:EndTime> |
79 | 1 | Jon Kerr Nilsen | </pre> |
80 | 1 | Jon Kerr Nilsen | Implementation note: See note for section 2.4.17 |