Tipicamente a submissão de Jobs é feita através de um arquivo texto, chamado de script, que fornece todas as informações necessárias para o gerenciador de filas e contém o roteiro dos comandos e programas a serem executados.

Todas as Jobs serão submetidas ao gerenciador de filas através do formulário de submissão.

Ao submeter o job, o SLURM irá retornar o número do mesmo (JOB_ID) e todas as mensagens serão direcionadas para o arquivo de saída.

Tipicamente o arquivo de script tem a seguinte estrutura:

{Definição do shell}

{Definição das opções do SLURM}

{Exportação de variáveis de ambiente (se necessário)}

{Carregamento dos módulos necessários}

{Execução do programa}

Opções do SLURM (#SBATCH)

O SLURM permite um grande número de opções que ajudam a gerenciar e direcionar os jobs no sistema. As principais opções são as seguintes:

#SBATCH --job-name= - Nome do job

#SBATCH --nodes=N1,N2 - Número mínimo e máximo de nós

#SBATCH --ntasks-per-node=P - Número de tarefas por nó

#SBATCH --gres= - Solicita um recurso especial

Por default, cada tarefa equivale a 1 núcleo (core). Portanto iremos usar os termos tarefa e núcleo indistintamente.

Carregando os módulos necessários

Antes de executar um software, é necessário configurar o ambiente para o mesmo. Para isso utilizamos o comando:

module load …

que carrega todos os módulos necessários para o software que será usado no job. Isso significa basicamente que as variáveis de ambiente necessárias para que o executável e as bibliotecas que ele utiliza sejam encontrados e outros parâmetros necessários para o funcionamento do software sejam definidos.

Se for necessário definir variáveis extras para o software, você mesmo pode exportar essas variáveis dentro dos scripts.

Exportando variáveis de ambiente

Se houver necessidade de definir variáveis de ambiente adicionais (que não são carregadas usando module load) para o programa que será executado na Job, isso pode ser feito usando o comando export. Por exemplo

export OMP_NUM_THREADS=1

define a variável OMP_NUM_THREADS com valor 1 e a variável poderá ser usada dentro do script e acessada por qualquer programa executado na Job. No caso de programas que escrevem muito em arquivos temporários, pode-se exportar também uma variável (por exemplo, SCRATCH_DIR) que informa ao programa que será executado onde é a área de scratch:

export SCRATCH_DIR=/scratch/global

Cada programa tem um nome próprio para essa variável. Exporte a variável correta para o seu programa.

Variáveis de ambiente do SLURM

O SLURM possui diversas variáveis de ambiente que podem ser usadas no script para passar informações relevantes para o programa que será executado, ou para imprimir informações relevantes no arquivo de saída do SLURM (slurm-.out). Algumas das mais relevantes são:

$SLURM_SUBMIT_DIR - Diretório de onde a Job foi submetida

$SLURM_JOB_NAME - Nome do job

$SLURM_JOB_NODELIST - Lista dos nós alocados ao job

$SLURM_NTASKS - Número de núcleos alocados ao job

A lista completa de variáveis de ambiente do SLURM pode ser vista no site oficial.

Exemplos de scripts do SLURM

Exemplo de script para Job na fila amd_serial:

#!/bin/bash

#SBATCH --job-name=nome_do_meu_job

#SBATCH --partition=amd_serial

#SBATCH --ntasks=1

module load

cd $SLURM_SUBMIT_DIR

meu_programa < input > output

Exemplo de script para rodar Job paralela que não utiliza MPI (portanto roda em apenas 1 nó) na fila int_medium (tempo máximo de 15 dias):

#!/bin/bash

#SBATCH --job-name=nome_do_meu_job

#SBATCH --partition=int_medium

#SBATCH --ntasks=20

#SBATCH --nodes=1

module load

cd $SLURM_SUBMIT_DIR

meu_programa < input > output

Nesse exemplo, automaticamente será reservado 44000 MB (20 * 2200 MB) de memória RAM para o job.

Exemplo de script para rodar um job paralelo (usando MPI) usando 16 núcleos distribuídos em 2 nós na fila amd_medium (tempo máximo de 7 dias):

#!/bin/bash

#SBATCH --job-name=nome_do_meu_job

#SBATCH --partition=amd_medium

#SBATCH --ntasks=16

#SBATCH --nodes=2

module load

cd $SLURM_SUBMIT_DIR

mpirun -np $SLURM_NTASKS meu_programa < input > output

Nesse exemplo, automaticamente será reservada a quantidade disponível de memória RAM por nó para a Job.

Exemplo de script para rodar um job na fila gpu_int reservando um nó inteiro para a Job:

#!/bin/bash

#SBATCH --job-name=nome_do_meu_job

#SBATCH --partition=gpu_int

#SBATCH --ntasks=16

#SBATCH --nodes=1

#SBATCH --gres=gpu:1

module load

cd $SLURM_SUBMIT_DIR

meu_programa < input > output

Exemplo de script para realizar um job de teste usando 8 núcleos em 1 nó e que durará no máximo 2 horas:

#!/bin/bash

#SBATCH --job-name=job_de_teste

#SBATCH --partition=int_short

#SBATCH --ntasks=10

#SBATCH --time=2:00:00

module load

cd $SLURM_SUBMIT_DIR

meu_programa < input > output

Como monitorar ou cancelar jobs

Atualmente, o sistema de monitoramento de filas em tempo real está em implantação e não é possível utilizar o recurso.

scancel

Para ser notificado acerca de eventos de Jobs (início, término, falhas e etc), basta inserir em seu script de submissão as seguintes diretivas:

#SBATCH --mail-type=ALL

#SBATCH --mail-user=

Onde “” deve ser substituído por um endereço de email de sua escolha.

Como funciona o agendamento de jobs

Se há recursos disponíveis no ambiente para atender à solicitação de todas as Jobs submetidas pelos usuários que estejam dentro dos limites impostos pelo sistema, então todas entrarão em execução, ainda respeitando-se tais limites. Entretanto, em geral esse não é o caso num ambiente com muitos usuários, e assim surge a necessidade de se utilizar um sistema de prioridades para classificar Jobs que ficam na fila esperando pela disponibilização de recursos.

No SLURM esse sistema de priorização é feito utilizando-se vários fatores. No nosso cluster o cálculo da prioridade da Job é estabelecido da seguinte forma:

Prioridade = 2.000*FatorTemporal + 10.000*FairShare + 5.000*FatorDeFila

Todos os fatores variam de 0 a 1. Portanto, a prioridade máxima de uma Job é 17.000 e a mínima é 0 (embora seja muito difícil a prioridade zerar). Vejamos o que significa cada fator desses:

Com o comando sprio pode-se ver a prioridade dos Jobs em espera (apenas admin):

sprio - Ver a prioridade de todos os jobs

sprio -u - Ver apenas os jobs do usuário

sprio -p - Ver apenas os jobs da fila

Usando o backfill para diminuir o tempo de espera do seu job

O padrão do sistema de filas é executar as Jobs pela ordem de prioridade (veja fórmula acima), contudo, caso seja possível estimar com bastante precisão o tempo máximo de execução da Job e ele for bem menor que o tempo limite da fila na qual irá rodar, utilizar a opção --time pode ajudar a garantir uma submissão com maior índice de prioridade através do algoritmo de backfill utilizado pelo SLURM. Esse algoritmo permite que Jobs de prioridade mais baixa sejam executados antes, desde que sua execução não atrapalhe outros de maior prioridade, ou seja, desde que ele termine antes do tempo previsto para iniciar da próxima execução agendada. Entretanto, esse recurso deve ser usado com moderação, pois, se levar mais tempo que o previsto pela opção --time, o processo será encerrado independente de qual for o resultado situacional.

Se, por exemplo, a Job for levar mais que 1 dia e no máximo 4 dias para terminar, então deve ser submetida para a fila int_medium ou amd_medium, e nesse caso é vantajoso utilizar

#SBATCH --time=4-0

Um outro uso interessante da opção --time seria para encurtar o tempo de espera de Jobs de Teste. As filas int_short e amd_short tem tempo máximo de 72 horas e possuem prioridade mais alta por isso. Mas é possível utilizar o backfill para rodar jobs de teste - que sejam ainda mais curtos do que essas 24 horas - antes de Jobs de prioridade mais alta na mesma fila. Por exemplo, utilize

#SBATCH --time=2:00:00

Com essa opção fica bem mais fácil de encaixar seu job mais rápido quando houver recursos disponíveis.

Softwares disponíveis no Ambiente HPC

Apenas softwares livres ou aqueles que o Catastronomy possui licença podem ser disponibilizados de forma global no cluster.

Os softwares utilizados passam por constante implantação e aprimoramento, resultando em adição ou remoção de recursos sem aviso prévio. Nesses casos específicos, solicitamos que sejam abertos tickets de suporte para tratar de pesquisas em andamento. Alguns dos listados abaixo estão disponíveis para todos os usuários do ambiente HPC.

Para softwares de uso mais restrito e individual recomendamos que sejam feitas solicitações de disponibilidade junto ao suporte ou diretamente com o orientador credenciado.

Atenção usuários:

Para solicitar a instalação de algum software para acesso global no cluster ou solicitar instalação de software específico ao usuário, utilize do formulário de contato. O usuário deve estar ciente de que, dependendo do fluxo de trabalho da equipe do Laboratório e das características do software, o atendimento a essa solicitação pode levar um tempo maior que o usual. É importante ressaltar que a solicitação de instalação deverá ser feita somente por usuários e/ou orientadores credenciados, ou seja, aqueles que possuem uma conta no cluster.

Aplicações

Observações:

Nem todas as funcionalidades dos programas estão paralelizadas. Verifique quais estão com o desenvolvedor.

Os softwares podem estar paralelizados apenas para memória compartilhada (só permite utilizar núcleos dentro de um mesmo nó).

Devido a limitações de pessoal e outros fatores, ainda que um software ou recurso esteja devidamente listado, não podemos garantir plena e contínua funcionalidade do mesmo. Pedimos a compreensão de todos e enfatizamos sobre a característica colaborativa do projeto, sendo então cada mensagem enviada ao suporte de grande ajuda para identificação de possíveis problemas. Mensagens de teor nocivo ou perjúrio serão encaminhadas aos respectivos orientadores e o acesso concedido ao usuário será revogado.

Bibliotecas e utilitários

Compiladores e interpretadores

Carregando os módulos necessários

Para utilizar qualquer um desses softwares deve-se configurar as variáveis de ambiente necessárias. Isso pode ser feito através do comando module.

Após localizar o módulo associado ao software desejado, para carregá-lo basta digitar

module load

Dessa forma o software fica acessível e pronto para ser utilizado.

Atenção: vários softwares possuem mais de uma versão instalada. Nesses casos, certifique-se de carregar o módulo da versão correta.

Em breve será publicada uma lista com as bibliotecas que foram utilizadas na compilação do software. Para maiores informações digite

Dicas específicas

As páginas relacionadas abaixo reúnem dicas específicas para uso mais eficiente dos softwares no cluster. As páginas serão atualizadas à medida que formos ampliando nossa base de conhecimento.

Quanto mais eficiente for o uso dos recursos computacionais no cluster, melhor será para todos os usuários. Portanto, se você tiver alguma dica de uso, nos envie pelo formulário de contato.

Como acessar os servidores e transferir arquivos

Para acessar tanto o ambiente Externo quanto o Interno do CAD, ou para transferir arquivos entre o cluster e o computador local, o usuário deve usar exclusivamente o portal CAD. Todos os protocolos de acesso e integração já estão inseridos nos módulos administrativos. Nenhum dado de qualquer natureza é diretamente transferido entre a máquina local e a o cluster, o que proporciona maior segurança tanto para o usuário quanto para o departamento. O protocolo SSH é utilizado para comunicação criptografada entre o cluster e as plataformas de gerenciamento em formato “ponto-a-ponto”, não sendo possível a utilização por nenhum outro recurso ou usuário.

Obs: Embora a rede Wi-Fi Eduroam possibilite o acesso à Internet e aos serviços web da UFCat, ela não permite conexão à portas de comunicação utilizadas nos servidores do DCCat. Essa impossibilidade ocorre devido a uma política de segurança da Rede Nacional de Ensino e Pesquisa (RNP) e, portanto, cumprida pelo Centro de Recursos Computacionais (Cercomp), órgão responsável pela disponibilização e gerenciamento da Rede Eduroam na UFCat. Desse modo, não é possível realizar conexões direcionadas ao cluster através de rede externa, portanto, a única via de acesso se dá de “dentro para fora” através da política de solicitação de pacotes. Certos de contar com a compreensão de todos, nos colocamos à disposição para eventuais dúvidas.

Transferências de arquivos

Atualmente, transferências de arquivos entre o cluster e o usuário se dá somente através dos formulários presentes nos portais. Futuramente, será possível o gerenciamento completo de Jobs e resultados através do portal do usuário.