Perguntas Frequentes

Esta Seção é voltada a responder a dúvidas frequentes dos usuários do GridUnesp. Em geral, são perguntas sobre acesso ao cluster, instalações de pacotes, processamento e acompanhamento dos jobs e falhas na execução das simulações.

Sumário

Acesso ao GridUnesp

1) Como obter ajuda para utilizar o GridUnesp?

Resposta

Entre em contato com a equipe de especialistas do GridUnesp enviando mensagem para support.ncc@unesp.br.

Caso esteja com problemas em relação ao job (à simulação), envie na mensagem informações suficientes e adequadas para que a equipe de especialistas do GridUnesp consiga ter o melhor entendimento possível sobre a situação. Informe, por exemplo:

  • a localização do script de submissão e dos arquivos e pastas de input;

  • a localização dos arquivos de log (slurm-jobID.out);

  • o comando usado para submeter o job;

  • e, se possível, o(s) número(s) do(s) job(s) em questão.

2) Como faço login no GridUnesp?

Resposta

Caso tenha um computador baseada em Unix (Linux, Mac), basta abrir um terminal e digitar

$ ssh username@access.grid.unesp.br

em que username é o login de usuário que você escolheu no processo de cadastro.

Caso seu computador tenha sistema operacional Windows, consulte a Seção Acessando o Cluster.

Aviso

Alguns usuários mais antigos talvez ainda tentem fazer login pelo servidor access.grid.unesp.br. Contudo, este servidor foi desligago permanentemente. Agora, o acesso ao cluster é através do servidor access2.grid.unesp.br.

Para mais informações, consulte a Seção Acessando o Cluster.

3) Não lembro minha senha. Como faço para resetar?

Resposta

Acesse a página

e informe o username ou e-mail cadastrado no GridUnesp. Um token para troca será enviado ao email cadastrado.

É fundamental utilizar senhas consideradas fortes em que:

  • haja um mínimo de 8 caracteres;

  • não contenha uma simples palavra comum;

  • contenha letras minúsculas, maiúsculas, números e símbolos (!, $, %, @, #, …).

Importante lembrar que as senhas devem ser alteradas em intervalos regulares (e.g., a cada ano) e que as novas senhas não devem ser iguais ou simples derivações das senhas passadas. Também é possível utilizar geradores de senha aleatória:

4) Ao tentar fazer login no GridUnesp, aparece “The authenticity of host ‘access2.grid.unesp.br (200.145.46.48)’ can’t be established”. O que isso significa?

Resposta

Ao acessar o servidor access2.grid.unesp.br pela primeira vez, seu client de conexão segura irá perguntar se você a reconhece como uma máquina confiável. Você deve verificar se a chave é igual à exibida abaixo e confirmar, digitando yes:

The authenticity of host 'access2.grid.unesp.br (200.145.46.48)' can't be established.
RSA key fingerprint is SHA256:WVFokXOLnuH9+2e7xxRU2gp7XJqxwuE6H8bbUMqTCXo.
Are you sure you want to continue connecting (yes/no)?

5) Ao tentar fazer login no GridUnesp, aparece “WARNING: POSSIBLE DNS SPOOFING DETECTED!”? O que isso significa?

Resposta

É possível que o usuário esteja há algum tempo sem fazer login no cluster do GridUnesp e, devido a mudanças na configuração do sistema como a modificação do servidor de acesso, poderá aparecer uma mensagem de erro com o seguinte conteúdo:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for access2.grid.unesp.br has changed,
and the key for the corresponding IP address 200.145.46.48
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:WVFokXOLnuH9+2e7xxRU2gp7XJqxwuE6H8bbUMqTCXo.
Please contact your system administrator.
Add correct host key in /home/username/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/username/.ssh/known_hosts:13
  remove with:
  ssh-keygen -f "/home/username/.ssh/known_hosts" -R "access2.grid.unesp.br"
ECDSA host key for access2.grid.unesp.br has changed and you have requested strict checking.
Host key verification failed.

