Category Archives: Uncategorized

Lambda Computational Cluster

 

First of all, you’ll need to receive log in and work permissions on Lambda. If you’re part of a course – your TA in charge will take care of that. If you’ve enrolled on a project which requires the use of the cluster – ask your project supervisor or lab engineer to contact the IT team and ask for usage permissions for you and your partner. The request must include your @campus email addresses, as those are used for authentication.

Note: Lambda is not available from outside the Technion. If you’re working outside the campus, you will need to connect to the Technion’s network via VPN as described here: English | Hebrew

After receiving login permissions, SSH to ‘lambda.cs.technion.ac.il’:
ssh ‑X <username>@lambda.cs.technion.ac.il
If you’re connected via VPN and you receive an Unknown Host error, use:
ssh -X <username>@132.68.39.159

Your username is your @campus.technion.ac.il username and the password is the same one you use to log in to that account.

Table of Contents

 

What is Lambda?

Lambda is a Slurm based computational cluster. It is a group of servers that provide computational resources to the faculty’s undergraduate students.

What is Slurm?

As the name suggests, Slurm Workload Manager is a software that allocates resources for computational jobs based on predefined settings.
Contrary to regular (or local) program execution, programs (jobs) are launched on the Login (or Controller) server and are distributed to one or more of the physical servers (Nodes). SLURM is the software that helps defining and executing these jobs, as well as managing users, permissions and resource allocation. It helps tracking and displaying job details as well.

Hardware

The cluster is comprised of one Controller and several Nodes.
The Controller is a virtual machine named ‘lambda’, to which users log in and from which they launch jobs.
The Nodes are physical machines named lambda1 through 5, on which the jobs run. Although not identical, each Node has two Xeon CPUs, several Nvidia GPUs and a considerable amount of RAM.
SSH connections are only performed to the Controller. Users cannot connect directly to the nodes.

Software

Both controller and nodes run Ubuntu 18.04 server and the latest version of Slurm.
Packages installed on the nodes:

  • Nvidia Drivers v450.66
  • CUDA v10.2.89
  • cuDNN v7.6.5
  • OpenMPI v4.0.4
  • OpenGL and xvfb
  • Python 2.7.17 and 3.6.9

User packages

You would most likely need to install additional packages for your own work.
Creating a virtual environment using Miniconda is supported(example for python3.9 ).

 wget https://repo.anaconda.com/miniconda/Miniconda3-py39_4.12.0-Linux-x86_64.sh
 chmod 755 Miniconda3-py39_4.12.0-Linux-x86_64.sh

pip3 is installed and can be used to install user packages (using the ‑‑user argument). See the User Guide for instructions, specifically the User Installs section.

python -m pip install --user SomePackage

Note that Python 2.7 has reached End of Life, so pip (for Python 2.x) is not installed although Python 2.7.17 is.

 

top

Using Slurm

Useful Commands .

After logging in, you’ll be able to use these command:

sinfo – shows the state of each node:

    • idle: No job currently runs on the node.
    • mix: Jobs currently run on this node.
    • down: Node error.
    • drain: The node waits for its jobs to finish and won’t accept new jobs (usually before boot).
    • boot: The node is rebooting (usually after an update).

squeue – show the currently running and pending jobs. Use ‘squeue -u $USER’ to view only your jobs.

Job states (ST):

      • R: The job is running.
      • PD: The job is pending (waiting in queue to run).
      • CG: The job is completing and will be finished soon.

If the job is pending (PD), the NODELIST(REASON) column will indicate why:

      • Priority: A higher priority job is pending execution.
      • Resources: The job has the highest priority and is waiting for resources.
      • QOS*Limit: You have the maximum number of jobs running. The job will launch when another one finishes. Refer to the Job and resource limits section.
      • launch failed requeued held: Job launch failed due to an unknown reason. Use scontrol to requeue the job. Contact us if the problem persists.

scontrol – used to control jobs. You can only control your jobs.

    • scontrol show job <id>: show details for job with id <id> (JOBID column in squeue).
    • scontrol requeue <id>: requeue job with id <id>

scancel – cancels a job. You can only cancel your jobs.

    • scancel job <id>

Your home folder is /home/<username>, is shared across the network and is the same folder on all the nodes. If you’re coming from Rishon cluster – your home folder is the same.
Important: Although the storage system is fault-tolerant, backup your files regularly to an external location. Make sure you have a backup when you finish a course or a project – home folders of inactive users will be deleted without prior notice.

Note: Although using SSH via a command shell (on Windows, Linux or Mac) is possible, you may want to take advantage of free graphical clients such as MobaXterm which also provides an SFTP file explorer to enable easy to use drag-and-drop file transfer to and from the server.

How to launch jobs

Slurm has two commands which you can use to launch jobs: srun and sbatch.
srun is straightforward: srun <arguments> <program>
You can use various arguments to control the resource allocation of your job, as well as other settings your job requires.
You can find the full list of available arguments here. Some of the most common arguments are:
-c # – allocate # CPUs per task.
‑‑gres=gpu:# – allocate # GPUs.
‑‑mpi=<mpi_type> – define the type of mpi to use. The default (when isn’t explicitly specified) is pmi2.
‑‑pty – run job in pseudo terminal mode. Useful when running bash.

Examples:
1. To get a shell with two GPUs, run:
srun ‑‑gres=gpu:2 ‑‑pty /bin/bash
run ‘nvidia-smi’ to verify the job received two GPUs.
2. Run the script ‘script.py’ using python3:
srun python3 script.py

sbatch lets you use a Slurm script to run jobs. You can find more information here.

 

top

Workload management

Slurm uses a Fair Share queueing system. The system assigns job priority based on cluster load and recent user activity in order to give every user a fair chance to execute jobs.
You will only notice the queuing system when the cluster is full (usually on the week preceding courses’ exercise submission deadline).

Priority calculation

This is a rough description of the priority calculation:
Each resource has a billing “cost”. When a job completes, its total cost is calculated using the allocated resources’ cost and the job’s run time. The user is then “billed” for that cost.
When the user runs another job, it enters the queue. Its priority is determined relative to the queued jobs – the lower the user’s bill, the higher the priority his job gets.
There are some other parameters used for calculating priority. One of them is queued time – the longer a job waits in the queue, the higher its priority.
Another layer of Fair Share is the Account system: Each course has an account (usually the course’s number). Projects are all in the same account. Billing is also calculated across accounts. Thus, if course A has a lower total billing cost (combined billing costs of all jobs executed from that account) than course B, jobs queued from course A will get priority over course B’s jobs.

