Difference between revisions of "Singularity"

Latest revision as of 16:43, 13 November 2024

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.

Singularity vs. Docker

Docker

• Popularidade: Docker é amplamente utilizado e tem uma grande comunidade de desenvolvedores.
• Flexibilidade: Permite a criação de containers para diferentes sistemas operacionais (Linux, Windows, macOS).
• Ecosistema: Oferece uma vasta gama de imagens pré-construídas (Docker Hub) e integração com ferramentas de CI/CD.
• Segurança: Embora seguro, pode exigir permissões elevadas (root) para certas operações.

Singularity

• Foco em HPC: Singularity é especialmente popular em ambientes de computação de alto desempenho (HPC) e pesquisa científica.
• Segurança: Projetado para ser executado com permissões de usuário comuns, sem a necessidade de privilégios elevados.
• Portabilidade: Focado principalmente em ambientes Linux, mas com suporte limitado para outros sistemas operacionais.
• Definição de Containers: Utiliza arquivos de definição (Singularity Definition Files) que são diferentes dos arquivos Dockerfile.

Versão em uso no VeRLab/JLab

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

Singularity CE v4.x ( Community Edition, freeware, versão em todas as máquinas a partir de jun/2024)

• Link para dicas de uso do Singularity CE v4.x

Versões anteriores utilizadas na rede rede VeRLab/Jlab

• Link para dicas de uso do Singularity CE v3.x (descontinuada em mai/2024)

• 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 (.sif) 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 (.sif.
  • 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 .sif 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$

Dicas de Uso

O uso do Singularity é direto ao ponto em muitos sentidos. Isso se deve ao fato de que, para utilizar os recursos da GPU, o container Singularity faz um linking com o driver da máquina host, o que já disponibiliza, para o container, a mesma versão do driver e do CUDA que já estão instalados na máquina host.

A principal vantagem dessa abordagem é evitar ter que fazer configurações extras como a do nvidia-container-toolkit, que é necessária no Docker.
Ainda assim, é importante prestar atenção à versão do driver Nvidia instalada no sistema para que o container consiga acessar a GPU!

A versão de CUDA instalada dentro do container é totalmente independente da versão instalada na máquina host, o que significa que é possível rodar uma versão do CUDA no container que é diferente da versão instalada na máquina host. Mas é importante prestar atenção que a versão do driver do container será sempre igual à versão do driver na máquina host, pois é feito um link do container para o host, e isso não pode ser mudado.

Pode-se verificar a versão do driver Nvidia instalado executando nvidia-smi na máquina host.

Por conta disso, pode ser que a versão do driver instalada na máquina host não suporte todas as versões do CUDA. Para ver quais versões são suportadas, é importante se atentar a quais versões do CUDA a versão do driver atual suporta. Isso pode ser verificado em:

• https://docs.nvidia.com/deploy/cuda-compatibility/index.html.

Para carregar o driver Nvidia no container use a opção --nv