Job Classes Introduction

Meanwhile I am working for more than 13 years in the team of engineers that is continuously improving and enhancing Grid Engine. Nevertheless I am often astonished how difficult and long-lasting it can be to design and implement new features. About seven months ago I started with a functional specification document describing a new object type called job class. A month later I was able to start with the implementation. Now, 319 modified files, 21.737 insertions and 5.673 deletions later, I am in the middle of the test phase. Our team created new alpha packages a week ago and test results indicate that we can release job classes with Univa Grid Engine 8.1 soon. It’s the right time to explain job classes in more detail with this and the upcoming blog entries.

Using Job Classes to Prepare Templates for Jobs

When Univa Grid Engine jobs are submitted then various submit parameters have to be specified either as switches which are passed to command line applications or through corresponding selections in the graphical user interface. Some of those switches define the essential characteristics of the job, others describe the execution context that is required so that the job can be executed successfully. Another subset of switches needs to be specified only to give Univa Grid Engine the necessary hints on how to handle a job correctly so that it gets passed through the system quickly without interfering with other jobs.

In small and medium sized clusters with a limited number of different job types this is not problematic. The number of arguments that have to be specified can either be written into default request files, embedded into the job script, put into an option file (passed with -@ of qsub) or they can directly be passed at the command line. Within larger clusters or when many different classes of jobs should run in the cluster then the situation is more complex and it can be challenging for a user to select the right combination of switches with appropriate values. Cluster managers need to be aware of the details of the different job types that should coexist in the cluster so that they can setup suitable policies in line with the operational goals of the site. They need to instruct the users about the details of the cluster setup so that these users are able to specify the required submission requests for each job they submit.

Job classes have been introduced in Univa Grid Engine 8.1 to be able to:

  • specify job templates that can be used to create new jobs.
  • reduce the learning curve for users submitting jobs.
  • avoid errors during the job submission or jobs which may not fit site requirements.
  • ease the cluster management for system administrators.
  • provide more control to the administrator for ensuring jobs are in line with the cluster set-up.
  • define defaults for all jobs that are submitted into a cluster.
  • improve the performance of the scheduler component and thereby the throughput in the cluster.

Examples Motivating the Use of Job Classes

Imagine you have users who often make mistakes specifying memory limits for a specific application called memeater. You want to make it easy for them by specifying meaningful defaults but you also want to give them the freedom to modify the memory limit default according to their needs. Then you could use the following job class configuration (only an excerpt of the full configuration is shown):

   jcname          memeater
   variant_list    default
   owner_list      NONE
   user_list       NONE
   xuser_list      NONE
   CMDNAME         /usr/local/bin/memeater
   l_hard          {~}{~}h_vmem=6G
   ...

Without going into the specifics of the job class syntax, the above job class will use a default of 6 GB for the memory limit of the job. It will, however, be feasible for users to modify this limit. Here are two examples for how users would submit a job based on this job class. The first maintaining the default, the second modifying it to 8 GB (again without going into the details of the syntax being used here):

   > qsub -jc memeater
   > qsub -jc memeater -l h_vmem=8G

Now assume a slightly modified scenario where you want to restrict a certain group of users called novice to only use the preset of 6 GB while another group of users called expert can either use the default or can modify the memory limit. The following job class example would accomplish this. And the trick is that job classes support so called variants as well as user access lists:

   jcname          memeater
   variant_list    default, advanced
   owner_list      NONE
   user_list       novice,expert,[advanced=expert]
   xuser_list      NONE
   CMDNAME         /usr/local/bin/memeater
   l_hard          h_vmem=6G,[{~}advanced={~}h_vmem=6G]
   ...

With this job class configuration, the novice users would only be able to submit their job using the first command example below while expert users could use both examples:

   > qsub -jc memeater
   > qsub -jc memeater.advanced -l h_vmem=8GB

The two use cases for job classes above are only snippets for all the different scenarios to which job classes may be applied and they only provide a glimpse onto the features of job classes. When I have more time then I will describe all attributes forming a job class object, commands that are used to define job classes as well as how these objects are used during job submission to form new jobs.

blog comments powered by Disqus