Logiciels installés et disponibles !!!

Logo Guix

1. Spécificités du cluster de test

Le cluster ALPHA (de test) a été intégralement construit autour de « Guix system ». L’outil en ligne de commande guix doit actuellement être privilégié pour installer des logiciels.

Ce choix facilite la vie de l’équipe pour l’instant. Lorsque la première tranche de GLiCID sera officiellement installée en fin de premier semestre 2023, elle sera construite de façon plus traditionnelle (RedHat 8 devrait être utilisé). Les logiciels déjà installés par Guix resteront disponibles (rien ne sera perdu).

En dehors de Guix, il est possible de bénéficier des logiciels de la forge Conda (avec quelques limitations, voir le point Conda et micromamba), d’utiliser des conteneurs (voir le point Conteneurs), voire d’utiliser des binaires pré-compilés provenant d’autres distributions (voir le point Programmes binaires pré-compilés).

1.1. Types de nœuds hétérogènes

Dans le cluster actuel (ALPHA), 2 types de nœuds sont disponibles :

Comme le nom l’indique, ce sont des machines virtuelles (VM) de tests, disposant de puissance de traitement limitée, dont le but est de valider des compilations ou des petits cas de tests. Ne pas lancer de gros calculs dessus, ces machines ne sont pas adaptées à cela.

  • budbud : ce sont les machines GPU. Ces nœuds fonctionnent nativement sous Centos 7.9 (image issue du CCIPL). Ils sont donc capables de faire tourner des logiciels Guix, mais également des binaires natifs Centos / RedHat 7.9.

2. Guix

Guix permet de bénéficier immédiatement de près de 22.000 paquets logiciels. Un des intérêts est de rendre l’utilisateur totalement autonome dans l’installation des logiciels (pas de droits administrateur nécessaires). Ce mode opératoire est pratique pour une phase de tests approfondis et rapides : pas d’attente des administrateurs pour installer les logiciels nécessaires.

Il n’y a donc pas, à proprement parler de logiciels pré-installés, à l’exception de Slurm. Chaque utilisateur peut installer ce qui lui est nécessaire et disposer d’un ensemble de logiciels totalement différent des autres utilisateurs.

Guix permet même d’installer de nombreuses différentes versions d’un même logiciel, des environnements d’exécution ad-hoc, cf. cette partie de la documentation de Guix, ou de remonter dans le passé comme expliqué ici.

3. Canaux logiciels de base sur GLiCID

Guix peut installer des logiciels en se basant sur différents canaux. Le canal de base contient plus de 20.000 packages. Sur le cluster GLiCID, des canaux supplémentaires sont ajoutés à cette base :

  • glicid : des logiciels spécifiques ou optimisés pour un bon fonctionnement sur le cluster GLiCID, (par exemple, des librairies openMPI spécifiques)

  • glicid-non-free : des logiciels non open-source ou des variations des logiciels de base, mais compilés ou optimisés avec des librairies non open-source (telles que cuda)

  • guix-hpc : des logiciels et librairies supplémentaires utiles dans un contexte de calcul scientifique

  • guix-hpc-non-free : comme ci-dessus mais concernant des logiciels non libres (tels que cuda)

  • guix-past : anciennes versions de logiciels ou librairies considérés comme obsolètes mais qui peuvent être utiles pour compiler d’anciens logiciels.

  • guix-science : autre série de logiciels scientifiques

  • guix-cran : archive complète du CRAN (librairies pour R)

  • guix-bimsb : archive de logiciels de bio-informatique

  • guix-zpid : autres logiciels scientifiques

L’utilisateur a la possibilité de personnaliser la liste des canaux si le besoin s’en faisait sentir.

4. Installation de Guix

Guix fonctionne indifférement sur toutes les machines de GLiCID (cluster Nautilus ou Waves). Les logiciels installés sont propres à chaque utilisateur et indépendants du système d’exploitation sous-jacent, ce qui rend la solution très intéressante dans le cas d’un cluster hétérogène.

Guix s’installe de façon personnalisée pour chaque utilisateur. Un profil est créé lors de la La toute première commande guix pull.

