---
title: Webinaire 7 GT Notebook
date: 2024-04-02
---
# Webinaire 7 GT Notebook - 4 octobre 2024 12h30-14h00
###### tags: `gt notebook`,`webinaire`

:::warning
Il y avait une coquille dans l'objet du mail, **il s'agit bien du Vendredi 4 octobre 12h30-14h00**.
:::


:::info

- Présent.e.s :
- Sébastien Rey-Coyrehourcq, UMR IDEES, GT Notebook
- Hugues Pécout, Géographie-Cité, GT Notebook
- Konrad Hinsen
- Nicolas Roelandt
- Nicolas Sauret
- Excusé.e.s :
- Lien site web : https://gt-notebook.gitpages.huma-num.fr/site_quarto/
- Issue & ODJ : https://gitlab.huma-num.fr/gt-notebook/webinaires/-/issues/8
- Lien visio BBB : https://webconf.univ-rouen.fr/greenlight/rey-px2-ewg-7av
- Lien d'inscription : https://enquetes-ng.univ-rouen.fr/index.php/719751
- Lien chat public : https://rocket.esup-portail.org/channel/GT-Notebook
- Lien mailling-list : https://groupes.renater.fr/sympa/info/notebooks-inter-reseaux
- Lien support présentation et notebooks de démonstration:
:::

## Ordre du Jour (Vendredi 04/10)

- Accueil (5 minutes)
- Interventions 15/20 minutes + 5 minutes de question de :
- Bernard Chambon (Ingénieur en développement logiciel, IN2P3, Villeurbane )
- Benoist GASTON (Ingénieur de Recherche HPC au CRIANN, Rouen)
- Pierre-Antoine Boutier (Ingénieur de recherche GRICAD, Grenoble)
- Ludovic Courtès (Ingénieur de Recherche Inria, Bordeaux)
- Infos / événements

## Accueil et description de la session

Pour cette septième édition du webinaire du GT Notebook, nous avons décidé de faire un focus sur **l'execution des Notebooks dans un environnement HPC**.

Ces dernières années, avec - entre autre- le développement rapide et soutenu du Machine Learning et de la Data Science dans de multiples disciplines, de nouvelles communautées avec de nouveaux besoins se sont manifestés auprès des équipes d'ingénieur·e·s dans les centres de calculs. Ces usages s'appuient sur le format Notebook (Jupyter, etc.), or celui n'est pas/n'était pas historiquement conçu pour un usage sur des clusters. C'est ce qui a poussé des équipes d'ingénieurs à développer différentes solutions pour déléguer les calculs réalisé dans les Notebook, en intervenant soit au niveau de la cellule, soit au niveau du Notebook lui-même.

Dans ce webinaire, et grâce à nos intervenants, nous allons voir quelques une des approches déjà en production au sein de différents centres de calcul.

## Présentations

### Bernard CHAMBON / The Jupyter notebooks platform at CC-IN2P3

:::info
Bernard CHAMBON est ingénieur en développement logiciel au Centre de Calcul de l'IN2P3 (CC-IN2P3, UAR6402 rattachée à l’IN2P3).
Il a mis en place et est responsable de la plateforme des notebooks Jupyter.

Le Centre de Calcul de l'IN2P3 fournit des moyens de calcul et de stockage à de grandes expériences de physique.
Il participe, avec d'autres centres internationaux, au traitement de données des expériences installées sur l’accélérateur LHC.
Il fournit aussi des moyens pour des expériences de physique des astroparticules, comme celui du futur télescope LSST, ou encore le satellite européen EUCLID.

Ma présentation a pour objectif de donner une vue d'ensemble de la plateforme de notebooks Jupyter, mise en place depuis 4 ans, pour permettre à nos utilisateurs de faire de l'analyse interactive de données.

Je ferai un focus sur l'utilisation du framework Dask pour distribuer des tâches, depuis un notebook, sur des nœuds de calcul gérés par le système de batch SLURM.
:::

#### Notes