Se o usuário está usando um computador Linux, bastar dar o seguinte comando:

$ ssh-keygen -f "/home/username/.ssh/known_hosts" -R "access2.grid.unesp.br"

Estando o usuário utilizando um computador Mac, o comando é:

$ ssh-keygen -f "/Users/username/.ssh/known_hosts" -R "access2.grid.unesp.br"

Aviso

Note aque, aqui, username é o login do computador pessoal do usuário, e não o login de acesso ao GridUnesp.

Finalmente, basta tentar acessar o cluster novamente, mas agora como o login do GridUnesp.

Para mais informações, veja a Seção Confirmação de segurança.

6) Por que não consigo fazer login?

Resposta

Devido a alguma falha na internet, o usuário pode perder a conexão. Todavia, pode ocorrer do usuário estar errando a senha e, por isso, ter sido bloqueado pelo sistema Fai2Ban. Por questões de segurança, o sistema bloqueia o usuário (por 15 minutos) toda vez que:

  • erra a senha várias vezes;

  • usa o comando scp várias vezes em um curto espaço tempo;

  • ou faz login de vários terminais em um curto espaço de tempo.

Para mais informações, veja a Seção Bloqueio de usuário.

7) Estava conectado no GridUnesp e de repente o terminal travou. Por quê?

Resposta

Devido a alguma falha na internet, o usuário pode perder a conexão. Todavia, pode ocorrer do usuário estar errando a senha e, por isso, ter sido bloqueado pelo sistema Fai2Ban. Por questões de segurança, o sistema bloqueia o usuário (por 15 minutos) toda vez que:

  • erra a senha várias vezes;

  • usa o comando scp várias vezes em um curto espaço tempo;

  • ou faz login de vários terminais em um curto espaço de tempo.

Para mais informações, veja a Seção Bloqueio de usuário.

8) Não sei o que fazer depois de acessar minha conta no GridUnesp. Pode me ajudar?

Resposta

Em linhas gerais, a razão para um professor, pesquisador ou estudante ter acesso a uma infraestrutura de computação de alta performance (HPC) é poder aproveitar o poder computacional (grande capacidade de armazenamento e processamento de dados) e a comodidade de deixar um programa, software, aplicação executando por um longo período (dias talvez) sem ter que se preocupar com falta de energia, falha de internet, superaquecimento do computador ou memória limitada, por exemplo.

O usuário iniciante pode começar procurando se informar sobre o uso do cluster através da documentação do GridUnesp

Há vários exemplos de scripts de submssião de simulações e comandos a serem usados para monitorar o processamento, além de informações sobre o funcionamento do cluster e instruções necessárias para executar aplicações científicas na Seção Manual do Usuário.

Necessitando de ajuda, o usuário sempre pode enviar mensagem para a lista de suporte (support.ncc@unesp.br).

9) É possível acessar o GridUnesp via browser?

Resposta

Não. Apenas é possível acessar o GridUnesp via SSH pelo terminal.

Transferência de arquivos

10) Como transfiro arquivos para minha conta do GridUnesp?

Resposta

Supondo que um usuário queira transferir um arquivo chamado “test.data” para seu diretório /home/ no GridUnesp. A partir do computador pessoal, caso utilize sistema Linux ou Mac, poderá dar o seguinte comando no terminal:

scp test.data username@access2.grid.unesp.br:/home/username/.

em que username é o login do usuário escolhido durante do cadastro.

Caso queira saber como fazer a transferência a partir de um computador pessoal com sistema operacional Windows, consulte a Seção Transferindo Arquivos.

11) Como transfiro arquivos do GridUnesp para meu computador pessoal?

Resposta

Supondo que um usuário queira transferir um arquivo chamado “test.data” da conta do GridUnesp (/home/username/test.data) para seu computador pessoal. A partir do computador pessoal, caso utilize sistema Linux ou Mac, poderá dar o seguinte comando no terminal:

