GRID COMPANION GUIDE

Transcription

1 Companion Subject: GRID COMPANION Author(s): Miguel Cárdenas Montes, Antonio Gómez Iglesias, Francisco Castejón, Adrian Jackson, Joachim Hein Distribution: Public 1.Introduction Here you will find the most basic information in order to get access to the EUFORIA Grid Infrastructure. The aim of this document is to provide the basic information needed to start to work with the grid How to get involved in The Grid? First of all, to be able to run jobs in the EUFORIA Grid Infrastructure you need a personal certificate. How to get a personal certificate? You should contact the Registration Authority of your institution. In the case that your institution does not have a Registration Authority, you should address to your National Certification Authority for science and computing issues. You can find the whole list of Certification Authorities in this page: It may also be wise to promote the creation of a new Registration Authority in your institution, but this is not mandatory. Once you have a certificate you need to affiliate this certificate to a Virtual Organization (VO), particularly to the EUFORIA Virtual Organization. A Virtual Organization is the group of scientists and computer resources with which you intend to work. The link to affiliate your certificate to EUFORIA Virtual Organization is: You will have to load your certificate into your browser to affiliate with the EUFORIA VO. The mechanism for doing this is browser specific, if you have problems contact us at support@euforia-project.eu. 1/9

2 Companion 1.2. How to enter in The Grid? The computers that allow the users to enter in the grid are called User Interface or Grid Portal. These kinds of computer are the entrance to the grid infrastructure. Usually there are several User Interfaces for each grid infrastructure. If you have an account on the ITM s Gateway machine (gateway.efda-itm.eu) then you should have access to the ITM s UI for the EUFORIA Grid: euforia.efda-itm.eu Try logging on with your Gateway username and password and if you cannot access the machine then get in touch with EUFORIA support (support@euforia-project.eu Partners in the EUFORIA project also provide the following UI machines: i2gui01.ifca.es iwrui2.fzk.de iwrui3.fzk.de A new user can obtain a personal account on one of these machines either by addressing a request to your local site administrator (if you are a member of the institutions that provide the UI machines listed above). If you don t know if your institution has a User Interface or your institution doesn't belong to the project, and you do not have a Gateway account, you need to contact us at: support@euforiaproject.eu Where should I put my certificate? Once you have a valid certificate and it has been affiliated to a Virtual Organization, then you need to upload your certificate to a User Interface (UI) of the EUFORIA project. The User Interfaces of the project are: i2gui01.ifca.es iwrui2.fzk.de iwrui3.fzk.de When you have an account on one of the User Interface of EUFORIA, then you need to log on to that account. You can log on using SSH. Once logged on you need to create a directory.globus and copy the files: usercert.pem and userkey.pem into this directory. If you do not have these two files (basically, these files are your public and private keys, part of your certificate), you can obtain them from your certificate by executing a shell script. Such a script may be provided by your Registration Authority (RA the people you obtained your certificate from). If it is not then you can use the one provided at this link: If you have any problems with the step please contact support@euforia-project.eu. 2/9

3 Companion Once you have done this you have covered the prerequisites required to access the EUFORIA grid. The next steps will show you how to start using the grid. 3/9

4 Companion 2. Using the Grid at a first glance Once you have an account on a EUFORIA UI which has been properly setup you can think of running an application. But... you cannot run applications directly on the UI: imagine what would happen if several users ran their applications on the UI, the performance would be very poor as the machine would be overloaded. What you are trying to achieve is to get your applications running on dedicated resources, rather can multi-user resources like the EUFORIA UIs. To execute something, you need to send your application and the data required for your application to the Worker Nodes (WN), which are the machines designed for execution of grid jobs. But, since you are running your application (job in grid terminology) on a remote machine, you have to describe your job: the executable, the arguments it needs, data requirements, output files... You can specify many different things but probably don t need to worry about all of them How can I prepare a simple job? Let s start with a simple application. Consider we want to run a shell script which reads a file (passed as an argument to the shell script), it processes this file and produces a new one, the name of which is also an argument of the shell script. A typical invocation from the command line would be: sh test_script.sh input.file ouput.file The description (JDL Job Description Language) of this application would be: Type = Job ; JobType = Normal ; Executable = /bin/sh ; Arguments = test_script.sh input.file output.file ; StdOutput = standard.out ; StdError = error.err ; InputSandbox = { test_script.sh, input.file }; OutputSandbox = { output.file, standard.out, error.err }; This is the contents of a file called test_script.jdl. Some things to remark: Executable: in this context the executable you want to run is /bin/sh. This program takes our script as an argument. Arguments: since the executable is /bin/sh we have to include our script as argument. Standard output and error have to be specified, but normally (like in this example) it is very easy to do. InputSandbox: here we have to include all the files that have to be transferred to the worker node. In our case, we have to transfer the script and the input file to be processed. The sh application should not be transferred since it exists in all the worker nodes. In general the worker nodes will have the same set of commands and programs installed by default on general linux systems. More information on what is installed on 4/9

5 Companion the worker nodes can be obtained by contacting EUFORIA support (see Conclusions for details on user support). OutputSandbox: all the files that we are interested in having after the execution of the job on the WN should be specified here How can I submit my job? Now we are ready to send this job to the grid. But before that, we have to create a proxy using your digital certificate. A proxy is a method of authenticating yourself in the grid. To create the proxy, execute on the User Interface: voms-proxy-init --voms euforia This command will prompt you for the key of your digital certificate (remember it is located in the.globus directory). After that, you will be logged into the grid. Let s submit the job, using the following command on the User Interface: i2g-job-submit test_script.jdl This command returns the job identifier, which uniquely defines the job to perform further operations. The format of this identifier is: It is often beneficial to save the job identifier that is returned from the job submit command in a file so it can be used to query job status or retrieve output later. One way of doing this is to copy the job identifier to a file called (for instance) job.id. You can also do this automatically using the o attribute, i.e.: i2g-job-submit o job.id test_script.jdl Finally, depending on how the User Interface is setup it may be necessary to specify the VO you want to submit the job too. If you try the submit steps above but the submission fail with the following error: **** Error: UI_NO_VOMS **** Unable to determine a valid user s VO Then you should specify you VO as follows: i2g-job-submit - vo euforia o job.id test_script.jdl 2.3. Is my job running? Now we want to know the state of our job. It can be waiting in the queue in cases where no free worker node exists at the moment in the grid; it can be running; it can fail (we do not want this situation); it can be done (this is what we want). To ask for this state, we have to type: i2g-job-status With this command we can see the different states of our job before the Done state appears. When the job reaches the Done status, we can retrieve our files. 5/9

6 Companion If you have saved the job identifier in a file when the job submit was performed then you can use this with the job status command as follows: i2g-job-status i job.id Where job.id is the name of the file you stored the job identifier in And where is my output? We said retrieve our files and that is because our output.file does not appear in our UI folder after finishing the job execution. To retrieve our output.file (and all the files specified in OutputSandbox), we must type: i2g-job-get-output - dir. After that, we will have a new folder with the name unique_string in a location indicated by the previous command. If we want this folder in a specific location, we can indicate this by means of changing the --dir attribute, like: i2g-job-get-output - dir /your/directory Where /your/directory is the location that you want the output directory to be placed. As with the job status command you can also use the i attribute to specify a file where the job identifier is stored, i.e.: i2g-job-get-output - dir. i job.id 2.5. How do I cancel a job? Sometimes you may need to cancel a Grid job, either one that has just been submitted or one that is already running. This can be easily done using the following command: i2g-job-cancel or if you have stored the job identifier in a file: i2g-job-cancel i job.id 6/9

7 Companion 3.Advanced Capabilities 3.1.Compiling a job for the Grid There will be a separate companion guide on compilation for the grid. Please see that document or contact user support if you want help on compilation I would like to send a large input with my job This is a very common scenario. In this case our files do not have to be transferred from the User Interface to the Worker Nodes. Instead of that, we will have our files in the Storage Element (SE), so our job will access to these files by using the appropriate commands in a shell script which will be executed in the Worker Node (this shell script is our executable). The first thing we have to do is to store our files in the SE. For that, we use the command from the UI: lcg-cr --vo euforia l lfn:/remote_file_route file:///local_file Where local_file is the name and path of the file you wish to copy from the UI. We now have access to the remote file using the remote_file_route (the name remote_file_route can be replaced with anything you want). The Storage Element is not designed to read/write files, it is designed to write files once, and have those files read many times. The command to copy a file from the Storage Element to the local site (the WN) is: lcg-cp -v --vo euforia lfn:/remote_file_route file:///local_file So, let s imagine we need to have access to a file called my_data_file.dat. First of all we have to copy this file to the SE, using the following command: lcg-cr vo euforia l lfn:/grid/euforia/my_name/my_data_file_remote.dat file:///my_data_file.dat With this, we are copying the local file to the SE and the route to the remote file is /grid/euforia/my_name/my_data_file_remote.dat. The convention is to use /grid/euforia/ for the beginning of the remote file location, although you can have any remote file route you wish (i.e. lfn:/myfile). To access this file from the WN, we need to include in the script which is executed the command: lcg-cp -v --vo euforia lfn:/grid/euforia/my_name/my_data_file_remote.dat file:///my_data_file_wn.dat And after that, the script will launch the program which uses the file my_data_file_wn.dat. The JDL for this job could be like: Type = Job ; JobType = Normal ; 7/9

8 Companion Executable = /bin/sh ; Arguments = test_script.sh ; StdOutput = standard.out ; StdError = error.err ; InputSandbox = { test_script.sh, my_executable }; OutputSandbox = { output.file, standard.out, error.err }; And test_script.sh could be: lcg-cp -v --vo euforia lfn:/grid/euforia/my_name/my_data_file_remote.dat file:///my_data_file_wn.dat chmod 777 my_executable./my_executable my_data_file_wn.dat The program my_executable requires the file my_data_file_wn.dat and will produce a file name output.file Parallel jobs There is be a separate companion guide for compiling and running parallel jobs on the EUFORIOA grid. Please see that document or contact user support if you want help on compilation Migrating Desktop Migrating Desktop provides users with a friendly environment for job submission and data handling in grid infrastructures. Contact us if you want more information on Migrating Desktop, as we intend to produce a companion guide on Migrating Desktop shortly Workflows Using Kepler, EUFORIA will allow managing workflows, so the output of some applications can be used as input data for other applications. This feature is currently being implemented, and will be the subject of another companion guide. 4.Conclusions This document has outlined the basic requirements and procedures for running jobs on the EUFORIA grid infrastructure. Whilst the commands can be complicated, and the initial setup is not always straight forward, the information in this document should allow anyone to run grid jobs. If you want more information, or have problems running in the EUFORIA infrastructure, please contact the support team at support@euforia-project.eu. We 8/9

9 Companion also run training courses on a wide range of topics; see the EUFORIA website ( for more details. 9/9