This course is a continuation An Introduction to Research Computing at York. If you are new to Linux command line we recommend you go through the steps of An Introduction to Research Computing at York before moving to this.
Viking Account Creation
Before you can access Viking you will to create a Viking account. The process can take a couple of days please complete the following steps
What is the Viking cluster and why should I use it?
If you are finding that your code is still taking a long time to finish or you wish to scale your work, the Viking cluster may be what you need.
Viking is a large Linux compute cluster aimed at users who require a platform for development and the execution of small or large compute jobs. Viking is a multidisciplinary facility, supporting a broad spectrum of research needs, free at the point of use to all University of York researchers. Viking is as much a facility for learning and exploring possibilities as it is a facility for running well-established high-performance computing workloads. In this light, we encourage users from all Faculties, backgrounds and levels of ability to consider Viking when thinking about how computing might support their research.
What is a cluster?
A cluster consists of many (hundreds or thousands) rack mounted computers called nodes. It would be similar to having hundreds of desktop computers sitting in the same room and able to talk to each other. Clusters are often accessed via login nodes, which can send jobs to the other nodes in the cluster. Your commands will not be run immediately, but will be sent to a queue, and run when there is space on the cluster.
The Viking cluster is Linux based and can be accessed in a similar manner to the research servers, but instead of accessing, say, research0.york.ac.uk, you would access viking.york.ac.uk.
Login into Viking
The process of logging into Viking is similar to the research servers as described in An Introduction to Research Computing at York. Viking has a Linux Operating system therefore how you access Viking will depend on what your operating system is on your local machine.
Before You Login
If you have not changed your IT Services password since August 2013 then you must do so before you will be able to login. All user password changes are manage via the My IT Account web page. Click on the Password Management (IDM) link in the Manage Your Password field to change your password. You may be given the option to 'synchronise' your password; please use this option if you do not want to change your password. The password change (or synchronisation) may take a few minutes before it is visible to the servers.
Accessing Viking off campus
To access the Viking off campus you can either use the Virtual Private Network - VPN or the SSH gateway service (registration required). The instructions below should work if you log on through the VPN; the SSH service works slightly differently.
Access from a Windows desktop
Command-line access using PuTTY
PuTTY is available on all IT Services Managed Windows systems. It is pre-installed on Classroom PCs; on Office PCs you can install it from Run Advertised Programs / Software Center. It appears under "Internet Tools" on the start menu.
On unmanaged PCs you can download the installer from the PuTTY Website.
Configuring PuTTY to connect to Viking
Open PuTTY and configure it to connect to Viking:
- Add the name "viking.york.ac.uk" to the 'Host Name' field
- Check the 'Connection Type' to SSH
- Type the name "Viking" in 'Saved Sessions'
- Click 'Save'
- Expand the 'SSH' tab from the 'Category' list
- Choose 'X11' from 'SSH' list
- Check 'Enable X11 Forwarding'
Connecting to Viking
- Start PuTTY
- Select 'Viking' from the 'Saved Sessions'
- Click 'Open'
A terminal window should appear. Log in with your university username and password. The first time you connect you will get a security alert showing the fingerprint of the server, labeled as 'ssh-rsa' or 'ssh-ed25519'.
If you are successful this is what you will see:
Whilst it is possible to configure X11 forwarding through PuTTY, X11 forwarding will only work on the Viking login nodes, which means that you won't be able to run graphical applications e.g. MATLAB on the Viking compute nodes using X11 forwarding. Details about virtual desktop sessions on Viking are provided in the Virtual Desktop section of this document.
See /wiki/spaces/RCS/pages/39158979 for more information
Navigating Viking
When you log in, you will be directed to one of several login nodes. These allow Linux command line access to the system, which is necessary for the editing programs, compiling and running the code. Usage of the login nodes is shared amongst all who are logged in. These systems should not be used for running your code, other than for development and very short test runs.
Access to the job/batch submission system is through the login nodes. When a submitted job executes, processors on the compute nodes are exclusively made available for the purposes of running the job.
For this exercise lets look at Viking and what is available and setup an area to run our jobs on Viking.
Loading software
We have an entire suite of software available on Viking. We use Easybuild to install the software and a module system to help you navigate what is available.
To view all available software run
[abc123@login1(viking) ~]$ module avail
If you want to see the versions of a particular software run:
[abc123@login1(viking) ~]$ module avail Kraken2
The module spider string command allows you to search for modules matching the string.
[abc123@login1(viking) ~]$ module spider Kraken2
To load a module type module load <module name>. You can append a version number to load a specific instance of a package. Note the <tab> key can be used to complete the command.
[abc123@login1(viking) ~]$ module load lang/Bison <tab> <tab> lang/Bison Bison/3.0.4-GCCcore-8.1.0 lang/Bison/3.0.4 [abc123@login1(viking) ~]$ module load lang/Bison/3.0.4-GCCcore-8.1.0
To list currently loaded modules type module list
[abc123@login1(viking) ~]$ module list
Run module purge to unload all loaded modules.
[abc123@login1(viking) ~]$ module purge
To unload a specific module use
[abc123@login1(viking) ~]$ module unload
If you need to have a program installed on Viking please email itsupport@york.ac.uk with the details.
See /wiki/spaces/RCS/pages/39159178 for more information.
Running your workloads on Viking
Viking uses a queuing system called Slurm to ensure that your jobs are fairly scheduled to run on Viking.
What is Slurm and what is a scheduler?
Slurm is a job scheduling system for small and large clusters. As a cluster workload manager, Slurm has three key functions.
- Lets a user request a resources on a compute node to run their workloads
- Provides a framework (commands) to start, cancel, and monitor a job
- Keeps track of all jobs to ensure everyone can efficiently use all computing resources without stepping on each others toes.
When a user submits a job Slurm will decide when to allow the job to run on a compute node. This is very important for shared machines such as the Viking cluster so that the resources are shared as fairly between users so one persons jobs does not dominate.
Resource allocation
In order to interact with the job/batch system (SLURM), the user must first give some indication of the resources they require. At a minimum these include:
- how long does the job need to run for
- on how many processors to run the job
The default resource allocation for jobs can be found /wiki/spaces/RCS/pages/39159441.
Armed with this information, the scheduler is able to dispatch the jobs at some point in the future when the resources become available. A fair-share policy is in operation to guide the scheduler towards allocating resources fairly between users.
Slurm commands
Before submitting a job to Viking it is useful to be introduced to useful Slurm commands.
Slurm Command Summary
The following are common commands that can be used on Viking. We will be using some of these commands in the examples going forward.
| Command | Description |
|---|---|
| squeue | reports the state of jobs (it has a variety of filtering, sorting, and formatting options), by default, reports the running jobs in priority order followed by the pending jobs in priority order |
| srun | used to submit a job for execution in real time |
| salloc | allocate resources for a job in real time (typically used to allocate resources and spawn a shell, in which the srun command is used to launch parallel tasks) |
| sbatch | submit a job script for later execution (the script typically contains one or more srun commands to launch parallel tasks) |
| sattach | attach standard input, output, and error to a currently running job , or job step |
| scancel | cancel a pending or running job |
| sinfo | reports the state of partitions and nodes managed by Slurm (it has a variety of filtering, sorting, and formatting options) |
| sacct | report job accounting information about active or completed jobs |
Running Slurm commands on Viking
Login to Viking. Run the following command. What do you see?
[abc123@login1(viking) ~]$ squeue
You should see a list of jobs. Each column describes the status of each job
| Column | Description |
|---|---|
| JOBID | A number used to uniquely identify your job within SLURM |
| PARTITION | The partition the job has been submitted to |
| NAME | The job's name |
| USER | The username of the job owner |
| ST | Current job status: R (running), PD (pending - queued and waiting) |
| TIME | The time the job has been running |
| NODES | The number of nodes used by the job |
| NODELIST (REASON) | The nodes used by the job or reason the job is not running |
When you start to run your jobs
[abc123@login1(viking) ~]$ squeue -u abc123
or
[abc123@login1(viking) ~]$ squeue -j JOBID
Will provide information on the jobs you have queued or are running.
Submitting jobs to the partitions on Viking.
There are two ways to run your programs on the cluster
Batch Jobs
These are non-interactive sessions where a number of tasks are batched together into a job script, which is then scheduled and executed by Slurm when resources are available.
- you write a job script containing the commands you want to execute on the cluster
- you request an allocation of resources (nodes, cpus, memory)
- the system grants you one, or more, compute nodes to execute your commands
- your job script is automatically run
- your script terminates and the system releases the resources
Interactive Sessions
These are similar to a normal remote login session, and are ideal for debugging and development, or for running interactive programs. The length of these sessions is limited compared to batch jobs however, so once your development is done, you should pack it up into a batch job and run it detached.
- you request an allocation of resources (cpus, memory)
- the system grants you a whole, or part, node to execute your commands
- you are logged into the node
- you run your commands interactively
- you exit and the system automatically releases the resources
Job scripts
Copying your data to and from Viking
You may have data stored elsewhere that you wish to copy to Viking. There are different ways to do this
There are different ways to copy your data dependent on which operating system you use on your local machine.
Copying Files To/From a Windows Desktop
WinSCP is an open source free SFTP client, SCP client, FTPS client and FTP client for Windows. Its main function is file transfer between a local and a remote computer. WinSCP is available on IT Services supported desktops or can be downloaded from http://winscp.net/eng/index.php.
Run WinSCP from the Start menu or double clicking on the icon on the desktop;
A login window will appear. Fill in the hostname and your username:
Running WinSCP
You can click the "Save" button to save the session details for future use:
Return to the login window and click the "Login" button. Some hosts may present you with an information window:
You will then be prompted for your password:
The file manager window will be displayed:
The drag-and-drop interface is a similar to Windows file manager and its use should be intuitive.
Help and support
In the first instance check our wiki pages or email itsupport@york.ac.uk where one of our team will be in touch.