Ce tout premier guix pull doit impérativement être effectué depuis une machine native guix (guix-devel-001 par exemple). Une fois cela fait, le profil est créé (des répertoires ~/.config/guix, '~/.guix-profile` entre autres). À cette occasion, une erreur peut apparaître concernant un répertoire dans /var/guix. Celui-ci est recréé automatiquement, il suffit alors de relancer la commande.

5. Installation des logiciels

Guix est utilisable depuis la totalité des machines. Sur les machines non natives Guix (RedHat 8 sur Nautilus), il faut charger le profil Guix avant de pouvoir l’utiliser :

source ~/.guix-profile/etc/profile
export GUIX_DAEMON_SOCKET="guix://guix-store.intra.glicid.fr"
export PATH=~/.config/guix/current/bin:$PATH
Rappel, cf Installation de Guix , ces commandes ne fonctionneront que si un profil Guix a déjà été initialisé.

Pour installer un logiciel, les étapes à suivre sont les suivantes :

  1. guix pull est la première commande à effectuer. Elle permet de récupérer la liste des packages disponibles au moment de la commande. Cette commande peut être considérée similaire à apt update ou yum update pour les distributions basées sur Debian ou RedHat.

    En réalité, cette commande fait beaucoup plus, (elle récupère un historique des versions de tous les logiciels de tous les canaux et capture toutes les dépendances entre eux). C’est un processus complexe, ce qui explique que le temps d’exécution de cette commande est beaucoup plus long que les équivalents habituels (compter plusieurs minutes).

    WARNING:

  2. À la fin du tout premier guix pull il est conseillé de se déloger de la frontale, puis se reloger pour prendre en compte le nouvel environnement (et en particulier les logiciels spécifiques à GLiCID). Ce n’est à faire que la toute première fois.

  3. Installer, avec guix install, le minimum pour compiler des logiciels. Par exemple, pour des logiciels écrits en C : guix install gcc make glibc.

  4. Vérifier ce qui est installé dans votre profil courant : guix package -I

  5. Vérifier ce qui est installable : guix package -A

  6. Vérifier si un logiciel existe : guix search chemical pour chercher dans la description, guix package -A | grep -i gromacs pour chercher dans la liste des packages.

  7. Installer le logiciel s’il est directement disponible depuis les dépôts Guix : guix install gromacs. Sinon, le compiler.

  8. Le lancer avec slurm : srun -p short mon-logiciel' ou `sbatch mon-batch.

Slurm est installé de base sur les frontales et les nœuds compute.

Les logiciels installés dans votre profil Guix sont partagés et disponibles sur l’ensemble du cluster.

L’installation des logiciels ne consomme pas d’espace sur vos /home. les logiciels, tout comme les profils utilisateurs sont stockés dans le store global de Guix. Sur votre /home ne se trouvent que des liens vers votre profil (et ces liens pointent vers le store global, qui est commun à tous).

Guix permet beaucoup, beaucoup plus. Se referrer à sa documentation complète.

6. Cas particuliers liés à Guix pour l’exécution de travaux sur le cluster.

Le cluster actuel (de test) est hétérogène : les frontales et les machines de test (vm-compute) sont des machines installées avec «Guix system», alors que d’autres (les machines GPU budbud de la partition short) sont actuellement des systèmes Centos 7.9. Elles n’utilisent ni le même système d’exploitation, ni les mêmes versions des librairies ou logiciels système. Pourtant, lancer un script via sbatch ou srun depuis la frontale vers ces machines disposant d’un système différent va globalement fonctionner de façon transparente. En effet, les logiciels installés dans votre profil Guix sont totalement autonomes et indépendants du système sous-jacent et le profil Guix de l’utilisateur est disponible sur l’ensemble des machines du cluster. Cela permet de faire fonctionner sans encombre tous les logiciels de VOTRE profil Guix. Ce sont les logiciels qui apparaissent avec la commande guix package -I.

L’exception est la suivante : les logiciels qui ne sont pas dans VOTRE profil guix ne seront pas disponibles sur les machines Centos. Cela peut paraître contre-intuitif, mais les logiciels de base de la frontale (bash, des commandes usuelles comme ps ou ls ni même srun ne le seront pas. Si les scripts de soumission slurm utilisent de telles commandes, alors il faut les installer dans votre profil : guix install bash coreutils procps par exemple )
Pour savoir si un programme provient du profil utilisateur ou du système sous-jacent, taper which leprogramme. S’il provient de /home/utilisateur/.guix-profile…, c’est qu’il provient du profil de l’utilisateur et fonctionnera sur toutes les machines du cluster. S’il provient de /run/current-system/profile/ alors, il ne provient PAS du profil guix de l’utilisateur et ne fonctionnera PAS sur les autres systèmes.

6.1. Illustration

$ which rsync
/home/dupont-y@univ-nantes.fr/.guix-profile/bin/rsync (1)

$ which ps
/run/current-system/profile/bin/ps (2)
1 est dans le profil utilisateur
2 provient du système sous-jacent (et ne fonctionnera pas sur les machines Centos) 
~$ srun -p short rsync --version
srun: job 2044 queued and waiting for resources
srun: job 2044 has been allocated resources
rsync  version 3.2.7  protocol version 31 (1)
Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others.
Web site: https://rsync.samba.org/
[...]


$ srun -p short ps --version
srun: job 2047 queued and waiting for resources
srun: job 2047 has been allocated resources
slurmstepd: error: execve(): ps: No such file or directory (2)
srun: error: budbud015: task 0: Exited with exit code 2

$ guix install procps (3)
The following package will be installed:
   procps 4.0.3
[...]

$ srun -p short ps --version
srun: job 2050 queued and waiting for resources
srun: job 2050 has been allocated resources
ps from procps-ng 4.0.3 (3)
1 Le logiciel est bien disponible comme attendu
2 ps n’est pas disponible dans le profil utilisateur et donc, introuvable sur les machines CentOS
3 une fois installé dans le profil utilisateur, tout fonctionne comme attendu

6.2. Trouver la source du logiciel manquant

Dans Guix, tout logiciel installé est invariable, autonome des autres ET stocké dans un dépôt global, commun à tout le cluster. Parfois les noms des paquetages coulent de source, parfois non. Dans la cas où un logiciel est disponible dans le système, il est facile de voir d’où il provient :

$ which tail
/run/current-system/profile/bin/tail (1)

$ ls -al /run/current-system/profile/bin/tail
lrwxrwxrwx 1 root root 66 Jan  1  1970 /run/current-system/profile/bin/tail -> /gnu/store/yr39rh6wihd1wv6gzf7w4w687dwzf3vb-coreutils-9.1/bin/tail (2)

$ guix install coreutils (3)
The following package will be installed:
   coreutils 9.1

The following derivation will be built:
  /gnu/store/lpza4apps2g660glzb00rb185q99dvdc-profile.drv

building [...]

$ which tail
/home/dupont-y@univ-nantes.fr/.guix-profile/bin/tail (3)
1 la commande tail provient du système, pas du profil utilisateur
2 la commande tail provient du package coreutils
3 en installant ce paquetage dans son profil, les commandes incluses dans coreutils (dont tail) deviendront utilisables sur l’ensemble du cluster

7. Compiler ses logiciels

La machine frontale vient nue, c’est-à-dire quasiment sans logiciels installés. C’est à chaque utilisateur de construire son environnement, c’est un parti-pris différent des machines traditionnelles.

7.1. Profil minimum pour compiler des logiciels en C

guix install gcc-toolchain glibc binutils make. Suffisant pour compiler un «hello world».

il faut bien comprendre qu’en réalité, vous n’installez pas ces logiciels dans votre HOME, vous les rendez juste disponibles dans votre profil principal.

Une documentation plus complète est disponible ici.

7.2. projets cuda

Cuda est une librairie propriétaire, non libre, uniquement disponible au format binaire, par la volonté de la société qui le développe (nvidia). Cette librairie est donc non disponible de base dans Guix. Comme indiqué dans le chapitre Canaux logiciels de base sur GLiCID, notre installation ajoute des canaux spécifiques pour simplifier l’installation de tels logiciels. cuda en fait partie et est donc installable aisément :
guix install cuda-toolkit

les nœuds budbud fonctionnent sous CENTOS 7.9. Les programmes compilés sur les frontales avec Guix fonctionnent parfaitement à la condition d’ajouter un chemin LD_LIBRARY_PATH.

cf. l’exemple suivant pour lancer un gromacs compilé avec cuda (package gromacs+gpu) :

LD_PRELOAD=/usr/lib64/libcuda.so.1 srun -p short -C gpu_a100 gmx -version

7.3. Projets openmpi

Il est conseillé d’utiliser la souche openMPI spécialement utilisable sur l’intégralité des machines de GLiCID : openmpi-glicid

Si le logiciel srun est amené à être lancé dans un sbatch s’exécutant sur les machines non natives Guix (budbud…) , il faut aussi installer le package slurm : guix install slurm-glicid. La raison est expliquée au chapitre «Cas particuliers liés à Guix pour l’exécution de travaux sur le cluster.»

8. Conteneurs

podman est actuellement utilisable et permet de faire fonctionner des conteneurs issus du hub docker (et celui de Nantes Université) ou des images singularity.

l’utilisation de podman nécessite des droits particuliers, qui doivent actuellement être accordés manuellement par les administrateurs. Nous contacter.
de petits ajustements techniques restent nécessaires pour avoir des performances satisfaisantes. Actuellement les entrées/sorties risquent d’etre médiocres (au 24/03/23).

Par exemple, pour faire fonctionner un environnement almalinux 9 (clone de RedHat 9) :

podman run -it docker://almalinux:9

9. Conda et micromamba

conda est un gestionnaire d’environnements logiciels assez populaire notamment dans la communauté Python, mais qui n’est pas sans poser de nombreux soucis dans un contexte d’utilisation HPC.

Les administrateurs de GLiCID déconseillent son utilisation, en particulier si les logiciels visés sont déjà disponibles dans Guix.

Néanmoins, l’ensemble des logiciels fournis par conda n’est pas (encore) disponible dans Guix. Dans ce cas précis, voici comment procéder.

9.1. Utiliser micromamba en lieu et place de conda

Un binaire conda est bien disponible dans Guix mais présente des bugs lors de l’initialisation, il est recommandé de ne pas l’utiliser. Pour contourner ce problème, il est recommandé d’utiliser micromamba en lieu et place de conda (cf. la doc de mamba pour plus de détails). Il n’est malheureusement (pas encore) disponible dans Guix, il faut donc l’installer manuellement.

9.2. Installer micromamba sur GLiCID

Une version compilée statiquement de micromamba est disponible dans les artefacts Github du project Mamba. Voici les commandes à lancer pour l’installer localement sur GLiCID.

# Télécharger micromamba depuis les packages Glicid
mkdir -p $HOME/.local/bin
wget -P $HOME/.local/bin https://s3.glicid.fr/pkgs/micromamba
chmod u+x $HOME/.local/bin/micromamba

# Initiliser micromamba
$HOME/.local/bin/micromamba -r /micromamba/$USER/ shell init --shell=bash --prefix=/micromamba/$USER/

# [OPTIONNEL] Ajouter un alias `conda`
echo -e '\n\n#Alias conda with micromamba\nalias conda=micromamba' >> ~/.bashrc

# Recharger le .bashrc
source ~/.bashrc
Il est possible que le fichier .bashrc ne soit pas toujours sourcé au login sur GLiCID (des investigations sont en cours). Si ce n’est pas le cas, pensez à faire source ~/.bashrc après chaque login pour bien charger micromamba.

À partir de ce moment-là, micromamba/conda est utilisable par l’utilisateur

9.3. Example d’utilisation de micromamba

micromamba --version  # ou: `conda --version`
# -> 1.4.0

# Créer un environnment micromamba/conda
micromamba create -n my_env

# Activer l'environnement
micromamba activate my_env

# -> Votre prompt doit maintenant être préfixé avec: (my_env) ...

# Installer des packages depuis conda-forge
micromamba install -c conda-forge numpy

# Tester les packages
python -V
python -c "import numpy as np; print(np.__version__)"
# -> 1.24.2

# Désactiver l'environnement
micromamba deactivate

# Votre prompt ne doit plus être préfixé

10. Programmes binaires pré-compilés

Les programmes binaires peuvent être de deux types :

  1. liés statiquement

  2. liés dynamiquement

C’est le développeur produisant le programme binaire qui choisit son type. Le défaut étant « lié dynamiquement », c’est donc le cas de l’immense majorité des logiciels fournis qui sont de ce type. Créer des binaires liés statiquement demande un effort supplémentaire, parfois conséquent, ce que les développeurs ne font généralement pas. Or, seuls les binaires totalement statiques sont portables d’un système à l’autre.

Ces binaires pré-compilés et liés dynamiquement sont problématiques, car ils vont aller chercher, à leur lancement, des versions spécifiques de librairies tierces. Une correspondance 1 pour 1 de ces librairies est attendue, ce qui est rarement le cas lorsque la distribution Linux utilisée à l’exécution est différente de celle utilisée à la compilation. Les versions et les noms de librairies varient selon les distributions et leurs générations. C’est pour cette raison que les binaires sont souvent destinés à une distribution ET une version précise. Par exemple :

  • ubuntu 18

  • centos 7.9

  • redhat 8.4

  • debian buster …

Quand cela est possible, il est donc recommandé de recompiler le logiciel (ou d’utiliser sa version Guix, ce qui revient au même) plutôt que d’utiliser des versions binaires dont on ignore tout.

Dans le cadre de Guix, il est possible de faire fonctionner nativement un tel binaire si les noms de librairies sont compatibles :

Cette procédure est à vos risques et périls et risque de dysfonctionner de façon spectaculaire : segfault ou autre. Il n’y a aucune garantie de bon fonctionnement.

  • il faut installer dans le contexte d’exécution (le profil utilisateur général, ou un profil dédié avec guix shell) les librairies nécessaires : par exemple, pour faire fonctionner un logiciel qui réclame libstdc++ et libz, il convient d’installer ces librairies ET les inclure dans les chemins de recherche :

guix install gcc:lib libzip (1)
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$LIBRARY_PATH (2)
./mon-logiciel
1 à faire une seule fois
2 à faire avant chaque lancement du logiciel

Ou pour mieux compartimenter :

guix shell -CF bash coreutils gcc:lib libzip

Dans les cas plus compliqués :

  • Il est aussi possible d’utiliser podman et de faire fonctionner le binaire dans le contexte d’exécution correspondant à ce qui est attendu, par exemple pour un binaire conçu pour ubuntu 20.04

podman run -it docker://ubuntu:20.04 mon-logiciel

11. Modules

Il est prévu de pouvoir utiliser les modules au travers d’un conteneur Centos 7.9 faisant office de couche de compatibilité (voir le point Conteneurs pour la disponibilité. )