Revision as of 12:41, 28 August 2024

Página em construção

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 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 falhar, o segundo disponibiliza a cópia dos arquivos.

Pastas /draft-xxx - armazenamento local

Para armazenar arquivos maiores como datasets e resultados de experimentos de forma local na máquina, fica disponível (na grande maioria das máquinas) uma pasta de rascunho que chamada de draft (antigamente eram chamadas /homeLocal).

As pastas draft são discos extras nas máquina que são independente do disco que tem o S.O. Ubuntu. Esses discos são montados com nomes draft-xxx que dependendo do tipo de tecnologia de armazenamento. Atualmente temos até 3 tipos de pasta draft na máquina:

• /draft-hdd: espaço em um HDD SATA para armazenar os rascunhos
• /draft-ssd: espaço um SSD SATA para armazenar os rascunhos
• /draft-nvme: um SSD NVMe para armazenar os rascunhos

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 do que na pasta em rede da storage (explicado a seguir).

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 nessa pasta, 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>

É importante ressaltar que as pastas draft não tem qualquer tipo de backup ou redundância, então sempre tenha repositórios para salvar seus códigos e scripts. Existe um esforço da equipe de infraestrutura em manter os discos sempre operando, o que dá uma "sensação de que nunca estragam", mas pode ocorrer.

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 se a máquina está disponível na planilha
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)