This lesson is in the early stages of development (Alpha version)

Scheduler Fundamentals

Overview

Teaching: 45 min
Exercises: 30 min
Questions
  • What is a scheduler and why does a cluster need one?

  • How do I launch a program to run on a compute node in the cluster?

  • How do I capture the output of a program that is run on a node in the cluster?

Objectives
  • Submit a simple script to the cluster.

  • Monitor the execution of jobs using command line tools.

  • Inspect the output and error files of your jobs.

  • Find the right place to put large datasets on the cluster.

Job Scheduler

An HPC system might have thousands of nodes and thousands of users. How do we decide who gets what and when? How do we ensure that a task is run with the resources it needs? This job is handled by a special piece of software called the scheduler. On an HPC system, the scheduler manages which jobs run where and when.

The following illustration compares these tasks of a job scheduler to a waiter in a restaurant. If you can relate to an instance where you had to wait for a while in a queue to get in to a popular restaurant, then you may now understand why sometimes your job do not start instantly as in your laptop.

/hpc-intro/Compare%20a%20job%20scheduler%20to%20a%20waiter%20in%20a%20restaurant

The scheduler used in this lesson is Slurm. Although Slurm is not used everywhere, running jobs is quite similar regardless of what software is being used. The exact syntax might change, but the concepts remain the same.

Running a Batch Job

The most basic use of the scheduler is to run a command non-interactively. Any command (or series of commands) that you want to run on the cluster is called a job, and the process of using a scheduler to run the job is called batch job submission.

In this case, the job we want to run is a shell script – essentially a text file containing a list of UNIX commands to be executed in a sequential manner. Our shell script will have three parts:

[netid@dev-amd20 ~]$ nano example-job.sh
#!/usr/bin/env bash

echo -n "This script is running on "
hostname

Creating Our Test Job

Run the script. Does it execute on the cluster or just our login node?

Solution

[netid@dev-amd20 ~]$ bash example-job.sh
This script is running on dev-amd20

This script ran on the login node, but we want to take advantage of the compute nodes: we need the scheduler to queue up example-job.sh to run on a compute node.

To submit this task to the scheduler, we use the sbatch command. This creates a job which will run the script when dispatched to a compute node which the queuing system has identified as being available to perform the work.

[netid@dev-amd20 ~]$ sbatch example-job.sh
Submitted batch job 28859234

And that’s all we need to do to submit a job. Our work is done – now the scheduler takes over and tries to run the job for us. While the job is waiting to run, it goes into a list of jobs called the queue. To check on our job’s status, we check the queue using the command squeue -u netid.

[netid@dev-amd20 ~]$ squeue -u netid
   JOBID PARTITION      NAME   USER ST       TIME  NODES NODELIST(REASON)
28859234 general-s  example-  netid R       0:05      1 lac-114

We can see all the details of our job, most importantly that it is in the R or RUNNING state. Sometimes our jobs might need to wait in a queue (PENDING) or have an error (E).

Where’s the Output?

On the login node, this script printed output to the terminal – but now, when squeue shows the job has finished, nothing was printed to the terminal.

Cluster job output is typically redirected to a file in the directory you launched it from. Use ls to find and cat to read the file.

Customising a Job

The job we just ran used all of the scheduler’s default options. In a real-world scenario, that’s probably not what we want. The default options represent a reasonable minimum. Chances are, we will need more cores, more memory, more time, among other special considerations. To get access to these resources we must customize our job script.