Some notes:

  • Cost is calculated for allocated resources, not used resources: If you ask for two GPUs, for example, and only use one – you will be billed for two GPUs. That’s one reason you shouldn’t overschedule resources.
  • Currently, only CPUs and GPUs have a ‘cost’.
  • There may be situations where user X from course A has a higher billing than user Y from course B, and yet the former’s jobs receive a higher priority than the latter. This is the desired behavior to avoid the cluster from being choked by a specific course.
  • Billing costs decay over time.
  • Billing cost is for priority calculation only. You won’t be charged real money.
  • As mentioned at the beginning of this section – you will only notice the queueing system when the cluster is full and there aren’t enough available resources to allocate to your job.

Partitions, accounts and QoS

A partition is a group of nodes. Slurm allows defining different partitions for micromanaging different types of jobs. We don’t need this functionality and don’t use it. Only one partition is defined (“all”) and is the default for everyone.

Quality of Service (QoS) is another control group entity that helps the Fair Share queueing system. We use account-specific QoS. Don’t try to change your job’s QoS – it won’t work (by design).

Accounts are groups of users. Each course has its own account. All projects belong to a single account. A user can belong to more than one account (if they enroll in more than one course or project).
Every user also has a Default Account which is chosen to run a job when no account is specified.
If you’re enrolled in more than one course (or a course and a project) and have received permission to use Lambda on both, your user is available on more than one account. Generally, the last course you’ve enrolled in will be your default account. Because every account has its own resource limits and billing, you can use a different account for each job you launch, in order to make full use of your resource permissions:
Run ‘sacctmgr show user $USER withassoc’ to view which accounts your user belongs to.
Use the ‘‑‑account=<account>’ or ‘-A <account>‘ arguments to choose which account the job runs on (e.g. srun -A projects ‑‑pty /bin/bash).

 

top

Job and resource limits

In order to avoid choking the cluster and to allow everyone to run their job, job and resource limits are being imposed. These are account-wide, and could be different for different accounts.
The limits are defined by the QoS. Only one QoS is assigned to each account and is set default.
To view the job and resource limits for an account:
Find the relevant QoS using ‘sacctmgr show user $USER withassoc
Show QoS details using ‘sacctmgr show qos <QoS>’ (replace <QoS> with the relevant QoS).

Effective job limits

These will be modified over time according to resource availability and needs:

Courses:

  • Maximum number of running jobs per user: 1
  • Maximum combined running and queued jobs per user: 5
  • Maximum running time per job: 1 day
  • Maximum allowed GPUs to be allocated per job: 1
  • Total maximum allowed GPUs to be allocated per user concurrently: 1
  • Total maximum allowed CPUs to be allocated per user concurrently: 2

Projects:

  • Maximum number of running jobs per user: 3
  • Maximum combined running and queued jobs per user: 10
  • Maximum running time per job: 7 days
  • Total maximum allowed GPUs to be allocated per user concurrently: 3

 

top

Code of Conduct

Priority algorithms and resource limits have their limitations. Sharing computational resources requires every user to play nice and fair. Be mindful of the fact that other students are using the system and on a typical semester – around 300 students may have permissions on Lambda at a time.
Please follow these guidelines so that everyone can have a positive experience:

  • Don’t abuse the queue: Even if there are no limits on the number of jobs you can queue, don’t overflow it.
  • Don’t abuse loopholes: No system is perfect and no system is watertight. If you find a scenario on which you can bypass job, resource or queue limits – please report.
  • Close idle jobs: The system cannot tell if you’re currently in front of your PC or just left Jupyter Notebook open and went to sleep – these resources could be used by someone else.
  • Don’t overschedule resources: If you need just one GPU – ask for one GPU. Hogging resources needlessly affects everyone – including you, when calculating priority for future jobs.
  • Prefer small jobs over one massive script: If you can modulate your work – please do. This helps for better job scheduling as well as protects against jobs fails.
  • Be nice: Your work is as important for you as everyone else’s work for them. Use common sense when sending jobs.
  • Don’t wait until the last minute: The cluster tends to be flooded with jobs on the week before a submission deadline. Take that into account when managing your time.
  • Understand workload management: The cluster promises to run every job at a reasonable time – it does not promise to run your job RIGHT NOW. Again: Manage your time accordingly.

 

top

System updates and reboots

As with any computer system, software updates are rolling out steadily. Those include various package, security and driver updates and must be applied on a regular basis in order to maintain system security, stability, usability and performance. These updates often require system reboot (yes, even in Linux).
Node (physical servers, lambda1-5) reboots will enter a DRAINING state upon a reboot request. They will not be allocated with new jobs and will reboot after all running jobs have been completed. After reboot (typically 2-3 minutes), they will automatically return to a ready (IDLE) state. Nodes will be rebooted one-by-one in order to minimize work interruption and to maintain maximum cluster availability.
Controller (lambda) reboots are more complicated – they will not affect running jobs, but will end all SSH sessions immediately. There’s currently no good solution to scheduling these reboots and preventing abruptly closing SSH sessions, and they must be performed during work hours and be monitored in case there’s a problem.
If your session was unexpectedly closed – that is probably why. The typical reboot time is ~1 minute. Your running jobs won’t be affected, but unsaved file changes, for example, will be lost. We’re always looking for ways to improve the system and we’ll update this section when a good solution is found. We’ll try to keep Controller reboots to a minimum.

 

top

Troubleshooting

Problem: Error message “ssh: Could not resolve hostname lambda: Name or service not known”.
Solution: Occurs mainly when connecting from outside the campus. Make sure the VPN is connected and try to SSH to 132.68.39.159 instead.

Problem: Error message “Remote side unexpectedly closed network connection” when trying to upload or download files to or from the server.
Solution: SSH sessions limit is 10. Close other connections and try again.

Problem: Job pending.
Solution: Resource over-scheduling (for the pending job) or cluster load. See the Workload management and Job and resource limits sections.

