Difference between revisions of "Singularity"

Revision as of 14:01, 27 April 2023

Singularity

O Singularity é uma ferramenta para a criação de "máquina container" (uma espécie de "máquina virtual") que trás algumas vantagens, quando for rodar experimentos nas máquinas de processamento do Verlab/J:

• Não precisa ser usuário com privilégios root para executar sua máquina container (apenas para criar) e pode instalar suas dependências de experimento no container sem alterar a máquina host. Isso evita mudanças e instalação de pacotes nas máquinas de processamento e que podem atrapalham experimentos de outros usuários.

• Depois de criar sua máquina container com todas suas dependências, pode-se usá-la para rodar experimento em diferentes máquinas host que tenham GPU. Isso trás flexibilidade para rodar experimento em máquinas simultaneamente, sem precisar instalar todas dependências novamente em outra máquina host.

• A massa de arquivos de dataset (que geralmente ocupam espaço >=500GB) ficam localmente armazenados na máquina host, assim evita tráfego desnecessário na rede. Geralmente na pasta /homeLocal/nome_do_usuario.

• O usuário deixa na sua pasta home da rede apenas sua máquina container em formato de imagem (que em geral ocupa ~4GB) assim quando logar em qualquer máquina de processamento a mesma estará disponível para rodar seu experimento.

• Dataset's e containers podem ser armazenados no serviço de storage da rede, assim ficam disponíveis em qualquer máquina de processamento para rodar seu experimento. Geralmente na pasta /srv/storage/datasets/nome_do_usuario e /srv/storage/singularity/images/nome_do_usuario.

Versão em uso no VeRLab/JLab

Atualmente temos a versão 3.10.x instalada nas máquinas da rede VeRLab/JLab.

• Singularity CE v3.x ( Community Edition, freeware, versão em todas as máquinas a partir de mar/2022)
  • Link para dicas de uso do Singularity CE v3.x

A versão 2.5.x já foi utilizada, mas seu suporte parou em jul/2018 e foi descontinuada na rede VeRLab/Jlab desde mar/2022.

Regras de bom uso dos recursos

• Arquivos mais importantes e pequenos, como códigos, documentos e resultados finais, devem ser mantidos na home do usuário.
  • Obs: Usuários não devem deixar o datasets e arquivos temporários de processamento dentro da sua pasta home. Os datasets são muitos arquivos que vão ser acessados durante o experimento e que seu tamanho total, em geral, é >=500GB. Pois isso aumenta o tráfego na rede desnecessáriamente.

• Massa de dados e arquivos maiores, tais como datasets, dados pre-processados e resultados parciais, devem ser armazenados em locais de uso comum dentro de uma pasta com o "nome do usuário" ou "nome do projeto" (no caso de um grupo de trabalho maior que tem um aluno sênior coordenando).

• Temos as seguintes opções de pastas de uso comum para massa de dados:
  • /homeLocal/ : pasta local na máquina, montada no barra da mesma. O usuário pode armazenar seus containers e dados de experimentos.
  • /srv/storage/datasets) : pasta no servidor de storage para armazenar datasets
  • /srv/storage/singularity/images/ : pasta no servidor de storage para armazenar as imagens singularity fechadas (.img ou .simg) que são executadas nos experimentos.
  • /srv/storage/singularity/forge/ : pasta no servidor de storage para criação de imagens singularity em modo sandbox (evitar deixar as imagens em sandbox, mais detalhes abaixo)
    • Foi escolhido que das máquinas de processamento na rede, apenas EPONA, GHOST e MAGRITTE serão capazes de criar um container e abrir em modo edição com $sudo singularity shell --writable... .
    • Outra restrição é que essa permissão só pode ser executada na pasta /srv/forge

• Cada usuário deve criar uma pasta com seu "nome de usuário" (ou "nome de projeto" se for o caso) dentro da pasta de uso comum para conter seus arquivos. Assim fica organizado e facilita identificar quem são os donos dos containers ou datasets. Exemplos para o nome de usuário "fulano":
  • O usuário é responsável por liberar o espaço em disco quando não estiver mais precisando do mesmo ou fazendo testes
  • /homeLocal/fulano :
  • /srv/storage/datasets/fulano
  • /srv/storage/singularity/forge/fulano
  • /srv/storage/singularity/images/fulano

• A máquina container para rodar os experimentos deve estar em formato de imagem para rodar mais rápido (.img ou .simg).
  • Porém, enquanto estiver em teste e instalando pacotes, ela deve ser uma "pasta sandbox".
  • Pedimos que não mantenham muitas imagens singularity em modo sandbox. Sempre que possível, feche sua imagem (converter para .img ou .simg) e de preferência coloque-as na pasta storage/singularity/images.
  • Obs: Imagens em modo sandbox deixam uma quantidade enorme de arquivos, e como o servidor de storage tem que mapear todos os arquivos na memória RAM, e às vezes a mesma estoura por esse motivo.

Instalação

Toda máquina de processamento do Verlab/J (máquinas com GPU) deve ter o Singularity instalado e não precisam ter pacotes específicos de software como ROS, cuda, tensorflow.

A equipe de rede é responsável por manter máquinas locais e máquinas de processamento disponíveis para executar o singularity. Foi escolhido que o sigularity estará disponível apenas nas máquinas com GPU Nvidia, assim confira a lista de máquinas na área restrita do site do verlab:

Estações de trabalho Desktop no Verlab/J com GPU Nvidia

• Instalar o Singularity em toda máquina host com GPU (máquina de processamento)
• Criar a pasta /homeLocal em toda máquina host.
  • O usuário precisa solicitar à equipe de rede para criar uma pasta filha na /homeLocal/nome_do_usuario e dar permissão de leitura/escrita. Assim, para casos específicos é possível criar e modificarem máquinas container localmente, sem usar o serviço de storage.
• Configurar o comando $sudo singularity ... de modo que todo usuário possa rodá-lo dentro da pasta /homeLocal, sem necessitar de senha root

Servidores de Processamento da rede Verlab/J com GPU Nvidia

• Configurar montagem automática das pastas na rede:
  • /srv/forge (apenas EPONA, GHOST e MAGRITTE)
  • /srv/storage/datasets
  • /srv/storage/singularity/images/
  • /srv/storage/singularity/forge/

• Foi escolhido que das máquinas de processamento na rede, apenas EPONA, GHOST e MAGRITTE serão capazes de criar um container e abrir em modo edição com $sudo singularity shell --writable... .
• Uma segunda restrição é que essa permissão só pode ser executada na pasta /srv/forge
• Configurar a montagem da pasta /srv/forge nas máquinas EPONA, GHOST e MAGRITTE e configurar a montagem das mesmas para que o comando $sudo singularity ... possa ser executado por qualquer usuário, sem necessitar de permissão root
• Para executar o container em modo leitura ($singularity shell...), a pasta /srv/forge é espelhada nas demais máquinas:
  • /srv/storage/singularity/forge$