view:34616 Last Update: 2024-11-3
فارسی
Englishكلاستر محاسباتي گروه فيزيك
مشخصات
Cluster pop-os runs single node operating system which is based on Ubuntu 18.01.
The cluster contains a compute node with following specifications:
2* Intel(R) Xeon(R) CPU E5-2699 v4 (processors: 44, cpu cores: 22,cache size:56320 KB)
256GB Memory+ NVIDIA Quadro P5000+NVIDIA - GeForce RTX 3070 Ti 8GB GDDR6XASUS GeForce GTX 1660 Super Overclocke6GB
کامپایلرها و نرم افزار های نصب شده بر روی کلاستر
C++
FORTRAN
Intel compiler (icc)
Parallel programming
--- Openmp
--- MPI
GPU based programs
--- opencl
--- cuda
XMDS
LAMMPS
MATLAB
نصب هر گونه نرم افزار منوط به امکان نصب آن نرم افزار در کلاستر تحت لینوکس و درخواست همکاران گرامی در هنگام دریافت اکانت است
سیستم صف
به منظور استفاده بهینه از کلاستر، سیستم صف مبتنی بر slurm در این کلاستر پیاده شده است.
در این کلاستر کاربران میبایست برنامه (job) خود را از طریق دستورات تعریف شده در slurm به کلاستر ارسال (sbatch or srun ) نمایند. امکان روئیت وضعیت برنامه، تخصیص منابع، ارسال ایمیل وضعیت برنامه و .... تحت slurm فراهم شده است. کاربران پس از دریافت حساب کاربری (user) میتوانند با استفاده از پروتکل ssh به کلاستر با آدرس (172.18.32.12@<user>) متصل شده و job خود را submit نمایند.
Cluster pop-os manages resources using Simple Linux Utility for Resource Management (SLURM). Slurm is a highly scalable cluster management and job scheduling system for large and small Linux clusters.
for more information see: http://slurm.schedmd.com
ليست پارتيشن هاي تعريف شده در كلاستر
کاربران job خود را تحت پارتیشن تعریف شده برای آنها می توانند ارسال نمایند
| دیگر موارد | رم اختصاصی | هسته اختصاصی | زمان اختصاصی | اولویت | محدودیت | Node | پارتیشن |
|---|---|---|---|---|---|---|---|
| 10% | 1 هسته | ۱ ساعت | 1 | ندارد | pop-os | phys-all | |
| 30% | 8 هسته | ۶ روز | 3 | دانشجویان | pop-os | phys-student | |
| 40% | 10هسته | ۶ روز | 2 | اساتید | pop-os | phys-academic | |
| با هماهنگی | 50% | 15 هسته | ۳ ساعت | 4 | دارد | pop-os | phys-large-job |
کاربران می توانند با استفاده از دستور sinfo به اطلاعات وضعیت کلاستر و با دستور scontrol show partition به محدودیتهای اعمال شده روی پارتیشن ها دسترسی یابند.
- قبل از انتخاب پارتیشن؛ از محدودیت های آن پارتیشن و idle بودن وضعیت آن پارتیشن اطمینان حاصل نمایید.
- هر اکانت اجازه ارسال یک job به خوشه را دارد.
- متناسب با ترافیک موجود در کلاستر، ممکن است برخی پارتیشن ها در حالت خاموش قرار گیرند.
- شایان ذکر است که به علت محدودیت های موجود؛ jobهای ارسال شده بر روی پارتیشن phys-large-job ؛چنانچه بیش از ۳ job کد در سیستم در حال اجرا باشد به حالت PENDING خواهد رفت.
حساب کاربری و محدودیت منابع برای کاربران
- متقاضیان دریافت حساب کاربری (اساتید و دانشجویان محترم) بایستی به صورت حضوری مراجعه نموده و فرم درخواست حساب کاربری را تکمیل و تحویل مسول پشتیبانی کلاستر نمایند.
- هر کابر صرفا مجاز به استفاده از حساب کاربری خود می باشد. در صورت مشاهده تخلف، حساب مورد استفاده مسدود خواهد شد.
- برای هر یک از همکاران عزیز، اکانت (account) تعریف شده و حساب کاربری دانشجویان تحت اکانت استاد راهنمای مربوطه خواهد بود.
- حساب کاربری دانشجویان کارشناسی ارشد یک ساله و دانشجویان دکتری 3 ساله می باشد.
- محدودیت استفاده از منابع به هر account متناسب با CPU و زمان استفاده شده مطابق زیر اعمال خواهد شد.
- با اتمام منابع تخصیصی امکان استفاده از کامپیوتر محاسباتی برای کاربران متصل یه اکانت مربوطه صرفا در صورت خالی بودن کلاستر میسر خواهد بود.
میزان cpu*time(minute) همکاران محترم (و دانشجویان مربوطه) در طول یک سال متناسب با حمایت صورت پذیرفته در راه اندازی و ارتقای سامانه می باشد. به عبارتی cputime=100800 معادل استفاده از 7 cpu به مدت 10روز متوالی است: 7*24*10*60 یا معادل 70 روز استفاده مداوم از یک هسته است 1*24*70*60
نحوه ارسال job به کلاستر و دستورات مورد نیاز
The Slurm job scheduler
This guide describes basic job submission and monitoring for Slurm, Slurm job scheduler and its use on the pop-os system.
Jobs on pop-os are run as batch jobs, i.e. in an unattended manner. Typically a user logs in to the pop-os
login nodes (<user>@172.18.32.12), prepares a job (which contains details of the work to carry out and the computer resources needed) and submits it to the job queue. The user can then log out (if she/he wishes) until their job has run, to collect the output data.
Jobs are managed by Slurm, which is in charge of
• allocating the computer resources requested for the job,
• running the job and
• reporting the outcome of the execution back to the user.
Running a job involves, at the minimum, the following steps
• preparing a submission script and
• submitting the job to execution.
Preparing a submission script
چنانچه از دستور sbatch برای ارسال job به کلاستر استفاده شود بایستی فایل batch file (به عنوان نمونه submit.sh) مطابق توضیحات زیر آماده و به کلاستر ارسال گردد.
A submission script is a shell script that describes the processing to carry out (e.g. the application, its input and output, etc.) and requests computer resources (number of cpus, amount of memory, etc.) to use for processing.
Example 1: a job by strudent (user=neda) running a single cpu job
Supposing the test.cpp is a c++ code which uses g++ compiler and requires 1 cpu for 30 minutes.
In this case the job requires a single cpu (this is the smallest unit we allocate on pop-os), So the user can use partition=phys-all with the following requirements:
• the job uses pop-os node,
• the application is a single process,
• the job will run for no more than 1 hours,
• the job is given the arbitrary name e.g :"test1" and
• the user should be emailed when the job starts and stops or aborts.
the following submission script runs the application in a single job
#!/bin/bash
#SBATCH -p phys-all <--------------------------set partition
#SBATCH --time=00:30:00 <--------------------------set wallclocktime (arbitrary)
#SBATCH --error=job.%J.err <--------------------------set output file for error (arbitrary)
#SBATCH --output=job.%J.out <--------------------------set output file (arbitrary)
#SBATCH --job-name="test1" <--------------------------set a name for the job
#SBATCH --mail-type=ALL <--------------------------set the massage status form (arbitrary)
#SBATCH --mail-user=????@znu.ac.ir <--------------------------set the email for job status messaging (arbitrary)
g++ test.cpp -o myfirstcode
./myfirstcode
Example 2: a job by strudent (user=neda) running a multi-cpu job
Supposing the test.cpp is an openmp parallel code in c++ which uses g++ compiler and lapack library and requires 6 cpu for 2 days.
In this case the job requires a multui-cpu, and since the user is student, he/she should use partition=phys-student with the following requirements:
• the job uses pop-os node,
• the application is a multi process,
• the job will run for no more than 72 hours,
• the job is given the arbitrary name e.g :"test2" and
• the user should be emailed when the job starts and stops or aborts.
the following submission script runs the application in a single job
#!/bin/bash
#SBATCH -p phys-student <--------------------------set partition
#SBATCH --ntasks=1 <--------------------------set number of nodes
#SBATCH --cpus-per-task=6 <--------------------------set number of cpupernode
#SBATCH --time=2-00:00:00 <--------------------------set wallclocktime (arbitrary)
#SBATCH --error=job.%J.err <--------------------------set output file for error (arbitrary)
#SBATCH --output=job.%J.out <--------------------------set output file (arbitrary)
#SBATCH --job-name="test2" <--------------------------set a name for the job
#SBATCH --mail-type=ALL <--------------------------set the massage status form (arbitrary)
#SBATCH --mail-user=????@znu.ac.ir <--------------------------set the email for job status messaging (arbitrary)
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK <--------------------------set number of cpu by slurm protocol
g++ -Ofast test.cpp -llapacke -llapack -fopenmp -o mysecondcode
./mysecondcode
In large part, the script above is similar to the one for a single node job except in this example, #SBATCH --cpu-per-task=m is used to reserve m cores per node (here on a single node e.g. --ntasks=1) and to prepare the environment for a openmp parallel run with m processes in pop-os node.
Example 3: a job by strudent (user=neda) running a gpu job
Supposing the test.cu is a cuda code which uses nvcc compiler and requires gpu and 1 cpu.
In this case the job requires a gpu, and since the user is student, he/she should use partition=phys-gpu with the following requirements:
• the job uses pop-os node,
• the application is a multi process,
• the job will run for no more than 24 hours,
• the job is given the arbitrary name e.g :"test2" and
• the user should be emailed when the job starts and stops or aborts.
the following submission script runs the application in a single job
#!/bin/bash
#SBATCH -p phys-gpu <--------------------------set partition
#SBATCH --time=00:03:00 <--------------------------set wallclocktime (arbitrary)
#SBATCH --error=job.%J.err <--------------------------set output file for error (arbitrary)
#SBATCH --output=job.%J.out <--------------------------set output file (arbitrary)
#SBATCH --job-name="test3" <--------------------------set a name for the job
#SBATCH --mail-type=ALL <--------------------------set the massage status form (arbitrary)
#SBATCH --mail-user=????@znu.ac.ir <--------------------------set the email for job status messaging (arbitrary)
nvcc test.cu -o mythird
./mythird
NOTE:
phys-all is the default partition and the one your jobs will go to if you do not specify a partition in your job submission script.
Users can also use phys-large-job partition if their job requires larger resorces (Time, Cpu, Mem). Attention: this partition has a minimum priority, and the job will be PREEMPTED by submited jobs from other partitions (go to pending status).
Setting a wall clock time means you are setting the time limit of the job, which influence the priority of your job. Do not set the wall clock time (i.e. --time=???) if you are sure that the running time is smaller than the wall clock time of the specified partition. A larger wall clock time==smaler priority. It is best to give this up to the maximum time allowed at first to get an idea of how long it runs. After you know that, it is best to give it a more reasonable time limit. Setting a reasonable timelimit will increase your chance of running quickly based on the backfill algorithm used.
If the wall clock time exceeds the wall clock time of the specified partition, the job will be killed automatically.
If the running time exceeds the wall clock time limit of the specified partition or demanded time, the job will exit.
The notification massage (email notification) is actived only for partition=phys-large-job. So you can ignore setting these parts
ارسال job به کلاستر توسط دستور sbatch
Once you have a submission script ready (e.g submit.sh), the job is submitted to the execution queue with the command sbatch script.sh. The queueing system prints a number (the job id) almost immediately and returns control to the linux prompt. At this point the job is in the submission queue. Once you have submitted the job, it will sit in a pending state until the resources have been allocated to your job (the length of time your job is in the pending state is dependent upon a number of factors including how busy the system is and what resources you are requesting). You can monitor the progress of the job using the command squeue (see below).
Once the job starts to run you will see files with names such as job-12.out either in the directory you submitted the job from (default behaviour) or in the directory where the script was instructed explicitly to change to.
مشاهده وضعیت job با دستور squeue
squeue is the main command for monitoring the state of systems, groups of jobs or individual jobs. The command squeue prints the list of current jobs. The list looks something like this:
| NODELIST(REASON) | NODES | TIME | ST | USER | NAME | PARTITION | JOBID |
|---|---|---|---|---|---|---|---|
| pop-os | 1 | 10:07 | R | ghanbari | heat | phys-academic | 2491 |
| pop-os | 1 | 0:22 | R | neda | test1 | phys-all | 2499 |
| pop-os (Resources) | 1 | 15:36 | PD | alireza | test2 | phys-student | 2511 |
The first column gives the job ID, the second the partition (or queue) where the job was submitted, the third the name of the job (specified by the user in the submission script) and the fourth the owner of the job. The fifth is the status of the job (R=running, PD=pending, CA=cancelled, CF=configuring, CG=completing, CD=completed, F=failed). The sixth column gives the elapsed time for each particular
job.
Slurm Job States
Your job will report different states before, during, and after execution. The most common ones are seen below, but this is not an exhaustive list.
| Job was killed, either by the user who submitted it, a system administrator, or by the Cgroups plugin (for using more resources than requested). | CA | CANCELLED |
| Job has ended in a zero exit status, and all processes from the job are no longer running. | CD | COMPLETED |
| This status differs from COMPLETED because some processes may still be running from this job. | CG | COMPLETING |
| Job did not complete successfully, and ended in a non-zero exit status. | F | FAILED |
| The node or nodes that the job was running on had a problem. | N | NODE_FAIL |
| Job is queued, so it is not yet running. Look at the Jobs that never start section for details on why jobs can remain in pending state. | PD | PENDING |
| Job has been allocated resources, and is currently running. | R | RUNNING |
| Job exited because it reached its walltime limit. | TO | TIMEOUT |
نکته: روی تعداد job های ارسالی کاربران به کلاستر محدودیت اعمال شده است. پس از ارسال هر job حتما از دستور squeue وضعیت آن را چک کنید و در صورت قرار داشتن در وضعیتی به جز R از ارسال job جدید خودداری کنید و به دنبال آن باشید که چرا job شما در وضعیت R قرار ندارد. (به آخرین ستون وضعیت job دقت نمایید)
کنسل کردن job ارسال شده به کلاستر
Use the scancel command to delete a job, e.g. scancel 1121 to delete job with ID 1121. A user can delete his/her own jobs at any time, whether the job is pending (waiting in the queue) or running. A user cannot delete the jobs of another user. Normally, there is a (small) delay between the execution of 10 the scancel command and the time when the job is dequeued and killed.
توجه: چنانچه کاربری اقدام به اجرای برنامه به صورت مستقیم بر روی کلاستر نماید، حساب کاربری مربوطه مسدود خواهد شد
کاربران گرامی سعی نمایند تا از نگهداری حجم بالای اطلاعات در کلاستر خودداری نمایند. علاوه بر این پیشنهاد می شود تا به صورت دوره ای نسخه پشتیبانی از داده های خود از روی کلاستر تهیه نمایند.
پشتیبانی کامپیوتر محاسباتی گروه فیزیک دانشگاه زنجان
دکتر مولاداد نیکبخت
ایمیل: hpc_physics[at]znu.ac.ir