Difference between revisions of "Singularity"

From VeRLab Wiki
Jump to: navigation, search
(→‎Singularity)
 
(228 intermediate revisions by 6 users not shown)
Line 4: Line 4:
 
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:
 
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 criar sua ''máquina container'' 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 que atrapalham experimentos de outros usuários.
+
* 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 mais flexibilidade para rodar experimento em outra máquina, sem precisar instalar todas dependências novamente.
+
* 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.
 +
<br><br><br>
 +
 +
== Singularity vs. Docker ==
 +
<br>
 +
'''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.
 +
 +
<br><br><br>
 +
 +
== 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 <span style="color: red;">a partir de jun/2024</span>) ===
 +
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity4  Link para dicas de uso do Singularity CE v4.x]
 +
 +
 +
 +
'''Versões anteriores utilizadas na rede rede VeRLab/Jlab'''
 +
 +
* [https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity3  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.
 +
<!-- Comentado
 +
* '''Singularity v2.5.x''' (''freeware'', <span style="color: red;">versão sem suporte desde jul/2018, vai ser descontinuada na rede VeRLab/JLab</span>)
 +
**[https://www.verlab.dcc.ufmg.br/mediawiki/index.php/Singularity2  Link para dicas de uso do Singularity v2.5.x]
 +
-->
 +
<br> <br> <br>
 +
 +
== 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.
 +
 +
<br> <br> <br>
  
 
== Instalação ==
 
== Instalação ==
−
Toda máquina com GPU deve rodar experimentos sem modificar os pacotes da máquina host (máquina de processamento).  
+
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:
+
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:
  
−
* Instalar o '''Singularity''' em toda máquina host com GPU (máquina de processamento)
+
=== Estações de trabalho Desktop no Verlab/J com GPU Nvidia ===
−
* Configurar de modo que todo usuário possa rodar apenas o comando <code> $sudo singularity </code> numa '''pasta local da máquina host''', sem necessitar de senha root.
+
* 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
  
−
Assim as pastas indicadas para "compilar" a máquina container é fora do home do usuário, tais como:
+
=== 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>
  
−
* <code> /tmp </code> ou
+
* 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>'''.
−
* <code> /homeLocal/usuario </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 ==
  
−
== Regras de bom uso dos recursos ==
+
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.<br>
−
* Usuários não devem deixar o dataset (massa de arquivos grande, em geral 1TB, que vão ser acessados durante o experimento) dentro da sua pasta home de usuário, pois isso aumenta o tráfego na rede desnecessário. Os datasets devem ser armazenados numa pasta local do computador com o nome do usuário. Por exemplo <code> /homeLocal/fulano </code>
+
 
 +
A principal '''vantagem''' dessa abordagem é evitar ter que fazer configurações extras como a do nvidia-container-toolkit, que é necessária no Docker.
 +
<br>
 +
Ainda assim, é importante prestar atenção à versão do driver Nvidia instalada no sistema para que o container consiga acessar a GPU!
  
−
* Cada usuário deve baixar os arquivos e os pacotes necessários para ''máquina container'' dentro da pasta /homeLocal/usuario, e "compilar" na mesma. O arquivo container pronto, deve ser armazenado na sua pasta /home/usuario
+
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 '''<code>nvidia-smi</code>''' na máquina host.
  
−
== Aprender a Criar sua Máquina Container ==
+
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:
  
−
Links recomendados para aprender a utilizar o '''Singularity''':
+
* https://docs.nvidia.com/deploy/cuda-compatibility/index.html.
  
−
https://singularity.lbl.gov/docs-docker
+
Para carregar o driver Nvidia no container use a opção  '''<code>--nv</code>'''

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)


Versões anteriores utilizadas na rede rede VeRLab/Jlab

  • 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:

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

Retrieved from "http://www.verlab.dcc.ufmg.br/mediawiki/index.php?title=Singularity&oldid=1435"