scp username@access2.grid.unesp.br:/home/username/test.data .

em que username é o login do usuário escolhido durante do cadastro.

Observe o ponto (.) ao final do comando. Ele indica que o arquivo “test.data” deverá ser transferido para a pasta corrente no computador pessoal.

Será solicitado informar a senha de acesso ao GridUnesp. Após digitar a senha e apertar o [Enter], o arquivo “test.data” será transferiado para o computador do usuário.

Caso seja usuário de Windows, poderá usar um software como o WinSCP para fazer a transferência.

Para mais informações, consulte a Seção Transferindo Arquivos.

Instalação de programas, softwares e bibliotecas

12) Estou tentando instalar um software, mas não tenho permissão de administrador. O que faço?

Resposta

O usuário do GriUnesp pode realizar instalação de aplicações científicas em seu próprio /home/. Muitos dos programas e bibliotecas permitem que a instalação seja feita em diretórios/pastas diferentes daquelas normalmente usadas como /usr/, /lib/. No entanto, caso não faça as configurações necessárias, poderá obter mensagens de erro, como falta de permissão.

Em todo caso, também é possível solicitar que a instalação seja feita pela equipe de suporte do GridUnesp.

Para mais informações, consulte a Seção Instalando Aplicações.

13) Como faço para instalar um software/aplicação/biblioteca no GridUnesp?

Resposta

Muitas aplicações científicas, softwares e bibliotecas podem ser instaladas em locais diferentes, como no /home/ do usuário. Basta fazer as devidas configurações durante a instalação. Algumas são facilmente instaladas usando o ambiente Anaconda.

Há casos em que a instalação é demasiada complexa, ou em que há o desejo de a aplicação/biblioteca ser disponibilizada para vários usuários. Neste caso, basta informar à equipe de especialistas do GridUnesp (support.ncc@unesp.br) a aplicação/biblioteca de interesse, bem como o link do site de referência contendo informações de como realizar a instalação.

Para mais informações, consulte a Seção Instalando Aplicações.

Processamento de simulações

14) Posso processar simulações no meu /home do GridUnesp?

Resposta

Depende.

O servidor access2.grid.unesp.br não deve ser usado para executar simulações. Ele serve apenas como local de acesso à conta do usuário para preparar o ambiente e enviar as simulações para serem executadas nos worker nodes (nós de processamento).

Todavia, pré e pós processamentos que demandem um curtíssimo tempo de execução e pouca memória 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.

Para mais informações, consulte a Seção Processando Simulações.

15) Como executar simulações no GridUnesp?

Resposta

O usuário deve preparar o ambiente de trabalho com os arquivos de input necessários e construir um scripts de submissão de simulações (jobs) para processamento nos worker nodes (nós de processamento). Esse script (vamos chamar de “sumit_job.sh”, por exemplo) é escrito em linguagem Bash e deve conter diretivas que podem ser lidos pelo escalonador de jobs (Slurm).

Para enviar um job para processamento, deve-se usar o comando

sbatch sumit_job.sh

Para obter mais informações sobre como processar simulações no GridUnesp, consulte a Seção Processando Simulações. Informações sobre construção de scripts e monitoramento de jobs estão na Seção Melhorando o Script de Submissão.

16) Como eu crio um script de submissão de jobs?

Resposta

Consulte as seções Processando Simulações e Melhorando o Script de Submissão. Nelas o usuários encontrará informações detalhadas e vários exemplos.

Monitoramento dos Jobs

17) Por quanto tempo meu job pode ficar processando no GridUnesp?

Resposta

São de 30 dias o tempo máximo de processamento de simulações. Para obter mais informações e saber como configurar o tempo máximo de processamento, consulte a seção Sistema de Filas.

18) Há quantas filas/particões no GridUnesp?

Resposta

O GridUnesp conta com 3 filas de jobs diferentes:

  • short (24 horas);

  • medium (7 dias);

  • long (30 dias).

