wiki:PublishingDcacheInfo
Last modified 9 years ago Last modified on 10/28/08 11:38:44

Publishing dCache as Glue 1.3 GlueSAs

Requirements

The current requirement is to publish all storage space as one or more GlueSAs without overlapping and without missing any storage, specifically:

  1. the sum of all GlueSA's TotalOnlineSize is the GlueSE's TotalOnlineSize,
  2. the sum of all GlueSA's UsedOnlineSize is the GlueSE's UsedOnlineSize,
  3. the sum of GlueSA's FreeOnlineSize is the GlueSE's FreeOnlineSize.
  4. the sum of all GlueSA's TotalNearlineSize is the GlueSE's TotalNearlineSize,
  5. the sum of all GlueSA's UsedNearlineSize is the GlueSE's UsedNearlineSize,
  6. the sum of GlueSA's FreeNearlineSize is the GlueSE's FreeNearlineSize.

Storage represented by a GlueSA must consistent with all child VOInfo objects; e.g., a GlueSA with two VOInfo child objects (one VOInfo with VOInfoACBR=VO:ATLAS and VOInfoPath=/pnfs/example.org/data/atlas and the other with VOInfoACBR=VO:LHCB and VOInfoPath=/pnfs/example.org/data/lhcb) then all storage represented by the GlueSA must be writable by the two VOs through the respective paths.

Solution, part 1

To publish all storage in dCache, the plan is to group pools into a set of normalised access zones (NAZ). The set of all NAZ for a dCache instance have the following properties:

  1. all pools belong to precisely one NAZ,
  2. all pools in same NAZ are accessable from the same set of links,
  3. all NAZ have at least one pool.

The first property guarantees complete coverage of dCache storage, the second property guarantees consistency in access (so we can publish meaningful VOInfo child objects) and the third is an optimisation.

In dCache terms, a NAZ is something a bit like a poolgroup, but they are automatically generated and only exist for the purposes of publishing information into Glue. These objects are not used within dCache. Some details of how NAZ are generated is available here.

Each NAZ is published as a GlueSA. These NAZ GlueSA objects will have the following GlueSACapability attributes:

GlueSACapability: WLCG-Usage=megatable::

always published, single-instance

GlueSACapability: read::

optional: published if at least one user can read storage

GlueSACapability: write::

optional: published if at least one user can write data

GlueSACapability: stage::

optional: if at least one user can cause HSM restore to this storage

GlueSACapability: dCache-Link=<link-ID>::

zero or more: identifying which links the space is accessable through

GlueSACapability: dCache-Linkgroup=<linkgroup-ID>::

zero or more: identifying which linkgroups are managing this space

The different access modes (for reading, for writing) are described by adding VOInfo child objects.

If a NAZ supports write-access for a VO, then a VOInfo child object is added with the usual information:

  • VOInfoPath: <path in namespace>
  • VOInfoACBR: VO:<vo-name> for whichever VO may write to this GlueSA with this path.
  • NB. No VOInfoTag is published.

If a NAZ supports read-access for a VO, then a VOInfo child object is added with:

  • VOInfoACBR describes the VO that may this GlueSA.
  • NB. No VOInfoPath or VOInfoTag is not published.

SRM reservations

For SRM reservations, we have a problem.

The problem

It is very hard to identify from which NAZ a reservation has used space. Technically, it's possible, but would require substantial rewrite of dCache and would also likely cripple the SE; the short answer, it isn't going to happen.

With unused capacity in the reservation (i.e., reserved in the space token, but not used) it is, quite literally, impossible as dCache supports late binding for storing files: until the client writes data one cannot know into which NAZ the file will be written.

Proposed solution

The SRM reservations must be published in addition to the NAZ GlueSA objects, resulting in overlap. However, the SRM-reservation GlueSAs will be clearly labelled so any accounting software can still get the right information.

Each SRM reservation is a GlueSA. The GlueSA will have the following Capability attributes:

GlueSACapability: Usage=srm-reservation::

always published, single instance

GlueSACapability: Usage=writing::

always published, single instance, consistent with above usage

GlueSACapability: LInkgroup=<linkgroup-ID>::

always published, single instance, consistent with above usage

GlueSACapability: Owner=<FQAN of reservation's owner>::

always published, single instance. This represents the FQAN (NOT DN) that was used to create the reservation. Only a VOMS certificate with the FQAN can release the reservation.

NB. the Usage=megatable capability is not published --- software that selects GlueSA objects by checking for this attribute will get the right answer.

Each SRM reservation GlueSA will have a single VOInfo object. This object will have:

  • VOInfoTag: <SRM reservation token>
  • NB. No VOInfoPath or VOInfoACBR is published.