Basic configuration (Getting it to run)

Basic configuration (Getting it to run)
Prev	Chapter 12. Central Flushing to tertiary storage systems	Next

This section describes how to setup a central flush control manager.

Whitin the PoolManager, a pool-group (<flushPoolGroup>) has to be created and populated with pools planned to be controlled by the central flush mechanism. An arbitrary number of flush control managers may run within the same dCache instance as long as each can work on its own pool-group and no pool is member of more than one <flushPoolGroup>.
To start the flush control system, an corresponding dCache batch file has to be setup, installed and started. As input parameter, the HsmFlushControl cell needs the name of the <flushPoolGroup>) and the name of the driver, controlling the flush behaviour. Within the same batch file more than one flush control manager may be started as long as they get different cell-names and different pool-groups assigned.
The flush control web pages have to be defined in the httpd.batch.

Creating the flush pool group

Creating <flushPoolGroup> and adding pools is done within the config/PoolManager.config setup file or using the PoolManager command line interface. Pools may be member of other pool-groups, as long as those pool-groups are not managed by other flush control managers.

psu create pool <pool-1>
psu create pool <...>
#
psu create pgroup <flushPoolGroup>
#
psu addto pgroup <flushPoolGroup>  <pool-1>
psu addto pgroup <flushPoolGroup>  <...>
#

[return to top]

Creating and activating the hsmcontrol batch file

#
set printout default errors
set printout CellGlue none
#
onerror shutdown
#
check -strong setupFile
#
copy file:${setupFile} context:setupContext
#
import context -c setupContext
#
check -strong serviceLocatorHost serviceLocatorPort
#
create dmg.cells.services.RoutingManager  RoutingMgr
#
create dmg.cells.services.LocationManager lm \
     "${serviceLocatorHost} ${serviceLocatorPort}"
#
create diskCacheV111.hsmControl.flush.HsmFlushControlManager <FlushManagerName>  \
        "<flushPoolGroup>  \
         -export   -replyObject \
         -scheduler=<SchedulerName>  \
         <Scheduler specific options> \
        "
#

Which the following meaning of the variables :

<flushPoolGroup> needs to be the name of the pool group defined in the PoolManager.conf files.
<SchedulerName> is the name of a class implementing the diskCacheV111.hsmControl.flush.HsmFlushSchedulable interface.
<Scheduler specific options> may be options specific to the selected scheduler.

Initially there are three schedulers available :

diskCacheV111.hsmControl.flush.driver.HandlerExample may be used as an example implementation of the HsmFlushScheduler interface. The functionality is useless in an production environment but can be useful to check the functionality of the central flush framework. If one allows this driver to take over control it will initiate the flushing of data as soon as it becomes aware of it. One the other hand it supports a mode where is doesn’t do anything except preventing the individual pools from doing the flush autonomously. In that mode, the driver assumes the flushes to be steered manually by the flush web pages decribed in the next paragraph. The latter mode is enabled by starting the flush driver with the <Scheduler specific options> set to -do-nothing
diskCacheV111.hsmControl.flush.driver.AlternateFlush is intended to provide suffient functionality to cope with issues described in the introduction of the paragraph. Still quite some code and knowledge has to go into this driver.
diskCacheV111.hsmControl.flush.driver.AlternatingFlushSchedulerV1 is certainly the most useful driver. It can be configured to flush all pools on a single machine simultaniously. It is trigger by space consumption, number of files within a pool or the time the oldest file resides on a pool without having been flushed. Please checkout the next section for details on configuration and usage.