The MSLC Compute Cluster is a mix of GPU and non-GPU compute nodes and high performance storage funded by the Massachusetts Life Sciences Center to support research at the Athinoula A. Martinos Center for Biomedical Imaging and the CTRU/IBC. The cluster provides 1200 CPU cores, 16 RTX6000 GPUs, 44 RTX8000 GPUs and 32 A100 GPUs along with 1 petabyte of flash based high performance storage.
Individual research labs and/or projects need their own “slurm group account” to assign jobs to when submitting. A lab can have one slurm group account for the whole lab or multiple accounts for different grants/projects (very much like scanner projects for users of the Martinos Center MRI bays).
The lab PI should email email@example.com with the preferred account name (8 characters or less – most common to use your labs most general UNIX group name if you have one) and background about your research project(s) and the list of users who will be submitting jobs for this project. Each user needs a “full login” Martinos Linux user account if they do not already have one. Full login accounts have a fee of $16.67/month.
Once your account/project is approved, you can ssh to the MLSC cluster master node:
ssh -l username mlsc.nmr.mgh.harvard.edu
The -l username can be omitted if you are connecting from another Martinos Center linux box. After you login, verify that you are in the slurm system by running
sshare -U -u $USER
and verifying your name is listed under at least one slurm account.
Please cite the Massachusetts Life Sciences Center on your posters and publications for any data analyzed on this cluster.
- SLURM group account – group of users working on same projects
- Possible for Lab to have multiple group accounts if need demonstrated
- Fairshare priority system is currently implemented by these groups, not by users
- job – submission of analysis that defines resource allocations needed
- partition – a group of nodes with a certain set of resource limits and defaults
- equivalent of queues in PBS/torque (In SLURM, queue is just the job queue)
- node – one of the physical servers (A100 DGX, EXXACT RTX, Dell R440)
- resource – memory, time, GPU, cores, etc required by job
- task – division of a job with multiple processes (ex: MPI). Typically just one per job.
- Separate programs/processes you run at the same time in the same job
- cpu/core – physical CPUs are called sockets in SLURM. Hyperthreading is off.
- number of cores usable by multi-threading capable programs like MATLAB
The equipment bought on the MLSC grant consists of:
- four NVIDIA DGX A100 servers with eight NVIDIA A100 GPUs, two AMD EPYC 7742 64 core CPUs, 1TB of memory, and ten 100Gbe network connections
- five EXXACT servers with ten NVIDIA RTX8000 GPUs, two Intel Xeon Gold 6226R 16 core CPUs, 1.5TB of memory, and one 100Gbe network connection
- one EXXACT servers with four NVIDIA RTX8000 GPUS, two Intel Xeon Gold 6226R 16 core CPUs and 1.5TB of memory and one 100Gbe network connection
- two EXXACT servers with eight NVIDIA RTX6000 GPUS, two Intel Xeon Gold 5218 16 core CPUs, 1.5TB of memory, and one 100Gbe network connection
- thirty-two DELL R440 servers with two Intel Xeon Silver 4214R 12 core CPUs, 384GB of memory, and one 25Gbe network connection
- a 1.35PB VAST all FLASH storage appliance with eight 100Gbe network connections
- four 100Gbe switches with over 100 total ports uplinked to MGB corporate network via redundant 100Gbe uplinks
- three full sized 42U racks with necessary PDUs for power, cables and floating KVM
The DGX systems are running Ubuntu 18.04 while all other systems are running CentOS8
For purposes of submitting your jobs on the SLURM cluster you should use this table to identify the partition to use and to plan how to ask for CPU, GPU, and memory resources.
|Dell R440 Server||30||24||384GB||none||basic||1.5TB|
|RTX 6000 GPU Server||2||32||1.5TB||8||rtx6000||7.0TB|
|RTX 8000 GPU Server||5||32||1.5TB||4 have 10, 1 has 4||rtx8000||7.0TB|
|NVIDIA DGX A100||4||64||1.0TB||8||dgx-a100||14TB|
What are called queues in the launchpad Torque/PBS system are called partitions in SLURM. In SLURM a queue refers to only the job submission queue.
The default time giving a job is just 4 hours unless you ask for more — to a max of 7 days. The –time format above is days-hours:minutes:seconds
The default memory for a job if not specified is just 10MB per core requested.
A “node” is the physical server box itself. If a box has 10 CPUs, and you ask for 2 nodes with 5 CPUs per node, it is possible you get all 10 CPUs of one box or 5 CPUs on one box and 5 CPUs on another. CPUs in SLURM are just cores as we have disabled HyperThreading to follow HPC best practice. Therefore there is only one thread per core.
Submitting batch jobs in SLURM
The generic command to submit in slurm is ‘sbatch’. However, there is a custom job submission wrapper script called jobsubmit you can use to make simple submissions. Run
for instructions on how to use it. NOTE: options for jobsubmit are not the same as for sbatch/srun.
Specifying memory and time limits are mandatory in order to force users think about their job resources more carefully. For this reason note that on the RTX GPU boxes there are on average ~3 CPU cores and 128GB RAM per GPU. On the Dell nonGPU nodes there are about 15GB RAM per CPU core.
It is also mandatory to specify the partition (aka queue) and slurm account (project/lab). You do not need to put the command you submit in quotes. Just make sure the command and all its args come after all the jobsubmit options. Note also by default no emails are sent unless the -M option is given. Example:
jobsubmit -p rtx8000 -A sysadm -m 128G -t 1-12:00:00 -c 3 -G 1 \
-M END,FAIL python3 my_gpu_job.py -d /cluster/data/subject –epochs 100
This jobsubmit script will actually create a sbatch submission script in the directory named /cluster/batch/username with the name sjob_subnumber.
Also your job’s terminal Standard Input and Output will be written to a file in that same directory with name sjob_subnumber.outjobnumber. There are options to split them to two different files. Files older than 15 days are removed from /cluster/batch nightly. So make sure to copy the output elsewhere when the job is done if you need to keep it.
If you choose to use sbatch instead of jobsubmit you must write a script to submit. You can embed submission options in the header script as well as give options on the command line. Example:
=========================testjob.sh========================== #!/bin/bash #SBATCH --account=sysadm #SBATCH --partition=basic #SBATCH --nodes=1 #SBATCH --ntasks-per-node=5 #SBATCH --mem=2G #SBATCH --time=0-01:15:00 cd /autofs/cluster/batch/raines/john-1.9.0-jumbo-1/run/ ./john --test=300 --format=md5crypt =============================================================
sbatch –job-name=john001 –output=john001_%j.out \
NOTE: the options to sbatch (and srun) are not the same as the jobsubmit wrapper. See the man pages for sbatch and srun for details.
You can submit a GPU job to both rtx6000 and rtx8000 partitions by specifying:
and it will take the first available.
To run an interactive job you need to use the ‘srun’ command. You should stick to single node jobs when doing this (e.g. -N 1). An example is this to get 2 RTX8000 GPUs for 1 day 10 hours with 6 CPU cores and 256 RAM.
srun -p rtx8000 -A sysadm -N 1 --ntasks-per-node=1 --gpus=2 --mem=256G \ --time=1-10:00:00 --cpus-per-task=6 --pty /bin/bash
If you want to be able to run X11 apps add ––x11=first to the options.
It is important for users to actually use the shells on the nodes they get this way and not leave them idle overnight. Fairshare weighting applies actually clock time used, not CPU time, so idle time affects your future job priority just as much as time spent using 100% the CPU or GPU.
Each node has a local /scratch directory that should be used for temporary files instead of /tmp. There is also the network directory /vast/scratch shared by all nodes.
Files in both local and VAST scratch directories are removed after 7 days old but we will soon implement a scheme where files are removed after 3 days unless they are in a directory with the same name as a running job on the node (e.g. /scratch/29770).
The TMPDIR environment variable is set to /scratch/$SLURM_JOBID in the default environment for each job. This is automatically created via prolog wrapper before the user part of the jobs starts and will be automatically removed when the job finishes.
Singularity container jobs
The cluster does not support Docker but does support running Docker containers converted to Singularity images. The best performance on the GPUs can almost always be obtained by using the optimized containers directly from NVIDIA. For more information see our Using Singularity on the MLSC Cluster page.
- squeue to see what is queued/running
- sinfo for general cluster state
- sbatch, srun or jobsubmit (as above) to submit
- sshare to see your slurm account fairshare stats
- “scontrol show job=job#” for more details while job is running
- scancel to cancel jobs
- sattach to view stdout/stderr of running jobs
Use the man command to see more help on each command. There are PBS wrappers on qstat, qsub, qdel but have limited options they support and output is often a bit different.
For finished jobs, a good way to see stats is like this:
sacct --starttime 2020-09-08 -o "JobID,Elapsed,CPUTime,MaxRSS,TotalCPU,State"
For more generic details about SLURM read the docs at https://slurm.schedmd.com/
Fairshare priority system
All jobs must be submitted under an account which are based on labs and/or projects. Users cannot use SLURM unless they are assigned to at least one account.
Each SLURM group account gets the same 200 “raw” shares which is basically an arbitrary number big enough to give some granularity. What matters is relative value compared to other groups. But since right now everyone has the same, it is immaterial.
Job priority in the submission queue is based on the group account’s share weighted by a usage factor by the resources used by the group. Each resource (GPU, CPU, memory) has a weight with “better” resources having more weight than slower ones (i.e. a A100 GPU has more weight than a RTX8000 which has more than a RTX6000). The older the usage, the less its weight with a half-life factor of 1 month (a job you ran a month ago will “weight down” your fairshare half as much as an equivalent job you just ran today). The half-life parameter is likely one will change often to tune the system.
The final fairshare factor for a slurm group account is normalized to be between 1.0 (account has run no jobs recently so has highest priority) and 0 (no share left – account will only have jobs run when nodes are free and no accounts with non-zero share have jobs waiting).
One can use the sshare command to monitor the Fairshare system. Below results are obtained for example using the following command on the MLSC login node.
# sshare -o Account,RawShares,RawUsage,FairShare Account RawShares RawUsage FairShare -------------------- ---------- ----------- ---------- root 703742066 0.500000 root 1 0 1.000000 arnoldgp 200 0 1.000000 bandlab 200 0 1.000000 brainbes 200 3432399 0.950533 carplab 200 0 1.000000 fsdev 200 135319956 0.135358 imanlab 200 107 0.999998 lcn 200 334070210 0.007172 lcnrtx 200 136947934 0.132108 lfilab 200 0 1.000000 purdongp 200 3653 0.999946 qtim 200 4190995 0.939941 roffmagp 200 89395433 0.266923 sysadm 200 381374 0.994379 visuo 200 0 1.000000 zolleigp 200 0 1.000000
RawUsage is the groups usage weighting factor with the 28 day halflife factor applied to all jobs that group has run according to the resource weights of each job.
FairShare is the normalized fairshare weight percentage applied to the priority of new jobs submitted for that account.
Use a command like the following to see an accounting of the usage of your group per user.
# sshare --account=lcn -a -o Account,User,RawShares,RawUsage,FairShare Account User RawShares RawUsage FairShare ---------------- ---------- ---------- ----------- ---------- lcn 200 334067236 0.007168 lcn avd12 parent 5983822 0.007168 lcn cmagnain parent 578823 0.007168 lcn fischl parent 171850255 0.007168 lcn iglesias parent 0 0.007168 lcn mu40 parent 155654334 0.007168
A more detailed description of the FairShare system can be found at Harvard FAS slurm cluster.
Volume on the VAST storage system are available with a 10TB limit per lab. This should be used for active projects using the MLSC cluster only staging to and from other storage as needed. The price is the same $26.67/TB/month as our primary Dell storage volumes.
This storage is Ultra High performance only over NFS to the cluster nodes. It will give better performance over NFS than Dell storage to non-cluster Martinos Linux systems. SMB/CIFS access to VAST available by Dell gateway proxy server is available if needed. Each volume gets a weekly mirror backup to Dell storage
Last Updated on March 5, 2021 by Paul Raines