Processando Simulações

A partir do servidor access2.grid.unesp.br, o usuário tem acesso a sua área de trabalho no /home/. De lá ele pode preparar o ambiente de trabalho para realizar o processamento das simulações (jobs).

Aviso

Os usuários não devem processar simulações diretamente no servidor access2. Esse servidor deve funcionar apenas como ponto de acesso ao /home/, a partir do qual as simulações devem ser preparadas para submissão de jobs. Somente pré e pós processamentos que demandem um curtíssimo tempo de execução e pouca memória é que podem ser executados no servidor access2. Ou seja, é uma exceção.

Em todas as demais situações, os usuários devem preparar os scripts de submissão de jobs para que as simulações sejam executadas nos nós de processamento. Por isso, caso a equipe do GridUnesp observe que o servidor access2 esteja sendo usado para execução de aplicações que demandem muito tempo e CPU, elas serão imediatemente canceladas para evitar que impactem negativamente na utilização do cluster pelos demais usuários.

Entendimento básico

Eis os passos que normalmente o usuário deverá seguir para realizar processamentos no GridUnesp:

Inicialmente o usuário irá preparar a área de trabalho, criando ou transferindo arquivos para seu /home/ de acordo com as explicações da seção Transferindo Arquivos).
Na sequência, é muito provável que tenha que instalar a(s) aplicação(ões) científica(s) necessária(s) ao trabalho que deseja realizar (veja a seção Instalando Aplicações).
Finalmente, deverá preparar um script de submissão de jobs (simulações). Esse script conterá as diretivas necessárias para a execução do job.

Importante

O GridUnesp utiliza o Slurm para gerenciar os processos do cluster. Dessa forma esse script de submissão geralmente é um script em bash com algumas instruções específicas do Slurm. Esse script é um arquivo de texto, que pode ser editado em outro computador e transferido ou editado no próprio servidor access2 com editores de texto como nano, vim ou emacs.

A imagem abaixo mostra uma simples ilustração do workflow: após o acesso ao servidor, o usuário prepara o ambiente de trabalho no /home/ (organizando os arquivos e instalações necessários) e envia as simulações para processamento nos worker nodes (nós de processamento).

Vamos supor que que um usuário chamado Spock (cujo login no GridUnesp é spock) queira, como teste, criar um script denominado vulcano.sh que apenas tenha como resultado o dia e a hora. Spock então escreve um arquivo com o seguinte conteúdo:

#!/bin/bash
#SBATCH -t 5:00

date
sleep 60

Aqui, #SBATCH é uma instrução necessário do Slurm que deve estar presente em todos os scripts de submissão de jobs. O parâmetro -t 5:00 significa que o tempo máximo de processamento será de 5 minutos a partir do momento em que o worker node iniciar a execução do job. E como Spock sabe que o comando date é muito simples e rápido de ser executado, ele também incluiu o comando sleep 60, apenas para fazer o job demarar um tempinho (60 segundos) antes de finalizar, a fim de que pudesse verifcar o status do job na fila.

Para submeter essa “simulação” tão simples para processamento no nó, Spock informa o seguinte comando em seu terminal

[spock@access2 ~]$ sbatch vulcano.sh

O comando sbatch vulcano.sh envia o script para o escalonador de jobs (Slurm), o qual irá ler as diretivas do script de submissão e enviá-lo para uma fila a partir de uma classificação segundo uma determinada ordem de prioridade. À medida que os recursos vão sendo liberados, cada job na fila vai entrando em execução.

Monitorando Simulações

Para visualizar a ordem em que seu job aparece na fila, Spock utiliza o comando

[spock@access2 ~]$ squeue -a

Aparece então na tela o seguinte resultado:

JOBID   PARTITION       NAME       USER  ST        TIME  NODES  NODELIST(REASON)
2846439 short,med  dobra2.sh       kirk  PD        0:00      1  (Priority)
2847404    medium  dobra3.sh     picard  PD        0:00      1  (Priority)
2848556 short,med patrono.sh     potter  PD        0:00      1  (Priority)
2848557 short,med  reparo.sh   hermione  PD        0:00      1  (Priority)
2848879     short vulcano.sh      spock  PD        0:00      1  (Priority)
2841620      long  crucio.sh  voldemort   R 10-02:40:51      1  node018
2843891    medium   force.sh       yoda   R  4-23:08:47      4  node[001,005,016,027]
2843895    medium    dark.sh      vader   R  4-23:08:47      6  node[002,005-007,009-010]
2845557      long   sabre.sh       luke   R     5:45:06      1  node044

