Last modified 12 years ago Last modified on 10/28/08 11:35:55

Grouping pools for publishing into GLUE

In Glue v1.3, a storage element is represented by a GlueSE object. Each GlueSE object can have multiple GlueSA child objects that describe the storage capacity of that end-users. Each GlueSA object can have multiple VOInfo objects that describe how end-users may use that GlueSA.

The problem

There's now a requirement that all storage is accounted for: pledged hardware must be seen to be in production. Because of this requirement, WLCG are changing their definition of GlueSA, making it more strict definition. Now all storage much be published as part of some GlueSA and no storage can be reported in more than one GlueSA.

The solution

We group together pools so that each pool is in precisely one grouping. The word "poolgroup" is explicitly avoided here as:

  1. these object have different semantics to normal dCache poolgroups.
  2. these object cannot be used in normal dCache operations: their artificial constructs used to publish dCache information using the GLUE data model.

The algorithm (all done within the info service; no dCache component outside of the info service is aware of any of this) is:

  1. Identify all pools in dCache.
  2. Identify all links in dCache.
  3. For each link:
    1. Identify all store and dcache units that might result in the link being selected.
    2. Identify all pools that may be selected by the link.
    3. "Paint" each pool (from 3.b) with the results from 3.a. For each store- or dcache- unit and operation (read, write, p2p, cache) with non-zero preference, mark <operation>-<unit> in the pool. If a pool has been painted with a <operation>-<unit> ordered pair then painting it again has no effect. If you like, this is a boolean space with all <operation>-<unit> ordered pairs are axes.
  4. Identify all pools with the same access criteria (the set of <operation>-<unit> pairs) and group them together. This includes pools that have no access criteria.

Each of the groupings identified in step 4. above is a NAZ.

Open issues

  1. Naming scheme for NAZ. Each NAZ name must have the following properties:
    1. unique within the dCache configuration,
    2. must be publishable in LDAP,
    3. must be automatically generated,
    4. must be persistant for a given configuration (so, no ordering effects).