Problem: Error message “Could not load dynamic library ‘libcudart.so.*'”
Solution: If you receive this error on lambda (the login server) – launch the script on a node using Slurm. lambda is a virtual server, has no GPUs and doesn’t have CUDA installed.
If you receive the error on a node:
Add these lines at the end of the .bashrc file in your home folder (~/.bashrc):
export PATH=”/usr/local/cuda/bin:$PATH”
export LD_LIBRARY_PATH=”/usr/local/cuda/lib64:$LD_LIBRARY_PATH”
Save the file, exit the session (or job) and reconnect. Start bash on a node:
srun –pty /bin/bash
and run this command
nvcc -V
You should get CUDA’s version details.

שו”ת (FAQ)

להלן אוסף שאלות ותשובות נפוצות

איך להתקין גירסת tensorflow שתומכת בפקודות מכונה חדשות

pip install –user –ignore-installed –upgrade “Download URL”

The download url of the whl file can be found here https://github.com/lakshayg/tensorflow-build

לאובונטו 16.04 זה יוצא:

python3 -m pip install –user –ignore-installed –upgrade https://github.com/lakshayg/tensorflow-build/releases/download/tf1.12.0-macOS-mojave-ubuntu16.04-py2-py3/tensorflow-1.12.0-cp35-cp35m-linux_x86_64.whl

 

איך מקבלים את המעבדים הכי קרובים לכרטיס גרפי?

לפקודות srun/sbatch נוסף הדגל  –gres-flags

דגל זה מקבל אחת משלושה ערכים הבאים:

enforce-binding – מבקש מעבדים הקרובים ביותר לGPU שהתבקש בלבד

disable-binding – לא מתייחס לסינון מעבדים עפ”י קרבה ל GPU המבוקש.

משמעויות

א. אם אני רץ עם GPU 1 או יותר מ GPU 1 אבל הם יושבים על אותו ה socket, ואני רוצה ביצועים מקסימליים, יש להשתמש בדגל הנ”ל ( כלומר –gres-flags=enforce-binding )
אם המעבדים לא פנויים, העבודה שלי תחכה בתור.

ב אם אני רץ עם 2 GPU ומעלה ולא כל ה GPU יושבים על אותו ה Socket הפעלת הדגל תגרום לעבודה שלי להדחות מיידית.

ג. אם אני לא מציין את הדגל הנ”ל, או שרשמתי disable-binding אני יכול לקבל כל מעבד פנוי ובהחלט לא בהכרח את הקרוב ביותר. אם כמות המעבדים הנדרשת פנויה העבודה שלי תתחיל לרוץ.

 

איך מבקשים גרטיס גרפי(GPU)?

כיוון שבצבר מחקר ישנם כמהסוגים של גרטיסים גרפיים, פותחה השיטה הבאה.ישנם שני פרמטרים באמצעותם אפשר לבקש כרטיס : type,constraint.

הפרמטר type מקבל את הערכים: new,old בלבד. כאשר new הכוונה כרטיסים מסוג פסקל ומעלה. ו old הכוונה מקסוואל

רשימת הערכים לפרמטר constratins מתקבלים ע”י הפקודה:

show nodes |grep 'Arch\|AvailableFeatures'

ונקראים features.

פלט לדוגמה:

NodeName=gaon1 Arch=x86_64 CoresPerSocket=8
AvailableFeatures=(null)
NodeName=gaon2 Arch=x86_64 CoresPerSocket=8
AvailableFeatures=1080ti
NodeName=gaon3 Arch=x86_64 CoresPerSocket=8
AvailableFeatures=1080
NodeName=gaon4 Arch=x86_64 CoresPerSocket=6
AvailableFeatures=titanx
NodeName=gaon5 Arch=x86_64 CoresPerSocket=1
AvailableFeatures=1080ti
NodeName=gaon6 Arch=x86_64 CoresPerSocket=1
AvailableFeatures=titanxp,titanx
NodeName=gaon7 Arch=x86_64 CoresPerSocket=1
AvailableFeatures=(null)

כלומר, לכל שרת הfeatures שונים. לחלק אין(גאון1,7) ולחלק יש אף יותר מאחד(גאון6).כמו כן הפרמטרים הם שונים לכל שרת.

התבנית הכללית היא

srun/sbatch --gres=gpu:TYPE:# --constraint='feature1|feature2...' my_prog

דוגמאות שימוש בשני הפרמטרים

כרטיס חדש בלבד (פסקל ומעלה)

srun --gres=gpu:new:1 --gres-flags=enforce-binding nvidia-smi

כרטיס ישן בלבד

srun --gres=gpu:old:1 nvidia-smi

כרטיס מסוג 1080 בלבד

srun --gres=gpu:new:1 --gres-flags=enforce-binding --constraint='1080' nvidia-smi

כרטיס titanxp או 1080ti בלבד

srun --gres=gpu:new:1 --constraint="titanxp|1080ti" --pty nvidia-smi

כרטיס מסוג titanx מקסוואל בלבד

srun --gres=gpu:old:1 --gres-flags=enforce-binding --constraint='titanx' nvidia-smi

 

איך מריצים עבודות בטור(זה אחר זה)?

הדוגמה הבאה מבקשת להריץ 3 עבודות בטור, כאשר כל עבודה מריצה את a.out 14 פעמים. סה”כ 42 פעמים.

seq.sh ———– #!/bin/bash #SBATCH -n 14 #SBATCH -p all #SBATCH -o slurm.%N.%j.out # stdout goes here #SBATCH -e slurm.%N.%j.out # stderr goes here srun -n 14 -c 2 ./a.out srun -n 14 -c 2 ./b.out srun -n 14 -c 2 ./c.out … ———– $sbatch seq.sh

איך מריצים עבודות במקביל?

 

par.sh ———– #!/bin/bash #SBATCH -p all #SBATCH -n 56 #SBATCH -o slurm.%N.%j.out # stdout goes here #SBATCH -e slurm.%N.%j.out # stderr goes here srun -n 14 ./a.out & srun -n 28 ./b.out & srun -n 14 ./c.out & … wait ———– $sbatch par.sh

שימו לב ל & בסוף כל שורה. כמו כן שימו לב לפקודת wait בסוף הגורמת לעבודת sbatch לחכות שכל עבודות הסתיימו.

ג’ופיטר-לאב מהבית