Distribuer sur le système de dask sur slurm

- service d'analyse aux utilisateurs
- identification sso de cc-in2p3
- jupyterhub : plurilingue


Basé sur Jupyterhub :
- composant qui permet de faire de l'authentification ou authentification externe
- spawn image docker (autre notebook jupyter)
- formulaire d'options
- possibilité

architecture

Docker va instancier les serveurs de notebook, qui sont connecté aux différents système de stockages (home du user, espace dédié).
Compte calcul = qui a la possibilité d'utiliser SLURM, et aussi le service Notebook, le SSO se fait via Keycloak
Les groupes vont driver le montage des points de montage dans le docker qui va être spawnée

JupyterNotebook
- Centos (passage vers RHEL prévision)

Pour la RAM, 2gb, assez faible mais cela peut servir pour pas mal de personnes de base. Dès qu'on a des utilisateurs qui veulent plus, on augmente snas trop de souci. 10aine utilisateur à 64gb par exemple. Pas de limite en nombre de CPU mais on monitore et on peut contraindre si besoin. La durée de vie des Notebook il n'y a pas de temps limite du moment que celui-ci est actif. On monitor les notebook idle, et on a timeout sur 3 jours. GPU aussi sur la plateforme. Ressource plus rare donc timeout un peu plus court.

CAdvisor va remonter de l'information et graphana derrière nous permet de voir des graphiques pour monitorer.

Dask composant logiciel utilisé :
- dask scheduler fait l'interface entre dask client et dask worker
- dask worker
- dask client (tourne dnas le notebook de l'utilisateur)

Deux ports :
- 1 pour le dask client vers le dask scheduler
- 2 ème port pour le dashboard pour avoir les métriques du daskworker, on a ca via une extension.

Les dask worker doivent avoir accès aux point de montage car il y'a en général des données volumineuses.

Dask :
- peut utiliser des ressources locales ou HPC.
- structure de données connus des utilisateurs
- lazy evaluation : tableau de fonction non executée directement,
par exemple : `@delay` et c'est la méthode `compute()` qui déclenche son execution

Il faut écrire du code en python, et surtout il faut connaitre Dask.

L'utilisatuer doit spécifié :
- Package "Dask4IN2P3" pour gérer un peu toute la plomberie : définit le venv et dépendances du virtual env
- Ram / Cpu
- info de timeout, etc

Ils ont définit une partition spécifique pour SLURM pour que cela démarre plus vite (haute priorité) => résultat, c'est assez rapide !

**Demo** : quel impact pour la parallelisation : combien de temps gagné du fait de didtribuer ces tâches sur un gd nbr de points d'execution.

Possibilité d'avoir plusieurs dask client sur le meme dask cluster.

60 70 utilisateurs en moyenne
100 max
possibilité de formations également
250 cores, 18000 coeurs et quasi pas d'attente sur le batch slurm

#### Questions

**Sébastien :** Quelles perspectives en terme de développement : quelles évolutions ?

BC: 60-70 utilisateurs en régime nominale. L'infra en elle-même va bien, mais demande pour du GPU.
Demande pour des N40S (nvidia) → 20 utilisateurs supplémentaires

6000 lignes de code python pour paramétrer le JHub.

Diff. game de machines (petite; moyenne, grande) au regard de la mémoire disponible

**Matthieu H. :** Qu'est-ce qui limite la scalabilité dans ce cas ? Le framework Dask ? La bande passante disque pour lire et écrire les images ?

Dask+SLURM : utilisé surtoute pour processer de gros volumes de données (TeraB). Pour garder de l'interactivité (car on travaille dans des notebooks), on doit paralleliser :-1:
- 30 To de données, 1500 fichiers de 20Go chacun

**Nicolas R. :** Pourquoi passer de CentOS à RHEL ? Quid 'almaLinux ?

le centre de calcul est en train de migrer vers RHEL9. (fin de support de CentOS 7)

**Tru H.:** des demandes de visualisation 3d dans les notebooks?

pas de visualisation 3D

### Benoist GASTON / Service Jupyter du supercalculateur Austral du CRIANN

:::info

Benoist Gaston est ingénieur HPC au sein de l'équipe calcul du CRIANN (Centre Régional Informatique et d'Application Numériques de Normandie).Il est rattaché au CCFR (Centre de Compétence HPC, HPDA et IA) du projet EuroCC qui accompagne les entreprises et le secteur public dans l'usage du HPC.

