FTS channel pause for FTS release 2.0

What is it?

This is the procedure for stopping (or pausing) channels when there is an known intervention on one of the underlying services.

When to use it?

If for example, an SRM is going down. You should pause the relevant channel(s) to avoid draining FTS jobs.

Procedure

The procedure is fairly simple.

Note which channels are set Active and which are Inactive

Make sure you know if any channels are already set Inactive and why.

In particular, you are encouraged to make use of the "-m" option to say why you are doing a specific operation (new in FTS 2.0).

The glite-transfer-channel-audit command will list previous changes to the channel (new in FTS 2.0).

Understand which channels are affected by the intervention

For example, if the SRM is under maintenance at Rutherford Appleton Laboratory, the affected channels will be CERN-RAL and RAL-CERN.

If Castor2 at CERN is under maintenance, all CERN-PROD channels will be affected.

Set the channels Inactive

A few minutes before the scheduled downtime:

For each channel affected, run as root on one of the FTS nodes (fts101 to fts105):

. /etc/profile
glite-transfer-channel-set -S Inactive CHANNELNAME -m "Setting channel inactive due to maintenance on our SRM"

Or all channels inactive:

. /etc/profile
for i in `glite-transfer-channel-list`; do glite-transfer-channel-set -S Inactive $i -m "Setting all channels inactive" ; done

The transfers should stop within a few minutes (currently running transfers always attempt to finish first).

Wait until the intervention is over

...

Set the channels Active again

For each channel affected, run as root on one of the FTS nodes (fts101 to fts105):

. /etc/profile
glite-transfer-channel-set -S Active CHANNELNAME -m "Setting channel back active after SRM maintenance"

Or set all channels active:

. /etc/profile
for i in `glite-transfer-channel-list`; do glite-transfer-channel-set -S Inactive $i \
     -m "Setting all channels back active after maintenance"; done

You should MAKE SURE that if any channels were set Inactive before the intervention, you do not set them Active without knowing that they really should be set Active again (e.g. there may be a parallel intervention going on at the given site).

Queued transfer will resume within a few seconds.

Maintainer: GavinMcCance