על מנת לקנפג את המחשב שלכם לעבוד עם ג’ופיטר לאב מהבית יש לפעול על פי ההוראות הבאות. שימו לב, כל ההוראות הם לשרת הוראה, בשביל שרת המחקר, אנא שנו rishon ל gaon כל השאר אותו דבר

  1.  נא לסיים בהצלחה את המדריך לעבודה מהבית :מדריך עבודה מהבית
  2.  

  3. יש להתחבר לשרת גאון/ראשון דרך המנהרה הנל שעשינו, כלומר:
    ssh username@localhost -p 9022
    שם המשתמש והסיסמה הוא בשביל השרת כניסה.
  4.  

  5. בתוך השרת כניסה יש להריץ ג’ופיטרלאב, לדוגמה כך:
    srun -c2 –gres=gpu:1 jl.bash
    כאשר jl.bash הוא קובץ שנבנה עפי המדריך למשתמש כאן
  6.  

  7. שהג’ופיטר עלה, אתם מקבלים url, לדוגמה כזה:
    http://132.68.39.26:PORT/?token=3bac4b2…&token=3bac4…eca2c
    (
    שימו לב הURL קוצר כדי לחסוך מקום, אתם צריכים את הURL המלא) 
    יש לשים לב לכתובת: 132.68.39.26 ולפורט PORT שאמור להיות הפורט שבחרתם במדריך למשתמש צבר הוראה או מדריך למשתמש צבר מחקר.הכתובת היא הכתובת של השרת חישוב שעליו קיבלתם משאבים. 
  8.  

  9. נא לפתוח חלון מקומי חדש (local terminal) במחשב שלכם.ובחלון זה יש להקיש:
    ssh -f -N -L PORT:132.68.39.26:PORT example@csm.cs.technion.ac.il שורה זו בעצם יוצרת מנהרה באמצעות שרת פקולטי בין המחשב שלכם לבין השרת חישוב עליו הג’ופיטרלאב רץ. 
  10.  

  11. אם הכל עבד כשורה, אפשר לגלוש בדפדפן על המחשב שלכם בבית לכתובת:
    http://localhost:PORT/?token=3bac4b2…&token=3bac4…eca2c
    כאשר ה
    URL הוא בעצם אותו URL שקיבלתם בשינוי הכתובת בלבד.

מודולים

*צבר מחקר בלבד כרגע

הקדמה

מודולים היא מערכת המאפשרת טעינה של רוב התוכנות החשובות הנמצאות בצבר. המערכת הנ”ל מקילה את השימוש לדוגמה בגירסאות cuda שונות או גירסות libcudnn שונות. המערכת מאפשרת טעינה או החלפה של סביבות תוך כדי עבודה ובכך מאפשרת למשתמשים להריץ עבודות בסביבות שונות בלחיצת כפתור.

שימוש

במקום להאריך בהסברים הבאנו מס’ דוגמאות מרכזיות הממחישות את כל העניין.

בדוגמאות הנ”ל נניח שמדובר בסטודנט העובד עם GPU ומעוניין בטעינת סביבות עבודה שונות של cuda.


$ module load cuda
$ module list
Currently Loaded Modulefiles:
1) cuda/9.0-7.0.5(default)

What was set?
$ module show cuda

——————————————————————-

setenv CUDA_HOME /home/EnvModules/packages/cuda/9.0-7.0.5
setenv CUDA_PATH /home/EnvModules/packages/cuda/9.0-7.0.5
append-path PATH /home/EnvModules/packages/cuda/9.0-7.0.5/bin
append-path CPATH /home/EnvModules/packages/cuda/9.0-7.0.5/include
append-path LD_LIBRARY_PATH /home/EnvModules/packages/cuda/9.0-7.0.5/lib64
append-path LIBRARY_PATH /home/EnvModules/packages/cuda/9.0-7.0.5/lib64
append-path MANPATH /home/EnvModules/packages/cuda/9.0-7.0.5/doc/man
conflict cuda (see at the end of this document)
——————————————————————-

נסכם במילים מה שראינו פה. השלב הראשון היה טעינת סביבת cuda. המשתמש לא ציין סביבה ספציפית ולכן נטענה הברירת מחדל (cuda/9.0-7.0.5(default)).
אח”כ הרצנו פקודה שמראה לנו מה בעצם נעשה כמו כן נשים לב שזה לא רק cuda אלא יש גם קישור (פנימי) לlibcudnn גירסת 7.0.5.

איזו מודולים קיימים?


$ module avail
The short form the command is:
$ module av
Available Modules can be also displayed in different modes, such as
• each Module per one line
$ module -t avail
• long
$ module -l avail

- Package/Alias -----------------------.- Versions --------.- Last mod. -------
/home/EnvModules/modules:
bazel/0.18.0 2018/10/23 07:42:50
cuda/9.0-7.0.5 2018/10/22 15:13:23
cuda/9.0-7.1.1 2018/10/22 15:31:34
cuda/9.2-7.1.4 2018/10/23 07:26:24
cuda/9.2-7.2.1 2018/10/25 17:24:30
mkl/2017.2.174 2018/10/22 15:46:01
utils/gperf/3.0.4-2 2018/10/24 14:39:40              2018/07/25 12:25:55

התנגשויות

נשים לב לשורה אחרונה בפלט שבו טענו את סביבת העבודה של קודה הנ”ל.

conflict cuda

שורה זו אומרת שאי אפשר לטעון שני סביבות של קודה בו זמנית. ואם אנסה בכל זאת:


ERROR: WARNING: cuda/9.0-7.1.1 cannot be loaded due to a conflict.
HINT: Might try "module unload cuda/9.0-7.1.1" first.

אז אפשר כמובן לקרוא את השגיאה ולעשות כפי שנאמר:


$module unload cuda
$module load cuda/9.0-7.1.1
OR
$module switch cuda/9.0-7.1.1
$module list
Currently Loaded Modulefiles:
1) cuda/9.0-7.1.1

ניקוי סביבה

אופציה נוספת הקיימת היא לנקות את כל סביבת העבודה:

$module purge
OR
$module clear

כאשר האפ’ השנייה שואלת שוב ליתר בטחון האם זאת הכוונה והאפשר’ הראשונה לא(כלומר מתאים יותר לסקריפטים אוטומטים)

טעינה אוטומטית

