Prometheus:Basics: Różnice pomiędzy wersjami

Z Komputery Dużej Mocy w ACK CYFRONET AGH
Skocz do:nawigacja, szukaj
(Przekład na język angielski - WIP)
m
 
(Nie pokazano 19 wersji utworzonych przez 3 użytkowników)
Linia 5: Linia 5:
 
Access to the Prometheus cluster is facilitated by the access host at:
 
Access to the Prometheus cluster is facilitated by the access host at:
 
<pre>
 
<pre>
prometheus.cyfronet.pl
+
prometheus.cyfronet.pl (alias for the following hosts):
 +
 
 +
login01.prometheus.cyfronet.pl
 +
login02.prometheus.cyfronet.pl
 
</pre>
 
</pre>
  
Linia 14: Linia 17:
 
</pre>
 
</pre>
  
You can also use the short alias '''pro.cyfronet.pl'''.
+
You can also use the short alias '''pro.cyfronet.pl'''
 +
 
 +
{| class="wikitable"  style="text-align:center;"
 +
! Login node !! Description
 +
|-
 +
| '''prometheus.cyfronet.pl'''<br>  '''pro.cyfronet.pl''' || Default login node for [https://plgrid.pl PLGrid] users
 +
|-
 +
| '''prace.pro.cyfronet.pl''' || Dedicated login node for [http://www.prace-ri.eu PRACE] users
 +
|-
 +
| '''prace-int.pro.cyfronet.pl''' || Alias of PRACE login node within [http://www.prace-ri.eu PRACE] internal network
 +
|-
 +
|}
  
 
An SSH client is required for login.
 
An SSH client is required for login.
 +
 +
SSH fingerprints:
 +
<pre>
 +
(ECDSA)  SHA256:tKk4RpOzWSTf+H8oN7COX1o5xMGSX7vMk956oHcdSB8
 +
(ED25519) SHA256:roerSF6HBUEqJpoPk36BXwz7NsPRIrTguoApYoYK+ro
 +
(RSA)    SHA256:v/iUvEh8faHN7IoZ5Vpm0kU6OYKXkGyWp9O9ZFkbeDw
 +
 +
(ECDSA)  MD5:16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd
 +
(ED25519) MD5:33:4e:15:cf:71:07:b3:6d:62:0e:b3:7a:9e:7c:7e:13
 +
(RSA)    MD5:f0:ea:1e:85:79:e0:29:f7:de:64:7a:df:ed:c4:f4:fa
 +
</pre>
 +
 +
Please ensure you accept a valid key.
  
 
== Available software ==
 
== Available software ==
  
A list of available software can be found at [[Oprogramowanie|tutaj]].
+
A list of available software can be found [[Software|here]].
  
Access to software is provided through the [[Prometheus:Lmod|Lmod]] tool.
+
Access to software is provided through the [[Modules:en|modules]] tool.
  
 
== Partitions ==
 
== Partitions ==
Linia 35: Linia 62:
 
| '''plgrid-testing''' || 1:00:00 || For testing and preparing computations (e.g. building applications, copying files etc.)
 
| '''plgrid-testing''' || 1:00:00 || For testing and preparing computations (e.g. building applications, copying files etc.)
 
|-
 
|-
| '''plgrid-short''' || 1:00:00 || For short tasks (walltime shorter than 1h); provides an increased likelihood that tasks will be rapidly scheduled for execution
+
| '''plgrid-now''' || 12:00:00 || Recommended for interactive jobs, for testing and preparing computations (e.g. building applications, copying files etc.), with maximum limits: 1 node, 24 cores, without GPGPU nodes
 +
|-
 +
| '''plgrid-short''' || 1:00:00 || For short jobs (walltime shorter than 1h); provides an increased likelihood that your job will be quickly scheduled for execution
 +
|-
 +
| '''plgrid-long''' || 168:00:00 || For long jobs (as specified in the relevant grant)
 +
|-
 +
| '''plgrid-large''' || 24:00:00 || For jobs requiring at least 432 cores (18 full nodes); contains additional resources not available through the '''plgrid''' partition
 
|-
 
|-
| '''plgrid-long''' || 168:00:00 || For long-duration tasks (as specified in the relevant grant)
+
| '''plgrid-gpu''' || 72:00:00 || For jobs requiring GPGPU computations (note that access to GPGPU must be allowed under the relevant grant)
 
|-
 
|-
| '''plgrid-large''' || 24:00:00 || For tasks requiring at least 432 cores (18 full nodes); contains additional resources not available through the '''plgrid''' partition
+
| '''plgrid-gpu-v100''' || 12:00:00 || For jobs requiring GPGPU V100 computations (note that access to GPGPU must be allowed under the relevant grant)
 
|-
 
|-
| '''plgrid-gpu''' || 72:00:00 || For tasks requiring GPGPU computations (note that access to GPGPU must be allowed under the relevant grant)
+
| '''prace''' || 72:00:00 || Partition for [http://www.prace-ri.eu PRACE] projects
 
|-
 
|-
 
|}
 
|}
Linia 52: Linia 85:
  
 
'''Notes:'''
 
'''Notes:'''
* Selecting the right partition and specifying the expected execution time greatly increase the chances that your task will be quickly scheduled for execution. We recommend that tasks be preferentially submitted to partitions with short maximum execution times (e.g. '''plgrid-short''' where feasible).
+
* Selecting the right partition and specifying the expected execution time greatly increase the chances that your job will be quickly scheduled for execution. We recommend that jobs be preferentially submitted to partitions with short maximum execution times (e.g. '''plgrid-short''' where feasible).
* Failing to specify a partition will cause your task to be submitted to the default partition, i.e. '''plgrid'''.
+
* Failing to specify a partition will cause your job to be submitted to the default partition, i.e. '''plgrid'''.
* Tasks submitted to '''plgrid''' (or submitted without specifying a partition) may be automatically transferred to '''plgrid-large''' or '''plgrid-short''' by the queue manager, if this will cause them to be executed faster.
+
* Jobs submitted to '''plgrid''' (or submitted without specifying a partition) may be automatically transferred to '''plgrid-large''' or '''plgrid-short''' by the queue manager, if this will cause them to be executed faster.
 
* Currently, all users may access '''plgrid''', '''plgrid-testing''', '''plgrid-short''' and '''plgrid-large'''. Access to other partitions is regulated by grants and provided on a case-by-case basis in the course of evaluating proposed grants.
 
* Currently, all users may access '''plgrid''', '''plgrid-testing''', '''plgrid-short''' and '''plgrid-large'''. Access to other partitions is regulated by grants and provided on a case-by-case basis in the course of evaluating proposed grants.
 
* If you wish to access '''plgrid-long''', this must be clearly expressed in your grant application.
 
* If you wish to access '''plgrid-long''', this must be clearly expressed in your grant application.
Linia 63: Linia 96:
  
 
{| class="wikitable" style="text-align:center;"
 
{| class="wikitable" style="text-align:center;"
! Location !! Volume quota !! Files quota !! Purpose !! Access !! Throughput !! Pojemność !! Backups !! '''Support for intensive <br/> writes and/or reads''' !! Availability !! Remarks
+
! Location !! Volume quota !! Files quota !! Purpose !! Access !! Throughput !! Available space !! Backups !! '''Support for intensive <br/> writes and/or reads''' !! Availability !! Remarks
 
|-
 
|-
|<tt>$HOME</tt> || 40 GB || 1 000 000 || [[Podstawy#Katalogi_domowe|katalog domowy użytkownika]] || NFS || 1 GB/s || ∞ || yes || no || global ||
+
|<tt>$HOME</tt> || 40 GB || 1 000 000 || [[Podstawy#Katalogi_domowe|user home directory]] || NFS || 1 GB/s || ∞ || yes || no || global ||
 
|-
 
|-
|<tt>$SCRATCH</tt> || 100 TB || 1 000 000 || [[Podstawy#Przestrzeń tymczasowa|storage for temporary task data]] || Lustre || 120 GB/s || 5 PB || no || yes || global || data older than '''30 days'''<br/>will be automatically deleted
+
|<tt>$SCRATCH</tt> || 100 TB || 1 000 000 || [[Podstawy#Przestrzeń tymczasowa|storage for temporary job data]] || Lustre || 120 GB/s || 5 PB || no || yes || global || data older than '''30 days'''<br/>will be automatically deleted
 
|-
 
|-
 
| <tt>$PLG_GROUPS_STORAGE/<team_name></tt>  ||colspan="2"| grant total || Storage for PL-Grid team datasets || Lustre || 30 GB/s || 2.5 PB || no || no || global ||
 
| <tt>$PLG_GROUPS_STORAGE/<team_name></tt>  ||colspan="2"| grant total || Storage for PL-Grid team datasets || Lustre || 30 GB/s || 2.5 PB || no || no || global ||
 
|-
 
|-
|<tt>$SCRATCH_LOCAL</tt> || 512 GB || ∞ || [[Podstawy#Lokalna_przestrze.C5.84_typu_scratch|local scratch storage]] || Lustre || 120 GB/s || - || no || yes || limited to single node || unavailable following<br/>completion of task;<br/>requires '''-C localfs'''
+
|<tt>$SCRATCH_LOCAL</tt> || 768 GB || ∞ || [[Podstawy#Lokalna_przestrze.C5.84_typu_scratch|local scratch storage]] || Lustre || 120 GB/s || - || no || yes || limited to single node || unavailable following<br/>completion of job;<br/>requires '''-C localfs'''
 
|}
 
|}
  
=== Zmienne środowiskowe ===
+
=== Environmental variables ===
  
Osobiste:
+
Personal:
* $HOME, $PLG_USER_STORAGE, np. '/people/plgtestowy' - wskazuje na katalog domowy
+
* $HOME, $PLG_USER_STORAGE, eg. '/people/plgtestowy' - points to your home directory
* $PLG_USER_SCRATCH_SHARED, $SCRATCH np. '/net/scratch/people/plgtestowy/' - scratch dla użytkownika - '''tu należy trzymać dane podczas obliczeń'''
+
* $PLG_USER_SCRATCH_SHARED, $SCRATCH eg. '/net/scratch/people/plgtestowy/' - points to your private scratch storage - '''this is where data should be stored during computations'''
  
Zespołowe (do nich należy dodać nazwę zespołu):
+
Team-wide (append team name to each variable):
* PLG_GROUPS_STORAGE, PLG_GROUPS_SHARED, np. '/net/archive/groups' - wskazuje na katalog do składowania danych zespołów (dane wejściowe, wyjściowe, wymiana danych pomiędzy osobami)
+
* PLG_GROUPS_STORAGE, PLG_GROUPS_SHARED, eg. '/net/archive/groups' - points to where teams are expected to deposit their data (including input data, output data and data shared between team members)
  
=== Lokalna przestrzeń typu scratch ===
+
=== Local scratch storage ===
  
Dla obliczeń generujących bardzo dużą ilość operacji na metadanych (open/close/create/remove) możliwe jest wykorzystanie dedykowanego zasobu dyskowego typu scratch, tworzonego specjalnie na potrzeby zadania. Aby tego dokonać, podczas zlecania zadania (w momencie alokacji zasobów, tj. zanim otrzymamy numer zadania) należy podać parametr <code>-C localfs</code>.
+
For computations which require a large quantity of metadata operations (open/close/create/remove) it is possible to set up dedicated scratch storage. To do so, please supply the <code>-C localfs</code> parameter when submitting your job (i.e. at the resource allocation stage, before the job ID is assigned).
Przykładowo, w skrypcie wsadowym powinna znaleźć się dyrektywa:
+
 
 +
For example, when submitting jobs in batch mode, use the following directive:
 
<code>#SBATCH -C localfs</code>
 
<code>#SBATCH -C localfs</code>
  
Tak zlecone zadanie będzie miało do dyspozycji nowy zasób dyskowy dostępny dla użytkownika na węzłach obliczeniowych pod zmienną środowiskową '''$SCRATCH_LOCAL''' (w formacie /localfs/<numer_zadania>). Przestrzeń '''$SCRATCH_LOCAL''' przystosowana jest szczególnie dla obliczeń na małych plikach. Każdy z węzłów zadania posiada oddzielną przestrzeń '''$SCRATCH_LOCAL''' dostępną wyłącznie na czas działania zadania.
+
Any job submitted in this fashion will be assigned a separate scratch volume, available on the computational nodes and referenced by the '''$SCRATCH_LOCAL''' environmental variable (using the /localfs/<task_id> naming convention). '''$SCRATCH_LOCAL''' space is optimized for processing small files. Each computational node possesses a separate '''$SCRATCH_LOCAL''' volume, available only during execution of the given job.
  
Każdorazowo rozmiar zasobu '''$SCRATCH_LOCAL''' wynosi 512GiB na każdy zaalokowany na potrzeby zadania węzeł obliczeniowy.
+
The size of '''$SCRATCH_LOCAL''' is 768 GiB per computational node assigned to your job. Please contact the administrators if you require more scratch space.
Prosimy o kontakt w przypadku, gdyby taka wartość okazała się niewystarczająca.
 
  
'''Uwaga:''' Katalog '''$SCRATCH_LOCAL''' dostępny jest wyłącznie na węzłach obliczeniowych zaalokowanych dla zadania i tylko na czas jego trwania. Co więcej, nie jest on współdzielony między węzłami (każdy węzeł posiada osobną przestrzeń). Po zakończeniu zadania użytkownik traci dostęp do zasobu. Jeśli dane tam przechowywane są istotne, to przed zakończeniem obliczeń powinny zostać one kopiowane do katalogu grupy ($PLG_GROUPS_STORAGE/<nazwa_zespołu>) lub ewentualnie do katalogu domowego użytkownika ($HOME).
+
'''Caution:''' The '''$SCRATCH_LOCAL''' volume is available only on those computational nodes which have been allocated to your job, and only while the job is executing. Furthermore, it is not shared across nodes (i.e. each node possesses a separate volume). Following completion of your job, you will lose any data saved in '''$SCRATCH_LOCAL''' - if this data is relevant, it must first be copied to your team storage ($PLG_GROUPS_STORAGE/<team_name>) or to your home directory ($HOME).
  
=== Przestrzeń dyskowa w pamięci operacyjnej MEMFS ===
+
=== MEMFS RAM storage ===
  
W celu wykorzystania pamięci RAM do przechowywania plików tymczasowych należy  dodatkowo wyspecyfikować parametr "-C memfs” przy zlecaniu zadania.  
+
In order to allocate RAM for storage of temporary files, please add the "-C memfs” parameter to your job specification.  
Przykładowo, w skrypcie wsadowym powinna znaleźć się dyrektywa:
+
For example, use the following directive in your batch script:
 
<code>#SBATCH -C memfs</code>
 
<code>#SBATCH -C memfs</code>
  
Po uruchomieniu zadania owy zasób dyskowy dostępny dla użytkownika na węzłach obliczeniowych pod zmienną środowiskową '''$MEMFS'''. Należy pamiętać, że pamięć wykorzystywana przy zapisie na MEMFS jest liczona do pamięci zarezerwowanej dla zadania a zadeklarowanej parametrem "--mem" lub "--mem-per-cpu".
+
A storage volume will be set up for your job, referenced by the '''$MEMFS''' environmental variable. Please note that memory allocated to MEMFS storage counts towards the total memory allocated for your job and declared through "--mem" or "--mem-per-cpu".
  
'''Uwaga:''' Przy wykorzystaniu pamięci operacyjnej jako zasobu dyskowego MEMFS należy pamiętać, że:
+
'''Caution:''' When using MEMFS for file storage, be aware of the following limitations:
* metodę tą można stosować tylko dla zadań jednowęzłowych
+
* this method is only available for single-node jobs
* należy pamiętać, że zużycie pamięci przez zadanie łącznie z pamięcią wykorzystywną w MEMFS nie może przekraczać pamięci zadeklarowanej parametrem "--mem" lub "--mem-per-cpu".
+
* the total amount of memory consumed by your job, including any MEMFS storage, must not exceed the value declared through "--mem" or "--mem-per-cpu".
* metodę tą można stosować jedynie gdy całościowe zapotrzebowania zadania na dyski oraz pamięć nie przekracza całości dostępnej pamięci węzła (dla normalnych węzłów Prometheusa 120GB)
+
* this method may only be used if the total memory requirements of your job (including MEMFS storage) do not exceed the memory available on a single node (120 GB per standard Prometheus node).
* najlepiej przeprowadzać obliczenia w trybie pełnowęzłowym.
+
* when using MEMFS, it is recommended to request allocation of a full node for your job.
  
== Uruchamianie zadań ==
+
== Running jobs ==
  
Zlecanie zadań na klastrze Prometheus odbywa się poprzez system kolejkowy SLURM.
+
The SLURM scheduling system is used to manage jobs on the Prometheus cluster.
  
Zadanie może być zlecone zarówno w trybie wsadowym jak i w trybie interaktywnym.
+
A job may be executed in batch or interactive mode.
  
'''<span style="color: crimson">Przed uruchomieniem zadań zapoznaj się z informacjami o [[System_Grant%C3%B3w|systemie grantów]]</span>'''
+
'''<span style="color: crimson">Before running any jobs, please familiarize yourself with the [[System_Grant%C3%B3w|grant system]]</span>'''
  
=== Tryb wsadowy ===
+
=== Batch mode ===
  
Do zlecania zadania w trybie wsadowym służy komenda <tt>sbatch</tt>.
+
To run a job in batch mode, use the <tt>sbatch</tt> command.
Użycie komendy:
+
Usage:
<code>sbatch skrypt.sh</code>.<br/>
+
<code>sbatch script.sh</code>.<br/>
Wszystkie opcje należy poprzedzić dyrektywą '''#SBATCH''' (koniecznie ze znakiem #).<br/>
+
All scheduler options should be preceded by the '''#SBATCH''' keyword (do not forget the #!).<br/>
Szczegółowe informacje: <code>man sbatch</code> oraz <code>sbatch --help</code>.
+
For more information see: <code>man sbatch</code> and <code>sbatch --help</code>.
  
'''Przykładowy skrypt:'''
+
'''Sample script:'''
  
'''<span style="color: crimson">UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.</span>'''
+
'''<span style="color: crimson">CAUTION! This sample script is provided as a reference and SHOULD NOT be executed as is. Before running any jobs, make sure that the scheduler options accurately reflect your requirements e.g. with regard to grant ID, partition name, execution time etc.</span>'''
  
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
#!/bin/bash -l
 
#!/bin/bash -l
## Nazwa zlecenia
+
## Job name
 
#SBATCH -J ADFtestjob
 
#SBATCH -J ADFtestjob
## Liczba alokowanych węzłów
+
## Number of allocated nodes
 
#SBATCH -N 1
 
#SBATCH -N 1
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
+
## Number of tasks per node (by default this corresponds to the number of cores allocated per node)
 
#SBATCH --ntasks-per-node=1
 
#SBATCH --ntasks-per-node=1
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
+
## Memory allocated per core (default is 5GB)
 
#SBATCH --mem-per-cpu=1GB
 
#SBATCH --mem-per-cpu=1GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
+
## Max task execution time (format is HH:MM:SS)
 
#SBATCH --time=01:00:00  
 
#SBATCH --time=01:00:00  
## Nazwa grantu do rozliczenia zużycia zasobów
+
## Name of grant to which resource usage will be charged
 
#SBATCH -A <grant_id>
 
#SBATCH -A <grant_id>
## Specyfikacja partycji
+
## Name of partition
 
#SBATCH -p plgrid-testing
 
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
+
## Name of file to which standard output will be redirected
 
#SBATCH --output="output.out"
 
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
+
## Name of file to which the standard error stream will be redirected
 
#SBATCH --error="error.err"
 
#SBATCH --error="error.err"
  
 
+
## change to sbatch working directory
## przejscie do katalogu z ktorego wywolany zostal sbatch
 
 
cd $SLURM_SUBMIT_DIR
 
cd $SLURM_SUBMIT_DIR
  
Linia 161: Linia 193:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
==== Zadania wykorzystujące MPI ====
+
==== MPI jobs ====
  
Uruchamianie zadań MPI na Prometheuszu wygląda podobnie jak uruchamianie takich zadań na innych klastrach wyposażonych w system kolejkowy SLURM integrujący się z bibliotekami MPI. W przypadku Prometheusa dostępne są różne wersje bibliotek MPI (najczęściej OpenMPI i IntelMPI) dla większości dostępnych kompilatorów. Podczas uruchamiania aplikacji proszę nie podawać explicite parametru <code>-n</code> lub <code>-np</code> system dobierze odpowiednie wartości na podstawie parametrów alokacji (umieszczonych w skrypcie startowym) i zostaną one zastosowane. W uzasadnionych przypadkach, gdzie aplikacja wymaga specyficznej konfiguracji (np. lokalne wątkowanie), można podać wspomniane parametry.
+
Running MPI jobs on Prometheus is similar to running them on other SLURM clusters with integrated MPI libraries. Prometheus provides various versions of MPI libraries (mostly OpenMPI and IntelMPI) for a variety of popular compilers. When running MPI jobs, the <code>-n</code> and <code>-np</code> scheduler options should not be explicitly specified - instead, the system will select optimal values based on allocation parameters expressed in the startup script. Usage of <code>-n</code> and <code>-np</code> should be restricted to exceptional cases which call for nonstandard configurations (e.g. local threading).
  
'''<span style="color: crimson">UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.</span>'''
+
'''<span style="color: crimson">CAUTION! This sample script is provided as a reference and SHOULD NOT be executed as is. Before running any jobs, make sure that the scheduler options accurately reflect your requirements e.g. with regard to grant ID, partition name, execution time etc.</span>'''
  
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
#!/bin/bash -l
 
#!/bin/bash -l
## Nazwa zlecenia
+
## Job name
 
#SBATCH -J MPITest
 
#SBATCH -J MPITest
## Liczba alokowanych węzłów
+
## Number of allocated nodes
 
#SBATCH -N 2
 
#SBATCH -N 2
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
+
## Number of tasks per node (by default this corresponds to the number of cores allocated per node)
 
#SBATCH --ntasks-per-node=24
 
#SBATCH --ntasks-per-node=24
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
+
## Memory allocated per core (default is 5GB)
 
#SBATCH --mem-per-cpu=5GB
 
#SBATCH --mem-per-cpu=5GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
+
## Max task execution time (format is HH:MM:SS)
 
#SBATCH --time=01:00:00  
 
#SBATCH --time=01:00:00  
## Nazwa grantu do rozliczenia zużycia zasobów
+
## Name of grant to which resource usage will be charged
 
#SBATCH -A <grant_id>
 
#SBATCH -A <grant_id>
## Specyfikacja partycji
+
## Name of partition
 
#SBATCH -p plgrid-testing
 
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
+
## Name of file to which standard output will be redirected
 
#SBATCH --output="output.out"
 
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
+
## Name of file to which the standard error stream will be redirected
 
#SBATCH --error="error.err"
 
#SBATCH --error="error.err"
  
 
srun /bin/hostname
 
srun /bin/hostname
  
## Zaladowanie modulu IntelMPI
+
## Load the IntelMPI module
 
module add plgrid/tools/impi
 
module add plgrid/tools/impi
  
## przejscie do katalogu z ktorego wywolany zostal sbatch
+
## change to sbatch working directory
 
cd $SLURM_SUBMIT_DIR
 
cd $SLURM_SUBMIT_DIR
  
Linia 199: Linia 231:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
Dobrą praktyką jest kompilowanie i uruchamianie aplikacji przy pomocy środowiska budowanego tym samym zestawem modułów. Zalecamy korzystanie z wrappera <code>mpiexec</code>. Wielkość alokacji, w tym przypadku 2 węzły po 24 rdzenie, przekłada się bezpośrednio na 48 tasków dostępnych dla aplikacji korzystającej z MPI. Dopuszczalne jest uruchomienie serii aplikacji MPI w jednym skrypcie, ale najczęściej, ze względu na długi czas wykonania, nie jest to optymalny sposób prowadzenia obliczeń. Niedopuszczalne jest jednoczesne uruchomienie wielu aplikacji MPI w ramach jednej alokacji, taka praktyka prowadzi do kłopotówzwiązanych z alokacją zasobów na wyłączność dla danej aplikacji.
+
It is considered good practice to compile and execute applications in an environment comprising the same set of modules. We recommend using the <code>mpiexec</code> wrapper. Computational resource allocation - in this case 2 nodes, 24 cores each - results in 48 MPI tasks available for execution. It is permissible to run a series of MPI applications with a single script, but given their execution time (which is usually long) this approach is discouraged. Running multiple MPI applications in parallel within a single allocation is not allowed due to resource contention issues.
  
==== Proste zrównoleglenie wielu niezależnych zadań ====
+
==== Simple parallelization of independent tasks ====
  
Dość częstym przypadkiem użycia klastra jest przetworzenie wielu paczek danych, gdzie każda paczka jest przetwarzana niezależnie. Dobrym przykładem takich zadań jest przetwarzanie wielu obrazów w ten sam sposób. SLURM umożliwia proste zrównoleglenie takiego przetwarzania poprzez użycie komendy '''srun'''. Przykładowy skrypt, który zrównolegli uruchomienie wielu instancji obliczeń, gdzie stopień równoległości jest ustalany na podstawie parametrów zadania, znajduje się poniżej:
+
Parallel processing is a typical use case scenario for computing clusters. One representative example involves processing multiple images with a shared algorithm. SLURM provides a way to easily parallelize such tasks with the '''srun''' command. A sample script which runs multiple computations in parallel (depending on their specifications) is provided below.
  
'''<span style="color: crimson">UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.</span>'''
+
'''<span style="color: crimson">CAUTION! This sample script is provided as a reference and SHOULD NOT be executed as is. Before running any jobs, make sure that the scheduler options accurately reflect your requirements e.g. with regard to grant ID, partition name, execution time etc.</span>'''
  
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
#!/bin/bash -l
 
#!/bin/bash -l
## Nazwa zlecenia
+
## Job name
 
#SBATCH -J testjob
 
#SBATCH -J testjob
## Liczba alokowanych węzłów
+
## Number of allocated nodes
 
#SBATCH -N 2
 
#SBATCH -N 2
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
+
## Number of tasks per node (by default this corresponds to the number of cores allocated per node)
 
#SBATCH --ntasks-per-node=24
 
#SBATCH --ntasks-per-node=24
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
+
## Memory allocated per core (default is 5GB)
 
#SBATCH --mem-per-cpu=5GB
 
#SBATCH --mem-per-cpu=5GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
+
## Max task execution time (format is HH:MM:SS)
 
#SBATCH --time=01:00:00  
 
#SBATCH --time=01:00:00  
## Nazwa grantu do rozliczenia zużycia zasobów
+
## Name of grant to which resource usage will be charged
 
#SBATCH -A <grant_id>
 
#SBATCH -A <grant_id>
## Specyfikacja partycji
+
## Name of partition
 
#SBATCH -p plgrid-testing
 
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
+
## Name of file to which standard output will be redirected
 
#SBATCH --output="output.out"
 
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
+
## Name of file to which the standard error stream will be redirected
 
#SBATCH --error="error.err"
 
#SBATCH --error="error.err"
  
 
module load plgrid/tools/imagemagick
 
module load plgrid/tools/imagemagick
  
## przejscie do katalogu z ktorego wywolany zostal sbatch
+
## change to sbatch working directory
 
cd $SLURM_SUBMIT_DIR
 
cd $SLURM_SUBMIT_DIR
  
Linia 236: Linia 268:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
Powyższy skrypt dla każdego pliku *tif w katalogu uruchomi aplikację <code>mogrify</code>, tak aby skonwertować obraz do pliku png. Pierwszą czynnością jest wylistowanie plików wejściowych, następnie wynik jest przekazywany do komendy <code>xargs</code>, która przez parametr '''-P''' zapewnia równoległe uruchomienie dalszego polecania <code>srun</code>. Do każdej instancji <code>srun</code> zostanie przekazany jeden parametr, maksymalna równoległość wyniesie '''${SLURM_NTASKS}'''. Każdy <code>srun</code> uruchomi aplikację <code>mogrify</code> na jednym rdzeniu z przydzielonym 5GB pamięci.  
+
The above script runs the <code>mogrify</code> application for each *tif file in the working directory, converting the image to the png format. We begin by listing all input files, and feed the output into the <code>xargs</code> command, which (through the '''-P''' flag) ensures parallel execution of each subsequent <code>srun</code> instance. Each instance is supplied with a single input parameter, with the maximum level of parallelism defined as '''${SLURM_NTASKS}'''. Thus, each invocation of <code>srun</code> runs the <code>mogrify</code> application on a single core, with 5GB of assigned memory.
  
=== Tryb interaktywny ===
+
=== Interactive mode ===
  
Do zlecania zadań w trybie interaktywnym z powłoką służy komenda (przykład):
+
To run shell commands in interactive mode, use the following (sample) command:
 
<code>srun -p plgrid-testing -N 1 --ntasks-per-node=1 -n 1 -A <grant_id> --pty /bin/bash -l</code>
 
<code>srun -p plgrid-testing -N 1 --ntasks-per-node=1 -n 1 -A <grant_id> --pty /bin/bash -l</code>
Powyższa komenda uruchomi zadanie w partycji plgrid-testing na 1 węźle z alokacją 1 rdzenia.
 
  
Samo polecenie <tt>srun</tt> odpowiada za uruchomienie komendy w ramach zaalokowanych zasobów.<br>
+
This will run a job in the plgrid-testing partition, on a single node, using a single core.
Jednak w przypadku, gdy zasoby nie zostały wcześniej zaalokowane, komenda ta uprzednio dokonuje ich rezerwacji tuż przed uruchomieniem obliczeń.
+
 
 +
The <tt>srun</tt> command is typically used to execute the specified operation on the assigned resources.<br> However, if resources have not been allocated in advance, <tt>srun</tt> also takes care of performing the allocation.
  
'''<span style="color: crimson">UWAGA: Tryb graficzny (poprzez protokół X11) dostępny jest jedynie na maszynie dostępowej klastra Prometheus. </span>'''
+
'''<span style="color: crimson">CAUTION: Graphic mode (using X11) is only available on the Prometheus access host. </span>'''
  
=== Zadania tablicowe ===
+
=== Array jobs ===
  
Zadania tablicowe to mechanizm pozwalający na zlecanie dużej ilości zadań wsadowych, które są do siebie podobne. Zadania tablicowe posiadają swój indeks, dostępny jako zmienną środowiskowa '''$SLURM_ARRAY_TASK_ID''' wewnątrz zadania, dzięki któremu można odpowiednio parametryzować uruchamianą aplikację. Sposób zlecania zadania jest analogiczny jak w przypadku zwykłych zadań wsadowych, a przykładowy skrypt zawierający parametr <code>--array</code> <code>-a</code>, definiujący zakres indeksów, wygląda następująco:
+
Array jobs provide a way to schedule large numbers of similar coputational tasks. Each instance of an array job is assigned an index referenced by the '''$SLURM_ARRAY_TASK_ID''' environmental variable, which can be used to parameterize the given instance. Submitting array jobs is similar to submitting ordinary batch jobs. The following sample script submits an array job with the task ID range defined by
 +
the <code>--array</code> (or <code>-a</code>) scheduler option:
  
'''<span style="color: crimson">UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.</span>'''
+
'''<span style="color: crimson">CAUTION! This sample script is provided as a reference and SHOULD NOT be executed as is. Before running any jobs, make sure that the scheduler options accurately reflect your requirements e.g. with regard to grant ID, partition name, execution time etc.</span>'''
  
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
#!/bin/bash -l
 
#!/bin/bash -l
## Nazwa zlecenia
+
## Job name
 
#SBATCH -J testjob
 
#SBATCH -J testjob
## Liczba alokowanych węzłów
+
## Number of allocated nodes
 
#SBATCH -N 1
 
#SBATCH -N 1
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
+
## Number of tasks per node (by default this corresponds to the number of cores allocated per node)
 
#SBATCH --ntasks-per-node=1
 
#SBATCH --ntasks-per-node=1
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
+
## Memory allocated per core (default is 5GB)
#SBATCH --mem-per-cpu=1GB
+
#SBATCH --mem-per-cpu=5GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
+
## Max task execution time (format is HH:MM:SS)
 
#SBATCH --time=01:00:00  
 
#SBATCH --time=01:00:00  
## Nazwa grantu do rozliczenia zużycia zasobów
+
## Name of grant to which resource usage will be charged
 
#SBATCH -A <grant_id>
 
#SBATCH -A <grant_id>
## Specyfikacja partycji
+
## Name of partition
 
#SBATCH -p plgrid-testing
 
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
+
## Name of file to which standard output will be redirected
 
#SBATCH --output="output.out"
 
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
+
## Name of file to which the standard error stream will be redirected
 
#SBATCH --error="error.err"
 
#SBATCH --error="error.err"
## Parametr wyznaczający indeksy zadania tablicowego
+
## Array index range
 
#SBATCH --array=0-100
 
#SBATCH --array=0-100
  
## przejscie do katalogu z ktorego wywolany zostal sbatch
+
## change to sbatch working directory
 
cd $SLURM_SUBMIT_DIR
 
cd $SLURM_SUBMIT_DIR
  
Linia 285: Linia 318:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
=== Zadania wykorzystujące GPGPU ===
+
=== GPGPU jobs ===
 +
 
 +
==== Accessing GPGPU nodes ====
 +
 
 +
A special partition named '''plgrid-gpu''' has been set up for jobs which require access to GPGPU hardware. In order to schedule such jobs, it is first necessary to obtain a grant specifically dedicated to GPGPU processing. This grant should not be used to run any other types of computational tasks.
  
==== Dostęp do węzłów z GPGPU ====
+
When applying for your grant, please specify that you require access to '''plgrid-gpu'''. It is also recommended (although not strictly required) to put '''gpu''' in your grant name (e.g. '''gpucomputations''') - this will help prevent potential mix-ups.
  
Dla zadań korzystających w obliczeniach z kart GPGPU przeznaczona została specjalna partycja -  '''plgrid-gpu'''.
+
All applications for access to '''plgrid-gpu''' are evaluated on a case-by-case basis by the resource provider.
Aby móc przeprowadzać obliczenia z wykorzystaniem GPGPU konieczne jest złożenie wniosku o grant właściwy, który przeznaczony zostanie w całości wyłącznie na obliczenia z wykorzystaniem kart GPGPU. Grant taki nie powinien być używany do przeprowadzania obliczeń w partycjach innych niż '''plgrid-gpu'''.
 
We wniosku o grant należy wyraźnie zaznaczyć, że wymagany jest dostęp do partycji '''plgrid-gpu'''. Zalecane jest także (ale nie jest to konieczne), aby grant taki posiadał w nazwie wyraz '''gpu''' (np. obliczeniagpu) - ułatwia to identyfikację grantów.
 
Każdy wniosek o dostęp do partycji '''plgrid-gpu''' jest rozpatrywany indywidualnie przez dostawcę zasobów.
 
  
==== Informacje ogólne ====
+
==== General information ====
  
Karty GPU w systemie kolejkowym SLURM są rodzajem tzw. generic resources (GRES), a ich identyfikatorem jest "gpu".<br/>
+
The SLURM scheduler treats GPUs as generic resources (GRES) identified by the "gpu" codeword.<br/> You can find out which nodes/partitions provide such resources by using the <tt>sinfo</tt> command:
Informację o tym na których węzłach/partycjach znajdują się karty GPU można otrzymać np. przy pomocy komendy <tt>sinfo</tt>:
 
  
 
<code>sinfo -o '%P || %N || %G'</code>
 
<code>sinfo -o '%P || %N || %G'</code>
  
Zlecanie zadań odbywa się poprzez podanie opcji <code>--partition=plgrid-gpu --gres=gpu[:count]</code> systemu kolejkowego.<br/>
+
Jobs are submitted by adding <code>--partition=plgrid-gpu --gres=gpu[:count]</code> to your list of scheduler options. If the <tt>count</tt> argument is omitted, the system will default to allocating a single GPU adapter per processing node.
W przypadku gdy nie ma podanej opcji <tt>count</tt>, system kolejkowy domyślnie alokuje jedną kartę na węźle obliczeniowym.
 
  
Po zleceniu zadania system kolejkowy automatycznie ustawia zmienną środowiskową <tt>$CUDA_VISIBLE_DEVICES</tt> oraz zezwala na dostęp do zaalokowanych do kart.
+
Following submission of your job, the scheduler automatically sets the <tt>$CUDA_VISIBLE_DEVICES</tt> environmental variable and permits access to allocated GPUs.
  
==== Zadania interaktywne ====
+
==== Interactive jobs ====
  
Przykładowo, gdy chcemy uruchomić zadanie interaktywne na jednym serwerze i zażądać 2 kart GPU:
+
For example, to run a single-node interactive job with 2 GPUs, type:
  
 
<code>srun -p plgrid-gpu -N 1 -n 24 -A <grant_id> --gres=gpu:2 --pty /bin/bash -l</code>
 
<code>srun -p plgrid-gpu -N 1 -n 24 -A <grant_id> --gres=gpu:2 --pty /bin/bash -l</code>
  
==== Zadania interaktywne MPI ====
+
==== Interactive MPI jobs ====
  
Uwaga! Wyjątkiem jest uruchamianie interaktywnych aplikacji MPI (np. w celach testów). Z powodu nieco innej obsługi kart GPU niż zwykłych procesorów przez system SLURM, uruchomienie zadania interaktywnego wymaga niestandardowej procedury.
+
Caution: running interactive MPI jobs (e.g. for testing) is a special case. Due to the fact that SLURM treats GPUs differently than general-purpose processors, launching interactive computations calls for a nonstandard procedure.
  
Przykładowo, gdy chcemy uruchomić zadanie interaktywne na dwóch serwerach i zażądać 2 kart GPU na każdym z nich (łącznie 4 karty GPU) na czas 1 godziny:
+
For example, to run an interactive job on 2 nodes with 2 GPUs per node (4 GPUs total) for 1 hour, specify the following:
  
 
<code>salloc -p plgrid-gpu -N 2 --ntasks-per-node 24 -n 48 -A <grant_id> --gres=gpu:2 --time 1:00:00</code>
 
<code>salloc -p plgrid-gpu -N 2 --ntasks-per-node 24 -n 48 -A <grant_id> --gres=gpu:2 --time 1:00:00</code>
  
Polecenie salloc zaalokowało nasze zadanie i zwróciło jego numer, przykładowo 1234.
+
The <tt>salloc</tt> command allocates our job and returns its ID - for example, 1234.
  
Następnie uruchamiamy srun wymagając 0 kart GPU w zadaniu o numerze zwróconym przez salloc:
+
Next, we use <tt>srun</tt> requesting 0 GPUs for the job whose ID was returned by <tt>salloc</tt>:
  
 
<code>srun --jobid=1234 --gres=gpu:0 -O --pty /bin/bash -l</code>
 
<code>srun --jobid=1234 --gres=gpu:0 -O --pty /bin/bash -l</code>
  
Otrzymaliśmy dostęp do powłoki na jednym z węzłów, teraz po załadowaniu odpowiedniego modułu MPI można już uruchomić własną aplikację za pomocą mpirun lub mpiexec. Isotne jest aby podczas uruchamiania aplikacji nie przekazywać zmiennych środowiska, czyli w przypadku IntelMPI należy dodać parametr <code>-genvnone</code>Aplikacja będzie miała dostęp do wszystkich kart GPU zaalokowanych w komendzie salloc, niezależnie od wymagania gpu:0 użytego w srun.
+
This gives us shell access on one of the computing nodes. Now, after loading the appropriate MPI module, we may run our actual application via <tt>mpirun</tt> or <tt>mpiexec</tt>. It is important to avoid exporting environmental settings - e.g., when using IntelMPI, remember to specify the <code>-genvnone</code> flag. The application will retain access to all GPUs allocated via <tt>salloc</tt> regardless of the <tt>gpu:0</tt> parameter in <tt>srun</tt>.
  
Po zakończeniu testów należy usunąć alokację za pomocą:
+
Once the computation has concluded, the allocation should be manually cleared by typing:
  
 
<code>scancel 1234</code>
 
<code>scancel 1234</code>
  
==== Zadania wsadowe ====
+
==== Batch jobs ====
  
Dla skryptu wsadowego dodatkowe zmiany nie są potrzebne, przykładowo gdy żądamy po jednej karcie na węzeł obliczeniowy, wystarczy dopisać do skryptu:
+
No special procedure is required for batch jobs. For example, to request one GPU adapter per computing node, simply add the following to your script:
  
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
Linia 341: Linia 373:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
 +
'''Note:''' Further details regarding SLURM commands may be obtained by typing <code> man sbatch</code>
  
'''Uwaga:''' Wszelkie informacje na temat komend SLURMa można znaleźć w manualu, np.: <code> man sbatch</code>
+
== Monitoring queues, partitions, nodes, jobs and resources ==
 
 
== Monitorowanie kolejek, partycji, węzłów, zadań i zasobów ==
 
 
 
*; Sktypty specyficzne dla Prometheusa
 
** '''[[Prometheus:pro-jobs|pro-jobs]]''' - statystyki dla zakolejkowanych lub już uruchomionych zadań użytkownika
 
** '''[[Prometheus:pro-jobs-history|pro-jobs-history]]''' - statystyki dla zakończonych zadań użytkownika
 
** '''[[Prometheus:pro-fs|pro-fs]]''' - statystyki użycia zasobów dyskowych przez użytkownika
 
** '''[[Prometheus:pro-groupdir-fix|pro-groupdir-fix]]''' - korekcja uprawnień danych w katalogu zespołu
 
** '''pro-grant-jobs''' - lista zadań w ramach grantów użytkownika (zawiera także zadania innych członków grup grantowych użytkownika)
 
 
 
 
 
*; Narzędzia systemu SLURM
 
**<code>squeue</code> - lista aktualnie zakolejkowanych/uruchomionych zadań
 
**<code>scontrol show job [<ID_zadania>]</code> - szczegóły zadania
 
**<code>sstat -a -j <ID_zadania>/<ID_zadania.batch></code> - zużycie zasobów w ramach kroków (step) działającego zadania
 
**<code>scancel <ID_zadania></code> - usunięcie zadania (działającego lub zakolejkowanego)
 
**<code>sacct</code> - zużycie zasobów zakończonego już zadania/kroku
 
**<code>scontrol show partition [<nazwa_partycji>]</code> - właściwości partycji
 
**<code>sinfo</code> - lista węzłów
 
**<code>scontrol show node [<nazwa_węzła>]</code> - właściwości węzła
 
 
 
<!-- == Opis właściwości węzłów obliczeniowych == -->
 
<!-- == Sposób korzystania z sieci Infiniband == -->
 
 
 
== Przenoszenie danych z klastra Zeus ==
 
 
 
Klastry Zeus i Prometheus nie współdzielą żadnych zasobów dyskowych, w związku z tym, aby korzystać z danych zgromadzonych na Zeusie, należy je najpierw skopiować. W tym celu możemy posłużyć się komendami:
 
* <code>scp</code> - w przypadku małych plików (używa loginu i hasła),
 
* <code>globus-url-copy</code> - w przypadku dużych plików (używa loginu i hasła LUB grid proxy),
 
* <code>uberftp</code> - w przypadku dużych plików, interaktywnie (używa grid proxy).
 
 
 
 
 
Podstawowe informacje o komendzie globus-url-copy:
 
* składnia: <code>globus-url-copy ŻRÓDŁO CEL</code>, gdzie źródło i cel poprzedzone są nazwą protokołu: np. <code>file://</code>,
 
* aby pobrać pliki z zeusa używamy 2 protokołów:
 
** gsiftp - <code>gsiftp://zeus.cyfronet.pl/</code> - uwierzytelnianie za pomocą proxy (musimy najpierw stworzyć grid proxy komendą <code>grid-proxy-init</code>),
 
** sshftp - <code>sshftp://zeus.cyfronet.pl/</code> - uwierzytelnianie hasłem PLGrid,
 
* uwierzytelnianie proxy pozwala uruchamiać wiele transferów bez podawania hasła za każdym razem,
 
* protokół docelowy to <code>file://</code> czyli plik/katalog lokalny,
 
* dla ŻRÓDŁA i CELU musimy podać pełną ścieżkę pliku lub możemy użyć skrótu w postaci <code>~plgLOGIN</code> do naszego katalogu domowego,
 
* dla CELU (czyli protokołu <code>file://</code>) możemy podać też zmienne środowiskowe np. <code>$PWD</code> - bieżący katalog,
 
* w przypadku CELU gdy podamy nazwę pliku np. <code>$PWD/nazwa.txt</code>, plik zapisze się pod daną nazwą, a gdy podamy tylko katalog, to plik zapisze się pod taką samą nazwą jak źródłowy,
 
* aby przesyłać całe katalogi, należy je najpierw spakować komendą <code>tar -czf archiwum.tar katalog</code>,
 
* w przypadku gdy nasz login na klastrze Prometheus różni się od tego na klastrze Zeus możemy użyć wyłącznie protokołu "sshftp://" a do ŹRÓDŁA należy dodać login na klastrze Zeus np. <code>sshftp://MOJ_USERNAME@zeus.cyfronet.pl/</code>.
 
 
 
  
Przykład użycia komendy <code>globus-url-copy</code>:
+
*; Dedicated Prometheus scripts
* skopiuj z katalogu domowego użytkownika plgLOGIN na klastrze Zeus, do bieżącego katalogu plik "bigfile.txt" i nadaj mu tą samą nazwę:
+
** '''[[Prometheus:pro-jobs|pro-jobs]]''' - lists jobs queued by or running for the current user
<pre>globus-url-copy sshftp://zeus.cyfronet.pl/~plgLOGIN/bigfile.txt file://$PWD/</pre>
+
** '''[[Prometheus:pro-jobs-history|pro-jobs-history]]''' - lists completed jobs for the current user
* skopiuj plik "/mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt" z klastara Zeus do bieżącego katalogu:
+
** '''[[Prometheus:pro-fs|pro-fs]]''' - returns disk usage statistics for the current user
<pre>globus-url-copy sshftp://zeus.cyfronet.pl//mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt file://$PWD/</pre>
+
** '''[[Prometheus:pro-groupdir-fix|pro-groupdir-fix]]''' - used to adjust access permissions for the team data directory
* j.w. ale z podanym loginem z klastra Zeus (domyślnie używany jest taki sam użytkownik na jakiego jesteśmy zalogowani)
+
** '''pro-grant-jobs''' - lists jobs scheduled under the user's active grants (including jobs whch belong to other users sharing these grants)
<pre>globus-url-copy sshftp://MOJ_USERNAME@zeus.cyfronet.pl//mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt file://$PWD/</pre>
 
  
 +
*; SLURM system commands
 +
**<code>squeue</code> - list of currently queued/running jobs
 +
**<code>scontrol show job [<job_ID>]</code> - details of a given job
 +
**<code>sstat -a -j <job_ID>/<job_ID.batch></code> - resource consumption for each step of a currently running job
 +
**<code>scancel <job_ID></code> - cancel a queued or running job
 +
**<code>sacct</code> - resource consumption for jobs/steps which have already been completed
 +
**<code>scontrol show partition [<partition_name>]</code> - details of a given partition
 +
**<code>sinfo</code> - list of nodes
 +
**<code>scontrol show node [<node_name>]</code> - details of a given node
  
Odnośniki do dodatkowych pomocy/dokumentacji:
+
<!-- == Properties of computing nodes == -->
* scp:
+
<!-- == Using the Infiniband network == -->
** http://linux.die.net/man/1/scp
 
* globus-url-copy:
 
** http://linux.die.net/man/1/globus-url-copy
 
** http://toolkit.globus.org/toolkit/docs/4.0/data/gridftp/rn01re01.html
 
* uberftp:
 
** http://linux.die.net/man/1/uberftp
 
** https://twiki.opensciencegrid.org/bin/view/Documentation/StorageUberFtp
 
* grid-proxy-init
 
** http://linux.die.net/man/1/grid-proxy-init
 
** http://toolkit.globus.org/toolkit/docs/4.0/security/prewsaa/rn01re05.html
 
  
== Zasady obowiązujące na klastrze Prometheus ==
+
== General rules for using the Prometheus cluster ==
  
* Obliczenia wykonywane na maszynie dostępowej będą usuwane bez ostrzeżenia. Maszyna dostępowa powinna służyć wyłącznie do przygotowywania plików wejściowych obliczeń i do ich zlecania na klaster za pośrednictwem systemu kolejkowego. Kopiowanie dużych ilości danych również może w znacznym stopniu obciążać maszynę dostępową, dlatego też zaleca się, aby kopiowanie przeprowadzać na węźle obliczeniowym (w zadaniu interaktywnym, np. <code>srun -p plgrid -A grant_id -n 1 --pty /bin/bash -l</code>). Podobnie jest z kompilacją programów - ją również należy wykonywać na węźle obliczeniowym, a nie bezpośrednio na maszynie dostępowej.
+
* Any computations launched on the access host will be killed without notice. The access host should only be used to prepare input files and submitting jobs to the scheduler. Since transferring large quantities of data may cause significant load on the access host, it is recommended to allocate a computing node for this purpose (in interactive mode, e.g. <code>srun -p plgrid -A grant_id -n 1 --pty /bin/bash -l</code>).  
* Obliczenia wykraczające poza zakres deklarowanego tematu badań zużywające znaczną część zasobów klastra będą usuwane bez ostrzeżenia.
+
* Compiling applications - this should be performed '''on a computing''' node, '''not''' on the '''access''' host (in interactive mode, e.g. <code>srun -p plgrid -A grant_id -n 1 --pty /bin/bash -l</code>).
* Dane obliczeniowe należy składować i przetwarzać na systemie plików Lustre pod lokalizacją $SCRATCH.
+
* Computations which are out of scope of the submitted research agenda or which consume a large fraction of the cluster's resources will be killed without notice.
* W obliczeniach '''nie''' należy korzystać z katalogu /tmp, do przechowywania plików tymczasowych należy wykorzystywać katalogi znajdujące się pod zmiennymi $SCRATCH, $SCRATCHDIR lub $TMPDIR.
+
* Working datasets and intermediate results should be stored and processed in the Lustre filesystem available under $SCRATCH.
* Na maszynie dostępowej ustawiony jest limit pamięciowy 6 GiB dla sumy wszystkich procesów danego użytkownika. Próba przekroczenia limitu powoduje automatyczne zabicie procesu próbującego przekroczyć ustalony limit.
+
* Computations '''should not''' make use of the /tmp directory to store temporary data - instead, please use directories referenced by $SCRATCH, $SCRATCHDIR or $TMPDIR.
 +
* The access host imposes a 6GB memory limit for all processes belonging to the current user. Exceeding this limit will cause the offending process to be automatically killed.
  
== Kontakt ==
+
== Contact ==
Pomoc dla użytkowników [http://www.plgrid.pl PL-Grid]: [https://helpdesk.plgrid.pl/ Helpdesk PL-Grid] <br /> Kontakt z administratorami: [mailto:prometheus@cyfronet.pl prometheus@cyfronet.pl], +48 12 632 33 55 w. 603
+
Assistance for [http://www.plgrid.pl PL-Grid] users is available at: [https://helpdesk.plgrid.pl/ Helpdesk PLGrid] <br /> System administrators may be contacted by e-mail at: [mailto:prometheus@cyfronet.pl prometheus@cyfronet.pl], or by phone at +48 12 632 33 55 int. 603.

Aktualna wersja na dzień 15:17, 2 lip 2021


Logging in

Access to the Prometheus cluster is facilitated by the access host at:

prometheus.cyfronet.pl (alias for the following hosts):

login01.prometheus.cyfronet.pl
login02.prometheus.cyfronet.pl

eg.

ssh <plgtestowy>@prometheus.cyfronet.pl

You can also use the short alias pro.cyfronet.pl

Login node Description
prometheus.cyfronet.pl
pro.cyfronet.pl
Default login node for PLGrid users
prace.pro.cyfronet.pl Dedicated login node for PRACE users
prace-int.pro.cyfronet.pl Alias of PRACE login node within PRACE internal network

An SSH client is required for login.

SSH fingerprints:

 (ECDSA)   SHA256:tKk4RpOzWSTf+H8oN7COX1o5xMGSX7vMk956oHcdSB8
 (ED25519) SHA256:roerSF6HBUEqJpoPk36BXwz7NsPRIrTguoApYoYK+ro
 (RSA)     SHA256:v/iUvEh8faHN7IoZ5Vpm0kU6OYKXkGyWp9O9ZFkbeDw

 (ECDSA)   MD5:16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd
 (ED25519) MD5:33:4e:15:cf:71:07:b3:6d:62:0e:b3:7a:9e:7c:7e:13
 (RSA)     MD5:f0:ea:1e:85:79:e0:29:f7:de:64:7a:df:ed:c4:f4:fa

Please ensure you accept a valid key.

Available software

A list of available software can be found here.

Access to software is provided through the modules tool.

Partitions

SLURM replaces PBS queues with the concept of partitions. The following paritions are currently available for Prometheus users:

Parition name Max task
duration
Description
plgrid 72:00:00 Default partition
plgrid-testing 1:00:00 For testing and preparing computations (e.g. building applications, copying files etc.)
plgrid-now 12:00:00 Recommended for interactive jobs, for testing and preparing computations (e.g. building applications, copying files etc.), with maximum limits: 1 node, 24 cores, without GPGPU nodes
plgrid-short 1:00:00 For short jobs (walltime shorter than 1h); provides an increased likelihood that your job will be quickly scheduled for execution
plgrid-long 168:00:00 For long jobs (as specified in the relevant grant)
plgrid-large 24:00:00 For jobs requiring at least 432 cores (18 full nodes); contains additional resources not available through the plgrid partition
plgrid-gpu 72:00:00 For jobs requiring GPGPU computations (note that access to GPGPU must be allowed under the relevant grant)
plgrid-gpu-v100 12:00:00 For jobs requiring GPGPU V100 computations (note that access to GPGPU must be allowed under the relevant grant)
prace 72:00:00 Partition for PRACE projects

Further information regarding any specific partition may be obtained by running the following command:

scontrol show partition [<partition_name>]

Notes:

  • Selecting the right partition and specifying the expected execution time greatly increase the chances that your job will be quickly scheduled for execution. We recommend that jobs be preferentially submitted to partitions with short maximum execution times (e.g. plgrid-short where feasible).
  • Failing to specify a partition will cause your job to be submitted to the default partition, i.e. plgrid.
  • Jobs submitted to plgrid (or submitted without specifying a partition) may be automatically transferred to plgrid-large or plgrid-short by the queue manager, if this will cause them to be executed faster.
  • Currently, all users may access plgrid, plgrid-testing, plgrid-short and plgrid-large. Access to other partitions is regulated by grants and provided on a case-by-case basis in the course of evaluating proposed grants.
  • If you wish to access plgrid-long, this must be clearly expressed in your grant application.
  • Access to plgrid-gpu requires applying for a separate grant which is wholly dedicated to GPGPU computations.
  • plgrid-testing must not be used for large-scale computations. This partition is specifically meant for tests and other maintenance tasks (e.g. building applications, interactively copying data etc.)

Disk storage

Location Volume quota Files quota Purpose Access Throughput Available space Backups Support for intensive
writes and/or reads
Availability Remarks
$HOME 40 GB 1 000 000 user home directory NFS 1 GB/s yes no global
$SCRATCH 100 TB 1 000 000 storage for temporary job data Lustre 120 GB/s 5 PB no yes global data older than 30 days
will be automatically deleted
$PLG_GROUPS_STORAGE/<team_name> grant total Storage for PL-Grid team datasets Lustre 30 GB/s 2.5 PB no no global
$SCRATCH_LOCAL 768 GB local scratch storage Lustre 120 GB/s - no yes limited to single node unavailable following
completion of job;
requires -C localfs

Environmental variables

Personal:

  • $HOME, $PLG_USER_STORAGE, eg. '/people/plgtestowy' - points to your home directory
  • $PLG_USER_SCRATCH_SHARED, $SCRATCH eg. '/net/scratch/people/plgtestowy/' - points to your private scratch storage - this is where data should be stored during computations

Team-wide (append team name to each variable):

  • PLG_GROUPS_STORAGE, PLG_GROUPS_SHARED, eg. '/net/archive/groups' - points to where teams are expected to deposit their data (including input data, output data and data shared between team members)

Local scratch storage

For computations which require a large quantity of metadata operations (open/close/create/remove) it is possible to set up dedicated scratch storage. To do so, please supply the -C localfs parameter when submitting your job (i.e. at the resource allocation stage, before the job ID is assigned).

For example, when submitting jobs in batch mode, use the following directive: #SBATCH -C localfs

Any job submitted in this fashion will be assigned a separate scratch volume, available on the computational nodes and referenced by the $SCRATCH_LOCAL environmental variable (using the /localfs/<task_id> naming convention). $SCRATCH_LOCAL space is optimized for processing small files. Each computational node possesses a separate $SCRATCH_LOCAL volume, available only during execution of the given job.

The size of $SCRATCH_LOCAL is 768 GiB per computational node assigned to your job. Please contact the administrators if you require more scratch space.

Caution: The $SCRATCH_LOCAL volume is available only on those computational nodes which have been allocated to your job, and only while the job is executing. Furthermore, it is not shared across nodes (i.e. each node possesses a separate volume). Following completion of your job, you will lose any data saved in $SCRATCH_LOCAL - if this data is relevant, it must first be copied to your team storage ($PLG_GROUPS_STORAGE/<team_name>) or to your home directory ($HOME).

MEMFS RAM storage

In order to allocate RAM for storage of temporary files, please add the "-C memfs” parameter to your job specification. For example, use the following directive in your batch script: #SBATCH -C memfs

A storage volume will be set up for your job, referenced by the $MEMFS environmental variable. Please note that memory allocated to MEMFS storage counts towards the total memory allocated for your job and declared through "--mem" or "--mem-per-cpu".

Caution: When using MEMFS for file storage, be aware of the following limitations:

  • this method is only available for single-node jobs
  • the total amount of memory consumed by your job, including any MEMFS storage, must not exceed the value declared through "--mem" or "--mem-per-cpu".
  • this method may only be used if the total memory requirements of your job (including MEMFS storage) do not exceed the memory available on a single node (120 GB per standard Prometheus node).
  • when using MEMFS, it is recommended to request allocation of a full node for your job.

Running jobs

The SLURM scheduling system is used to manage jobs on the Prometheus cluster.

A job may be executed in batch or interactive mode.

Before running any jobs, please familiarize yourself with the grant system

Batch mode

To run a job in batch mode, use the sbatch command. Usage: sbatch script.sh.
All scheduler options should be preceded by the #SBATCH keyword (do not forget the #!).
For more information see: man sbatch and sbatch --help.

Sample script:

CAUTION! This sample script is provided as a reference and SHOULD NOT be executed as is. Before running any jobs, make sure that the scheduler options accurately reflect your requirements e.g. with regard to grant ID, partition name, execution time etc.

#!/bin/bash -l
## Job name
#SBATCH -J ADFtestjob
## Number of allocated nodes
#SBATCH -N 1
## Number of tasks per node (by default this corresponds to the number of cores allocated per node)
#SBATCH --ntasks-per-node=1
## Memory allocated per core (default is 5GB)
#SBATCH --mem-per-cpu=1GB
## Max task execution time (format is HH:MM:SS)
#SBATCH --time=01:00:00 
## Name of grant to which resource usage will be charged
#SBATCH -A <grant_id>
## Name of partition
#SBATCH -p plgrid-testing
## Name of file to which standard output will be redirected
#SBATCH --output="output.out"
## Name of file to which the standard error stream will be redirected
#SBATCH --error="error.err"

## change to sbatch working directory
cd $SLURM_SUBMIT_DIR

srun /bin/hostname
module load plgrid/apps/adf/2014.07 
adf input.adf

MPI jobs

Running MPI jobs on Prometheus is similar to running them on other SLURM clusters with integrated MPI libraries. Prometheus provides various versions of MPI libraries (mostly OpenMPI and IntelMPI) for a variety of popular compilers. When running MPI jobs, the -n and -np scheduler options should not be explicitly specified - instead, the system will select optimal values based on allocation parameters expressed in the startup script. Usage of -n and -np should be restricted to exceptional cases which call for nonstandard configurations (e.g. local threading).

CAUTION! This sample script is provided as a reference and SHOULD NOT be executed as is. Before running any jobs, make sure that the scheduler options accurately reflect your requirements e.g. with regard to grant ID, partition name, execution time etc.

#!/bin/bash -l
## Job name
#SBATCH -J MPITest
## Number of allocated nodes
#SBATCH -N 2
## Number of tasks per node (by default this corresponds to the number of cores allocated per node)
#SBATCH --ntasks-per-node=24
## Memory allocated per core (default is 5GB)
#SBATCH --mem-per-cpu=5GB
## Max task execution time (format is HH:MM:SS)
#SBATCH --time=01:00:00 
## Name of grant to which resource usage will be charged
#SBATCH -A <grant_id>
## Name of partition
#SBATCH -p plgrid-testing
## Name of file to which standard output will be redirected
#SBATCH --output="output.out"
## Name of file to which the standard error stream will be redirected
#SBATCH --error="error.err"

srun /bin/hostname

## Load the IntelMPI module
module add plgrid/tools/impi

## change to sbatch working directory
cd $SLURM_SUBMIT_DIR

mpiexec ./calcDiff 100 50

It is considered good practice to compile and execute applications in an environment comprising the same set of modules. We recommend using the mpiexec wrapper. Computational resource allocation - in this case 2 nodes, 24 cores each - results in 48 MPI tasks available for execution. It is permissible to run a series of MPI applications with a single script, but given their execution time (which is usually long) this approach is discouraged. Running multiple MPI applications in parallel within a single allocation is not allowed due to resource contention issues.

Simple parallelization of independent tasks

Parallel processing is a typical use case scenario for computing clusters. One representative example involves processing multiple images with a shared algorithm. SLURM provides a way to easily parallelize such tasks with the srun command. A sample script which runs multiple computations in parallel (depending on their specifications) is provided below.

CAUTION! This sample script is provided as a reference and SHOULD NOT be executed as is. Before running any jobs, make sure that the scheduler options accurately reflect your requirements e.g. with regard to grant ID, partition name, execution time etc.

#!/bin/bash -l
## Job name
#SBATCH -J testjob
## Number of allocated nodes
#SBATCH -N 2
## Number of tasks per node (by default this corresponds to the number of cores allocated per node)
#SBATCH --ntasks-per-node=24
## Memory allocated per core (default is 5GB)
#SBATCH --mem-per-cpu=5GB
## Max task execution time (format is HH:MM:SS)
#SBATCH --time=01:00:00 
## Name of grant to which resource usage will be charged
#SBATCH -A <grant_id>
## Name of partition
#SBATCH -p plgrid-testing
## Name of file to which standard output will be redirected
#SBATCH --output="output.out"
## Name of file to which the standard error stream will be redirected
#SBATCH --error="error.err"

module load plgrid/tools/imagemagick

## change to sbatch working directory
cd $SLURM_SUBMIT_DIR

ls *.tif | xargs -t -d "\n" -P ${SLURM_NTASKS} -n 1 srun -n 1 -N 1 --mem=5gb mogrify -format png

The above script runs the mogrify application for each *tif file in the working directory, converting the image to the png format. We begin by listing all input files, and feed the output into the xargs command, which (through the -P flag) ensures parallel execution of each subsequent srun instance. Each instance is supplied with a single input parameter, with the maximum level of parallelism defined as ${SLURM_NTASKS}. Thus, each invocation of srun runs the mogrify application on a single core, with 5GB of assigned memory.

Interactive mode

To run shell commands in interactive mode, use the following (sample) command: srun -p plgrid-testing -N 1 --ntasks-per-node=1 -n 1 -A <grant_id> --pty /bin/bash -l

This will run a job in the plgrid-testing partition, on a single node, using a single core.

The srun command is typically used to execute the specified operation on the assigned resources.
However, if resources have not been allocated in advance, srun also takes care of performing the allocation.

CAUTION: Graphic mode (using X11) is only available on the Prometheus access host.

Array jobs

Array jobs provide a way to schedule large numbers of similar coputational tasks. Each instance of an array job is assigned an index referenced by the $SLURM_ARRAY_TASK_ID environmental variable, which can be used to parameterize the given instance. Submitting array jobs is similar to submitting ordinary batch jobs. The following sample script submits an array job with the task ID range defined by the --array (or -a) scheduler option:

CAUTION! This sample script is provided as a reference and SHOULD NOT be executed as is. Before running any jobs, make sure that the scheduler options accurately reflect your requirements e.g. with regard to grant ID, partition name, execution time etc.

#!/bin/bash -l
## Job name
#SBATCH -J testjob
## Number of allocated nodes
#SBATCH -N 1
## Number of tasks per node (by default this corresponds to the number of cores allocated per node)
#SBATCH --ntasks-per-node=1
## Memory allocated per core (default is 5GB)
#SBATCH --mem-per-cpu=5GB
## Max task execution time (format is HH:MM:SS)
#SBATCH --time=01:00:00 
## Name of grant to which resource usage will be charged
#SBATCH -A <grant_id>
## Name of partition
#SBATCH -p plgrid-testing
## Name of file to which standard output will be redirected
#SBATCH --output="output.out"
## Name of file to which the standard error stream will be redirected
#SBATCH --error="error.err"
## Array index range
#SBATCH --array=0-100

## change to sbatch working directory
cd $SLURM_SUBMIT_DIR

myCalculations $SLURM_ARRAY_TASK_ID

GPGPU jobs

Accessing GPGPU nodes

A special partition named plgrid-gpu has been set up for jobs which require access to GPGPU hardware. In order to schedule such jobs, it is first necessary to obtain a grant specifically dedicated to GPGPU processing. This grant should not be used to run any other types of computational tasks.

When applying for your grant, please specify that you require access to plgrid-gpu. It is also recommended (although not strictly required) to put gpu in your grant name (e.g. gpucomputations) - this will help prevent potential mix-ups.

All applications for access to plgrid-gpu are evaluated on a case-by-case basis by the resource provider.

General information

The SLURM scheduler treats GPUs as generic resources (GRES) identified by the "gpu" codeword.
You can find out which nodes/partitions provide such resources by using the sinfo command:

sinfo -o '%P || %N || %G'

Jobs are submitted by adding --partition=plgrid-gpu --gres=gpu[:count] to your list of scheduler options. If the count argument is omitted, the system will default to allocating a single GPU adapter per processing node.

Following submission of your job, the scheduler automatically sets the $CUDA_VISIBLE_DEVICES environmental variable and permits access to allocated GPUs.

Interactive jobs

For example, to run a single-node interactive job with 2 GPUs, type:

srun -p plgrid-gpu -N 1 -n 24 -A <grant_id> --gres=gpu:2 --pty /bin/bash -l

Interactive MPI jobs

Caution: running interactive MPI jobs (e.g. for testing) is a special case. Due to the fact that SLURM treats GPUs differently than general-purpose processors, launching interactive computations calls for a nonstandard procedure.

For example, to run an interactive job on 2 nodes with 2 GPUs per node (4 GPUs total) for 1 hour, specify the following:

salloc -p plgrid-gpu -N 2 --ntasks-per-node 24 -n 48 -A <grant_id> --gres=gpu:2 --time 1:00:00

The salloc command allocates our job and returns its ID - for example, 1234.

Next, we use srun requesting 0 GPUs for the job whose ID was returned by salloc:

srun --jobid=1234 --gres=gpu:0 -O --pty /bin/bash -l

This gives us shell access on one of the computing nodes. Now, after loading the appropriate MPI module, we may run our actual application via mpirun or mpiexec. It is important to avoid exporting environmental settings - e.g., when using IntelMPI, remember to specify the -genvnone flag. The application will retain access to all GPUs allocated via salloc regardless of the gpu:0 parameter in srun.

Once the computation has concluded, the allocation should be manually cleared by typing:

scancel 1234

Batch jobs

No special procedure is required for batch jobs. For example, to request one GPU adapter per computing node, simply add the following to your script:

#SBATCH --partition=plgrid-gpu
#SBATCH --gres=gpu

Note: Further details regarding SLURM commands may be obtained by typing man sbatch

Monitoring queues, partitions, nodes, jobs and resources

  • Dedicated Prometheus scripts
    • pro-jobs - lists jobs queued by or running for the current user
    • pro-jobs-history - lists completed jobs for the current user
    • pro-fs - returns disk usage statistics for the current user
    • pro-groupdir-fix - used to adjust access permissions for the team data directory
    • pro-grant-jobs - lists jobs scheduled under the user's active grants (including jobs whch belong to other users sharing these grants)
  • SLURM system commands
    • squeue - list of currently queued/running jobs
    • scontrol show job [<job_ID>] - details of a given job
    • sstat -a -j <job_ID>/<job_ID.batch> - resource consumption for each step of a currently running job
    • scancel <job_ID> - cancel a queued or running job
    • sacct - resource consumption for jobs/steps which have already been completed
    • scontrol show partition [<partition_name>] - details of a given partition
    • sinfo - list of nodes
    • scontrol show node [<node_name>] - details of a given node


General rules for using the Prometheus cluster

  • Any computations launched on the access host will be killed without notice. The access host should only be used to prepare input files and submitting jobs to the scheduler. Since transferring large quantities of data may cause significant load on the access host, it is recommended to allocate a computing node for this purpose (in interactive mode, e.g. srun -p plgrid -A grant_id -n 1 --pty /bin/bash -l).
  • Compiling applications - this should be performed on a computing node, not on the access host (in interactive mode, e.g. srun -p plgrid -A grant_id -n 1 --pty /bin/bash -l).
  • Computations which are out of scope of the submitted research agenda or which consume a large fraction of the cluster's resources will be killed without notice.
  • Working datasets and intermediate results should be stored and processed in the Lustre filesystem available under $SCRATCH.
  • Computations should not make use of the /tmp directory to store temporary data - instead, please use directories referenced by $SCRATCH, $SCRATCHDIR or $TMPDIR.
  • The access host imposes a 6GB memory limit for all processes belonging to the current user. Exceeding this limit will cause the offending process to be automatically killed.

Contact

Assistance for PL-Grid users is available at: Helpdesk PLGrid
System administrators may be contacted by e-mail at: prometheus@cyfronet.pl, or by phone at +48 12 632 33 55 int. 603.