Uma vez atingido o limite de tempo solicitado para determinada simulação, caso o processamento ainda esteja em execução, o job será cancelado por TIMEOUT.

Para obter mais informações e saber como configurar o tempo máximo de processamento, consulte a seção Sistema de Filas.

19) Como sei que meu job começou a processar?

Resposta

Através do comando (em que username é o login do usuário)

squeue -u username

é possível verificar se o job já está em processamento ou se ainda está pendente de recursos. Caso já esteja em execução, aparecerá R no status. Porém, caso a simulação ainda esteja esperando a liberação de recursos, aparecerá o status PD.

À medida que os jobs já em execução forem finalizando, os recursos do cluster vão sendo liberados para aqueles em PD.

Para obter mais informações, consulte a seção Monitorando Simulações.

20) Por que meu job está demorando tanto para começar a processar?

Resposta

Em geral, caso um job esteja demorando muito tempo para iniciar o processamento, é porque há outros jobs na fila que estão consumindo os recursos do cluster, não havendo ainda os recursos solicitados pela simulação do usuário.

Para ver todos os jobs que estão em execução, o comando é

squeue -a

Para saber o total de jobs na fila, o comando é

squeue -a | wc -l

Para saber o total de jobs pendentes de recursos, o comando é

squeue -a | grep PD | wc -l

Para saber a ordem de prioridade dos jobs pendentes de recursos, o comando é

squeue -o "%.18i %.9Q %.8j %.8u %.10V %.6D %R" --sort=-p,i --states=PD

No entanto, pode ocorrer de haver alguma falha no script de submissão do job que acaba demandando por recursos impossíveis de ser atendidos pelo sistema. Assim, caso o usuário tenha solicitado 50000 CPUs, ou 60 dias de tempo máximo de processamento, por exemplo, o job ficará pendente indefinidamente.

Para obter mais informações, consulte as seções Monitorando Simulações e Política de Prioridade.

21) Existe alguma previsão de quando meu job vai começar a processar?

Resposta

Quando o usuário submete jobs para processamento, ele solicita um tempo máximo em que o job pode ficar processando. No entanto, o tempo exato de duração é um dado desconhecido pois depende de diversos fatores, como a latência na transferência e na leitura e na escrita de dados. Além disso, se, por qualquer razão que seja, um ou mais jobs venha(m) a falhar, os recursos em uso são imediatamente liberados para os jobs que se encontram pendentes na fila.

Em suma, o tempo que um job irá esperar na fila para começar a processar depende de fatores não determinísticos.

22) Por que meus jobs não começaram a processar enquanto outros usuários tem tantos jobs em execução?

Resposta

O cluster do GridUnesp está configurado para não haver recursos idle (ociosos). Assim, em períodos em que os recursos do GridUnesp estão sendo bastante demandados, um job submetido que solicita 28 CPUs pode ter que ficar esperando por um tempo significativo na fila. Por outro lado, um job que seja submetido logo na sequência e que esteja solicitando apenas 2 CPUs acaba obtendo prioridade, conseguindo “passar na frente” daqueles que demandam mais recursos.

O cálculo da prioridade de um job na fila leva em conta a política de Fair Share, o que envolve fatores como:

  • tempo máximo de processamento, número de CPUs e número de nós demandados;

  • quantidade de membros no grupo do usuário;

  • quantidade total de recursos até então usados pelas simulações do usuário.

Para obter mais informações, consulte as seções Política de Prioridade e Otimizando o Desempenho.

Falhas no processamentos

23) Meu job foi cancelado por TIMEOUT. O que isso significa?

Resposta

Uma vez atingido o limite de tempo solicitado para determinada simulação, caso o processamento ainda esteja em execução, o job é cancelado por TIMEOUT.

Para obter mais informações e saber como configurar o tempo máximo de processamento, consulte a seção Sistema de Filas.

24) Meu job foi cancelado por falta do INPUT. O que isso significa?

Resposta