על מנת לטעון אוטומטית מודולים קבועים יש להוסיף את הפקודות הרלוונטית לסקריפט של ה batch או ל .bashrc ואז כמובן לעשות לו source בסקריפט שמריצים

 

איך משתמשים?

 

יש להוסיף את השורה הבא לקובץ .bashrc בספרית הבית שלכם:

source /etc/profile.d/modules.sh

מדריך למשתמש צבר מחקר

k

הקדמה

מערכת מנ”ע היא מערכת המשדכת בין משאבים שהוקצו לרשותה ובין דרישות המשתמשים. בהקשר שלנו המשאבים הם יחידות חישוב(cores) וכרטיסים גרפיים(gpu).

צורת העבודה עם מנ”ע היא ע”י הגשת עבודות לביצוע לתור נדרש. המערכת דואגת לתזמן כל עבודה עפי מס’ רב של קריטריונים הכוללים איכות שירות(QOS) יחסיות (fair share) ועוד. עפ”י שיקלול זה כל עבודה מקבלת עדיפות וממוקמת בתור.

ישנה אפשרות לעבוד לזמן קצר בצורה אינטראקטיבית כך שמקבלים shell למכונה המבוקשת לצורכי דיבוג שגיאות או בדיקות קצרות. זמן מקסימלי לעבוד בצורה זו הוא 30 דקות.

רכיבי המערכת

שרת כניסה – זהו השרת שאליו המשתמשים נגשים עם החשבון שלהם. ממנו יש גישה לכל התורים הרלוונטים וממנו משתמשים שולחים עבודות לביצוע.

שם השרת: gaon.cs.technion.ac.il או בקיצור gaon

שרתי עבודה(nodes) : אלו השרתים המריצים את העבודות בפועל

שמות השרתים: …gaon1,gaon2,gaon3

התחברות למערכת


אימות משתמשים נעשה באמצעות AD, כלומר החשבון במנ”ע הוא החשבון בפקולטה, עם אותו השם ואותה הסיסמה. שם המשתמש הוא מהצורה username(אין צורך לציין td-csf\username). הסיסמה היא הסיסמה של td-csf

שרת הכניסה: gaon.cs.technion.ac.il
צורת התחברות : ssh
השרת נגיש רק בתוך הטכניון. אפשר לגשת אליו דרך שרתים פקולטים הפתוחים מחוץ לטכניון(csl,csm,csa) וכו’

מערכת מק”מ(מערכת קבצים מבוזרת)

מערכת מק”מ הינה מערכת קבצים מבוזרת.
ספריית הבית של המשתמשים נמצאת ב /home/username ספרייה זו מסונכרנת מול שרתי החישוב באותו מיקום בעץ ספריות שלהם. כלומר /home/almoni בשרת הכניסה זהה בתוכנו ל /home/almoni בכל השרתי החישוב, כל קובץ שיווצר במקום אחד יופיע בכל אחד מהשרתים בצבר באותו המקום.

רשימת תפוצה

כפי שאפשר לראות המערכת מורכבת מכמה חלקים ובאופן טבעי תצטרך לעבור תחזוקה שיפורים ושדרוגים. על מנת לאפשר לכל משתמש להיערך מראש להשבתות יצרנו בשבילכם רשימת תפוצה אליה ישלחו חדשות עידכונים בנוגע לצבר המחקר.

אפשר להרשם בלינק : http://listserv.technion.ac.il/cgi-bin/wa?SUBED1=CS-LABS-L&A=1

שימו לב, לבחור בקטגורית Topcis ב gaoncluster.

מערכת ניטור

ישנה אפשרות את מצב הצבר ברגע נתון ע”י מערכת ניטור. המערכת נותנת גרפים שונים וסטטיסטיקות, כמו למשל מס’ GPU פנויים, כמו CPU בשימוש וכו’.

הגישה אליו: https://sysgrafana.cs.technion.ac.il/dashboard/db/slurm-full-dyn?refresh=30s&orgId=1

משתמש: gaon
סיסמה:gaongaon

המערכת היא לצפייה בלבד.

צורת עבודה עם מנ”ע

למערכת מנ”ע יש כמה סוגים של פקודות(בסוף המסמך זה יש פירוט של רובם), sinfo,squeue הם פקודות שיתנו לכם לראות את המצב בצבר, sinfo יראה את המצב של התורים השונים הקיימים. Squeue יראה את העבודות העומדות בתור(כולל אלו שרצות בפועל כרגע). סוג שני של פקודות הם srun,sbatch, אלו פקודות ההרצה, כלומר כדי לשלוח עבודה משתמשים בהם. יש שני סוגים של עובדות. Srun, משתמשים בדר”כ לעבודות קצרות,פשוטות, הפלט של העבודה שנשלחה יודפס ישירות למסך ממנו נשלחה העבודה. לעומת זאת בסוג השני – sbatch , אפשר לשלוח מס’ רב של עבודות אחת אחרי השניה, הפלט נשלח לקבצים(יוסבר בהמשך) ולא למסך. במצב srun כל בעית תקשורת בדרך בינכם לשרת החישוב עליו רצה העבודה, תפסיק את העבודה. בעיה זו לא קיימת במצב sbatch.

על מנת לראות את ההגבלות על הרצות במערכת יש להתשמש בשני הפקודות הבאות:
sinfo, פקודה זו תיתן בין היתר את הזמן המקסימלי להרצה בודדת. לדוגמה 07-00:00:00 הכוונה 7 ימים בדיוק.
sacctmgr show qos, יראה את ההגבלות/יכולות של כל quality of service המוגדרים במערכת.
לדוגמה, ניתן למשל לראות את הפרמטר MaxSubmitPU המגביל את מס’ העבודות שאפשר לשלוח לתור בו זמנית ע”י משתמש יחיד.

שלוש דוגמאות לעבודה עם מנ”ע

