Como rodar seu experimento

Página em construção

Os passos a seguir atendem para a grande maioria dos experimentos, se tem necessidade de algo diferente ou mais específico, procure um membro da equipe de infraestrutura do VeRLab/JLab.

Infraestrutura da rede VeRLab/JLab

• A equipe de infraestrutura é composta por membros do VeRLab/JLab que trabalham de forma voluntária para manter o melhor possível a disponibilidades dos serviços e equipamentos. Se tiver interesse em participar e aprender, procure um dos professores ou membro da equipe para ajudar.

• A rede é composta em sua maioria por Servidores de processamento e Desktop com S.O. Ubuntu em que cada usuário consegue realizar autenticação com sua senha.

Pasta home

Cada usuário da rede tem uma pasta pessoal montada automaticamente em todas as máquinas no path: /home/<nome_usuario> .

Essa é a home do seu usuário e ela está mapeada em rede e tem uma quota de tamanho limitado. O objetivo dessa pasta é armazenar apenas arquivos menores como códigos fonte, scripts, artigos, arquivos .pdf e etc.

Não armazene datasets, programas ou arquivos grandes (>10GB), temos outra solução para isso na rede explicado a seguir.

A pasta home não tem um backup, mas ela é armazenada de forma redundante com duas cópias em servidores diferentes, de modo que se um servidor/disco falhar, um segundo disponibiliza a cópia dos arquivos.

Pastas draft-xxx - armazenamento local

Para armazenar, de forma local na máquina, arquivos maiores como datasets e resultados de experimentos, fica disponível uma "pasta de rascunho" no caminho /draft-xxx (antigamente era chamada /homeLocal).

A pasta draft-xxx só tem visibilidade local, não fica em rede, ou seja, ela só está disponível na máquina específica, não é disponível em todas as máquinas ao mesmo tempo. Mas tem a vantagem de ter uma alta taxa de I/O (escrita e leitura), já que são discos conectados no barramento da placa-mãe. Assim a tendência de experimentos que precisam escreve/ler constantemente do disco executarem mais rápido na pasta local /draft-xxx do que na pasta em rede da storage (explicado a seguir).

As pastas /draft-xxx são usadas para montar os discos/partições extras da máquina. Esses espaços de armazenamento são independente do disco/partição que tem o S.O. Ubuntu, mas não tem qualquer tipo de backup ou redundância, então sempre tenha repositórios para salvar cópias de backup dos seus códigos e scripts.

Existe um esforço continuo da equipe de infraestrutura em manter os armazenamentos sempre operando e de forma confiável, o que dá uma "sensação de que nunca estragam", mas pode ocorrer.

Os caminhos mudam o "xxx" de acordo com o tipo de tecnologia de armazenamento:

caminho	tipo de armazenamento	Taxa de I/O máxima típica*	Obs
/draft-hdd	disco magnético (HDD SATA)	Read ~180MB/s Write ~140MB/s	Usualmente temos discos maiores ~2TB - 4TB
/draft-ssd	SSD SATA	Read ~500MB/s Write ~400MB/s	Em geral, espaço menor, ~ 480GB - 1TB
/draft-nvme	SSD NVMe	Read ~2400MB/s Write ~1500MB/s	Em geral, espaço menor, ~ 480GB - 1TB

• Atenção: Essas taxas de I/O são típicas e teóricas, apenas para comparação entre as velocidades de cada tecnologia de armazenamento, não são os valores reais de R/W que teremos nas máquinas.

Mas podemos deduzir que os discos HDD serão um pouco mais lentos, mas terão maior espaço disponível. Por outro lado, os SSD e NVMe serão mais rápidos e com menor espaço.

Esse espaço de armazenamento não tem uma quota específica por usuário, então deve ser bom senso de todos limpar os dados dessas pastas quando parar de utilizar. Tem sido recorrente os usuários "esquecerem" dados antigos nessas pastas, então lembre-se de liberar seus dados para permitir que outro usuários tenham espaço em disco disponível quando necessitarem.

O usuário que desejar baixar datasets, criar container singularity e fazer um experimento nas pastas /draft-xxx, deve solicitar à equipe de infraestrutura para criar uma subpasta para seu usuário, por exemplo, /draft-hdd/<usuario>

Pastas /srv/storage/forge - armazenamento em rede (Serviço de storage)

Também temos o serviço de storage, popularmente chamado apenas de storage, que visa armazenar arquivos maiores como datasets e resultados de experimentos, mas remotamente e disponível em rede.

A grande vantagem é que todas as máquinas vão er acesso aos dados, porém a taxa de I/O cria tráfego na rede e pode sofrer lentidão se muitos experimentos estão sendo executados, ou se o serviço de storage está sobre carregado. Em geral, a taxa de I/0 pode ser mais baixa que as pastas draft mas é o custo benefício para executar experimentos compartilhando dados em mais de uma máquina simultaneamente.

Existe um esforço da equipe de infraestrutura de manter o serviço de storage estável e online, mas algumas queda de energia e defeitos em disco podem ocorrer, mesmo que com uma baixa frequência.

O que você precisa

1. Possuir um login no laboratório
2. Criar seu ambiente de execução usando o Singularity
3. Procurar na planilha de "Dados Gerais das Máquinas" um servidor de processamentos que atenda a seus requisitos de hardware na na área restrita do site (mesma credencial das máquinas)
4. Preencher a intenção de uso da máquina na planilha de "Utilização e Experimentos com GPUs e CPUs" na área restrita do site (mesma credencial das máquinas)

Antes de rodar seu experimento

1. Verifique na "planilha de utilização das máquinas" se a máquina está disponível e preencha uma reserva para seu usuário. Caso a máquina esteja ocupada, verifique a próxima data disponível e preencha a reserva.
2. Quando estiver logado na máquina, verifique se os recursos computacionais estão livres:
   • Pode-se ter uma ideia geral na página da Grafana que tem link e instruções de login na área restrita do site do Verlab
     Infelizmente a Grafana está desativada no momento, precisamos de ajuda para colocar ela online novamente!
   • Parte 1: uso da CPU e RAM pode-se usar o htop ( como usar o htop )
   • Parte 2: uso da GPU (placa de vídeo) , pode-se rodar nvidia-smi .
     Os processos que estiverem carregados na memória da GPU além o Xorg (mesmo que com zero de processamento) mostram que tem usuários utilizando e vão precisar de algum recurso de CPU e RAM para a troca de contexto de seu experimento.
3. Se a máquina estiver ocupada, pode-se conversar com quem está usando para saber quando termina seu experimento ou combinar um compartilhamento do uso

Durante a execução do seu experimento

Monitore o uso de recursos do seu experimento para garantir que ele não está vazando memória RAM e/ou consumindo todos recursos da máquina. Principalmente se a máquina for um chunkserver do storage (confira na lista de máquinas área restrita do site do Verlab).
O serviço de armazenamento distribuído, que chamamos de storage, contém todas as imagens singularity, datasets e é responsável pelo experimento de todos os colegas do Verlab/J.
Se seu experimento exaurir os recursos computacionais das máquinas chunkserver, todo sistema de storage fica lento e atrapalha o experimento de todos!

Para monitorar seu experimento, é sugerido:

1. usar um multiplexador de terminais para manter sua sessão executando em segundo plano após desconectar o ssh. Nas máquinas da rede VeRLab/JLab temos instalado tmux e byobu (link para tutoriais)
2. usar uma "pane" com htop, filtrando seu usuário, ou nome do executável;
3. usar outra "pane" com watch nvidia-smi (a tela é atualizada a cada 2 segundos)