Singularity

2024-05-30T18:21:30Z

Rada: Adicionei uma seção de dicas de uso que ajuda a usar o Singularity.

== 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) ===
** [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity3 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:
**<code>/homeLocal/</code> : pasta local na máquina, montada no barra da mesma. O usuário pode armazenar seus containers e dados de experimentos.
**<code>/srv/storage/datasets</code>) : pasta no servidor de storage para armazenar datasets
**<code>/srv/storage/singularity/images/</code> : pasta no servidor de storage para armazenar as imagens singularity fechadas (<code>.sif</code>) que são executadas nos experimentos.
**<code>/srv/storage/singularity/forge/</code> : 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 '''<code> $sudo singularity shell --writable... </code>'''.
*** Outra restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>

* 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'''
**<code>/homeLocal/fulano</code> :
**<code>/srv/storage/datasets/fulano</code>
**<code>/srv/storage/singularity/forge/fulano</code>
**<code>/srv/storage/singularity/images/fulano</code>

* A máquina container para rodar os experimentos deve estar em formato de imagem para rodar mais rápido (<code>.sif</code>.
** 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 <code>.sif</code> 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 [https://www.verlab.dcc.ufmg.br/restrict-area/ á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 <code>/homeLocal</code> em toda máquina host.
** O usuário precisa solicitar à equipe de rede para criar uma pasta filha na <code>/homeLocal/nome_do_usuario</code> 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 <code> $sudo singularity ... </code> de modo que todo usuário possa rodá-lo dentro da pasta <code>/homeLocal</code>, sem necessitar de senha root

=== Servidores de Processamento da rede Verlab/J com GPU Nvidia ===
* Configurar montagem automática das pastas na rede:
**<code>/srv/forge</code> (apenas '''EPONA, GHOST e MAGRITTE''')
**<code>/srv/storage/datasets</code>
**<code>/srv/storage/singularity/images/</code>
**<code>/srv/storage/singularity/forge/</code>

* 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 '''<code> $sudo singularity shell --writable... </code>'''.
* Uma segunda restrição é que essa permissão só pode ser executada na pasta <code>'''/srv/forge'''</code>
* Configurar a montagem da pasta <code>/srv/forge</code> nas máquinas EPONA, GHOST e MAGRITTE e configurar a montagem das mesmas para que o comando <code> $sudo singularity ... </code> possa ser executado por qualquer usuário, sem necessitar de permissão root
* Para executar o container em modo leitura ('''<code>$singularity shell...</code>'''), a pasta <code>/srv/forge</code> é espelhada nas demais máquinas:
**<code>/srv/storage/singularity/forge$</code>

== 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. Por conta disso, pode ser que a versão do driver atual 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.

A versão instalada do driver pode ser obtida rodando <code>nvidia-smi</code> dentro da máquina host.

VeRLab Wiki - User contributions [en]

Singularity