דוגמה ראשונה: הכנת סביבת עבודה

    1. Login to gaon
      ssh -X example@gaon.cs.technion.ac.il
    2. Print partitions(queues states)
      sinfo
    3. Print jobs states
      squeue -o "%.18i %.9P %.8j %.8u %.2t %.10M %.6D %R %Q"
    4. Ask for bash shell in one of the computing servers
      srun -p gip,all -c2 --gres=gpu:1 --pty bash
      Explanation:
      -p all,gip submit the job to two queues(all,gip) , once it gets elected to run in one of them , it automatically removed in the other. this way the user benefit using his higher priorty on its lab queue(gip) and if this queue is too busy it can ran with lower priority on other servers in “all” queue.
      c2
       ask for 2 cores
      gpu:1
      ask for 1 gpu of any type
      --pty bash
      gives terminal in one of the computing node.
    5. See your job in the queue
      squeue -o "%.18i %.9P %.8j %.8u %.2t %.10M %.6D %R %Q"
    6. Edit .bashrc file
      enter ~/.bashrc file with:
      nano ~/.bashrc
      add as last line the following:
      export LC_ALL="en_US.UTF-8"
      source /etc/profile.d/modules.sh

      Install development environment (notice the --user ! )
      This is an example for tensorflow + pytorch + keras, change it for your own needs.
      Only run in computing node, not on login server(gaon)


module load cuda/9.2-7.2.1
pip3 install --user --upgrade pip
pip3 install --user --upgrade tensorflow-gpu
pip3 install --user http://download.pytorch.org/whl/cu90/torch-0.3.1-cp35-cp35m-linux_x86_64.whl
pip3 install --user torchvision
pip3 install --user numpy scipy matplotlib keras

  • Test evironment
    python3
    >>>import tensorflow as tf
    >>>tf.__version__
    ‘1.11.0’
    >>>import keras
    Using TensorFlow backend.
    >>>import torch
    no output is good

 

שאלת הבנה: האם הסביבה הותקנה בשרת חישוב שאליו התחברתי בלבד או לכל שרתי החישוב?

תשובה: למרות שהתקנו את הסביבת פיתוח בשרת חישוב ספציפי, הסביבה בעצם הותקנה בכל השרתי חישוב במקביל. שני סיבות לדבר, הראשון שהתקנה בהקשר שלנו היא רק הורדת קבצים והעתקתם לספרייה ספציפית בתוך ספרית הבית שלכם, והשני הוא שהספריות בית שלכם משותפות לכל השרתים. המשמעות היא שאתם יכולים עכשיו להריץ עבודות מבלי להיות נעולים על השרת בו התקנתם את הסביבה שלכם. כמובן שזה נכון להתקנות מסוג pip ודומיו, להתקנות מסוג אחר למשל apt-get זה לא יהיה נכון.

דוגמה שנייה: הרצת main.py של mnist

אני מניח שהורדתם את הקובץ והעתקתם אותו לשרת gaon לספריית הבית שלכם.
שימו לב לשנות בשני מקומות ב main.py את הביטוי “../data” ל “data” (כלומר להוריד את הנקודותיים והסלש)

  1. Login to gaon
    ssh -X example@gaon.cs.technion.ac.il
  2. Create file exp2.bash containing:

#!/bin/bash
#SBATCH -N 1 # number of minimum nodes
#SBATCH -c 2 # number of cores
#SBATCH --gres=gpu:1 # Request 1 gpu
#SBATCH -p gip,all # submit the job to two queues(all,gip) , once it gets elected to run in one of them , it automatically removed in the other
#SBATCH --mail-user=example@cs.technion.ac.il
# (change to your own email if you wish to get one, or just delete this and the following lines)
#SBATCH --mail-type=ALL # Valid values are NONE, BEGIN, END, FAIL, REQUEUE, ALL
#SBATCH --job-name="just_a_test"
#SBATCH -o slurm.%N.%j.out # stdout goes here
#SBATCH -e slurm.%N.%j.out # stderr goes here

source /etc/profile.d/modules.sh
module load cuda/9.2-7.2.1
nvidia-smi
source ~/tensorflow/bin/activate
python3 main.py

      1.  chmod +x exp2.bash
      2. From gaon server run
        sbatch exp2.bash
      3. Lookit up in queue list
        squeue -o "%.18i %.9P %.8j %.8u %.2t %.10M %.6D %R %Q"
      4. View it output
        tail -f ~/slurm.NodeName.JobID.out (fill in your NodeName,JobID)
        Example output:
        tail -f slurm.gaon3.103512.out
        Train Epoch: 3 [53760/60000 (90%)] Loss: 0.172956
        Train Epoch: 3 [54400/60000 (91%)] Loss: 0.340682
        Train Epoch: 3 [55040/60000 (92%)] Loss: 0.294907
        Train Epoch: 3 [55680/60000 (93%)] Loss: 0.243409
        Train Epoch: 3 [56320/60000 (94%)] Loss: 0.262233
        Train Epoch: 3 [56960/60000 (95%)] Loss: 0.220493
        Train Epoch: 3 [57600/60000 (96%)] Loss: 0.375372
        Train Epoch: 3 [58240/60000 (97%)] Loss: 0.156547
        Train Epoch: 3 [58880/60000 (98%)] Loss: 0.272710
        Train Epoch: 3 [59520/60000 (99%)] Loss: 0.129080

 

  • Troubleshoot if the output seems wrong, you can see the output live using srun instead of sbatch.

    srun -c2 -N1 --gres=gpu:1 --job-name="just_a_test" exp2.bash

דוגמה שלישית: cifar10

הרצה לדוגמה של cifar10 על שרתי חישוב

1. Login to gaon
ssh username@gaon.cs.technion.ac.il

2. add to .bashrc: source /etc/profile.d/modules.sh

3. Run the following:
srun --gres=gpu:1 -c2 --pty bash (for 1 gpu)
pip3 install --user --upgrade pip
python3 -m pip install --user --upgrade tensorflow-gpu==1.11

source ~/.bashrc
cp -r /home/EnvModules/packages/other/cifar10Tutorial/cifar10 ./
cd cifar10
module load cuda/9.2-7.2.1
python3 cifar10_train.py

עבודה עם ג’ופיטר

התקנה:

python3 -m pip install --upgrade --user pip
python3 -m pip install --user jupyterlab

השלב הבא הוא ליצור סקריפט שיחסוך לנו הקלדות, אנא צרו קובץ בשם jl.bash עם התוכן הבא:

#!/bin/bash
hn=`hostname -I`
unset XDG_RUNTIME_DIR
.local/bin/jupyter-lab --no-browser --ip=$hn --port=PORT

נא לבחור PORT כמספר בתחום 2000 ומעלה

example@gaon:~$chmod +x ./jl.bash

