Latest revision as of 12:34, 30 September 2025

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 - armazenamento em rede

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, containers 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 de "rascunho" - armazenamento em disco local

Para armazenar, de forma local na máquina, arquivos maiores como datasets, containers 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:

• 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 outros usuários encontrem espaço 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 - armazenamento em rede distribuído (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 em rede, de modo que fica disponível em todas as máquinas da rede VeRLab/JLab.

O caminho de montagem do serviço de storage se encontra em /srv/storage/

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

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 usuário que desejar baixar datasets, criar container singularity e fazer um experimento nas pastas /srv/storage/forge, deve solicitar à equipe de infraestrutura para criar uma subpasta para seu usuário, por exemplo, /srv/storage/forge/<nome_usuario>

O que você precisa para executar seu experimento no VeRLab/JLab

1. Possuir um login de usuário habilitado na rede do laboratório
2. Ter uma pasta para seu usuário usar como rascunho (/draft-xxx/<nome_usuario> ou /srv/storage/forge/<nome_usuario>)
3. Ter seu container com o ambiente de execução usando o Singularity4 ou Docker-Rootless-Mode
4. Procurar na planilha de "[VeRLab] Utilização, Experimentos GPUs e CPUs", aba "Perfil das Máquinas" uma máquina que atenda seus requisitos de hardware
5. Preencher seu whatsapp/telegram na aba "Contatos"
6. Verificar disponibilidade da máquina na aba "Status de Execução" e agendar seu uso na aba "Log e Intenção de Utilização".

OBS:

• O link para a planilha "[VeRLab] Utilização, Experimentos GPUs e CPUs" encontra-se na na área restrita do site (acesso com seu usuário e senha do laboratório)

Antes de rodar seu experimento

1. Verifique na planilha "[VeRLab] Utilização, Experimentos GPUs e CPUs" se a máquina está disponível e se você já preencheu 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:
   • 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 uma máquina específica que precisar estiver ocupada, pode-se conversar com quem está usando para 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/JLab.
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 htop --user <nome_usuario> ;
3. usar outra "pane" com watch nvidia-smi (a tela é atualizada a cada 2 segundos)