Current Usage on SC3 on GridView

News:

• FTS Website is in place (Dec. 8)

• Channels
• Transfer Jobs and Placement Jobs
• Job States
• Individual File States
• Authorization
• FTS Architecture

• Command-line tools
  • Transfer interface
  • Channel Management
  • Statistics
  • SRM
  • gridftp
  • glite-url-copy
• Java API
• C API
• Other APIs

• Download
• Release Notes
• Installation and Configuration

• Known issues and FAQ
• Getting help
• Bug Reporting

The FTS performs file transfers on channels. An FTS instance serves a configurable set of channels. Every channel is unidirectional, i.e. it is intentional that different FTS instances may serve the two directions of a network link between two sites. Usually the receiving site configures the corresponding channel, as it is shown on the image to the right. We define channel as follows:

Channel: A channel is a specific (perhaps dedicated) network pipe for transferring
files between two sites. We distinguish between

• Production Channels. These are typically dedicated Tier0-Tier1, Tier1-Tier1 or Tier1-Tier2 network pipes. Production transfer jobs run on these channels to ensure efficient bulk distribution. All files in a job must be assignable to the same channel, otherwise the job will not be assigned to a production channel.
  
• Non-production Channels. Typically open networks shared with other applications. Jobs otherwise not assignable to a production channel may be serviced on the open network. Such channels are usually denoted by a 'Star'.

Transfer Jobs and Placement Jobs

The difference between Transfer and Placement jobs is the interaction with the File and Replica catalogs. For Transfer Jobs the client has to specify the SURLs involved in the transfer, for Placement Jobs, the FTS will resolve the logical file names to SURLs by itself.

Transfer Jobs are composed of:

• A list of files (source - destination pairs) to transfer. For production channels, each pair has to be coming from the same source and be transferred to the same desitnation. On non-production channels, this restriction is not there.
• A set of optional parameters (key/value pairs), for passing options to the underlying transport layer. Currently the only supported options are the gridFTP parameters for TCP buffer size and number of streams. If present, the key must be 'gridFTP' with the values specified as '-tcp-bs 1000 -p 20' in the format used by the globus-url-copy commandline tool. The options are advisory to the service. If not specified, the service defaults are used. It is recommended to use the service defaults, i.e. to ignore this option.
• A security token. Depending of the mode of operation this is either a MyProxy password or a delegation ID.

Alternatively, you can also submit what we call Placement Jobs. Placement Jobs are composed of:

• A list of Logical File Names (string array) to involve in the transfer.
• The destination Storage Element This is the name of the destination SE as published in the information system and retrievable through Service Discovery.
• The source Storage Element This is the name of the source SE to use.
• A set of optional parameters - same as for Transfer Jobs
• A security token. - same as for Transfer Jobs

Job States

Final States for Transfer Jobs

Transfer jobs will go through a set of states while the FTS is working on them.
The final states for the FTS Transfer Jobs are:

Normal Job Path: Transfer Jobs

The normal route for a Transfer Job through the FTS is as follows:

• Upon submission to the FTS, the job will be in Submitted state.
• If the VO to which the user belongs authorizes the transfer, the transfer will move into Pending state.
• Once the files in the given job start to be transferred, the job becomes Active.
• If all files have successfully transferred, the final state will be Done.

Final States for Placement Jobs

The difference between transfer jobs and placement jobs is that there is also a lookup and a registration step involved, which means that the state machine is slightly different.
The final states for the FTS Placement Jobs are:

Normal Job Path: Placement Jobs

The normal route for a Placement Job through the FTS is as follows:

• Upon submission to the FTS, the job will be in Submitted state.
• If the VO to which the user belongs authorizes the transfer, the transfer will move into Pending state.
• Once the files in the given job start to be transferred, the job becomes Active.
• If all files have successfully transferred, the state will be Done.
• Finally, if the copies have been successfully registered in the replica catalog, the final state will be Finished.

Cancel a Job

Should the user decide to cancel the job, the following possibilities may occur:

• If the user cancels while the job is still in Submitted state, the job will go to the final Canceled state immediately.
• If the user cancels while the job is Pending or Active, the job will go into the Canceling state.
• Jobs in the Canceling state will not start to execute new file transfers in the list of files the job has anymore. Current active transfers will be canceled. Once all active transfers have either transferred successfully or have been cancelled, the job state will move to the final Canceled state. On the rare occasion where the user is cancelling just before the last file that is being transferred is just finishing, the final state may move to Done (for Transfer, and eventually Finished for Placement jobs).

Failures

Transfer Jobs: If there was an error that the FTS cold not resolve, the transfer is moved to the Failed or Hold state from Active. From the Hold state the user has to resurrect the job by either moving it to the Pending or Failed states explicitly.

Placement Jobs: The same as for Transfer Jobs, except that Failed is not a final state and there is an additional failure that can happen after the Done state (failure to register the file in the catalog). The final state will be FinishedDirty instead.

Individual File States

Final States

The individual states of a single file inside a Transfer Job will also go through a set of states while the FTS is queuing it for transfer.
The final states for the files are:

Normal File Path: Transfer Jobs

The normal route for a file through the FTS is as follows:

