FTS2 IS NOW OBSOLETE PLEASE SEE FTS3 FOR THE LATEST VERSION!!!

File Transfer Service

Current version

The current version of the FTS software, including all documentation: FtsRelease21.

For updates please refer to DMFtsPatchStatus

The next release is FtsRelease22 with the documentation:

• Install Guide
• Configuration Guide
• Administration Guide
• Administration Procedures
• Known issues

Bug and problem reporting

• All operational problems with the FTS service should be submitted via the GGUS portal.

• All software problems should be submitted and are tracked in savannah.cern.ch.

• If you don't know whether the problem is an operational or a software issue, submit it via the GGUS portal.

Software requirements tracking

The current prioritized list of software improvements requested by the EGEE VOs and tracked by the Technical Coordination Group on the JRA1 workplan:

• EGEE gLite work plans
• List of bugs in Savannah

FTS Overview

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 back-end 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 service 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 consume very little resources and can be put freely on any agent node in the cluster.

FTS Monitor ("FTM")

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

It currently 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.

Other links

• Internal documentation for FTS version 2.0 and 2.1 and 2.2: FtsInternalDocumentation.
• Current FTS presentations and diagrams are on the FTSPresentationsPage.
• The validation FTS pilot service is described in TransferOperationsPilotService.

Operational notes

The current status of the CERN-PROD service is described in TransferOperations.

• Operations procedures for the computer centre operators are documented in OPM for the gridfts cluster
• Deployment layout is documented in FtsTier0Deployment
• Installation / upgrade / FAQ / etc is described at FtsInstallation
• CERN-PROD intervention plans are described in FtsTier0ServerInterventions
• Standard service manager procedures are described in FtsProcedures20

FTS testing

• Collection of FTS test topics FtsTest

Maintainer: RosaGarciaRioja