FTS channels for an example Tier-1 site

This page shows which channels to setup for an example Tier-1.

It follows the advice given in:

https://twiki.cern.ch/twiki/pub/LCG/FtsServerInstall15/SC4FTSsetupplan.doc

Example site topology

We assume there is a tier-1 site at a lab called 'Testlab'. The site resources (e.g. the storage resouce) for this site are registered in EGEE.BDII and the GOCDB with sitename TESTLABT1.

This T1 site has several associated T2 sites, mostly univesities or smaller labs in the same country:

• Pants University. Its resouces are registered with sitename PANTS.
• SmallLab enterprises. Its resources are registered with sitename SMALLENT.
• Random labs running the Small Hadron Collider experiment. Its resources are registered with sitename RAND-SHC.

The rest of the world contains two larger tier-1 sites:

• Rutherford Appleton Lab. Its resources are registered with sitename RAL-LCG2.
• INFN National Center for Telematics and Informatics. Its resources are registered with sitename INFN-CNAF.

What channels do define are what to call them

The actual names you choose for the channels should be readable (but do not need to be the GOCDB names). There are a few restrictions and some suggestions:

• The name MUST be upper case.
• The name MUST NOT contain any characters that bash thinks are special (e.g. dots, slashes, etc).
• The name SHOULD indicate the source and destination site, preferably separated by a dash.
• "catch-all" source or destination SHOULD be indicated by STAR.

When you define the channel you must additionally specify the source and destination sites for the channel. This will either be an asterix for 'catch-all' channels or MUST be the GOCDB/EGEE.BDII sitename for the site in question.

The Tier-1 channels: you are resposible for transfers when you are the destination

The WLCG model described above requires you to run channels from other tier-1 sites for which you are the DESTINATION. In the example there are two other T1 sites.

Define the channels, pulling data from each of the other T1 sites:

glite-transfer-channel-add RAL-TESTLAB RAL-LCG2 TESTLAB1
glite-transfer-channel-add CNAF-TESTLAB INFN-CNAF TESTLAB1

The channel names RAL-TESTLAB and CNAF-TESTLAB are suggestons (you may choose some other name subject to the rules above). The two fields afterwards are fixed (i.e. you must define the channel using the correct GOCDB name of the source and destination site).

You would then define two channel agents or type URLCOPY (or SRMCOPY if you prefer) to handle the channels. The agent names, as specified in YAIM, should match whatever you chose to call the channels.

FTA_AGENTS_ONE_HOSTNAME="fts_prod.testlab.xx"
FTA_AGENTS_ONE="RAL-TESTLAB CNAF-TESTLAB"

You SHOULD NOT define a channel that pushes data out to other tier-1 sites. The resposibility for those transfers lies with the other T1 site, not with you.

The catch-all Tier-1 channel: you are resposible when you are the destination

A tier-1 should also run a sngle 'catch-all' channel for itself, PULLING data into itself from any other site. The specific tier-1 links will be managed on the dedicated channels you defined above; the purpose of this channel is to catch the data coming from your own or other tier-2 sites.

Define the channel:

glite-transfer-channel-add STAR-TESTLAB "*" TESTLAB1

and create the agent's definition in the YAIM file (along with the other ones you already have):

FTA_AGENTS_ONE_HOSTNAME="fts_prod.testlab.xx"
FTA_AGENTS_ONE="RAL-TESTLAB CNAF-TESTLAB STAR-TESTLAB"

You are resposible for transfers GOING TO any of your Tier-2 sites

To ease the burden on the tier-2 sites, the tier-1 site runs the transfer for them. The tier-1 is resposible for running transfers for which one of its tier-2 sites is the destination. The covers two use case:

• Data coming fronm the tier-1 site itself
• Data coming from elsewhere, e.g. other tier-1 sites or any tier-2 sites.

For each tier-2 site, create a 'catch-all' channel for it, picking up all transfers for which it is the desintation. In the example:

glite-transfer-channel-add STAR-PANTS "*" PANTS
glite-transfer-channel-add STAR-SMALLLAB "*" SMALLENT
glite-transfer-channel-add STAR-RANDOMLABS "*" RAND-SHC

any add the agent definitions to the YAIM config:

FTA_AGENTS_ONE_HOSTNAME="fts_prod.testlab.xx"
FTA_AGENTS_ONE="RAL-TESTLAB CNAF-TESTLAB STAR-TESTLAB STAR-PANTS STAR-SMALLLAB STAR-RANDOMLABS"

OPTIONAL agents

You have now defined all agents you need to cover all the tier-1's resposibilites as outlined in

https://uimon.cern.ch/twiki/pub/LCG/FtsServerInstall15/SC4FTSsetupplan.doc

You may optionally wish to define agent (WITHIN these responsibilities) that allow you to manage specific links on a separate channel (instead of managing them on the 'catch-all' channel. For example you may wish to manage some of the links explicitly to or from your tier-2 sites. In the example, the Testlab tier-1 wants to manage the link to and from SmallLab explicitly, so two more channels should be defined:

glite-transfer-channel-add TESTLAB-SMALLLAB TESTLAB1 SMALLENT
glite-transfer-channel-add SMALLLAB-TESTLAB SMALLENT TESTLAB1

and the agents to go with them:

FTA_AGENTS_ONE_HOSTNAME="fts_prod.testlab.xx"
FTA_AGENTS_ONE="RAL-TESTLAB CNAF-TESTLAB STAR-TESTLAB STAR-PANTS STAR-SMALLLAB STAR-RANDOMLABS TESTLAB-SMALLLAB SMALLLAB-TESTLAB"

Transfers from SEs not in the information system or classic-SEs

By default, if an SRM is supplied which is NOT in the information system, the transfer will fail. This default is chosen to ensure that only production SRMs are managed by the FTS.

If you wish to disable this safety and allow any SRM as the source, set the YAIM parameter.

FTA_TYPEDEFAULT_VOAGENT_PYTHON_ACTIONS_ENABLEUNKNOWNSOURCE=true

This will cause unpublished source SRMs to be matched on any channel with a STAR source.

Use of FTA_TYPEDEFAULT_VOAGENT_PYTHON_ACTIONS_ENABLEUNKNOWNDEST is not recommended at all, since we do not recommend to usage of STAR on the destination of a channel for LCG production.

Channel which are not recommended

It is explicitly not recommended to setup:

• STAR-STAR channels. This is for small scale simple VOs, not production Grids. The reason for this is that if any tier-1 site has problems publishing their channel information into EGEE.BDII, the fairly simplistic channel matching in the service discovery tool will not find that T1 site's FTS server. It will then fall back to looking for a STAR-STAR channel to service the user's job and will find yours. So the entire FTS workload of the other T1 site will be sucked onto your FTS server.

• Channels outwith your resposibility. For example a channel pushing data to another tier-1 site. Since this resposibilty is covered by another T1 site's FTS server, the service discovery tool will (probably at random) select either your FTS or the correct FTS to service the job. This makes debugging the overall service quite hard.

• A subset of the above, channels where the destination is STAR are not recommended, since this will usually overlap with the resposibilities of other T1 sites.

Last edit: GavinMcCance on 2008-10-13 - 16:15

Maintainer: GavinMcCance