46
edições
Mudanças
Criou página com 'O [https://slurm.schedmd.com/ '''''Slurm Workload Manager'''''] (anteriormente conhecido como ''Simple Linux Utility for Resource Management'' ou SLURM), ou Slurm, é num esca...'
O [https://slurm.schedmd.com/ '''''Slurm Workload Manager'''''] (anteriormente conhecido como ''Simple Linux Utility for Resource Management'' ou SLURM), ou Slurm, é num escalonador de tarefas gratuito e de código aberto para Linux e kernels similares ao Unix, usado por muitos dos supercomputadores e clusters de computadores do mundo. O Slurm Workload Manager possui três funções principais:
* alocar nós computacionais para acesso exclusivo e/ou não-exclusivo (compartilhado) aos usuários por um determinado período de tempo necessário para executar as tarefas computacionais submetidas (''jobs'').
* oferece um ambiente integrado que permite executar e monitorar em tempo real as tarefas lançadas nos nós computacionais alocados.
* gerencia a fila de submissão, arbitrando conflitos entre os pedidos de recursos computacionais.
== Comandos do Slurm ==
Segue abaixo, uma lista de comandos úteis disponíveis para o Slurm que permite a interação dos usuários. A lista completa de comandos por ser encontrada na documentação oficial do Slurm através do link [https://slurm.schedmd.com/quickstart.html https://slurm.schedmd.com/quickstart.html]
{|class="wikitable" width=100% border=1 cellpadding=35px
!|Comando
!|Descrição do comando
|-
|'''SRUN'''
|Submete na linha de comando um job para execução.
|-
|'''SBATCH'''
|Submete scripts shell (eg. bash) para a fila de espera do SLURM.
|-
|'''SALLOC'''
|Reserva recursos do cluster (tempo de cpu, memória, quantidade de nós, etc) para a execução de uma tarefa computacional.
|-
|'''SBCAST'''
|Para transmissão de um arquivo para todos os nós que foram alocados para um determinado job.
|-
|'''SCANCEL'''
|Para cancelar um job que esteja sendo executado ou que ainda esteja na fila de espera.
|-
|'''SQUEUE'''
|Para monitorar o estado dos jobs nas diversas filas de espera do SLURM.
|-
|'''SINFO'''
|Para monitorar o estado global das partições configuradas (filas).
|-
|'''SVIEW'''
|Providencia a integração de toda a informação e disponibiliza-a através de uma interface gráfica.
|}
<br/>
Uma mnemônica muito útil é lembrar que todos os comandos do SLURM começam pela letra s. Todos os comandos possuem manuais que podem ser acessados online via linha de comando, '''man <comando>'''
Exemplo com o comando '''sbatch''' :
<pre class="bash">
[test3@masternode ~]$ man sbatch
</pre>
Em geral a grande maioria dos usuários precisa familiarizar-se com três comandos básicos do SLURM: '''sbatch, squeue e scancel'''. Assim como no PBS Pro, a submissão de uma tarefa envolve a elaboração de um script shell (em geral em bash) que possui no seu preâmbulo diretrizes específicas do SLURM. Essas diretrizes começam com a palavra-chave '''#SBATCH''' (o análogo da palavra-chave '''#PBS''' para o PBS Pro). No corpo do script é então chamado o executável do programa com os seus respectivos parâmetros.
== Submissão de tarefas computacionais ==
=== Filas de submissão ===
No UNIVERSO do SLURM o conceito de '''filas''' envolve a noção de partição de nós computacionais em grupos. Esses grupos não são necessariamente disjuntos (nós podem participar de mais de uma partição) e podem ser solicitados de acordo com a especificação de recursos do sistema (tempo de cpu, memória, etc). Para respeitar a herança do PBS Pro iremos nos referir indistintamente aos termos '''filas''' e '''partições'''.
O cluster Veredas possui no momento três filas de submissão definidas apenas pelo recurso '''walltime''':
* partição '''long''': nós '''nodes[003-006]''' máximo 3 dias..
* partição '''short''': nós '''nodes[001-002]''' máximo 1 hora.
O usuário poderá listar a qualquer momento os recursos oferecidos por cada partição com o seguinte comando:
<pre class="bash">
[test3@masternode ~]$ scontrol show partitions
PartitionName=short
AllowGroups=ALL AllowAccounts=ALL AllowQos=ALL
AllocNodes=ALL Default=YES QoS=N/A
DefaultTime=NONE DisableRootJobs=NO ExclusiveUser=NO GraceTime=0 Hidden=NO
MaxNodes=UNLIMITED MaxTime=01:00:00 MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED
Nodes=node[001-002]
PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=NO
OverTimeLimit=NONE PreemptMode=OFF
State=UP TotalCPUs=24 TotalNodes=2 SelectTypeParameters=NONE
JobDefaults=(null)
DefMemPerNode=UNLIMITED MaxMemPerCPU=3000
PartitionName=long
AllowGroups=ALL AllowAccounts=ALL AllowQos=ALL
AllocNodes=ALL Default=NO QoS=N/A
DefaultTime=NONE DisableRootJobs=NO ExclusiveUser=NO GraceTime=0 Hidden=NO
MaxNodes=UNLIMITED MaxTime=3-00:00:00 MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED
Nodes=node[003-006]
PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=NO
OverTimeLimit=NONE PreemptMode=OFF
State=UP TotalCPUs=52 TotalNodes=4 SelectTypeParameters=NONE
JobDefaults=(null)
DefMemPerNode=UNLIMITED MaxMemPerCPU=3000
</pre>
ou através do seguinte comando,
<pre class="bash">
[test3@masternode ~]$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
short* up 1:00:00 1 idle node[001-002]
long up 3-00:00:00 4 idle node[003-006]
</pre>
Para racionalizar a utilização de recursos é conveniente que o usuário respeite a real demanda de sua tarefa e submeta seu script à partição mais apropriada, ou seja, ''jobs'' de curta duração (< 1 hora) na partição '''short'''. Caso contrário, pode correr o risco de a sua solicitação permanecer por muito tempo na fila de espera.
O estado dos ''jobs'' submetidos ou em execução poderá também ser examinado no SLURM através do comando '''squeue''', tal como era feito no PBS Pro com o comando ''qstat'':
<pre class="bash">
[test3@masternode ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
977 long test root R 0:10 1 node004
</pre>
<br/>
<div class="aviso">
'''Aviso:''' Os exemplos de scripts de submissão que se seguem são para propósitos ilustrativos e representam ''templates'' que os usuários poderão adaptar conforme as suas necessidades específicas.
</div>
=== Tarefas sequenciais ===
Executar um ''job'' sequencial é bastante simples. Basta requisitar a duração necessária para executar a tarefa. Qualquer tarefa puramente seqüencial, que não utiliza MPI ou ''threads'', irá usar necessariamente '''um core apenas''' do nó computacional.
<syntaxhighlight lang="Bash">
#!/bin/bash
#SBATCH --job-name="TESTJOB"
#SBATCH --ntasks=1
#SBATCH --time=01:00:00
./a.out > OUTFILE
</syntaxhighlight>
Por padrão o ''output'' do ''script'' acima será redirecionado para um arquivo do tipo ''slurm-'''XXXX'''.out'', onde '''XXXX''' é o número do job que foi atribuído pelo SLURM. Este arquivo de ''output'' estará localizado no diretório de onde foi feita a submissão. O interessante a notar, e a que nos referiremos mais adiante (ver), é de que este arquivo é criado no instante da execução do ''script'' e o seu conteúdo aumenta à medida que o programa vai sendo executado. Remover este arquivo antes da finalização do job acarreta portanto perda total do output da tarefa. Diferentemente no PBS Pro os arquivos de output só eram criados na área do usuário depois de o job finalizar. É possível especificar um nome para o arquivo de output fazendo uso da diretriz '''''#SBATCH --output=meu_job.out'''''. O mesmo vale para o arquivo de erro, '''''#SBATCH --error=meu_job.err'''''.
=== Tarefas paralelas (MPI) ===
Solicite quatro núcleos no cluster por 10 minutos, usando 100 MB de RAM por núcleo. Assumindo que hello.mpi foi compilado com suporte a MPI, srun irá criar quatro instâncias dele, nos nós alocados pelo Slurm:
<syntaxhighlight lang="Bash">
#!/bin/bash
#
#SBATCH --job-name=test_mpi
#SBATCH --output=res_mpi.txt
#
#SBATCH --ntasks=4
#SBATCH --time=10:00
#SBATCH --mem-per-cpu=5000
module load gnu-mpi/mpich/3.4
srun hello.mpi
</syntaxhighlight>
Segue o resultado da execução deste script:
<pre class="bash">
[test3@masternode]# cat res_mpi.txt
---------------------------------------------------------------------------------------------------------------
We have 4 processes.
Process 1 reporting for duty.
Process 2 reporting for duty.
Process 3 reporting for duty.
</pre>
=== Tarefas paralelas com ''threads'' (OpenMP) ===
O trabalho será executado em uma alocação em que quatro núcleos foram reservados no mesmo nó de computação:
<syntaxhighlight lang="Bash">
#!/bin/bash
#
#SBATCH --job-name=test_omp
#SBATCH --output=res_omp.txt
#
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=10
#SBATCH --time=10:00
#SBATCH --mem-per-cpu=100
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
./hello.omp
</syntaxhighlight>
Como saída o arquivo res_omp contém:
<pre class="bash">
#!/bin/bash
Hello World from thread 0
Hello World from thread 3
Hello World from thread 1
Hello World from thread 2
There are 4 threads
</pre>
=== Tarefas paralelas com ''threads'' (OpenMP + MPI) ===
Você pode misturar multiprocessamento (MPI) e multi-threading (OpenMP) no mesmo trabalho, simplesmente assim:
<syntaxhighlight lang="Bash">
#! / bin / bash
#
#SBATCH --ntasks = 8
#SBATCH --cpus-per-task =
module load gnu-mpi/openmpi/4.1
export OMP_NUM_THREADS = $ SLURM_CPUS_PER_TASK
srun ./myprog
</syntaxhighlight>
<br/>
=== Variáveis de ambiente do Slurm ===
Quaisquer variáveis de ambiente que você define com o comando '''sbatch''' serão passadas para o seu ''job''. Por esse motivo, se o seu programa precisar que determinadas variáveis de ambiente , é melhor colocá-las no ''script'' do seu ''job''. Isso também facilita a reprodução dos resultados do ''job'' posteriormente, caso você necessite.
A tabela abaixo, contém informações sobre algumas das variáveis de ambiente de entrada e saída mais comuns quando se usa o comando '''sbatch''' no ''script shell''. Para informações adicionais, veja a página man do '''sbatch''' ou acesse a documentação online no site oficial do Slurm [https://slurm.schedmd.com/sbatch.html https://slurm.schedmd.com/sbatch.html].
{|class="wikitable" width=100% border=1 cellpadding=35px
!|Variáveis de ambiente
!|Definição
|-
|'''SLURM_JOB_ID (and SLURM_JOBID for backwards compatibility)'''
|''The ID of the job allocation.''
|-
|'''SLURM_JOB_NAME'''
|''Name of the job.''
|-
|'''SLURM_JOB_NODELIST (and SLURM_NODELIST for backwards compatibility)'''
|''List of nodes allocated to the job.''
|-
|'''SLURM_JOB_NUM_NODES (and SLURM_NNODES for backwards compatibility)'''
|''Total number of different nodes in the job's resource allocation.''
|-
|'''SLURM_ARRAY_TASK_COUNT'''
|''Total number of tasks in a job array.''
|-
|'''SLURM_ARRAY_TASK_ID'''
|''Job array ID (index) number.''
|-
|'''SLURM_ARRAY_TASK_MAX'''
|''Job array's maximum ID (index) number.''
|-
|'''SLURM_ARRAY_TASK_MIN'''
|''Job array's minimum ID (index) number.''
|-
|'''SLURM_ARRAY_TASK_STEP'''
|''Job array's index step size.''
|-
|'''SLURM_ARRAY_JOB_ID'''
|''Job array's master job ID number.''
|-
|'''SLURM_CLUSTER_NAME'''
|''Name of the cluster on which the job is executing.''
|-
|'''SLURM_CPUS_ON_NODE'''
|''Number of CPUS on the allocated node.''
|-
|'''SLURM_CPUS_PER_TASK'''
|''Number of cpus requested per task. Only set if the '''--cpus-per-task''' option is specified.''
|-
|'''SLURM_JOB_ACCOUNT'''
|''Account name associated of the job allocation.''
|-
|'''SLURM_JOB_CPUS_PER_NODE'''
|''Count of processors available to the job on this node.''
|-
|'''SLURM_JOB_DEPENDENCY'''
|''Set to value of the '''--dependency''' option.''
|-
|'''SLURM_MEM_PER_NODE'''
|''Same as '''--mem'''.''
|-
|'''SLURM_MEM_PER_CPU'''
|''Same as '''--mem-per-cpu'''.''
|-
|'''SLURM_NTASKS (and SLURM_NPROCS for backwards compatibility)'''
|''Same as '''-n, --ntasks'''''.
|-
|'''SLURM_NTASKS_PER_NODE'''
|''Number of tasks requested per node. Only set if the '''--ntasks-per-node''' option is specified.''
|-
|'''SLURM_NTASKS_PER_SOCKET'''
|''Number of tasks requested per socket. Only set if the '''--ntasks-per-socket''' option is specified.''
|-
|'''SLURM_SUBMIT_DIR'''
|''The directory from which '''sbatch''' was invoked.''
|-
|'''SLURM_SUBMIT_HOST'''
|''The hostname of the computer from which '''sbatch''' was invoked.''
|-
|'''SLURM_TASK_PID'''
|''The process ID of the task being started.''
|-
|'''SLURMD_NODENAME'''
|''Name of the node running the job script.''
|}
== Comparação entre o SLURM e o PBS Pro ==
Segue alguns comandos essenciais do SLURM e seus equivalentes no PBS Pro.
{|class="wikitable" width=80% border=1 cellpadding=35px
!|Comando Slrum
!|Descrição do comando
!|Comando PBS Pro
|-
|'''srun'''
|submete um comando via SLURM no modo interativo.
|'''qsub -I'''
|-
|'''sbatch'''
|submete um ''script shell''.
|'''qsub'''
|-
|'''squeue'''
|lista todos os ''jobs'' (em execução ou no modo de espera) nas filas.
|'''qstat'''
|-
|'''scontrol'''
|modifica o estado de um ''job'' (maioria só é permitida ao ''root'').
|'''qalter'''
|-
|'''scancel'''
|cancela um ''job'', quer em execução ou na fila de espera.
|'''qdel'''
|}
=== Variáveis de ambiente ===
Existem também algumas diferenças no tocante às variáveis de ambiente como ilustra a tabela abaixo:
{|class="wikitable" width=40% border=1 cellpadding=35px
!|Comando Slrum
!|Descrição do comando
|-
|$SLURM_JOB_ID
|$PBS_JOBID
|-
|$SLURM_JOB_NAME
|$PBS_JOBNAME
|}
O SLURM não possui o equivalente à variável '''$PBS_NODEFILE''' que aponta para o arquivo que contém os nomes dos nós computacionais reservados para a execução do ''job''. Contudo, quando necessário, é possível criar manualmente esse tipo de arquivo com o comando '''srun''':
<syntaxhighlight lang="Bash">
#!/bin/bash -x
HOSTFILE=/tmp/hosts.$SLURM_JOB_ID
srun hostname -s > $HOSTFILE
if [ -z "$SLURM_NPROCS" ] ; then
if [ -z "$SLURM_NTASKS_PER_NODE" ] ; then
SLURM_NTASKS_PER_NODE=1
fi
SLURM_NPROCS=$(( $SLURM_JOB_NUM_NODES * $SLURM_NTASKS_PER_NODE ))
fi
/path/to/mpirun -machinefile $HOSTFILE -np $SLURM_NPROCS programa.x
rm /tmp/hosts.$SLURM_JOB_ID
</syntaxhighlight>
=== Diretório de execução ===
Uma outra diferença importante que distingue o '''SLURM''' do '''PBS Pro''' é que enquanto no primeiro escalonador a tarefa batch é executada automáticamente no diretório de onde foi submetido o seu script, o segundo precisa explicitamente que seja introduzida a seguinte linha:
<syntaxhighlight lang="Bash">
#!/bin/bash -x
...
cd $PBS_O_WORKDIR
...
</syntaxhighlight>
As variáveis de ambiente que são definidas durante uma sessão shell do '''SLURM''' são automáticamente exportadas para o ''job batch'' em todos os nós computacionais no instante em que o script entra em execução. Já no '''PBS Pro''' é necessário garantir isso com a introdução da diretriz:
<syntaxhighlight lang="Bash">
#!/bin/bash -x
...
#PBS -V
...
</syntaxhighlight>
=== Output ===
O '''SLURM''' apresenta ainda uma vantagem considerável e muito útil para aqueles usuários que precisam inspecionar numéricamente e em tempo real a evolução do seu programa, como por exemplo, a convergência de uma determinada iteração: os arquivos de saída '''stdout''' e de erro, '''stderr''' (ver as flags do SLURM) , são criados automáticamnte no diretório de onde foi submetido o script e vão crescendo gradualmente de tamanho à medida que a simulação evolui no tempo. O '''PBS Pro''' mostra-se insuficiente neste quesito: somente no final da execução da tarefa é que os arquivos de saída são escritos no diretório destinado.
=== Diretrizes de submissão ===
Finalmente com o intuito de auxiliar os usuários na migração dos seus scripts de submissão do '''PBS Pro''' para o '''SLURM''' apresentamos a seguinte tabela comparativa das diretrizes de submissão:
{|class="wikitable" width=60% border=1 cellpadding=35px
!|PBS Pro
!|Slurm
|-
|#PBS -N job_name
|#SBATCH –job-name=”job_name” ou #SBATCH -J job_name
|-
|#PBS -l nodes=n
|#SBATCH –nodes=n
|-
|#PBS -l walltime=HH:MM:SS
|#SBATCH –time=HH:MM:SS
|-
|#PBS -l min_walltime=HH:MM:SS
|#SBATCH –time-min=HH:MM:SS
|-
|#PBS -q <queue>
|#SBATCH –partition=<queue>
|-
|#PBS -l mppwidth=n
|#SBATCH –ntasks=n
|-
|#PBS -l mppnppn=N
|#SBATCH –ntasks-per-node=N
|-
|#PBS -l mppdepth=d
|#SBATCH –cpus-per-task=d
|-
|#PBS -l mppmem=mM
|#SBATCH –mem=m
|-
|#PBS -l mppnodes=<nid-list>
|#SBATCH –nodelist=<nid-list>
|-
|#PBS -W group_list=a_group
|#SBATCH –account=a_group
|-
|#PBS -o /path/to/stdout
|#SBATCH –output=/path/to/stdout (pode ser usado %j para jobid)
|-
|#PBS -e /path/to/stderr
|#SBATCH –error=/path/to/stderr
|-
|#PBS -V
|não é necessário
|}
Devemos também ressaltar que as diretrizes do SLURM podem ser especificadas na linha de comando em vez de colocadas no ''script'':
<pre class="bash">
[test3@masternode ~]$ sbatch --job-name="meu job" --ntasks=N ...
</pre>
<div class="aviso">
'''Aviso:''' Para uma informação mais detalhada sobre o escalonador '''SLURM''' o usuário poderá baixar e consultar o arquivo [https://www.lcc.ufmg.br/sites/default/files/manuais/BullXClusterSuite-UserGuide.pdf Bullx cluster suite: User’s Guide]. Para quem estiver interessado o [https://www.cscs.ch Swiss National Supercomputing Centre] disponibiza um video no qual são feitas várias demonstrações de como o usuário pode interagir com o '''SLURM'''.
</div>
[[Category:Manuais]]
[[Category:Cluster Avicena]]
[[Category:Slurm]]
[[Category:Gerenciador de filas]]
* alocar nós computacionais para acesso exclusivo e/ou não-exclusivo (compartilhado) aos usuários por um determinado período de tempo necessário para executar as tarefas computacionais submetidas (''jobs'').
* oferece um ambiente integrado que permite executar e monitorar em tempo real as tarefas lançadas nos nós computacionais alocados.
* gerencia a fila de submissão, arbitrando conflitos entre os pedidos de recursos computacionais.
== Comandos do Slurm ==
Segue abaixo, uma lista de comandos úteis disponíveis para o Slurm que permite a interação dos usuários. A lista completa de comandos por ser encontrada na documentação oficial do Slurm através do link [https://slurm.schedmd.com/quickstart.html https://slurm.schedmd.com/quickstart.html]
{|class="wikitable" width=100% border=1 cellpadding=35px
!|Comando
!|Descrição do comando
|-
|'''SRUN'''
|Submete na linha de comando um job para execução.
|-
|'''SBATCH'''
|Submete scripts shell (eg. bash) para a fila de espera do SLURM.
|-
|'''SALLOC'''
|Reserva recursos do cluster (tempo de cpu, memória, quantidade de nós, etc) para a execução de uma tarefa computacional.
|-
|'''SBCAST'''
|Para transmissão de um arquivo para todos os nós que foram alocados para um determinado job.
|-
|'''SCANCEL'''
|Para cancelar um job que esteja sendo executado ou que ainda esteja na fila de espera.
|-
|'''SQUEUE'''
|Para monitorar o estado dos jobs nas diversas filas de espera do SLURM.
|-
|'''SINFO'''
|Para monitorar o estado global das partições configuradas (filas).
|-
|'''SVIEW'''
|Providencia a integração de toda a informação e disponibiliza-a através de uma interface gráfica.
|}
<br/>
Uma mnemônica muito útil é lembrar que todos os comandos do SLURM começam pela letra s. Todos os comandos possuem manuais que podem ser acessados online via linha de comando, '''man <comando>'''
Exemplo com o comando '''sbatch''' :
<pre class="bash">
[test3@masternode ~]$ man sbatch
</pre>
Em geral a grande maioria dos usuários precisa familiarizar-se com três comandos básicos do SLURM: '''sbatch, squeue e scancel'''. Assim como no PBS Pro, a submissão de uma tarefa envolve a elaboração de um script shell (em geral em bash) que possui no seu preâmbulo diretrizes específicas do SLURM. Essas diretrizes começam com a palavra-chave '''#SBATCH''' (o análogo da palavra-chave '''#PBS''' para o PBS Pro). No corpo do script é então chamado o executável do programa com os seus respectivos parâmetros.
== Submissão de tarefas computacionais ==
=== Filas de submissão ===
No UNIVERSO do SLURM o conceito de '''filas''' envolve a noção de partição de nós computacionais em grupos. Esses grupos não são necessariamente disjuntos (nós podem participar de mais de uma partição) e podem ser solicitados de acordo com a especificação de recursos do sistema (tempo de cpu, memória, etc). Para respeitar a herança do PBS Pro iremos nos referir indistintamente aos termos '''filas''' e '''partições'''.
O cluster Veredas possui no momento três filas de submissão definidas apenas pelo recurso '''walltime''':
* partição '''long''': nós '''nodes[003-006]''' máximo 3 dias..
* partição '''short''': nós '''nodes[001-002]''' máximo 1 hora.
O usuário poderá listar a qualquer momento os recursos oferecidos por cada partição com o seguinte comando:
<pre class="bash">
[test3@masternode ~]$ scontrol show partitions
PartitionName=short
AllowGroups=ALL AllowAccounts=ALL AllowQos=ALL
AllocNodes=ALL Default=YES QoS=N/A
DefaultTime=NONE DisableRootJobs=NO ExclusiveUser=NO GraceTime=0 Hidden=NO
MaxNodes=UNLIMITED MaxTime=01:00:00 MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED
Nodes=node[001-002]
PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=NO
OverTimeLimit=NONE PreemptMode=OFF
State=UP TotalCPUs=24 TotalNodes=2 SelectTypeParameters=NONE
JobDefaults=(null)
DefMemPerNode=UNLIMITED MaxMemPerCPU=3000
PartitionName=long
AllowGroups=ALL AllowAccounts=ALL AllowQos=ALL
AllocNodes=ALL Default=NO QoS=N/A
DefaultTime=NONE DisableRootJobs=NO ExclusiveUser=NO GraceTime=0 Hidden=NO
MaxNodes=UNLIMITED MaxTime=3-00:00:00 MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED
Nodes=node[003-006]
PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=NO
OverTimeLimit=NONE PreemptMode=OFF
State=UP TotalCPUs=52 TotalNodes=4 SelectTypeParameters=NONE
JobDefaults=(null)
DefMemPerNode=UNLIMITED MaxMemPerCPU=3000
</pre>
ou através do seguinte comando,
<pre class="bash">
[test3@masternode ~]$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
short* up 1:00:00 1 idle node[001-002]
long up 3-00:00:00 4 idle node[003-006]
</pre>
Para racionalizar a utilização de recursos é conveniente que o usuário respeite a real demanda de sua tarefa e submeta seu script à partição mais apropriada, ou seja, ''jobs'' de curta duração (< 1 hora) na partição '''short'''. Caso contrário, pode correr o risco de a sua solicitação permanecer por muito tempo na fila de espera.
O estado dos ''jobs'' submetidos ou em execução poderá também ser examinado no SLURM através do comando '''squeue''', tal como era feito no PBS Pro com o comando ''qstat'':
<pre class="bash">
[test3@masternode ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
977 long test root R 0:10 1 node004
</pre>
<br/>
<div class="aviso">
'''Aviso:''' Os exemplos de scripts de submissão que se seguem são para propósitos ilustrativos e representam ''templates'' que os usuários poderão adaptar conforme as suas necessidades específicas.
</div>
=== Tarefas sequenciais ===
Executar um ''job'' sequencial é bastante simples. Basta requisitar a duração necessária para executar a tarefa. Qualquer tarefa puramente seqüencial, que não utiliza MPI ou ''threads'', irá usar necessariamente '''um core apenas''' do nó computacional.
<syntaxhighlight lang="Bash">
#!/bin/bash
#SBATCH --job-name="TESTJOB"
#SBATCH --ntasks=1
#SBATCH --time=01:00:00
./a.out > OUTFILE
</syntaxhighlight>
Por padrão o ''output'' do ''script'' acima será redirecionado para um arquivo do tipo ''slurm-'''XXXX'''.out'', onde '''XXXX''' é o número do job que foi atribuído pelo SLURM. Este arquivo de ''output'' estará localizado no diretório de onde foi feita a submissão. O interessante a notar, e a que nos referiremos mais adiante (ver), é de que este arquivo é criado no instante da execução do ''script'' e o seu conteúdo aumenta à medida que o programa vai sendo executado. Remover este arquivo antes da finalização do job acarreta portanto perda total do output da tarefa. Diferentemente no PBS Pro os arquivos de output só eram criados na área do usuário depois de o job finalizar. É possível especificar um nome para o arquivo de output fazendo uso da diretriz '''''#SBATCH --output=meu_job.out'''''. O mesmo vale para o arquivo de erro, '''''#SBATCH --error=meu_job.err'''''.
=== Tarefas paralelas (MPI) ===
Solicite quatro núcleos no cluster por 10 minutos, usando 100 MB de RAM por núcleo. Assumindo que hello.mpi foi compilado com suporte a MPI, srun irá criar quatro instâncias dele, nos nós alocados pelo Slurm:
<syntaxhighlight lang="Bash">
#!/bin/bash
#
#SBATCH --job-name=test_mpi
#SBATCH --output=res_mpi.txt
#
#SBATCH --ntasks=4
#SBATCH --time=10:00
#SBATCH --mem-per-cpu=5000
module load gnu-mpi/mpich/3.4
srun hello.mpi
</syntaxhighlight>
Segue o resultado da execução deste script:
<pre class="bash">
[test3@masternode]# cat res_mpi.txt
---------------------------------------------------------------------------------------------------------------
We have 4 processes.
Process 1 reporting for duty.
Process 2 reporting for duty.
Process 3 reporting for duty.
</pre>
=== Tarefas paralelas com ''threads'' (OpenMP) ===
O trabalho será executado em uma alocação em que quatro núcleos foram reservados no mesmo nó de computação:
<syntaxhighlight lang="Bash">
#!/bin/bash
#
#SBATCH --job-name=test_omp
#SBATCH --output=res_omp.txt
#
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=10
#SBATCH --time=10:00
#SBATCH --mem-per-cpu=100
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
./hello.omp
</syntaxhighlight>
Como saída o arquivo res_omp contém:
<pre class="bash">
#!/bin/bash
Hello World from thread 0
Hello World from thread 3
Hello World from thread 1
Hello World from thread 2
There are 4 threads
</pre>
=== Tarefas paralelas com ''threads'' (OpenMP + MPI) ===
Você pode misturar multiprocessamento (MPI) e multi-threading (OpenMP) no mesmo trabalho, simplesmente assim:
<syntaxhighlight lang="Bash">
#! / bin / bash
#
#SBATCH --ntasks = 8
#SBATCH --cpus-per-task =
module load gnu-mpi/openmpi/4.1
export OMP_NUM_THREADS = $ SLURM_CPUS_PER_TASK
srun ./myprog
</syntaxhighlight>
<br/>
=== Variáveis de ambiente do Slurm ===
Quaisquer variáveis de ambiente que você define com o comando '''sbatch''' serão passadas para o seu ''job''. Por esse motivo, se o seu programa precisar que determinadas variáveis de ambiente , é melhor colocá-las no ''script'' do seu ''job''. Isso também facilita a reprodução dos resultados do ''job'' posteriormente, caso você necessite.
A tabela abaixo, contém informações sobre algumas das variáveis de ambiente de entrada e saída mais comuns quando se usa o comando '''sbatch''' no ''script shell''. Para informações adicionais, veja a página man do '''sbatch''' ou acesse a documentação online no site oficial do Slurm [https://slurm.schedmd.com/sbatch.html https://slurm.schedmd.com/sbatch.html].
{|class="wikitable" width=100% border=1 cellpadding=35px
!|Variáveis de ambiente
!|Definição
|-
|'''SLURM_JOB_ID (and SLURM_JOBID for backwards compatibility)'''
|''The ID of the job allocation.''
|-
|'''SLURM_JOB_NAME'''
|''Name of the job.''
|-
|'''SLURM_JOB_NODELIST (and SLURM_NODELIST for backwards compatibility)'''
|''List of nodes allocated to the job.''
|-
|'''SLURM_JOB_NUM_NODES (and SLURM_NNODES for backwards compatibility)'''
|''Total number of different nodes in the job's resource allocation.''
|-
|'''SLURM_ARRAY_TASK_COUNT'''
|''Total number of tasks in a job array.''
|-
|'''SLURM_ARRAY_TASK_ID'''
|''Job array ID (index) number.''
|-
|'''SLURM_ARRAY_TASK_MAX'''
|''Job array's maximum ID (index) number.''
|-
|'''SLURM_ARRAY_TASK_MIN'''
|''Job array's minimum ID (index) number.''
|-
|'''SLURM_ARRAY_TASK_STEP'''
|''Job array's index step size.''
|-
|'''SLURM_ARRAY_JOB_ID'''
|''Job array's master job ID number.''
|-
|'''SLURM_CLUSTER_NAME'''
|''Name of the cluster on which the job is executing.''
|-
|'''SLURM_CPUS_ON_NODE'''
|''Number of CPUS on the allocated node.''
|-
|'''SLURM_CPUS_PER_TASK'''
|''Number of cpus requested per task. Only set if the '''--cpus-per-task''' option is specified.''
|-
|'''SLURM_JOB_ACCOUNT'''
|''Account name associated of the job allocation.''
|-
|'''SLURM_JOB_CPUS_PER_NODE'''
|''Count of processors available to the job on this node.''
|-
|'''SLURM_JOB_DEPENDENCY'''
|''Set to value of the '''--dependency''' option.''
|-
|'''SLURM_MEM_PER_NODE'''
|''Same as '''--mem'''.''
|-
|'''SLURM_MEM_PER_CPU'''
|''Same as '''--mem-per-cpu'''.''
|-
|'''SLURM_NTASKS (and SLURM_NPROCS for backwards compatibility)'''
|''Same as '''-n, --ntasks'''''.
|-
|'''SLURM_NTASKS_PER_NODE'''
|''Number of tasks requested per node. Only set if the '''--ntasks-per-node''' option is specified.''
|-
|'''SLURM_NTASKS_PER_SOCKET'''
|''Number of tasks requested per socket. Only set if the '''--ntasks-per-socket''' option is specified.''
|-
|'''SLURM_SUBMIT_DIR'''
|''The directory from which '''sbatch''' was invoked.''
|-
|'''SLURM_SUBMIT_HOST'''
|''The hostname of the computer from which '''sbatch''' was invoked.''
|-
|'''SLURM_TASK_PID'''
|''The process ID of the task being started.''
|-
|'''SLURMD_NODENAME'''
|''Name of the node running the job script.''
|}
== Comparação entre o SLURM e o PBS Pro ==
Segue alguns comandos essenciais do SLURM e seus equivalentes no PBS Pro.
{|class="wikitable" width=80% border=1 cellpadding=35px
!|Comando Slrum
!|Descrição do comando
!|Comando PBS Pro
|-
|'''srun'''
|submete um comando via SLURM no modo interativo.
|'''qsub -I'''
|-
|'''sbatch'''
|submete um ''script shell''.
|'''qsub'''
|-
|'''squeue'''
|lista todos os ''jobs'' (em execução ou no modo de espera) nas filas.
|'''qstat'''
|-
|'''scontrol'''
|modifica o estado de um ''job'' (maioria só é permitida ao ''root'').
|'''qalter'''
|-
|'''scancel'''
|cancela um ''job'', quer em execução ou na fila de espera.
|'''qdel'''
|}
=== Variáveis de ambiente ===
Existem também algumas diferenças no tocante às variáveis de ambiente como ilustra a tabela abaixo:
{|class="wikitable" width=40% border=1 cellpadding=35px
!|Comando Slrum
!|Descrição do comando
|-
|$SLURM_JOB_ID
|$PBS_JOBID
|-
|$SLURM_JOB_NAME
|$PBS_JOBNAME
|}
O SLURM não possui o equivalente à variável '''$PBS_NODEFILE''' que aponta para o arquivo que contém os nomes dos nós computacionais reservados para a execução do ''job''. Contudo, quando necessário, é possível criar manualmente esse tipo de arquivo com o comando '''srun''':
<syntaxhighlight lang="Bash">
#!/bin/bash -x
HOSTFILE=/tmp/hosts.$SLURM_JOB_ID
srun hostname -s > $HOSTFILE
if [ -z "$SLURM_NPROCS" ] ; then
if [ -z "$SLURM_NTASKS_PER_NODE" ] ; then
SLURM_NTASKS_PER_NODE=1
fi
SLURM_NPROCS=$(( $SLURM_JOB_NUM_NODES * $SLURM_NTASKS_PER_NODE ))
fi
/path/to/mpirun -machinefile $HOSTFILE -np $SLURM_NPROCS programa.x
rm /tmp/hosts.$SLURM_JOB_ID
</syntaxhighlight>
=== Diretório de execução ===
Uma outra diferença importante que distingue o '''SLURM''' do '''PBS Pro''' é que enquanto no primeiro escalonador a tarefa batch é executada automáticamente no diretório de onde foi submetido o seu script, o segundo precisa explicitamente que seja introduzida a seguinte linha:
<syntaxhighlight lang="Bash">
#!/bin/bash -x
...
cd $PBS_O_WORKDIR
...
</syntaxhighlight>
As variáveis de ambiente que são definidas durante uma sessão shell do '''SLURM''' são automáticamente exportadas para o ''job batch'' em todos os nós computacionais no instante em que o script entra em execução. Já no '''PBS Pro''' é necessário garantir isso com a introdução da diretriz:
<syntaxhighlight lang="Bash">
#!/bin/bash -x
...
#PBS -V
...
</syntaxhighlight>
=== Output ===
O '''SLURM''' apresenta ainda uma vantagem considerável e muito útil para aqueles usuários que precisam inspecionar numéricamente e em tempo real a evolução do seu programa, como por exemplo, a convergência de uma determinada iteração: os arquivos de saída '''stdout''' e de erro, '''stderr''' (ver as flags do SLURM) , são criados automáticamnte no diretório de onde foi submetido o script e vão crescendo gradualmente de tamanho à medida que a simulação evolui no tempo. O '''PBS Pro''' mostra-se insuficiente neste quesito: somente no final da execução da tarefa é que os arquivos de saída são escritos no diretório destinado.
=== Diretrizes de submissão ===
Finalmente com o intuito de auxiliar os usuários na migração dos seus scripts de submissão do '''PBS Pro''' para o '''SLURM''' apresentamos a seguinte tabela comparativa das diretrizes de submissão:
{|class="wikitable" width=60% border=1 cellpadding=35px
!|PBS Pro
!|Slurm
|-
|#PBS -N job_name
|#SBATCH –job-name=”job_name” ou #SBATCH -J job_name
|-
|#PBS -l nodes=n
|#SBATCH –nodes=n
|-
|#PBS -l walltime=HH:MM:SS
|#SBATCH –time=HH:MM:SS
|-
|#PBS -l min_walltime=HH:MM:SS
|#SBATCH –time-min=HH:MM:SS
|-
|#PBS -q <queue>
|#SBATCH –partition=<queue>
|-
|#PBS -l mppwidth=n
|#SBATCH –ntasks=n
|-
|#PBS -l mppnppn=N
|#SBATCH –ntasks-per-node=N
|-
|#PBS -l mppdepth=d
|#SBATCH –cpus-per-task=d
|-
|#PBS -l mppmem=mM
|#SBATCH –mem=m
|-
|#PBS -l mppnodes=<nid-list>
|#SBATCH –nodelist=<nid-list>
|-
|#PBS -W group_list=a_group
|#SBATCH –account=a_group
|-
|#PBS -o /path/to/stdout
|#SBATCH –output=/path/to/stdout (pode ser usado %j para jobid)
|-
|#PBS -e /path/to/stderr
|#SBATCH –error=/path/to/stderr
|-
|#PBS -V
|não é necessário
|}
Devemos também ressaltar que as diretrizes do SLURM podem ser especificadas na linha de comando em vez de colocadas no ''script'':
<pre class="bash">
[test3@masternode ~]$ sbatch --job-name="meu job" --ntasks=N ...
</pre>
<div class="aviso">
'''Aviso:''' Para uma informação mais detalhada sobre o escalonador '''SLURM''' o usuário poderá baixar e consultar o arquivo [https://www.lcc.ufmg.br/sites/default/files/manuais/BullXClusterSuite-UserGuide.pdf Bullx cluster suite: User’s Guide]. Para quem estiver interessado o [https://www.cscs.ch Swiss National Supercomputing Centre] disponibiza um video no qual são feitas várias demonstrações de como o usuário pode interagir com o '''SLURM'''.
</div>
[[Category:Manuais]]
[[Category:Cluster Avicena]]
[[Category:Slurm]]
[[Category:Gerenciador de filas]]