O script job-nanny serve para evitar que as aplicações científicas façam leitura e escrita diretamente na partição /home/, o que poderia levar a uma sobrecarga na rede devido à grande transferência de arquivos entre esta partição e os nós de processamento. Assim, o script job-nanny verifica obrigatoriamente parâmetros como INPUT e OUTPUT.

Caso o usuário não especifique algum desses parâmetros no script de submissão, o job será cancelado.

Para mais informações, consulte a seção Script job-nanny.

25) Meu job foi cancelado por falta do OUTPUT. O que isso significa?

Resposta

O script job-nanny serve para evitar que as aplicações científicas façam leitura e escrita diretamente na partição /home/, o que poderia levar a uma sobrecarga na rede devido à grande transferência de arquivos entre esta partição e os nós de processamento. Assim, o script job-nanny verifica obrigatoriamente parâmetros como INPUT e OUTPUT.

Caso o usuário não especifique algum desses parâmetros no script de submissão, o job será cancelado.

Para mais informações, consulte a seção Script job-nanny.

26) Por que meu job falhou?

Resposta

Muitas são as razões que podem levar uma simulação a falhar:

  • falta de arquivos de input;

  • falha no código do usuário;

  • falha no(s) arquivo(s) de input;

  • falha na declaração de variáveis de ambiente;

  • falha na compilação de executáveis e bibliotecas;

  • memória insuficiente para processamento da simulação;

  • atingimento do limite máximo de tempo de processamento solicitado etc.

Em geral, a simples análise dos arquivos de log e/ou output ajudam a verificar a fonte do problema. O nome padrão dos arquivos de log no GridUnesp tem o formato

slurm-<job_ID>.out

em que <job_ID> é o número do job correspondente.

Caso o usuário não consiga descobrir a origem do problema, pode enviar mensagem para a lista de suporte (support.ncc@unesp.br). Na mensagem devem constar informações suficientes e adequadas para que a equipe de especialistas do GridUnesp consiga ter o melhor entendimento possível sobre a situação. Informe, por exemplo,:

  • a localização do script de submissão e dos arquivos e/ou pastas de input;

  • a localização dos arquivos de log (slurm-jobID.out);

  • o comando usado para submeter o job;

  • e, se possível, o(s) número(s) do(s) job(s) em questão.

Optimização das simulações

27) O que faço para o processamento do meu job ficar mais rápido?

Resposta

É possível aumentar a quantidade de memória utilizando os parâmetros

  • -c (CPUs por processo);

  • --mem (memória por nó, em MB);

  • --mem-per-cpu (memória por CPU, em MB).

No entanto, dependendo do programa/aplicação, disponibilizar mais memória não necessariamente fará com que o processamento seja mais rápido. Deve-se analisar caso a caso.

Ainda é possível dividir o processamento em várias tarefas (vários processos) utilizando o parâmetro -n. Porém, isso só funciona se o programa/aplicação tiver sido desenvolvido para suportar a opção de Memória Distribuída.

Para mais informações, consulte as seções Melhorando o Script de Submissão, Memória Compartilhada e Memória Distribuída.

28) Quantas CPUs/threads posso solicitar para o meu job?

Resposta

Cada um dos 56 nós de processamento conectados ao servidor access2.grid.unesp.br posssui 28 núcleos cada (com hyperthread ativado). Ou seja, são 56 CPUs por nó.

Cada CPU tem 2 GB, totalizando 128 GB de memória RAM.

Para mais informações, consulte a seção Cluster do GridUnesp.

29) Tem GPU no GridUnesp?

Resposta

Não. A inclusão de GPU já consta nos planos do Núclo de Computação Científica da Unesp (NCC/Unesp) para as próximas aquisições de hardware, estando pendente de suporte financeiro/orçamentário.

30) Como faço para processar simulações com várias CPUs?

Resposta

Basta informar (no script de submissão) a quantidade de CPUs desejada através do parâmetro -c. Supondo que se deseja realizar o processamento de um job com 16 CPUs. Bata solicitar esses recursos no script de submissão:

