This section describes the steps with the administrator interface necessary to create space reservations.
Log into the administrator interface, navigate to the
PoolManager and check which poolgroups have been
configured. The following shows how the poolgroups are
configured after completing the section called “Assigning pools to a VO”.
[root@dcache-node] #ssh -c blowfish -p 22223 -l adminadmin@dcache-node's password: dCache Admin (VII) (user=admin) [dcache-node.fzk.de] (local) admin > cd PoolManager [dcache-node.fzk.de] (PoolManager) admin > psu ls -l pgroup ResilientPools linkList : poolList : gks linkList : gks-link (pref=20/20/-1/20;;ugroups=2;pools=1) poolList :dcache-node.fzk.dedcache-node_1 (enabled=true;active=11;rdOnly=false;links=0;pgroups=1;hsm=[];mode=enabled) dech linkList : dech-link (pref=20/20/-1/20;;ugroups=2;pools=1) poolList :dcache-node_2 (enabled=true;active=8;rdOnly=false;links=0;pgroups=1;hsm=[];mode=enabled) default linkList : default-link (pref=10/10/-1/10;;ugroups=3;pools=1) poolList :dcache-node_4 (enabled=true;active=10;rdOnly=false;links=0;pgroups=1;hsm=[];mode=enabled)dcache-node_3 (enabled=true;active=9;rdOnly=false;links=0;pgroups=1;hsm=[];mode=enabled) dteam linkList : dteam-link (pref=20/20/-1/20;;ugroups=2;pools=1) poolList :
It is worth going back and reviewing the section called “Assigning pools to a VO”. In that section:
Directory tags were introduced: a set of keyword-value pairs defined for each directory. The default set of tags are inherited from a directory's parent directory. The value of these tags may be overridden.
Storage classes were defined in terms of directory tags, with a practical example. The namespace (directory) permissions were altered to allow only one gid to write data with that storage class, effectively binding a storage-class to that gid, and so to a specific VO.
Links were created that are only selected if the operation has a particular storage class. This effectively makes the Links VO-specific.
Pools were moved so the VO-specific links had some
dedicated storage. Other pools were left accessable
through the default link.
With the above configured VO-specific links
(gks-link and
dech-link), we are ready to create
VO-specific LinkGroups.
The psu create linkGroup command creates a
new link group. Since we have two VOs to support, we will
create two LinkGroups.
[] (PoolManager) admin > psu create linkGroup gks-linkGroup-Disk [dcache-node.fzk.de] (PoolManager) admin > psu create linkGroup dech-linkGroup-Diskdcache-node.fzk.de
To confirm this operation succeeded, we ask for a list of all LinkGroups.
[dcache-node.fzk.de
Notice that, by default, the LinkGroups are configured to
allow nearline access-latency (currently a
synonym for storage using tape) and all three
retention-policies.
These five permission attributes
(onlineAllowed, ...) are altered using
commands of the form psu set linkGroup
. For
example:
attribute
linkGroup-name
boolean-value
[dcache-node.fzk.de
This will set onlineAllowed to
true.
Roughly speaking, access latency describes (under normal
operational conditions) how quickly we guarantee to make a
file available for reading. online implies
very small latency, typical for files stored on disk;
nearline implies a much higher latency,
typical for data stored on tape. For a disk-only dCache,
such as the one we have configured, only
online access-latency is supported, so we
need to change these settings of the LinkGroups.
[] (PoolManager) admin > psu set linkGroup onlineAllowed gks-linkGroup-Disk true [dcache-node.fzk.de] (PoolManager) admin > psu set linkGroup nearlineAllowed gks-linkGroup-Disk false [dcache-node.fzk.de] (PoolManager) admin > psu set linkGroup onlineAllowed dech-linkGroup-Disk true [dcache-node.fzk.de] (PoolManager) admin > psu set linkGroup nearlineAllowed dech-linkGroup-Disk false We must save the settings to make them persistent [dcache-node.fzk.de] (PoolManager) admin > savedcache-node.fzk.de
Another important consideration is how reliable is the
underlying storage and a site's operating policies. Disk-only
storage are generally regarded as only suitable for storage
with a replica-like retension policy: a tape backend is
generally a requirement for custodial
storage. So these retension policy setting must be altered,
too.
[] (PoolManager) admin > psu set linkGroup replicaAllowed gks-linkGroup-Disk true [dcache-node.fzk.de] (PoolManager) admin > psu set linkGroup outputAllowed gks-linkGroup-Disk false [dcache-node.fzk.de] (PoolManager) admin > psu set linkGroup custodialAllowed gks-linkGroup-Disk false [dcache-node.fzk.de] (PoolManager) admin > psu set linkGroup replicaAllowed dech-linkGroup-Disk true [dcache-node.fzk.de] (PoolManager) admin > psu set linkGroup outputAllowed dech-linkGroup-Disk false [dcache-node.fzk.de] (PoolManager) admin > psu set linkGroup custodialAllowed dech-linkGroup-Disk false We must save the settings to make them persistent [dcache-node.fzk.de] (PoolManager) admin > savedcache-node.fzk.de
The LinkGroups are created empty: they manage no storage and
no space reservation is available. To allow a LinkGroup to
manage some space, the corresponding Link(s) must be added
using the psu addto command:
[] (PoolManager) admin > psu addto linkGroup gks-linkGroup-Diskdcache-node.fzk.degks-link[] (PoolManager) admin > psu addto linkGroup dech-linkGroup-Diskdcache-node.fzk.dedech-linkWe must save the settings to make them persistent [] (PoolManager) admin > savedcache-node.fzk.de
Now we can confirm that the space has been added to the LinkGroups by asking how much space is free in the LinkGroups.
[dcache-node.fzk.de
One method of creating a space reservation is via the
administrator interface. The functionality to do this lies
within the SrmSpaceManager cell. So, to create a space,
first navigate to the SrmSpaceManager.
[] (PoolManager) admin > .. [dcache-node.fzk.de] (local) admin > cd SrmSpaceManagerdcache-node.fzk.de
Since we have recently changed the properties of the
PoolManager the SrmSpaceManager may not have had the
opportunity to take these new settings into affect. The
SrmSpaceManager queries PoolManager periodically to
check for changes, but this process can be triggered manually
with the update link groups command.
[dcache-node.fzk.de
The refresh process should be very quick; however, wait a few
seconds to be sure that the effects have reached the
SrmSpaceManager.
The current status of the reservations can be queried using
the ls command. Once the synchronisation
has completed, you should get something like the following:
[dcache-node.fzk.de
Notice the first number in each LinkGroup line. This is the
LinkGroup ID (or lgid for short). In the
above example, LinkGroup gks-linkGroup-Disk
has lgid of 0 and
dech-linkGroup-Disk has lgid
of 1. However, this association is not guaranteed: check
which lgid has a corresponding LinkGroup.
Now we can reserve some space within the different LinkGroups. Be sure to note down the space token IDs for the two space tokens.
Allocate some space in lgid 0 for VO gks [] (SrmSpaceManager) admin > reserve -vor=NULL -vog=/gks -acclat=ONLINE -retpol=REPLICA -lgid=0 -desc=DISK 30000 "-1" 10000 voGroup:/gks voRole:NULL retentionPolicy:REPLICA accessLatency:ONLINE linkGroupId:0 size:30000 created:Sun Sep 07 14:57:37 CEST 2008 lifetime:-1ms expiration:NEVER description:DISK state:RESERVED used:0 allocated:0 ... and reserve some space in lgid 1 for VO dech [dcache-node.fzk.de] (SrmSpaceManager) admin > reserve -vor=NULL -vog=/dech -acclat=ONLINE -retpol=REPLICA -lgid=1 -desc=DISK 30000 "-1" 10001 voGroup:/dech voRole:NULL retentionPolicy:REPLICA accessLatency:ONLINE linkGroupId:1 size:30000 created:Sun Sep 07 15:01:20 CEST 2008 lifetime:-1ms expiration:NEVER description:DISK state:RESERVED used:0 allocated:0dcache-node.fzk.de
We have created two space reservations with reservation IDs of
10000 and 10001. The
space reservation ID is a concept that's internal to dCache.
The end-users refer to a space reservation by an opaque and
unique reference: the space token. A
space token is an arbitrary string that the storage-element
chooses. For dCache the reservation ID is returned to the
end-user as the space token; the two reservations we have just
created have space tokens of 10000 and
10001.
A VO may request more storage for a space reservation. This is to accomplish through the adminstrator interface.
Navigate to theSrmSpaceManager[] (local) admin > cddcache-node.fzk.deSrmSpaceManagerIdentify which reservation needs resizing [] (SrmSpaceManager) admin > ls Reservations: 10001 voGroup:/dech voRole:NULL retentionPolicy:REPLICA accessLatency:ONLINE linkGroupId:1 size:30000 created:Sun Sep 07 17:19:25 CEST 2008 lifetime:-1ms expiration:NEVER description:DISK state:RESERVED used:0 allocated:0 10000 voGroup:/gks voRole:NULL retentionPolicy:REPLICA accessLatency:ONLINE linkGroupId:0 size:30000 created:Sun Sep 07 17:19:12 CEST 2008 lifetime:-1ms expiration:NEVER description:DISK state:RESERVED used:0 allocated:0 total number of reservations: 2 total number of bytes reserved: 60000 LinkGroups: 1 Name:dech-linkGroup-Disk FreeSpace:38654705664 ReservedSpace:30000 AvailableSpace:38654675664 VOs:{/dech:*} onlineAllowed:true nearlineAllowed:false replicaAllowed:true custodialAllowed:false outputAllowed:false UpdateTime:Sun Sep 07 14:16:26 CEST 2008(1220789786439) 0 Name:gks-linkGroup-Disk FreeSpace:38654705664 ReservedSpace:30000 AvailableSpace:38654675664 VOs:{/gks:*} onlineAllowed:true nearlineAllowed:false replicaAllowed:true custodialAllowed:false outputAllowed:false UpdateTime:Sun Sep 07 14:16:26 CEST 2008(1220789786439) total number of linkGroups: 2 total number of bytes reservable: 0 total number of bytes reserved : 0 last time all link groups were updated: Sun Sep 07 17:16:32 CEST 2008(1220800592738) Change the size of reservation 10001 [dcache-node.fzk.de] (SrmSpaceManager) admin > update space reservation 10001 40000 10001 voGroup:/dech voRole:NULL retentionPolicy:REPLICA accessLatency:ONLINE linkGroupId:1 size:40000 created:Sun Sep 07 17:19:25 CEST 2008 lifetime:-1ms expiration:NEVER description:DISK state:RESERVED used:0 allocated:0dcache-node.fzk.de