Comments in UNIX shell scripts (denoted by #) are typically ignored, but there are exceptions. For instance the special #! comment at the beginning of scripts specifies what program should be used to run it (you’ll typically see #!/usr/bin/env bash). Schedulers like Slurm also have a special comment used to denote special scheduler-specific options. Though these comments differ from scheduler to scheduler, Slurm’s special comment is #SBATCH. Anything following the #SBATCH comment is interpreted as an instruction to the scheduler.

Let’s illustrate this by example. By default, a job’s name is the name of the script, but the -J option can be used to change the name of a job. Add an option to the script:

[netid@dev-amd20 ~]$ cat example-job.sh
#!/usr/bin/env bash
#SBATCH -J hello-world

echo -n "This script is running on "
hostname

Submit the job and monitor its status:

[netid@dev-amd20 ~]$ sbatch example-job.sh
[netid@dev-amd20 ~]$ squeue -u netid
   JOBID PARTITION      NAME   USER ST       TIME  NODES NODELIST(REASON)
28859235 general-s  hello-wo  netid R       0:05      1 lac-114

Fantastic, we’ve successfully changed the name of our job!

Resource Requests

What about more important changes, such as the number of cores and memory for our jobs? One thing that is absolutely critical when working on an HPC system is specifying the resources required to run a job. This allows the scheduler to find the right time and place to schedule our job. If you do not specify requirements (such as the amount of time you need), you will likely be stuck with your site’s default resources, which is probably not what you want.

The following are several key resource requests:

Note that just requesting these resources does not make your job run faster, nor does it necessarily mean that you will consume all of these resources. It only means that these are made available to you. Your job may end up using less memory, or less time, or fewer nodes than you have requested, and it will still run.

It’s best if your requests accurately reflect your job’s requirements. We’ll talk more about how to make sure that you’re using resources effectively in a later episode of this lesson.

Submitting Resource Requests

Modify our hostname script so that it runs for a minute, then submit a job for it on the cluster.

Solution

[netid@dev-amd20 ~]$ cat example-job.sh
#!/usr/bin/env bash
#SBATCH -t 00:01 # timeout in HH:MM

echo -n "This script is running on "
sleep 20 # time in seconds
hostname
[netid@dev-amd20 ~]$ sbatch example-job.sh

Why are the Slurm runtime and sleep time not identical?

Job environment variables

When Slurm runs a job, it sets a number of environment variables for the job. One of these will let us check what directory our job script was submitted from. The SLURM_SUBMIT_DIR variable is set to the directory from which our job was submitted. Using the SLURM_SUBMIT_DIR variable, modify your job so that it prints out the location from which the job was submitted.

Solution

[netid@dev-amd20 ~]$ nano example-job.sh
[netid@dev-amd20 ~]$ cat example-job.sh
#!/usr/bin/env bash
#SBATCH -t 00:00:30

echo -n "This script is running on "
hostname

echo "This job was launched in the following directory:"
echo ${SLURM_SUBMIT_DIR}

Resource requests are typically binding. If you exceed them, your job will be killed. Let’s use wall time as an example. We will request 1 minute of wall time, and attempt to run a job for two minutes.

[netid@dev-amd20 ~]$ cat example-job.sh
#!/usr/bin/env bash
#SBATCH -J long_job
#SBATCH -t 00:01 # timeout in HH:MM

echo "This script is running on ... "
sleep 240 # time in seconds
hostname

Submit the job and wait for it to finish. Once it is has finished, check the log file.

[netid@dev-amd20 ~]$ sbatch example-job.sh
[netid@dev-amd20 ~]$ squeue -u netid
[netid@dev-amd20 ~]$ cat slurm-28923938.out
This script is running on ...
slurmstepd: error: *** JOB 28923938 ON amr-252 CANCELLED AT 2021-02-19T13:55:57
DUE TO TIME LIMIT ***

Our job was killed for exceeding the amount of resources it requested. Although this appears harsh, this is actually a feature. Strict adherence to resource requests allows the scheduler to find the best possible place for your jobs. Even more importantly, it ensures that another user cannot use more resources than they’ve been given. If another user messes up and accidentally attempts to use all of the cores or memory on a node, Slurm will either restrain their job to the requested resources or kill the job outright. Other jobs on the node will be unaffected. This means that one user cannot mess up the experience of others, the only jobs affected by a mistake in scheduling will be their own.

Tips for requesting resources

Users often wonder how to most efficiently request resources to spend less time queueing. Here are some tips:

  • Keep --time under four hours: This will allow your jobs to have access to the most nodes. This is because of buy-in nodes. Buy-in nodes are purchased by research groups, and when a group member submits a job, they are guaranteed access to this node within four hours (though their jobs could start sooner if there’s room on their buy-in node or somewhere else). By keeping your job to less than four hours, you are able to run on the buy-in nodes without blocking a member of that buy-in group.

  • Keep --mem less than 256GB and the total number of CPUs less than 40: This again ensures access to the widest range of nodes. Nodes that can support larger memory and numbers of CPUs are separated into a different partition that can have a larger backlog.

  • Check your efficiency after running: Use the seff -j <job_id> command to see how much of the resources requested were actually used. This allows you to tweak your submissions for future scripts or estimate usage in different conditions.

Cancelling a Job

Sometimes we’ll make a mistake and need to cancel a job. This can be done with the scancel command. Let’s submit a job and then cancel it using its job number (remember to change the walltime so that it runs long enough for you to cancel it before it is killed!).

[netid@dev-amd20 ~]$ sbatch example-job.sh
[netid@dev-amd20 ~]$ squeue -u netid
Submitted batch job 28925831

   JOBID PARTITION     NAME  USER ST       TIME  NODES NODELIST(REASON)
28925831 general-s long_job netid  R       0:03      1 amr-252

Now cancel the job with its job number (printed in your terminal). A clean return of your command prompt indicates that the request to cancel the job was successful.

[netid@dev-amd20 ~]$ scancel 38759
# It might take a minute for the job to disappear from the queue...
[netid@dev-amd20 ~]$ squeue -u netid
JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)