• Upon submission to the FTS, all files in a job will be in Submitted state.
• If the VO to which the user belongs authorizes the transfer, the transfer will move into Pending state and all files will do so as well.
• Once the file is scheduled for transfer and the transfer is being executed, the file state is set to Active.
• If the file has successfully transferred, its final state will be Done.

File Transfer States

Normal File Path: Placement Jobs

The normal route for a file through the FTS for Placement Jobsis as follows:

• Upon submission to the FTS, all files in a job will be in Submitted state.
• If the VO to which the user belongs authorizes the transfer, the transfer will move into Pending state and all files will do so as well.
• Once the file is scheduled for transfer and the transfer is being executed, the file state is set to Active.
• If the file has successfully transferred, its state will be Done.
• Finally, if it has been registered successfully in the catalog, its final state will be Finished.

Cancel a File

Should the user decide to cancel a file transfer, the following possibilities may occur:

• If the user cancels while the file is still in Submitted state, the file will go to the final Canceled state immediately.
• If the user cancels while the file transfer is Active, the FTS will try to cancel the ongoing transfer and the file state will be set to the Canceling state.
• Files in the Canceling state will either be canceled and cleaned up or they will successfully transferred to the end. Files that have been cancelled will move to the final Canceled state. Files that have been transferred correctly will move to Done. In some cases the file transfer may also fail for reasons unrelated to the cancel request, in which case the final state will be set to Failed.

Failures and the Waiting State

If there was an error, the transfer is moved to the Waiting state. Depending on the VO policy on what to do with files in this state, the file may move automatically to the Hold, Pending or Failed states. From the Hold state, the file has to be set to Pending or Failed explicitly through the FTS interface. This is the place where the VO may implements its own retry policies.

In addition, for Placement Jobs, there may be the failure to register the file in the catalog, which may move a file from the Done state to FailedCatalog instead of Finished.

Authorization

There are in total 6 different roles that a user can have and acumulate on the service:

• Admin: Administrator of the service. Can perform any operation,
  including submitting jobs.
• Channel Manager: Manages a single channel. Can perform any
  operation involving the same channel information (query and update)
  and requests linked to the same channel (query and update/cancel).
• VO Manager: Manages a single VO. Can perform any operation
  involving requests linked to the same VO (query and update/cancel).
  Can also query information about channels.
• Submitter User: Regular user with additional capability to submit jobs.
• Regular User: Managers its own job, including querying and canceling it.
• Vetoed User: has been vetoed in the service. Cannot perform any operation.

These five roles have the following abilities to operate on the FTS in detail:

• X The operation marked with an X is fully authorized for the given role.
• C The Channel Manager is authorized to perform the operations on the jobs of the channels that it is actually managing. Listing will retrieve only the requests of the channes that it actually manages.
• V The VO Manager is authorized to perform the operations for the jobs of the VOs that it manages. Listing will retrieve all jobs for the given VOs.
• U The user is authorized to perform the operation only for its own jobs. Listing will list all its jobs.
• The vetoed user may be successful in performing a List request, but the returned list will always be empty.

Architecture

The gLite File Transfer Service has been designed in a modular and extensible way to allow good scalability. The components of the FTS are:

• The clients. The FTS client libraries or command line tools are used by the applications to communicate with the FTS. Of course there may be many clients connected to the FTS web service, the communication is over a secure connection using the SOAP protocol.
   
• The FTS Web Service. The web service component is implemented as a Tomcat web application. This is a proper web service that implements the WSDL as defined by the FTS interface. Based on the Web Service Description Language document, anyone can build their own clients in their own preferred language. There can be many Tomcat containers deployed that access the same underlying database, which is one of the possibilities to scale the system. The web service connects to the database through JDBC using a Tomcat database connection pool.
   
• The FTS Database. There is a MySQL and an Oracle implementation of the FTS schema. This is the only persistency point in the system and it scales only as well as the corresponding backend allows (Oracle scales better than MySQL, obviously). There can be only a single instance of this database for a given FTS instance.
   
• The File Transfer Agents. The agents will act based on certain conditions in the database. They make sure that the finite state machine of the FTS is adhered to and perform all state transitions for the transfer jobs and the files being transferred. It is an agent that actually performs the file transfers on the channels that the FTS manages. The architecture of the agents is explained in more detail below.

The File Transfer Agents

The Agent component also has a modular design in itself. There are two basic agent types for the different responsabilities and tasks that the FTS has to perform. We distinguish between VO Agents and Channel Agents.

The table above gives a description of the responsiblities and dependencies for VO and Channel Agents. For Placement Jobs,
also the items printed in blue are relevant. The items in red are in planning and not part of the FTS yet (Nov.2005).

There is a dedicated VO agent for each VO that a given channel serves and there is a dedicated channel agent per channel. So if an FTS serves 5 channels for 4 VOs each, there will be 20 Agents running. These agents may be running all on different physical machines, which also allows for additional scalability of the service.

Components involved in the File Transfe Agent (FTA) architecture. The yellow box contents belong to the FTA, the other
componets are external to the FTA and are shown to emphasize the modular aspect of this particular component of Grid middleware.

The FTA implements a set of connectors which may be extended to support more external components. For example, now Oracle and MySQL connectors are supported as of version 1.3. It is straightforward to implement connectors for other database backends. The same modular model is used for the catalogs and the transfer service connectors. The FTA makes use of the gLite service discovery API which itself is also modular and can switch between information system implementations based on configuration.