Spock percebe então que há 9 jobs na fila, sendo que 5 deles estão aguardando que alguns dos outros 4 jobs em execução finalizem o processamento para que os recursos sejam liberados. Os status PD e R significam PENDING E RUNNING respectivamente. Spock ainda consegue notar que, dos 4 jobs que estão rodando (processando/executando):

o job de número 2841620 está processando há 10 dias, 2 horas e 40 minutos em apenas 1 nó (node018);
o job 2843891 está em execução há 4 dias e 23 horas em 4 nós (node001, node005, node016 e node017);
o job 2843895 está em execução também há 4 dias e 23 horas usando 6 nós (node002, node005, node006, node007, node009 e node010);
o job 2845557 está processando há apenas 5 horas e 45 minutos em um único nó (node044).

Finalmente, após algum tempo de espera, o job do Spock entrou em processamento. Para verificar o status apenas do seu job, ele executa o comando

[spock@access2 ~]$ squeue -u spock

cujo resultado é

JOBID   PARTITION       NAME       USER  ST        TIME  NODES  NODELIST(REASON)
2848879     short vulcano.sh      spock   R        0:09      1  node011

Spock ainda pensou em cancelar seu job, mas decidiu deixá-lo processar até o fim. Porém, caso quisesse realmente cancelar, sabia que bastaria usar o comando

scancel 2848879

E como estava interessado em ver mais detalhes do job, Spock executou o comando

[spock@access2 ~]$ scontrol show job 2848879

cujo resultado é

JobId=2848879 JobName=vulcano.sh
   UserId=spock(11992) GroupId=enterprise(11006) MCS_label=N/A
   Priority=310871 Nice=0 Account=ncc QOS=normal
   JobState=RUNNING Reason=None Dependency=(null)
   Requeue=1 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
   RunTime=00:00:18 TimeLimit=00:05:00 TimeMin=N/A
   SubmitTime=2022-04-01T18:47:30 EligibleTime=2022-04-01T18:47:30
   AccrueTime=2022-04-01T18:47:30
   StartTime=2022-04-01T18:47:30 EndTime=2022-04-01T18:52:30 Deadline=N/A
   SuspendTime=None SecsPreSuspend=0 LastSchedEval=2022-04-01T18:47:30
   Partition=short AllocNode:Sid=access2:32492
   ReqNodeList=(null) ExcNodeList=(null)
   NodeList=node011
   BatchHost=node011
   NumNodes=1 NumCPUs=2 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
   TRES=cpu=2,node=1,billing=2
   Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*
   MinCPUsNode=1 MinMemoryCPU=2G MinTmpDiskNode=0
   Features=(null) DelayBoot=00:00:00
   OverSubscribe=OK Contiguous=0 Licenses=(null) Network=(null)
   Command=/home/spock/vulcano.sh
   WorkDir=/home/spock
   StdErr=/home/spock/slurm-2848879.out
   StdIn=/dev/null
   StdOut=/home/spock/slurm-2848879.out
   Power=
   MailUser=(null) MailType=NONE

Por fim, após o término do processamento do job de teste, Spock visualiza o contéudo do arquivo de saída (slurm-2848879.out):

Sex Abr  1 18:47:31 -03 2022

Satisfeito com o teste por ter-lhe provido o conhecimento básico de como criar um script, submiter um job e monitorar o processamento, Spock sente-se agora mais confiante e preparado para avançar com as simulações de seu projeto de pesquisa.

Resumo dos comandos básicos

Enviando para a fila de execução

sbatch submit_job.sh

Verificando status de todos os jobs na fila

squeue -a

Verificando status apenas dos jobs de um usuário em específico

squeue -u username

Obtendo detalhes de um processo

scontrol show jobid <id_do_job>

Cancelando processo

scancel <id_do_job>