Cancelling multiple jobs

We can also cancel all of our jobs at once using the -u option. This will delete all jobs for a specific user (in this case, yourself). Note that you can only delete your own jobs.

Try submitting multiple jobs and then cancelling them all.

Solution

First, submit a trio of jobs:

[netid@dev-amd20 ~]$ sbatch example-job.sh
[netid@dev-amd20 ~]$ sbatch example-job.sh
[netid@dev-amd20 ~]$ sbatch example-job.sh

Then, cancel them all:

[netid@dev-amd20 ~]$ scancel -u netid

Other Types of Jobs

Up to this point, we’ve focused on running jobs in batch mode. Slurm also provides the ability to start an interactive session.

There are very frequently tasks that need to be done interactively. Creating an entire job script might be overkill, but the amount of resources required is too much for a login node to handle. A good example of this might be building a genome index for alignment with a tool like HISAT2. Fortunately, we can run these types of tasks as a one-off with salloc.

salloc runs a single command on the cluster and then exits. Let’s demonstrate this by running the hostname command with salloc. (We can cancel an salloc job with Ctrl-c.)

[netid@dev-amd20 ~]$ salloc hostname
amr-252

salloc accepts all of the same options as sbatch. However, instead of specifying these in a script, these options are specified on the command-line when starting a job. To submit a job that uses 2 CPUs for instance, we could use the following command:

[netid@dev-amd20 ~]$ salloc -n 2 echo "This job will use 2 CPUs."
This job will use 2 CPUs.
This job will use 2 CPUs.

Typically, the resulting shell environment will be the same as that for sbatch.

Interactive jobs

Sometimes, you will need a lot of resources for interactive use. Perhaps it’s our first time running an analysis or we are attempting to debug something that went wrong with a previous job. Fortunately, Slurm makes it easy to start an interactive job with salloc:

[netid@dev-amd20 ~]$ salloc

You should be presented with a bash prompt. Note that the prompt will likely change to reflect your new location, in this case the compute node we are logged on. You can also verify this with hostname.

salloc can be passed all of the same options that you use to create a job script, but will use the default options (for better or for worse). However, to make life easier, provides an alias called interact with reasonable default arguments:

[netid@dev-amd20 ~]$ interact

To see its arguments use the help flag:

[netid@dev-amd20 ~]$ interact -h

When you are done with an interactive job, type exit to quit your session.

Creating remote graphics

To see graphical output inside your jobs, we recommend that you use OnDemand’s Interactive Desktop application. Choose it from the list of Interactive Applications, fill in the same information you use in a Slurm job script, and press the “Launch” button. A job to create this desktop will be automatically submitted for you, which you can then access by clicking the “Launch “ button.

You will be taken to a more tradtional graphical user interface. If you would like to run a command from a terminal, go to the Applications menu, and under System Tools, select Terminal.

Key Points

  • The scheduler handles how compute resources are shared between users.

  • A job is just a shell script.

  • Request slightly more resources than you will need.