ועכשיו אפשר לקבל ג’ופיטר לאב על המחשב שלנו שרץ על השרתי חישוב

example@gaon:~$srun -c4 --gres=gpu:1 --pty jl.bash

את הכתובת שמקבלים יש כמובן להעתיק לדפדפן המקומי על המחשב שלנו

הערות

מדיניות הרצות

  • כל עבודה תרוץ 60 דקות אלא אם כן המשתמש ביקש אחרת במפורש(–time).
  • עבודות אינטרקטיביות(למשל bash) יסגרו אוטומטית אחרי 50 דקות.
  • כל עבודה תסגר אחרי לכל היותר 7 ימים.
  • ככל שהשימוש במשאבים בזמן הרצת העבודה נמוך יותר, כך העדיפות לעבודה באה נמוך יותר.
    למשל אדם שהריץ עבודה וביקש 13 שעות, ומתוכם בפועל הריץ שעה אחת בלבד, יקבל ניקוד שלילי לעדיפות של העבודות הבאות שלו הרזולוציה היא של 12 שעות. (הפרשים של מס’ שעות קטן אינו משמעותי)

מדריך למשתמש צבר הוראה

הקדמה

מערכת מנ”ע היא מערכת המשדכת בין משאבים שהוקצו לרשותה ובין דרישות המשתמשים.בהקשר שלנו המשאבים הם יחידות חישוב(cores) וכרטיסים גרפיים(gpu).

צורת העבודה עם מנ”ע היא ע”י הגשת עבודות לביצוע לתור נדרש. המערכת דואגת לתזמן כל עבודה עפי מס’ רב של קריטריונים הכוללים איכות שירות(QOS) יחסיות (fair share) ועוד. עפ”י שיקלול זה כל עבודה מקבלת עדיפות וממוקמת בתור.

ישנה אפשרות לעבוד לזמן קצר בצורה אינטראקטיבית כך שמקבלים shell למכונה המבוקשת לצורכי דיבוג שגיאות או בדיקות קצרות. זמן מקסימלי לעבוד בצורה זו הוא 30 דקות.

רכיבי המערכת

שרת כניסה – זהו השרת שאליו המשתמשים נגשים עם החשבון שלהם. ממנו יש גישה לכל התורים הרלוונטים וממנו משתמשים שולחים עבודות לביצוע.

שם השרת: rishon.cs.technion.ac.il  או בקיצור  rishon

שרתי עבודה(nodes) : אלו השרתים המריצים את העבודות בפועל

שמות השרתים: rishon1,rishon2,rishon3,rishon4

התחברות למערכת


אימות משתמשים נעשה באמצעות AD, כלומר החשבון במנ”ע הוא החשבון בפקולטה, עם אותו השם ואותה הסיסמה. שם המשתמש הוא מהצורה username(אין צורך לציין td-csf\username). הסיסמה היא הסיסמה של td-csf

שרת הכניסה: rishon.cs.technion.ac.il
צורת התחברות : ssh
השרת נגיש רק בתוך הטכניון.

ניתן לגשת אליו על ידי שימוש בחיבור  VPN בלבד.

להלן ההוראות להגדרת חיבור VPN

Pulse Settings: https://cis.technion.ac.il/en/central-services/communication/off-campus-connection/ssl-vpn/

Token Settings: https://cis.technion.ac.il/en/central-services/communication/off-campus-connection/otp/

 

במקרה של תקלה בחיבור VPN אנא צרו קשר :

https://cis.technion.ac.il/en/support/contact-cis-support/

 

מערכת מק”מ(מערכת קבצים מבוזרת)

מערכת מק”מ הינה מערכת קבצים מבוזרת. ספריית הבית של המשתמשים נמצאת ב
/home /username ספרייה זו מסונכרנת מול שרתי החישוב באותו מיקום בעץ ספריות שלהם. כלומר /home /almoni בשרת הכניסה זהה בתוכנו ל /home/almoni בכל השרתי החישוב, כל קובץ שיווצר במקום אחד יופיע בכל אחד מהשרתים בצבר באותו המקום.

צורת עבודה עם מנ”ע

למערכת מנ”ע יש כמה סוגים של פקודות(בסוף המסמך זה יש פירוט של רובם), sinfo,squeue הם פקודות שיתנו לכם לראות את המצב בצבר, sinfo יראה את המצב של התורים השונים הקיימים. Squeue יראה את העבודות העומדות בתור(כולל אלו שרצות בפועל כרגע). סוג שני של פקודות הם srun,sbatch, אלו פקודות ההרצה, כלומר כדי לשלוח עבודה משתמשים בהם. יש שני סוגים של עובדות. Srun, משתמשים בדר”כ לעבודות קצרות,פשוטות, הפלט של העבודה שנשלחה יודפס ישירות למסך ממנו נשלחה העבודה. לעומת זאת בסוג השני –  sbatch , אפשר לשלוח מס’ רב של עבודות אחת אחרי השניה, הפלט נשלח לקבצים(יוסבר בהמשך) ולא למסך. במצב srun כל בעית תקשורת בדרך בינכם לשרת החישוב עליו רצה העבודה, תפסיק את העבודה. בעיה זו לא קיימת במצב sbatch.

שני דוגמאות לעבודה עם מנ”ע

