No permission to view FIOgroup.FabricServicesMenu

WLCG FTS Service Description

This page describe briefly the WLCG FTS service.

Example FTS Deployment

• Current deployment of FTS on CERN-PROD: FtsTier0Deployment
• Example deployment for a Tier1: FtsServerDeployExampleTier1

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

• Development work for upcoming FTS releases is maintained EGEE.FTS.
• For a mapping from FTS to gLite releases see: FtsANoteOnVersions.
• Details of client and server version interaction: FtsClientCompatabilityMatrix.

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.

FTS PL/SQL code

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