Singularity
Contents
[hide]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)
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
- 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
- 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.
- O usuário precisa solicitar à equipe de rede para criar uma pasta filha na
- 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:
Para carregar o driver Nvidia no container use a opção --nv