דוגמה ראשונה: הכנת סביבת עבודה

  1. Login to rishon
    ssh -X example@rishon.cs.technion.ac.il
  2. Print partitions(queues states)
    sinfo
  3. Print jobs states
    squeue -o “%.18i %.9P %.8j %.8u %.2t %.10M %.6D %R %Q”
  4. Ask for bash shell in one of the computing servers
    srun -p 236605,all -c2 --gres=gpu:1 --pty bash
    Explanation:
    -p 236605,all  submit the job to two queues(all,236605) , once it gets elected to run in one of them , it automatically removed in the other. this way the user benefit using his higher priorty on his course queue(236605 or 236370) and if this queue is too busy it can ran with lower priority on other servers in all queue.
    make sure you write the course number you enroll to.People who are not enroll to either of these courses, should not run with this flag, the system will route them according to their status.c2 – ask for 2 cores
    gpu:1 – ask for 1 gpu of any type
    --pty bash – gives terminal in one of the computing node.
  5. See your job in the queue
    squeue -o “%.18i %.9P %.8j %.8u %.2t %.10M %.6D %R %Q”
  6. Edit .bashrc file
    enter ~/.bashrc file with:
    nano ~/.bashrc
    add as last line the following:
    export LC_ALL=”en_US.UTF-8″
  7. Install development environment (notice the --user ! )
    This is an example for tensorflow + pytorch + keras, change it for your own needs.
    Only run in computing node, not on login server(rishon)
    %pip3 for python 3.5 or pip2 for python 2.7
    pip3 install --user --upgrade pip
    pip3 install --user --upgrade tensorflow-gpu==1.11
    pip3 install --user http://download.pytorch.org/whl/cu90/torch-0.3.1-cp35-cp35m-linux_x86_64.whl
    (pip2 install --user http://download.pytorch.org/whl/cu90/torch-0.3.1-cp27-cp27mu-linux_x86_64.whl)
    pip3 install --user torchvision
    pip3 install --user numpy scipy matplotlib keras

* if pip3/pip2 doesn’t work , use: python3/2 -m pip install –user ….

Test evironment
source ~/tensorflow/bin/activate
python
>>>import tensorflow as tf
>>>tf.__version__
‘1.5.0’
>>>import keras
Using TensorFlow backend.
>>>import torch
no output is good

שימו לב, בקשה לshell, למשל כמו פה –pty bash הינה מוגבלת ל 50 דקות ומיועדת לניפוי שגיאות. להרצות אמיתיות יש להריץ את הסקריפט עצמו ולא לפתוח shell ומתוכו להריץ פקודות.

שאלת הבנה: האם הסביבה הותקנה בשרת חישוב שאליו התחברתי בלבד או לכל שרתי החישוב?

תשובה: למרות שהתקנו את הסביבת פיתוח בשרת חישוב ספציפי, הסביבה בעצם הותקנה בכל השרתי חישוב במקביל. שני סיבות לדבר, הראשון שהתקנה בהקשר שלנו היא רק הורדת קבצים והעתקתם לספרייה ספציפית בתוך ספרית הבית שלכם, והשני הוא שהספריות בית שלכם משותפות לכל השרתים. המשמעות היא שאתם יכולים עכשיו להריץ עבודות מבלי להיות נעולים על השרת בו התקנתם את הסביבה שלכם. כמובן שזה נכון להתקנות מסוג pip ודומיו, להתקנות מסוג אחר למשל apt-get  זה לא יהיה נכון.

דוגמה שנייה: הרצת main.py של mnist

שימו לב, לשלב הראשון שבו נכנסים לשרת rishon, זה לא שלב טריוויאלי, אם תריצו עבודות תוך כדי שאתם בbash שקיבלתם בדוגמה הקודמת דברים לא יעבדו כמו שאתם מצפים.
אני מניח שהורדתם את הקובץ והעתקתם אותו לשרת rishon לספריית הבית שלכם.
שימו לב לשנות בשני מקומות ב main.py את הביטוי “../data” ל “data” (כלומר להוריד את הנקודותיים והסלש)

  • Login to rishon
    ssh -X example@rishon.cs.technion.ac.il
  • Create exp2.bash, using nano or vi
    #!/bin/bash
    #SBATCH -N 1  # number of  minimum nodes
    #SBATCH -c 2 # number of cores
    #SBATCH –gres=gpu:1   # Request 1 gpu
    #SBATCH -p 236370,all #  or 236605,all for more details see explanation above (srun command)
    #SBATCH –mail-user=example@cs.technion.ac.il
    # (change to your own email if you wish to get one, or just delete this and the following lines)
    #SBATCH –mail-type=ALL  # Valid values are NONE, BEGIN, END, FAIL, REQUEUE, ALL
    #SBATCH –job-name=”just_a_test”
    #SBATCH -o slurm.%N.%j.out    # stdout goes here
    #SBATCH -e slurm.%N.%j.out   # stderr goes here
    nvidia-smi
    source ~/tensorflow/bin/activate
    python3 main.py
  • From rishon server run
    sbatch exp2.bash
  • Lookit up in queue list
    squeue -o “%.18i %.9P %.8j %.8u %.2t %.10M %.6D %R %Q”
  • View it output
    tail -f ~/slurm.NodeName.JobID.out (fill in your NodeName,JobID)
    Example output:
    tail -f slurm.rishon3.103512.out
    Train Epoch: 3 [53760/60000 (90%)]      Loss: 0.172956
    Train Epoch: 3 [54400/60000 (91%)]      Loss: 0.340682
    Train Epoch: 3 [55040/60000 (92%)]      Loss: 0.294907
    Train Epoch: 3 [55680/60000 (93%)]      Loss: 0.243409
    Train Epoch: 3 [56320/60000 (94%)]      Loss: 0.262233
    Train Epoch: 3 [56960/60000 (95%)]      Loss: 0.220493
    Train Epoch: 3 [57600/60000 (96%)]      Loss: 0.375372
    Train Epoch: 3 [58240/60000 (97%)]      Loss: 0.156547
    Train Epoch: 3 [58880/60000 (98%)]      Loss: 0.272710
    Train Epoch: 3 [59520/60000 (99%)]      Loss: 0.129080


Troubleshoot: If the output seems wrong, you can see the output live using srun instead of sbatch.

srun -c2 -N1 --gres=gpu:1 --job-name="just_a_test" exp2.bash

Don’t forget to chmod +x exp2.bash.

עבודה עם ג’ופיטר

התקנה:

python3 -m pip install --upgrade --user pip
python3 -m pip install --user jupyterlab

השלב הבא הוא ליצור סקריפט שיחסוך לנו הקלדות, אנא צרו קובץ בשם jl.bash עם התוכן הבא:

#!/bin/bash
hn=`hostname -I`
unset XDG_RUNTIME_DIR
.local/bin/jupyter-lab --no-browser --ip=$hn --port=PORT

נא לבחור PORT כמספר בתחום 2000 ומעלה

example@gaon:~$chmod +x ./jl.bash

ועכשיו אפשר לקבל ג’ופיטר לאב על המחשב שלנו שרץ על השרתי חישוב

example@gaon:~$srun -c4 --gres=gpu:1 --pty jl.bash

את הכתובת שמקבלים יש כמובן להעתיק לדפדפן המקומי על המחשב שלנו