#!/bin/bash
#SBATCH -c 16

Para mais informações, consulte a seção Melhorando o Script de Submissão. Talvez seja importante também consultar a seção Memória Compartilhada.

31) Como faço para processar jobs em paralelo?

Resposta

É possível usar o conceito de memória distribuída. Para isso, deve-se informar ao sistema (no script de submissão) a quantidade de processos através do parâmetro -n, além de carregar o módulo da Intel

#!/bin/bash
#SBATCH -n 4

module load intel/compilers/2017
module load intel/mpi/2017

ou carregar o módulo do OpenMP

#!/bin/bash
#SBATCH -n 4

module load openmpi/4.0.1

Caso seja possível ao programa/aplicação correspondente, outra opção para processar jobs em paralelo seria utilizar o conceito de job array, o qual consiste em dividir o trabalho em vários trabalhos menores e executar várias simulações simultaneamente.

Para mais informações, consulte as seções Melhorando o Script de Submissão, Memória Distribuída e Job Array.

32) Como faço para usar ferramentas MPI?

Resposta

Deve-se informar ao sistema (no script de submissão) a quantidade de processos através do parâmetro -n, além de carregar o módulo da Intel:

#!/bin/bash
#SBATCH -n 4

module load intel/compilers/2017
module load intel/mpi/2017

Para mais informações, consulte a seção Memória Distribuída.

33) Como configurar determinada quantidade de nós de processamento?

Resposta

Caso a simulação do usuário esteja preparadda para trabalhar com Memória Distribuída, é possível informar qual o número exato de nós de processamento (worker nodes) que deseja alocar. Isso é feito usando a opção -N do SBATCH. Veja a seção Melhorando o Script de Submissão.

Digamos que o usuário deseje espalhar 18 processos por 4 nós. Isso seria possível usando algo como:

#!/bin/bash
#SBATCH -n 18 -N 4

module load intel/compilers/2017
module load intel/mpi/2017

Contudo, em algumas situações (como quando a fila de jobs está consideravelmente grande), pode ser mais interessante ao usuário não especificar uma quantidade exata de worker nodes, mas delimitar quantidades mínima e máxima, deixando a decisão para o escalonadador do sistema (Slurm). Como exemplo, digamos que o usuário deseje espalhar 18 processos entre 2 e 4 nós. Isso poderia ser feito com o seguinte exemplo de script de submissão:

#!/bin/bash
#SBATCH -n 18 -N 2-4

module load intel/compilers/2017
module load intel/mpi/2017

Quando apenas um único valor é especificado, o sistema identifica as quantidades mínima e máxima de nós como sendo as mesmas: -N 4, por exemplo, é equivalente a -N 4-4.

34) É possível enviar vários jobs de uma vez com um único comando sbatch?

Resposta

Sim. Para isso, deve-se usar o conceito de job array, o qual consiste em dividir o trabalho em vários trabalhos menores e executar várias simulações simultaneamente.

Ao informar uma sequência de valores ao parâmetro -array no script de submissão, o sistema identifica o job como sendo, na verdade, vários jobs distintos:

#!/bin/bash
#SBATCH --array=1-7:2

Para mais informações, consulte a seção Job Array.

35) Por que o processamento do meu job é mais rápido quando uso um único nó do que quando uso vários?

Resposta

De acordo com a maneira como o GridUnesp está configurado atualmente, algumas aplicações têm seu desempenho diminuído drasticamente caso utilize processos espalhados por vários nós. De acordo com o explicado na seção Informações sobre o Storage, ao solicitar vários worker nodes, o job utiliza a partição /store/, a qual é um file system compartilhado entre os nós. Isso significa que poderá haver um problema de latência (demora na comunicação): os nós precisam realizar uma comunicação entre si, além do tempo de transferência de dados na rede e do tempo de leitura e escrita naquela partição.

