AliEn Workload Management System (WMS)

Users describe their jobs using the Job Description Language (JDL) which is based on Condor ClassAd language [116]. In the JDL specification of the job the only mandatory parameter is the name of the executable that has to be run (AliEn Job Manager central service will fill the other necessary fields when the job is submitted to the system). Optionally the user may also specify in the JDL the arguments which has to be passed to the executable, requirements that the worker nodes has to fulfil (e.g. available disk space), the input data file names which the job needs, the names of the output files the job is going to produce, the software application packages which the job

48 needs as well the name of the validation script which must be used to validate the output of the job.

There are two models of distributing the jobs on the Grid. In the first model (called ‗push‘) there is a central service which queries site services from time to time and collects the information about the sites (e.g. the number of free worker nodes available or installed application packages list). This information is then used to choose the suitable site for scheduling a given waiting job. Keeping the up to date status of the whole Grid is not a trivial operation, because there are thousands of elements the status of which can change very often, and thus there is no guarantee that the information which is used to take the job scheduling decision will always be accurate.

Site A Site B Site C

Central services

Sites’ info

Site information

Jobs

Figure 2.7. ‗Push‘ Grid job submission model

In the ‗pool‘ model there is no need in the service which keeps track of all Grid resources. Instead the sites which have free resources for running jobs periodically send their information (e.g. the number of free worker nodes available or installed application packages list) to the central resource brokering service, which checks whether there is a match between the requirements of the jobs waiting in the task queue and the resources

49 provided by the site which is asking for a job. If the match occurs then the service immediately schedules the matched job for the execution on the site, otherwise the brokering service reports to the site that there is no match and after waiting some time the site repeats the request.

Site A Site B Site C

Central services

Site information Jobs

Figure 2.8. ‗Pull‘ Grid job submission model

AliEn uses the ‗pool‘ approach. Every institution which provides resources to the AliEn Grid runs a service called Computing Element (CE). The CE serves as an interface between the local resources available on the site and the central services (as already mentioned in Section 2.1 there are cases when the CE is used as an interface to some other Grid infrastructure). Whenever there is a free resource for running a job on the site the CE sends the description of its capabilities to the AliEn Job Broker central service. This description is also based on the JDL and contains the name of the CE, the list of available software application packages, the name of the Storage Element (SE) closest to that CE, etc. The Job Broker performs the matching of the CE resources with the jobs waiting in the Task Queue and if there is a match it instructs CE to submit to the local batch system the script which

50 after arriving to the WN will start the AliEn service called Job Agent (JA). However, it is important to mention that at this point the job is not yet assigned to the matched CE, and if another CE sends a request which matches the same job the Job Broker will instruct that CE to start the JA as well.

When the JA starts on the worker node it executes a set of sanity checks and if the checks are successful it sends job request to the Job Broker. The request sent by the JA is more detailed than the one which is sent by CE. It contains among other things the available disk space, memory, information about the platform and the OS of the WN. If the description satisfies the requirements of the job waiting in the Task Queue the Job Broker assigns the job to the JA. The JA analyzes the JDL of the job, downloads the necessary input files, prepares the environment for execution and executes the job. Once the user job terminates the JA initiates the transfer of the output files to the SE and registers the files in the AliEn file catalogue. After that the JA tries to get another job for execution and if there are no more jobs to execute the JA exits.

The use of JAs provides a multiple benefits. First of all JAs eliminate the possibility of job failure due to problems with the local batch system or problems with the WNs. They also reduce the time between the submission and execution of a user job since sever sites can submit JA for the same job, which at the end will be assigned to the fastest JA (the one which first manages to request the job from the Job Broker). Finally the use of JAs reduces the load on the local batch system, since a single JA can execute multiple jobs.

At the same time JAs significantly increase the load on the Job Broker, since in the architecture without JAs only the CE communicates with the Job Broker and multiple jobs can be assigned to the same CE within the same response to the request. This is not possible with the JAs since they act asynchronously and independently from each other, and each of them has to communicate with the Job Broker.

51 However one has to mention that additional functionality provided by the JAs outweighs the drawbacks and in the current operation model the Job Broker was capable of serving more than 20000 JAs running in parallel.