As senhas são informações pessoais e intransferíveis. Os usuários dos serviços do ambiente tecnológico do LNCC, incluindo o SDumont, devem definir suas senhas de acordo com a política de senhas do LNCC. Clique aqui para maiores informações sobre as políticas e procedimentos do LNCC.
Recomenda-se utilizar:
Quantidade mínima de caracteres numéricos: 1
Serão considerados caracteres numéricos: 0123456789
Quantidade mínima de caracteres especiais: 1
Serão considerados caracteres especiais (incluindo o espaço): ! #$%&*)(_+=-}{^`'~][/;?:><.,|"
Quantidade mínima de caracteres alfabéticos maiúsculos: 1
Serão considerados caracteres alfabéticos maiúsculos: ABCDEFGHIJKLMNOPQSTUVXYWZ
Quantidade mínima de caracteres alfabéticos minúsculos: 1
Serão considerados caracteres alfabéticos minúsculos: abcdefghijklmnopqrstuvxywz
Números aleatórios;
Substituir letras por números ou caracteres especiais;
Criar uma frase que auxilie na memorização da senha (ex: “Utilizar uma frase para memorizar a senha é mais seguro” pode gerar a senha “u1FpMaSe+s”;
Criar padrões para formação da senha (#ftg9@AwS, #ftg9@GmAiL e etc.).
Evitar a utilização de:
Repetição de sequências de caracteres conhecidos ou sequências de teclas do teclado como: 123456, abcdef, asdfgh, qwerty e etc;
Uso de nomes, sobrenomes, nomes de membros da família e demais dados pessoais;
Uso de placas de carros;
Uso de palavras do dicionário;
Uso de nomes de times de futebol, filmes, músicas, personagens e etc.;
Repetição de senhas anteriores;
Anotar a senha em papel ou no próprio computador;
Uso da mesma senha em mais de uma conta.
O comprimento da senha deve ter um mínimo de 8 caracteres.
As senhas devem ter um período de validade inferior a 06 (seis) meses.
A conta será bloqueada após 5 tentativas incorretas. As solicitações de desbloqueio deverão ser encaminhadas ao Helpdesk-SDumont, que seguirá o procedimento de validação das informações do usuário para efetuar o desbloqueio.
Dentro do período de validade da senha, o usuário pode alterá-la a qualquer momento. Para isso, basta utilizar o comando passwd diretamente no terminal do nó de login do SDumont, conforme descrito abaixo:
[meu.usuario@sdumontXX ~]$ passwd Changing password for user meu.usuario. (current) LDAP Password: #--- ATENÇÃO: DIGITAR A SENHA ATUAL New password: #--- ATENÇÃO: DIGITAR A SUA NOVA SENHA Retype new password: #--- ATENÇÃO: REDIGITAR A SUA NOVA SENHA passwd: all authentication tokens updated successfully.
Caso o usuário tenha esquecido a senha, as solicitações de redefinição (reset) devem ser realizadas pelo próprio usuário através da intranet ou, quando esta não estiver disponível, através do Helpdesk-SDumont, que seguirá o procedimento de validação de informações do usuário para disponibilizar uma senha temporária.
O portal para redefinição de senha está disponível no endereço: https://novasenhasdumont.lncc.br.
Acesse a interface, informe seu login de acesso ao SDumont, resolva o captcha e clique no botão Enviar.
Os usuários devem alterar suas senhas imediatamente ao se conectarem no SDumont após uma redefinição de senha pela equipe do Helpdesk-SDumont.
*Lembre-se: No próximo acesso após a redefinição, caso tenha salvado a senha anterior no cliente VPN, será necessário ajustar essa configuração com a nova senha redefinida ao acessar o SDumont.
Essas diretrizes então em acordo com a Política de Segurança do LNCC. Para maiores informações.
Se for necessário utilizar o ksh como shell do script de submissão, é necessário incluir a linha abaixo no script de submissão antes de carregar os módulos:
. /opt/modules/default/Modules/init/ksh
Caso ocorra erro parecido com o descrito abaixo:
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
APP.............. 0000000001409B95 Unknown Unknown Unknown
APP.............. 00000000014077B7 Unknown Unknown Unknown
APP.............. 00000000013B8E74 Unknown Unknown Unknown
APP.............. 00000000013B8C86 Unknown Unknown Unknown
APP.............. 0000000001357E76 Unknown Unknown Unknown
APP.............. 000000000135DF30 Unknown Unknown Unknown
....
Adicionar as linhas abaixo no script de submissão, antes de iniciar a execução da aplicação:
ulimit -c unlimited
ulimit -s unlimited
O sistema de VPN não suporta grandes taxas de transmissão de dados, prejudicando a transferência.
Estamos projetando a implementação de um servidor dedicado para poder realizar o upload/download dos dados de forma mais prática e eficiente, porém ainda sem data para entrar em produção.
A solução adotada por enquanto é a de realizar a cópia dos dados a partir do nó de login do SDumont para algum host acessível através da Internet, utiliza comandos como o scp (enviar e receber dados) ou wget (receber dados). Dessa forma, a comunicação de saída não passa pela VPN, possibilitando alcançar melhores taxas de transferência.
Caso ocorra erro parecido com o descrito abaixo:
DAPL ERR reg_mr Cannot allocate memory
Adicionar a linha abaixo no script de submissão, antes de iniciar a execução da aplicação:
export I_MPI_FABRICS=shm:ofa
Essa variável de ambiente configura a fabric a ser utilizada na comunicação dos processos MPI ao utilizar o Intel MPI. A primeira (shm) define a comunicação internamente no nó e a segunda (ofa) entre os nós.
Dessa forma a configuração para os requisitos de alocação de memória é realizada automaticamente.
Maiores informações: Selecting Fabrics | Intel® MPI Library for Linux
Há algumas formas de realizar essa tarefa. As mais simples estão listadas abaixo.
Essa é a forma mais simples. Se a aplicação não necessita utilizar parâmetros de entrada e é executada diretamente, é necessário apenas configurar o ambiente do SLURM corretamente.
O exemplo abaixo executará 48 vezes a mesma aplicação, sendo 24 em cada nó.
Script de submissão exemplo_1_simples.srm
#!/bin/bash #SBATCH --nodes=2 #Numero de Nós #SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó #SBATCH --ntasks=48 #Numero total de tarefas MPI #SBATCH -p cpu_small #Fila (partition) a ser utilizada #SBATCH -J exemplo_1 #Nome job #SBATCH --exclusive #Utilização exclusiva dos nós durante a execução do job #Exibe os nós alocados para o Job echo $SLURM_JOB_NODELIST nodeset -e $SLURM_JOB_NODELIST cd $SLURM_SUBMIT_DIR #Configura o executavel EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x #exibe informações sobre o executável /usr/bin/ldd $EXEC srun --resv-ports --nodes 1 --ntasks=24 $EXEC > $PWD/log1.txt & srun --resv-ports --nodes 1 --ntasks=24 $EXEC > $PWD/log2.txt & wait
Quando o “srun” é executado utilizando um binário serial, ele disparará a execução do número de vezes que foi
definido pelo “--ntasks”.
No exemplo acima, executará 24 vezes o benchmark cg do NPB em cada um dos nós nós.
No exemplo anterior o job colocará a saída das execuções em um arquivo para cada execução do srun, agregando assim a saída de 24 execuções em um único arquivo de log, o que pode ficar confuso.
Uma forma de contornar isso é utilizar um script intermediário.
No exemplo abaixo, a linha do srun executará um script, que por sua vez executará as 24 instâncias da aplicação, direcionando a saída para arquivos diferentes.
Script de submissão exemplo_2_simples_com_script.srm
#!/bin/bash #SBATCH --nodes=2 #Numero de Nós #SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó #SBATCH --ntasks=48 #Numero total de tarefas MPI #SBATCH -p cpu_small #Fila (partition) a ser utilizada #SBATCH -J exemplo_2 #Nome job #SBATCH --exclusive #Utilização exclusiva dos nós durante a execução do job #Exibe os nós alocados para o Job echo $SLURM_JOB_NODELIST nodeset -e $SLURM_JOB_NODELIST cd $SLURM_SUBMIT_DIR #Configura o script intermediario SCRIPT=${PWD}/script_intermediario_2.sh srun --resv-ports --nodes 1 --ntasks=1 -c 24 $SCRIPT log_run_node1 & srun --resv-ports --nodes 1 --ntasks=1 -c 24 $SCRIPT log_run_node2 & wait
script_intermediario_2.sh - *DEVE SER EXECUTÁVEL
#!/bin/bash #Configura o executavel EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x #Configura a variavel do log - passada por parametro pela execucao do srun RUN_LOG=${1} #Exibe informações sobre o executável /usr/bin/ldd $EXEC #Inicia as execucoes $EXEC > ${PWD}/${RUN_LOG}_1_log.txt & $EXEC > ${PWD}/${RUN_LOG}_2_log.txt & $EXEC > ${PWD}/${RUN_LOG}_3_log.txt & $EXEC > ${PWD}/${RUN_LOG}_4_log.txt & $EXEC > ${PWD}/${RUN_LOG}_5_log.txt & $EXEC > ${PWD}/${RUN_LOG}_6_log.txt & $EXEC > ${PWD}/${RUN_LOG}_7_log.txt & $EXEC > ${PWD}/${RUN_LOG}_8_log.txt & $EXEC > ${PWD}/${RUN_LOG}_9_log.txt & $EXEC > ${PWD}/${RUN_LOG}_10_log.txt & $EXEC > ${PWD}/${RUN_LOG}_11_log.txt & $EXEC > ${PWD}/${RUN_LOG}_12_log.txt & $EXEC > ${PWD}/${RUN_LOG}_13_log.txt & $EXEC > ${PWD}/${RUN_LOG}_14_log.txt & $EXEC > ${PWD}/${RUN_LOG}_15_log.txt & $EXEC > ${PWD}/${RUN_LOG}_16_log.txt & $EXEC > ${PWD}/${RUN_LOG}_17_log.txt & $EXEC > ${PWD}/${RUN_LOG}_18_log.txt & $EXEC > ${PWD}/${RUN_LOG}_19_log.txt & $EXEC > ${PWD}/${RUN_LOG}_20_log.txt & $EXEC > ${PWD}/${RUN_LOG}_21_log.txt & $EXEC > ${PWD}/${RUN_LOG}_22_log.txt & $EXEC > ${PWD}/${RUN_LOG}_23_log.txt & $EXEC > ${PWD}/${RUN_LOG}_24_log.txt & wait
A utilização de parâmetros por parte do executável vai depender de cada caso. Se ele lê um arquivo de entrada, é possível criar um arquivo para cada execução independente.
Script de submissão exemplo_3_com_parametros_em_arquivo.srm
#!/bin/bash #SBATCH --nodes=2 #Numero de Nós #SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó #SBATCH --ntasks=48 #Numero total de tarefas MPI #SBATCH -p cpu_small #Fila (partition) a ser utilizada #SBATCH -J exemplo_3 #Nome job #SBATCH --exclusive #Utilização exclusiva dos nós durante a execução do job #Exibe os nós alocados para o Job echo $SLURM_JOB_NODELIST nodeset -e $SLURM_JOB_NODELIST cd $SLURM_SUBMIT_DIR #Configura o script intermediario SCRIPT=${PWD}/script_intermediario_3.sh srun --resv-ports --nodes 1 --ntasks=1 -c 24 $SCRIPT run_node1 & srun --resv-ports --nodes 1 --ntasks=1 -c 24 $SCRIPT run_node2 & wait
script_intermediario_3.sh - *DEVE SER EXECUTÁVEL
#!/bin/bash #Configura o executavel EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x #Configura a variavel da execucao - passada por parametro pela execucao do srun RUN=${1} #Exibe informações sobre o executável /usr/bin/ldd $EXEC #Inicia as execucoes $EXEC -f ${PWD}/${RUN}_1_entrada > ${PWD}/${RUN}_1_log.txt & $EXEC -f ${PWD}/${RUN}_2_entrada > ${PWD}/${RUN}_2_log.txt & $EXEC -f ${PWD}/${RUN}_3_entrada > ${PWD}/${RUN}_3_log.txt & $EXEC -f ${PWD}/${RUN}_4_entrada > ${PWD}/${RUN}_4_log.txt & $EXEC -f ${PWD}/${RUN}_5_entrada > ${PWD}/${RUN}_5_log.txt & $EXEC -f ${PWD}/${RUN}_6_entrada > ${PWD}/${RUN}_6_log.txt & $EXEC -f ${PWD}/${RUN}_7_entrada > ${PWD}/${RUN}_7_log.txt & $EXEC -f ${PWD}/${RUN}_8_entrada > ${PWD}/${RUN}_8_log.txt & $EXEC -f ${PWD}/${RUN}_9_entrada > ${PWD}/${RUN}_9_log.txt & $EXEC -f ${PWD}/${RUN}_10_entrada > ${PWD}/${RUN}_10_log.txt & $EXEC -f ${PWD}/${RUN}_11_entrada > ${PWD}/${RUN}_10_log.txt & $EXEC -f ${PWD}/${RUN}_12_entrada > ${PWD}/${RUN}_11_log.txt & $EXEC -f ${PWD}/${RUN}_13_entrada > ${PWD}/${RUN}_12_log.txt & $EXEC -f ${PWD}/${RUN}_14_entrada > ${PWD}/${RUN}_13_log.txt & $EXEC -f ${PWD}/${RUN}_15_entrada > ${PWD}/${RUN}_14_log.txt & $EXEC -f ${PWD}/${RUN}_16_entrada > ${PWD}/${RUN}_15_log.txt & $EXEC -f ${PWD}/${RUN}_17_entrada > ${PWD}/${RUN}_16_log.txt & $EXEC -f ${PWD}/${RUN}_18_entrada > ${PWD}/${RUN}_17_log.txt & $EXEC -f ${PWD}/${RUN}_19_entrada > ${PWD}/${RUN}_18_log.txt & $EXEC -f ${PWD}/${RUN}_20_entrada > ${PWD}/${RUN}_19_log.txt & $EXEC -f ${PWD}/${RUN}_21_entrada > ${PWD}/${RUN}_20_log.txt & $EXEC -f ${PWD}/${RUN}_22_entrada > ${PWD}/${RUN}_21_log.txt & $EXEC -f ${PWD}/${RUN}_23_entrada > ${PWD}/${RUN}_22_log.txt & $EXEC -f ${PWD}/${RUN}_24_entrada > ${PWD}/${RUN}_23_log.txt & wait
* Importante observar que nesse caso é necessário gerar previamente um arquivo de entrada diferente para cada execução.
É possível também passar diferentes parâmetros diretamente para o script.
Script de submissão exemplo_3.1_com_parametros_direto.srm
#!/bin/bash #SBATCH --nodes=2 #Numero de Nós #SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó #SBATCH --ntasks=48 #Numero total de tarefas MPI #SBATCH -p cpu_small #Fila (partition) a ser utilizada #SBATCH -J exemplo_3.1 #Nome job #SBATCH --exclusive #Utilização exclusiva dos nós durante a execução do job #Exibe os nós alocados para o Job echo $SLURM_JOB_NODELIST nodeset -e $SLURM_JOB_NODELIST cd $SLURM_SUBMIT_DIR #Configura o script intermediario SCRIPT=${PWD}/script_intermediario_3.1.sh srun --resv-ports --nodes 1 --ntasks=1 -c 24 $SCRIPT parametro_1 parametro_2 parametro_3 parametro_4 parametro_5 parametro_6 parametro_7 parametro_8 parametro_9 parametro_10 parametro_11parametro_12 parametro_13 parametro_14 parametro_15 parametro_16 parametro_17 parametro_18 parametro_19 parametro_20 parametro_21 parametro_22 parametro_23 parametro_24 & srun --resv-ports --nodes 1 --ntasks=1 -c 24 $SCRIPT parametro_25 parametro_26 parametro_27 parametro_28 parametro_29 parametro_30 parametro_31 parametro_32 parametro_33 parametro_34 parametro_35 parametro_36 parametro_37 parametro_38 parametro_39 parametro_40 parametro_41 parametro_42 parametro_43 parametro_44 parametro_45 parametro_46 parametro_47 parametro_48 & wait
script_intermediario_3.1.sh - *DEVE SER EXECUTÁVEL
#!/bin/bash #Configura o executavel EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x #Exibe informações sobre o executável /usr/bin/ldd $EXEC #Inicia as execucoes $EXEC ${1} & $EXEC ${2} & $EXEC ${3} & $EXEC ${4} & $EXEC ${5} & $EXEC ${6} & $EXEC ${7} & $EXEC ${8} & $EXEC ${9} & $EXEC ${10} & $EXEC ${11} & $EXEC ${12} & $EXEC ${13} & $EXEC ${14} & $EXEC ${15} & $EXEC ${16} & $EXEC ${17} & $EXEC ${18} & $EXEC ${19} & $EXEC ${20} & $EXEC ${21} & $EXEC ${22} & $EXEC ${23} & $EXEC ${24} & wait
* Nesse caso, a linha do srun passará 24 parâmetros diferentes para o script intermediário.
* O script intermediário pega os 24 diferentes parâmetros de entrada e os distribui para as 24 execuções.
Uma outra forma seria criar diferentes scripts intermediários completos, cada um contando todos os parâmetros necessários, sem a necessidade de passar valores do script de submissão.
Script de submissão exemplo_4_com_scripts_completos.srm
#!/bin/bash #SBATCH --nodes=2 #Numero de Nós #SBATCH --ntasks-per-node=24 #Numero de tarefas por Nó #SBATCH --ntasks=48 #Numero total de tarefas MPI #SBATCH -p cpu_small #Fila (partition) a ser utilizada #SBATCH -J exemplo_4 #Nome job #SBATCH --exclusive #Utilização exclusiva dos nós durante a execução do job #Exibe os nós alocados para o Job echo $SLURM_JOB_NODELIST nodeset -e $SLURM_JOB_NODELIST cd $SLURM_SUBMIT_DIR srun --resv-ports --nodes 1 --ntasks=1 -c 24 ${PWD}/script_intermediario_4_completo.1.sh & srun --resv-ports --nodes 1 --ntasks=1 -c 24 ${PWD}/script_intermediario_4_completo.2.sh & wait
script_intermediario_4_completo.1.sh - *DEVE SER EXECUTÁVEL
#!/bin/bash #Configura o executavel EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x #Exibe informações sobre o executável /usr/bin/ldd $EXEC #Inicia as execucoes $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & $EXEC parametro_1 parametro_2 .... parametro_N & wait
script_intermediario_4_completo.2.sh - *DEVE SER EXECUTÁVEL
#!/bin/bash #Configura o executavel EXEC=/scratch/app/NPB3.3.1-MZ/bin/cg.C.x #Exibe informações sobre o executável /usr/bin/ldd $EXEC #Inicia as execucoes $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & $EXEC parametro_A parametro_B .... parametro_XZY & wait
* Nesse caso é necessário um script específico para cada linha do srun.
* Esse script intermediário deverá conter todos os parâmetros necessários para a execução da aplicação, representados por “parametro_X.Y”
Ao submeter um job utilizando o OpenMPI 2.0, algumas aplicações apresentam o seguinte aviso no arquivo de log:
Esse é um problema recorrente e até o momento não apresentou problemas de desempenho nos benchmarks realizados.
É possível configurar o job para enviar uma notificação através do e-mail. Para utilizar essa funcionalidade, é necessário configurar as linhas abaixo no script de submissão:
#SBATCH --mail-type=TIPO
#SBATCH --mail-user=DESTINO
Onde TIPO é um dos possíveis valores:
DESTINO é o endereço de e-mail que receberá as notificações.
Múltiplos TIPOS podem ser especificados através de uma lista separada por vírgula.
Múltiplos DESTINOS também podem ser especificados através de uma lista separada por vírgula.
*ATENÇÃO: Ao configurar o envio de e-mail, verifique a caixa de Spam da sua conta se a notificação enviada pelo SLURM foi taxada como tal. Alguns servidores de E-Mail podem não identifcar a noticação como um e-mail válido.
O docker está instalado no SDumont. Antes de utilizá-lo, é necessário verificar se o usuário está inserido no grupo do docker, utilizando o comando id:
$ id
uid=6XXXX(username) gid=61YYYY(projeto) grupos=61YYYY(projeto),50000(docker)
Caso grupo 50000(docker) não aparece na saída do comando id, entre em contato com o Helpdesk-SDumont e solicite a inclusão do usuário no Grupo.
Se o usuário já tiver acesso ao grupo do docker: para garantir que o docker seja executado com o grupo correto, é necessário executar o comando de submissão através do comando 'sg grupo -c "comando de submissão"', conforme o exemplo abaixo:
sg docker -c "srun -N 1 -n 1 -p cpu_dev docker run hello-world"
ou
sg docker -c "sbatch script.srm"
Para Jobs Interativos (salloc) - Exemplo 2, ao acessar diretamente o nó de execução, não é necessário utilizar o comando sg para executar o docker.
O Path para o diretório de SCRATCH de Parceiros e ICTs da Petrobras sempre será /scratch/parceirosbr.
De acordo com o projeto que estiver trabalhado você deverá utilizar o subdiretório correspondente.
Se você participar de apenas um projeto de parceiros e ICTs poderá customizar sua variável SCRATCH nos arquivos de configuração da sua conta (~/.bashrc por exemplo).
Devido as particularidades da infraestrutura dos parceiros e ICTs da Petrobras, não é possível definir a variável $SCRATCH da mesma forma que é feito para os usuários do LNCC.
Não. O SDumont não possui licença para softwares proprietários. Sendo assim, esse softwares devem ser adquiridos pelo usuário.
Sim. Todos os nós tem acesso a internet.
Os usuários podem realizar a instalação de softwares em sua área de dados. Os softwares que serão utilizados nos nós de processamento devem ser instalados em um subdiretório do /scratch/projeto.
A equipe de suporte do SDumont também pode realizar a instalação dos softwares, mediante abertura de chamado.
Há alguns fatores que determinam o tempo de espera na fila e o início da execução dos jobs:
Os fatores de prioridade do SLURM são descritos em: https://slurm.schedmd.com/priority_multifactor.html#general
Resumindo, os principais fatores utilizados no SDumont para a composição da prioridade do job são:
Job_priority = Age + Fairshare + Partition + QOS
Cada um dos fatores acima possuem um peso que é multiplicado por um fator normalizado.
Age: Representa o tempo que um job está aguardando na fila e elegível para execução. Esse valor vai aumentando a medida que um job fica pendente na fila.
Fairshare: O componente de Fairshare para a prioridade de um job influencia a ordem em que os jobs na fila de um usuário são agendados para execução com base na parte dos recursos de computação que foram alocados e nos recursos que seus jobs já consumiram.
Partition: Cada fila possui um valor de prioridade específico. Quanto maior o número, maior será a prioridade do job nessa fila.
QOS: Cada QOS possui um valor de prioridade específico. Quanto maior o número, maior será a prioridade do job com essa QOS.
Para ter uma lista dos jobs em relação à prioridade (e seus fatores), é possível usar um dos comandos abaixo
"sprio -l" ou "sprio -l -p fila1,fila2"
ou
"squeue -O jobid,username:20,partition:20,PriorityLong" ou "squeue -O jobid,username:20,partition:20,PriorityLong -p fila1,fila2"
Caso um projeto já tenham utilizado todas as UA's solicitadas, ele não é impedido de utilizar o SDumont, porém a prioridade de seus jobs é reduzida. Através do SLURM é possível saber se um projeto já consumiu todas as UA's utilizando um dos seguintes comandos:
sacctmgr list user $USER -s format=partition%20,qos
squeue --me -O jobid,partition:20,qos
As QOSs usuais são "Normal" e "Low" (atribuída quando um projeto consumiu todas as UAs e que representa uma redução de 5% da prioridade).
Cada fila possui uma prioridade específica, sendo que as de desenvolvimento (*_dev) possuem uma prioridade maior do que outras, já que são de curta duração e com o intuito de testar jobs pequenos.
O SLURM utiliza um mecanismo de "backfill" para realizar a alocação dos jobs e iniciar sua execução. Esse mecanismo leva em consideração o tempo de duração (WallCLock) de todos os jobs e, com base nisso, calcula o tempo esperado de quando um job iniciará (entrará em execução). O mecanismo de backfill iniciará um job de menor prioridade se o seu tempo estimado de duração (conforme indicado pelo parâmetro "--time" na submissão com sbatch) não for atrapalhar o início de um job de maior prioridade. Dessa forma, quanto menor for o tempo estimado de duração de um job, maior será a sua chance de entrar em execução.
Muitas das filas compartilham os nós de computação, o que aumenta o tempo de espera. Por exemplo, a fila cpu e cpu_long compartilham os mesmos nós. Dessa forma, alguns nós podem ficar alocados na fila cpu_long por até 30 dias, aumentando o tempo de espera na fila cpu. Importante ressaltar que (1) quando um nó está alocado em uma fila, ele não fica disponível para as outras, mesmo que nele esteja sendo utilizado apenas 1 core; e (2) as filas *_shared não possuem nós compartilhados com outras filas, porém elas permitem o compartilhamento jobs no nó de execução.
Um fator importante e que influencia no aumento do tempo de espera na fila é o constante crescimento do número de usuários utilizando o SDumont.
squeue --start
Exibe o tempo esperado de quando um job pendente entrará em execução (coluna START_TIME). A data prevista informada pelo parâmetro "--start" é constantemente alterada levando em conta esses fatores. Dependendo dos recursos solicitados (tempo de execução, número de nós/cores), alguns jobs acabam aguardando na fila por um tempo maior que o esperado.