Por outro lado, utilzando processos que envolvam apenas 1 worker node, os dados são armazenados na partição /tmp/ do nó, então a escrita e leitura é feita diretamente nesse disco, aumentando assim o desempenho do processamento.

Contudo, cada caso é um caso, cada software é um software, e precisa testar para verificar em quais situações vale a pena concentrar o processamento em apenas um worker node ou não. Em alguns casos - principalmente em períodos em que o cluster está sendo bastante demandado e o tempo de espera para disponibilização de recursos é significativo - talvez valha a pena espalhar o processamento em vários nós, ainda que a aplicação tenha sua enficiência reduzida.

Para mais informações, consulte a seção Otimizando o Desempenho.

36) O GridUnesp utiliza rede InfiniBand ou Ethernet?

Resposta

O GridUnesp atualmente trabalha com rede Ethernet.

Há alguns anos, o GridUnesp possuía uma rede InfiniBand, considerada bastante rápida e adequada a várias aplicações científicas. Esse equipamento, contudo, é muito caro, tornando inviável sua manutenção a longo prazo.

Com o advento do upgrade do cluster em 2017/2018, a comunicação entre os nós de processamentos e com o storage passou a ser feita por uma rede Ethernet 40 GB/s.

Boas práticas de uso

37) Minha simulações têm arquivos muito grandes? Tem algum problema?

Resposta

Para simulações que sejam processadas em apenas um worker node (nó de processamento), o sistema utiliza a partição /tmp/ do próprio woker node para leitura e escrita de dados. Esse disco tem cerca de 120 GB, sendo utilizado por todas as simulações em processamento no nó. Assim, caso os arquivos/pastas de input e output do job somem apenas alguns gigabytes, não há problema algum para a normalidade operacional do sistema.

Contudo, caso os inputs e outputs somem algumas dezenas de gigabytes, o usuário deve tomar o cuidado de “obrigar” o job a utilizar a partição /store/ (em vez da /tmp/ do nó). A partição /store/ é um file system compartilhado entre os worker nodes e possui terabytes de espaço, sendo mais seguro em cenários cujos jobs demandem um espaço considerável de armazenamento.

Para informar ao sistema que a simulação deve usar o /store/, basta o usuário editar o script de submissão incluindo uma das linhas seguintes:

export LARGE_FILES="true"

export SHARED_FS="true"

Caso o script de submissão demande expressamente mais de 1 nó (-N 3, por exemplo), a opção por usar a partição /store/ é automática, não necessitando informar as linhas acima.

Para mais informações sobre as partições, consulte as seções Informações sobre o Storage e Parâmetros do job-nanny.

38) Como faço para usar o /store/ em vez do /tmp/?

Resposta

Para informar ao sistema que a simulação deve usar o /store/, basta o usuário editar o script de submissão incluindo uma das linhas seguintes:

export LARGE_FILES="true"

export SHARED_FS="true"

Caso o script de submissão demande expressamente mais de 1 nó (-N 3, por exemplo), a opção por usar a partição /store/ é automática, não necessitando informar as linhas acima.

39) Como faço para usar o /tmp/ em vez do /store/?

Resposta

Para informar ao sistema que a simulação deve usar o /tmp/, basta o usuário editar o script de submissão incluindo uma das linhas seguintes:

export LARGE_FILES="false"

export SHARED_FS="false"

Caso o script de submissão demande expressamente mais de 1 nó (-N 3, por exemplo), a opção por usar a partição /store/ é automática.

Já quando o usuário demanda que a execução do job seja realizada utilizando vários processos através de memória distribuída (veja a seção Memória Distribuída), pode ocorrer do Slurm (o sistema escalonador de jobs) distribuir os processos em vários nós. Caso queira, o usuário pode forçar que o processamento seja feito em apenas 1 worker node. Para isso, basta usar -N 1.

40) Posso deixar meus arquivos guardados no GridUnesp?

Resposta

