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
Number of topics: 1
Maintainer:
GavinMcCance