The executable interacting with the Tertiary
Storage System (TSS), as described in the chapter above, has
to be provided to dCache on all pools connected to the
TSS. The executable, either a script or a
binary, has to be made “executable” for the user,
dCache is running as, on that host.
The following files have to be modified to allow dCache to interact with the TSS.
/opt/d-cache/config/PoolManager.conf file (one per
system)
After the layout files and the various ’setup’ files have been corrected, the following domains have to be restarted :
To be able to read a file from the tape in case the cached file has been deleted from all pools, enable the restore-option. The best way to do this is to log in to the Admin Interface and run the following commands:
[example.dcache.org](local) admin >cdPoolManager[example.dcache.org](PoolManager) admin >pm set -stage-allowed=yes [example.dcache.org](PoolManager) admin >save
A restart of the dCacheDomain is not necessary in this case.
Alternatively, if the file
/opt/d-cache/config/PoolManager.conf already
exists then you can add the entry
pm set -stage allowed=yes
and restart the dCacheDomain.
/opt/d-cache/config/PoolManager.conf
with this single entry! This will result in an error.
The dCache layout file must be modified for each pool node
connected to a TSS. If your pool nodes have been
configured correctly to work without TSS, you will find
the entry lfs=precious in the layout file
(that is located in /opt/d-cache/etc/layouts and in
the file /opt/d-cache/etc/dcache.conf
respectively) for each pool service. This entry is a
disk-only-option and has to be removed for each pool which
should be connected to a TSS. This will default the
lfs parameter to hsm
which is exactly what we need.
The pool ’setup’ file is the file
$poolHomeDir/$poolName/setup. It mainly
defines 3 details related to TSS connectivity.
executable which is
launched on storing and fetching files.
STORE FILE requests
allowed per pool.
FETCH FILE requests
allowed per pool.
Define the executable and Set the maximum number of
concurrent PUT and GET operations:
hsm set <hsmType> [<hsmInstanceName>] [-command=</path/to/executable>] [-key=<value>] # # PUT operations # set the maximum number of active PUT operations >= 1 # st set max active <numberOfConcurrentPUTS> # # GET operations # set the maximum number of active GET operations >= 1 # rh set max active <numberOfConcurrentGETs>
executable which
should be launched for each TSS operation.
Setting the maximum number of concurrent
PUT and GET
operations.
Both numbers must be non zero to allow the pool to perform transfers.
Example:
We provide a script
to simulate a connection to a TSS. To use this script
place it in the directory /opt/d-cache/jobs, and create
a directory to simulate the base of the TSS.
[root] #mkdir -p /hsmTape/data
Login to the Admin Interface to change the entry of the pool ’setup’ file for a pool named pool_1.
(local) admin >cd pool_1(pool_1) admin >hsm set osm osm(pool_1) admin >hsm set osm -command=/opt/d-cache/jobs/hsmscript.sh(pool_1) admin >hsm set osm -hsmBase=/hsmTape(pool_1) admin >st set max active 5(pool_1) admin >rh set max active 5(pool_1) admin >save
In order to allow dCache to remove files from attached TSSes, the “cleaner.enable.hsm = true” must be added immediately underneath the [namespaceDomain/cleaner] service declaration:
[namespaceDomain] ... other services ... [namespaceDomain/cleaner] cleaner.enable.hsm = true .. more ...
After restarting the necessary dCache domains, pools, already containing files, will start transferring them into the TSS as those files only have a disk copy so far. The number of transfers is determined by the configuration in the pool ’setup’ file as described above in the section called “The pool ’setup’ file”.