Em regra, não. Apenas arquivos e pastas necessários à realização de futuras simulações podem ser mantidas no cluster. Os recursos do GridUnesp são compartilhados por centenas de usuários e, dado que os recursos são finitos, deve-se evitar usar o espaço em disco como uma cloud pois, caso o armazenamento atinja 100% de uso, todo o sistema começa a falhar, afetando inclusive os jobs dos usuários. Além disso, em caso de falha irrecurperável, os dados podem ser perdidos.

Para mais informações, consulte a seção Manutenção dos Dados.

41) Como faço para apagar arquivos da minha conta?

Resposta

Utilize o comando rm. Veja exemplos na seção Manutenção dos Dados.

42) Tem algo que eu possa fazer para contribuir para manter o GridUnesp em bom funcionamento?

Resposta

Sim. Compliance é fundamental para a normalidade operacional de qualquer sistema e/ou instituição. E com o GridUnesp não é diferente.

Os usuários cadastrados no GridUnesp devem seguir as normas da seção Boas Práticas sobre as regras que envolvem compartilhamento, manutenção e processamento de dados, bem como devem sempre ser diligentes no cumprimento da Política de Uso do GridUnesp (veja a seção Política de Uso).

Outros tipos de dúvidas

43) O GridUnesp usa Ubuntu?

Resposta

Não. O cluster utiliza distribuição AlmaLinux ( e não Ubuntu, como se poderia supor). Isso significa que, caso, em situações bastante excepcionais, seja necessário a equipe do GridUnesp fazer instalações na raiz do sistema, seria utilizado o comando yum install (em vez do apt-get install do Ubuntu).

Anteriormente o cluster era baseado em Linux com distribuição CentOS. Felizmente a distribuição corrente (AlmaLinux) apresenta compatibilidade 1 para 1 com CentOS. Ou seja, todos os comandos que eram usados para CentOS funcionam igualmente para AlmaLinux.

44) Qual é o sistema operacional do GridUnesp? Linux ou Windows?

Resposta

O cluster está baseado em sistema operacional Linux com distribuição AlmaLinux.

45) É possível usar programs interativos no GridUnesp?

Resposta

Sim. Digamos que um usuário chamado Spock, cujo login no GridUnesp seja spock, queira abrir o arquivo submit_job.sh com o editor Nedit a partir do /home/ do servidor acess2. Esse programa permite opções interativas de edição. Primeiramente, teria que fazer login com a opção -X:

ssh -X spock@access2.grid.unesp.br

Depois, abriria o arquivo:

nedit submit_job.sh &

Atenção

Os jobs no GridUnesp são submetidos utilizando batch mode (script de submissão via linha de comando com sbatch) em vez de ambientes gráficos.

Além disso, não é recomendada a submissão de jobs em modo interativo. Todavia, é possível usar o comando salloc para jobs interativos em batch mode, desde que sejam usados apenas para teste de scripts de submissão e depuração de problemas nos programas ou aplicações científicas usados/as pelos usuários. Para entender como usar essa opção, o usuário pode consultar páginas como

https://slurm.schedmd.com/salloc.html http://manpages.ubuntu.com/manpages/bionic/man1/salloc.1.html

46) Como abrir aplicações visuais no GridUnesp?

Resposta

Digamos que um usuário chamado Spock, cujo login no GridUnesp seja spock, queira abrir o arquivo submit_job.sh com o editor Nedit a partir do /home/ do servidor acess2. Esse programa permite opções interativas de edição. Primeiramente, teria que fazer login com a opção -X`:

ssh -X spock@access2.grid.unesp.br

Depois, abriria o arquivo:

nedit submit_job.sh &

47) Está difícil resolver o problema com minha simulação. Seria possível ter uma conversa por vídeo conferência?

Resposta

Sim. Envie mensagem para a lista de suporte (support.ncc@unesp.br) explicando suncitamente o problema. Uma pessoa do time de especialistas do GridUnesp analisará o caso e, dependendo do cenário, ele irá retornar o contato propondo uma solução ou marcando uma conversa por vídeo conferência em dia e hora a serem combinados.