User guide: JASMIN - RDF transfers

User guide: transferring data between JASMIN and ARCHER/RDF

Introduction

Users of ARCHER or the UK Research Data Facility (RDF) may benefit from using a dedicated Optical Private Network (OPN) connection, or light path, between JASMIN and RDF. This link bypasses the standard JANET network and makes a direct connection between certain hosts at either end.

Using the light path

The light path connects the RDF data tranfer node host dtn02.rdf.ac.uk with the JASMIN host jasmin-xfer1.ceda.ac.uk.

It is configured so that dtn02.rdf.ac.uk is visible as if it were on the local network of jasmin-xfer1.ceda.ac.uk, but only from jasmin-xfer1.ceda.ac.uk. From other hosts within the JASMIN infrastructure, the name will resolve over the standard network and not the light path. 

The light path consists of a bonded pair of 1Gbit/sec connections.

Prerequisites

In order to make use of this connection, you will need:

  • An account on JASMIN with access to jasmin-xfer1.ceda.ac.uk
  • An account on RDF with access to dtn02.rdf.ac.uk. Contact ARCHER/RDF helpdesk.

Examples

In the following examples, it is assumed that you are already logged in to jasmin-xfer1.ceda.ac.ukand that you enabled agent forwarding in your inital SSH connection, e.g.

[user@myhost ~]$ ssh -A user@jasmin-xfer1.ceda.ac.uk

Log in using the private network connection

Log in using the private network provided by the light path:

[username@jasmin-xfer1 ~]$ ssh username@dtn02.rdf.ac.uk

Note: your username at the RDF end may not be the same as at the JASMIN end. If this is successful, you can proceed to the next step.

Test data transfer using the light path

Copy a simple file from jasmin-xfer1 to dtn02 using scp.

[username@jasmin-xfer1 ~]$ scp testfile.txt username@dtn02.rdf.ac.uk:~/mydir/testfile.txt

If successful, try using alternative transfer methods to transfer data, using dtn02.rdf.ac.uk. scpis not always the best method.

Bbcp example

With a transfer initiated on jasmin-xfer1.ceda.ac.uk, pulling data from dtn02.rdf.ac.uk, you need to include module load bbcp to set up the path at the RDF end before you can refer to the bbcp executable:

bbcp -P 5 -v -s 16 -F --port 50000:50300 -S "/usr/bin/ssh %I -l %U %H module
 load bbcp; bbcp" username@dtn02.rdf.ac.uk:<PATH_TO_SOURCE_FILE> <PATH_TO_TARGET_FILE>  

A good way of testing performance is to use /dev/zero as the source and /dev/null as the target:

bbcp -P 5 -v -s 16 -F --port 50000:50300 -S "/usr/bin/ssh %I -l %U %H module
 load bbcp; bbcp" username@dtn02.rdf.ac.uk:/dev/zero /dev/null

Don't forget to use ssh -A (agent forwarding enabled) for your initial connection to jasmin-xfer1.ceda.ac.uk so that your SSH key can be used to authenticate you on the remote host. This works if you have pasted your public key into your ~/.ssh/authorized_keys file on the remote host. Note you do NOT need to copy your private key anywhere.

Gridftp example

If you have an account both at the JASMIN end and the RDF end, you can use gridftp over ssh to transfer the data:

target. Try this command on jasmin-xfer1:

globus-url-copy -vb -p -16 -fast sshftp://username@dtn02.rdf.ac.uk/<PATH_TO_SOURCE_FILE> <PATH_TO_TARGET_FILE>

Alternatives

The JASMIN - RDF light path is available to users only on jasmin-xfer1.ceda.ac.uk. There will be occasions when, due to shared use of the network or the machines at either end, using the JASMIN high-performance data transfer service  may provide better performance, however it is designed for more general destinations where a light path is not available. Its routing bypasses the RAL site firewall but does NOT enable access to the JASMIN - RDF light path so once out of the RAL network it uses the standard JANET network.

For example, the command below issued on jasmin-xfer2.ceda.ac.uk initiates the same transfer as the last Gridftp example, but over the different path from the JASMIN Data Transfer Zone (not using the light path). In this case, either dtn01 or dtn02 can be used.

globus-url-copy -vb -p 16 -fast sshftp://username@dtn02.rdf.ac.uk/<PATH_TO_SOURCE_FILE> <PATH_TO_TARGET_FILE>

You can experiment with different values for -p (sensible range 1 - 32) to see which achieves the best transfer rates, perhaps using /dev/zero and /dev/null before trying on real data.

globus-url-copy -vb -p 32 -fast sshftp://username@dtn02.rdf.ac.uk/dev/zero /dev/null
globus-url-copy -vb -p 32 -fast sshftp://username@dtn02.rdf.ac.uk/<PATH_TO_SOURCE_FILE> <PATH_TO_TARGET_FILE>

Note that file size can have a big effect on transfer speed: transferring lots of small files is generally much slower than fewer large files, but this can vary. Often the transfer rate takes a while to "ramp up" to full speed: you can observe this interactively if you use the -vb option as shown.

Further information

This website and others run by CEDA use cookies. By continuing to use this website you are agreeing to our use of cookies.