La présentation portera sur le service Jupyter déployé sur Austral, le nouveau supercalculateur du Criann en précisant son fonctionnement et l'usage qui en est fait principalement la communauté de l'IA et du traitement des données.

:::

#### Notes

CRIANN : association (1992) des établissements ESR de normandie, rectorat, établissements de santé)
Mutualisation services haute performance (centre de données,réseau, centre de calcul)

14 employés (tech & admin)
financement publics : région, état + qlq industriels

Certifications ISO 27001 et Habilitation Données de Santé

Service HPC : mésocentre régional : première marche avant d'aller chercher des ressources nationales

EuroCC : projet européen qui regroupe des centres HPC en Europe, faciliter usage HPC et technologies associées (HPDA, IA et calcul quantique)

assure des moyens de calcul souverains

utilisateurs :
- 30 labo et industries
- simulation numérique, physique des matériaux, et plus récemment économie, géographie, biologie, SHS

besoin de traitement de données à haute performance (HPDA - High Performance Data Analysis) plutôt que du HPC pure.

- communauté Ia depuis 2017 (besoins HPC croissants en physique, mathématique, chimie, etc)

demande croissante en terme de matériel : GPU
tester de manière interactive leur code avant de lancer le supercalculateur
Besoins de calcul importants pour créer les modèles et pas seulement pour traiter les données

- suite logicielle importante du fait de l'augmentation des disciplines et des besoins (simulation, biologie, mécanique des fluides, modélisation, macanique, acoustique, mathématiques, machine/deep learning,)

acquisition d'un supercalculateur Austral, qui a pris la suite de Miria


Processeurs AMD GENOA (23000 coeurs), 88 GPU NVIDIA A100
répartis sur 11 noeuds, un GPU peut être divisé en 7 sous-GPU

JupyterHub:
- besoin de pouvoir tester du code interactivement
- un bassin d'utilisateurs croissant (doctorants)
- gestion de la connexion avec authentification
- sessions jupyter courtes (temps limités)
- accès aux environnements AUSTRAL

Sur austral : session JH courte qui tourne sur les sessions de calcul directement.
L'utilisateur peut aller se connecter sur JH, démarrer un service Jupyter et travailler un env. logiciel disponible sur Austral, mais pour une durée limitée.

JH ne cible qu'une partie d'Austral (via SLURM).

basé sur la solution déployée par l'Idris (Jean Zay)

Selection de profil de calcul à la connexion sur le JH → définit une durée d'utilisation (8h)

Tache executé par slurm c'est un service jupyterlab
Si pas de ressources disponible le service ne démarre pas.
Liste de Kernel dispo est celle installé sur Austral

Service Tensorboard pour visualiser leurs modèles et widget Daskboard pour les utilisateurs de Dask
Utilisation native sur le serveur, pas d'utilisation de container

#### Questions

**Yann S.:** pourquoi ne pas acheter de gpus "bas de gamme" plutôt que de scinder les A100 avec MIG? Est-ce qu'il y a un intérêt au niveau coût?

**Pierre-Antoine B. :** @Yann : un premier élément de réponse :
- le ratio puissance/conso est quand même meilleur
- les GPU "bas de gamme" (en réalité plus ancien) ne sont plus forcémnet disponibles à l'achat

**Benoist G.:** On a de toutes les façons des utilisateurs qui ont besoin de ces A100. À l'usage, les utilisateurs préfèrent peu de grosses bêtes plutôt que plein de petites.

**Antoine Fortuné:** Les environnements (kernels) sont géré par conda ?

Oui! et certains packages sont installés à la main.

**Matthieu H.:** Une instance jupyterlab = 1 et un seul noeud de calcul complet dédié ? ou il y a la possibilité de demander plus ou moins ?

non, une instance JLab = la ressource qui est dédiée par SLURM sur les "job profile"


**Tru Huynh:** les utilisateurs peuvent-ils ajouter leur propre "kernel"?

Oui, ils peuvent le faire s'ils sont agguéris : config en local de python puis ..?

---
### Pierre-Antoine Bouttier / Titre à définir

:::info

Pierre-Antoine Bouttier est ingénieur de recherche CNRS en ingéniérie logicielle, actuellement directeur adjoint de l'UAR GRICAD.

GRICAD, sous la tutelle de l’UGA, du CNRS, de G-INP et de l’INRIA, a pour mission de soutenir les communautés de recherche grenobloises dans leurs besoins en calcul scientifique ainsi qu'en gestion des données et des logiciels de recherche. Parmi les services proposés par l'unité, GRICAD opère plusieurs supercalculateurs afin de répondre aux besoins en calcul intensif de l'ensemble des communautés de recherche.

Cette présentation détaillera comment GRICAD, à travers des services dédiés ou via l'usage des supercalculateurs, offre des possibilités pour travailler avec les bloc-notes Jupyter. S'ensuivront quelques réflexions sur les relations entre calcul et traitement de données intensifs et Jupyter.

:::

#### Notes

GRICAD : Mésocentre de calcul grenoblois
Unité qui fournit des conseils de l'accompagnement, formations au profit des communatués de recherche grenobloises

→ fournit des services et infrastructures pour le calcul intensif


**Services fournies et infrastructure**

1/ JupyterHub@Gricad : accessible tous personnels du référentiel UGA
20Go données par utilisateur, avec données persistantes

l'intérêt de ce jupyterhub est assez limité: pas très puissant, pas de GPU, mais très intéressant pour l'enseignement (mais hors mission).
Pas de GPU (donc pas d'IA)
quelques utilisateurs à quelques centaines simultanés (principalement formations)

2/ Cloud computing
VM à la demande avec des ressources ajustables, en fonction de demandes liés à des projets.

Centaines de Go, dizaines de Go RAM, 1 vGPU
Installation et maintenance des VM à la charge des utilisateurs
- usages diversifiés
- liberté totale sur la pile logicielle
- inconvénient : demande des connaissances et compétences en administration système : vrai frein pour certaines communautés

3/ Supercalculateurs :

- Dahu: HPC classique et traitement massif de données
- Bifoot: IA et calcul sur GPU

**Jupyter sur un super calculateur**


Connexion via SSH, réservation de ressources
- mode interactif
- mode passif (simulation préparée en avance)

installation de Jupyter grâce à GUIX et configuration avec 2 lignes à ajouter au fichier de configuration

Tunnel SSH pour l'accès à l'interface (bien lire la doc et faire les copier-coller au bon endroit)

Remarques:
- accès à l'ensemble eds espaces de stockage du cluster
- complexe au début pour les non-initiés
- usage du supercalculateur en mode interactif : frein ?

**Remarques sur les notebooks et HPC**

HPC l'usage interactif n'est pas nominal/standard car les temps d'attente/calculs peuvent être très longs (plusieurs jours)

Problème si 1h réservée : il faut être présent quand les ressources disponibles

Pourquoi un notebook sur un cluster ? besoin de plus de puissance (données massives)

ce qu'on peut améliorer:

- côté utilisateur :
- le besoin de HPC est un indicateur pour extraire le code du notebook et passer sur un projet de dév logiciel à part entière, propre au HPC
- permet d'appliquer des bonnes pratiques de développement de logiciel de la recheche (gestion de version, modularité, maintenance)

- côté GRICAD :
- fournir des solutions simples pour accéder aux ressources (cloud computing → VM toute prêtes avec des gabarits de ressources)
- mieux accompagner les utilisateurs

#### Questions

Pierre Antoine : Quid de la reproductibilité de l'env. logiciel (cf GUIX) dans le cadre d'un projet notebook... ?

---
### Ludovic Courtès / Vers un environnement reproductible pour les blocs-notes Jupyter

:::info

Les blocs-notes de Jupyter Notebook s'imposent comme un moyen permettant aux chercheur·euses de partager et de reproduire des expériences impliquant du calcul. Certains centres de calcul permettent maintenant d'utiliser leurs ressources à travers Jupyter, grâce à une instance JupyterHub.

Chaque bloc-notes fait appel à des outils extérieur : un interprète, un compilateur, des bibliothèques, etc. Cependant, ces dépendances ne sont pas explicites dans le bloc-notes. Dans ces conditions, comment garantir que deux personnes exécutant le bloc-notes dans un environnement différent obtiendront le même résultat ?

Dans cet exposé, je présenterai [Guix-Jupyter](https://gitlab.inria.fr/guix-hpc/guix-kernel), un noyau Jupyter qui vise à fournir un environnement d'exécution contrôlé et reproductible pour les blocs-notes Jupyter. Un bloc-notes Jupyter utilisant ce noyau peut spécifier sous forme d'annotations l'environnment logiciel nécessaire à son exécution. Chaque cellule s'exécute ensuite dans un environnement défini avec le noyau choisi : Python, Julia, R, etc.

Guix-Jupyter utilise en coulisse GNU Guix pour le déploiement logiciel ; je décrirai l'architecture utilisée et en discuterai les avantages et inconvénients. Je montrerai comment cette approche a le potentiel de rendre les bloc-notes Jupyter réellement reproductibles et portables en la comparant à d'autres approches.
:::

#### Notes

Jupyter = science reproductible (?)
aide beaucoup pour la reproductibilité (code + analyse mélangé)
Mais pas d'informations sur ce qui se passe réllement ?

Approche locale: est-ce que les dépendances sont installées ? Est-ce que ça ne va pas installer quelque chose dans l'environnement utilisateur ?

Approche MyBinder : repose sur des outils (pip, apt, ) avec des fichiers de configuration

Problème : il faut des connaissances en administration système (surtout piur des mésocentres) pas forcément réalisable par une personne seule

4 possibilités pour des calculs reproductibles
1. inspecter les données et le code
2. faire tourner sur l'ordinateur de son choix (pas possible avec MyBinder)
3. explorer le comportement du code
4. vérifier les objets produits

Problème du cloud: utilisation d'ordinateurs appartenant à d'autres personnes, perte d'autonomie

Peut on faire du Notebook autocontenu ?

guix: déployer des environnements logiciels de manière reproductible

guix+Jupyter: noyau Jupyter qui permet de déployer un environnement logiciel

définition d'un environnement dans une cellule de conficguration que Guix va créer

Possibilité d'utiliser guix search depuis le notebook

guix pin <numéro de commit> : définition de l'ensemble des paquets disponibles

noyau guic-jupyter sert d'intermédiaire entre jupyter et les noyaux Python/R/Julia

Possibilité d'avoir des cellules qui appellent plusieurs noyaux

Exécution du noyau complètement isolé dans un container (un seul répertoire, un seul utilisateur) => impossible de faire référence à un fichier qui n'est pas sur la machine

Télécharger des données dont le contenu est connu à l'avance avec guix (contrôle de la validité via un hash) => faire référence aux mêmes données

Guix-jupyter : expérience sans vraiment d'utilisateurs, beaucoup de questions (interopérabilité)

Pour résumer
- notebooks auto-suffisants
- lancer du code reproductible
- une 3ème point que j'ai oublié

#### Questions

**Bernard Chambon**
- Qu'est-ce qui limite la scalabilité dans ce cas ? Le framework Dask ? La bande passante disque pour lire et écrire les images ?

---
### Infos / événements

### JE de l'automne