No permission to view FIOgroup.FabricServicesMenu

WLCG FTS Service Description

This page describe briefly the WLCG FTS service.

Example FTS Deployment

FTS Releases

FTS 2.1 on SLC4 is the current production release.

Release Release Notes Install Guide Admin Guide Procedures
2.1 FtsRelease21 FtsServerInstall21 FtsServerAdmin20 FtsServiceProcedures
2.0 FtsRelease20 FtsServerInstall20 FtsServerAdmin20 FtsServiceProcedures
1.5 FtsRelease15 FtsServerInstall15 FtsServerAdmin15 FtsProcedures15
1.4 FtsRelease14 FtsServerInstall14 FtsServerAdmin14 FtsProcedures14
1.3 FtsRelease13 FtsServerInstall13 FtsServerAdmin13  
1.1.1 FtsRelease112 FtsServerInstall112 FtsServerAdmin112  

FTS Component Overview

There are four components to any of the FTS Service. Any one node can run any number of components (although this has not been tested in full production). At CERN we currently deploy only one component type per node.

FTS Web service ("FTS")

This component allows users to submit FTS jobs and query their status. It is the only component that users interact with. It runs as a Tomcat web-application (Java based). The node also has a local BDII with a GIP publishing the necessary information about this FTS server (the site BDII should configured to pull this information).

Referred to throughout a node type FTS.


FTS agents ("FTA")

These are the backand agents that do the work of the service. Each agent runs as a distinct daemon, and you may have as many agents daemons running on a node as it can support. There are two main type (channel and VO agent) which may be mixed across nodes as necessary.

Referred to throughout a node type FTA.

FTS agents: channel agent

Each network channel, (e.g. "transfers from CERN to RAL") has a distinct daemon running transfers for it. The daemon is responsible for starting and controlling transfers on the associated network link. When a transfer is started, a controlling process for that transfer is (double) forked from the controlling agent.

There should be one agent daemon for every channel that the FTS has defined, each managing a different channel.

Since they produce a large number of forked processes, the channel agent daemons are generally spread over a number of agent nodes ~equally.


FTS agents: VO agents

Each VO served by the FTS ervice has a distinct VO agent daemon running for it. This performs house-keeping tasks for that VO. There should be one VO agent daemon for every VO that will use the FTS service.

The VO agents consumee very little resources and can be put frelly on any agent node in the cluster.

FTS Monitor ("FTM")

This provides an Apache httpd server which serves monitoring data to a varierty of clients. Most of the served data is statically produced by (frequently running) cron-script or daemons (rather than CGI-based).

It currentl provides a GridView monitoring feed into the WLCG monitoring system and a couple of modules for basic service monitoring. It is intended that new monitoring modules can be dropped in as needed.

Referred to throughout a node type FTM.


There are some DB jobs that run inside the core schema: FTS PL/SQL code guidelines are described in FtsDbCodeGuide. There are some

Useful FTS Commands

Some commands that are useful to an FTS adminstrator FtsUsefulCommands

Topic attachments
I Attachment History ActionSorted ascending Size Date Who Comment
PNGpng agent-deployment.png r1 manage 145.3 K 2008-09-15 - 10:55 GavinMcCance Agent daemon deployment
PNGpng webservice-deployment.png r1 manage 99.0 K 2008-09-15 - 10:55 GavinMcCance Webservice deployment

This topic: LCG > FtsWlcg
Topic revision: r33 - 2010-01-22 - SteveTraylen
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback