Skip to content

GitLab

Commit 22617782 authored by Martin Souchal's avatar Martin Souchal
Browse files

reorg

parent 2651e578
Pipeline #99517 passed with stages
in 1 minute and 57 seconds
Hide whitespace changes
Inline Side-by-side
Showing with 167 additions and 64 deletions
prez.html
View file @ 22617782
......@@ -43,31 +43,29 @@
.right[![](images/logo-computeops-web.png)]
---
# Architecture HPC
### High Performance Computing
# Plan
- Cluster de calcul
- Utilisation d'accélérateurs (GPUs, TPUs...)
- Calcul parrallèle avec mémoire partagée (MPI)
- Spark, hadoop...
- Scheduler (Univa, SGE, Slurm, etc...)
=> Une technologie de conteneur doit s'intégrer dans cet environnement
---
# Problématiques software HPC
- Les conteneurs : principes généraux
- Les conteneurs et le HPC
- Focus sur Singularity
- Orchestration et Job Scheduling
- Conclusion
---
# Les conteneurs
### Un peu d'histoire...
- Technologie apparue dans Solaris via les jails
- Basé sur les kernel namespaces (kernel 2.4.19) et les cgroups (kernel 2.6.24)
- LXC/LXD en 2008, Docker en 2013
- Kubernetes en 2014 chez Google
- 2015 : Docker top 15 GitHub, création de l'[Open Container Initiative](https://opencontainers.org/) (OCI)
<img style="width:60%; float: right;" src="images/landscape.png" >
---
# Les conteneurs
### Principe de base
- Au repos, un conteneur est un fichier (ou un ensemble de fichiers) qui est enregistré sur un disque.
- A l'arrêt, un conteneur est un fichier (ou un ensemble de fichiers) qui est enregistré sur un disque.
- Au démarage du conteneur, le moteur décompresse les fichiers et les méta-données nécessaires, puis les transmet au noyau Linux, comme un processus normal.
- Au démarage du conteneur un appel API au noyau déclenche une isolation supplémentaire (si nécessaire) et monte une copie des fichiers de l'image du conteneur.
- Une fois lancés, les conteneurs ne sont un processus Linux comme un autre.
......@@ -121,8 +119,8 @@
---
# Runtimes
- Runtimes bas niveau : runc (docker), LXC/LXD, crun, conmon (RedHat)
- Runtimes haut niveau : Docker, Singularity, Podman (RedHat), containerd (Docker), CR-IO (Kubernetes)
- Runtimes bas niveau : runc (docker), LXC/LXD, crun, conmon (RedHat), nvidia-docker (Nvidia)
- Runtimes haut niveau : Docker, Singularity, Podman (RedHat), containerd (Docker), CR-IO (Kubernetes), enroot (Nvidia), SmartOs (Samsung)
- MicroVms : KataContainer (INTEL), Firecracker (AWS), gVisor (google)
- Image builder : buildah, img, orca-build...
......@@ -131,6 +129,32 @@
.footnote[Source : [Alterway](https://blog.alterway.fr/le-point-sur-les-container-runtimes.html), [XataZ](https://catlife.drycat.fr/~/XataZ/la-jungle-des-conteneurs)]
---
# Isolation et performances
- runtimes de bas niveau en user mode (namespaces) :
- Temps d'instanciation minimal
- Isolation faible (proche du matériel)
- Performances optimales
- runtimes sécurisées (Kata, gVisor) :
- Isolation forte (équivalent VM)
- Temps d'instanciation modéré (plus rapide que VMs)
- Performances dégradées, dépendantes hardware
- Performances lièes aux formats d'images
- Format en couches optimisés pour téléchargement
- Format fchier optimisé pour le stockage
---
# Sécurité
- Docker : daemon root, possibilité d'être root dans un conteneur
- Conteneurs user mode :
- même utilisateur hors du conteneur et dans le conteneur
- les problématiques de sécurité sont reportées sur le noyau linux
- Isolation plus ou moins forte
- Vecteur de failles de sécurité logicelle important
- Vecteur d'attaque pour rootkit (très facile de cacher du code malicieux dans un conteneur)
---
# Registres publics
### Ou trouver des images de conteneurs prêtes à l'emploi ?
......@@ -147,10 +171,50 @@
# Registres privés
### Comment partager ses applications conteneurisées ?
- Gitlab
- Harbor
- Singularity Hub
- Azure, AWS, etc...
- Gitlab (Registre Docker)
- Harbor (Registre Docker)
- Singularity Hub (Registre Singularity)
- Azure, AWS, etc... (OCI)
- Pour stocker des images OCI dans des registres docker : [ORAS](https://github.com/deislabs/oras/)
<img style="float: right;" src="images/oras.png" >
---
# Bonnes pratiques
- Partager le manifeste du conteneur avec le conteneur
- Utiliser l'intégration continue pour la génération de conteneurs
- Spécifier toutes les versions exactes des OS et des logiciels dans les manifestes (conda env export, pip freeze, etc....)
- Taguer les images des conteneurs
- Signer les conteneurs diffusés à l'aide de clés
- Préferer les catalogues d'images vérifiées, ou au moins ceux qui scannent les failles de sécurité
---
name: inverse
class: center, inverse, middle
# Les conteneurs et le HPC
---
# Architecture HPC
### High Performance Computing
<img style="width:40%;float: right;" src="images/HPC-arch.png" >
- Cluster/grappe de calcul
- Matériel spécifique :
- Utilisation d'accélérateurs (GPUs, TPUs...)
- Réseau Infiniband/Omnipath
- Calcul parallèle avec mémoire partagée (MPI)
- Spark, hadoop...
- Orchestration avec un Job Scheduler (Univa, SGE, Slurm, etc...)
---
# Problématiques software HPC
- Besoin de performances et d’optimisations au plus proche du matériel.
- Des jobs qui tournent des semaines, voir des mois ; la maintenance doit être planifiée longtemps en avance,
- Applications scientifiques parfois complexes à compiler, avec de nombreuses dépendances,
- Des noyaux souvent plus vieux que d’ordinaire (nombreux soucis avec la glibc)...,
- Environnement cluster = multi-utilisateurs.
- Support : "J’ai besoin du logiciel X..."
---
# En quoi les conteneurs peuvent nous aider dans le contexte scientifique ?
......@@ -196,45 +260,52 @@
.right[![rescience](images/rescience.png)]
---
# Bonnes pratiques
- Partager le manifeste du conteneur avec le conteneur
- Utiliser l'intégration continue pour la génération de conteneurs
- Spécifier toutes les versions exactes des OS et des logiciels dans les manifestes (conda env export, pip freeze, etc....)
- Taguer les images des conteneurs
- Signer les conteneurs diffusés à l'aide de clés
- Préferer les catalogues d'images vérifiées, ou au moins ceux qui scannent les failles de sécurité
---
# Sécurité
---
background-image: url(images/docker.png)
# Docker et le calcul
### Un ecosystème pas très adapté...
- Docker est un micro service
- Network namespace et compatibilité matériel réseau pour cluster (Intel OmniPath, Infiniband...). Problématique MPI.
- Image docker : superpositions de couches
- GPU
- Sécurité
- daemon root
- pas d’isolation : une appli root du conteneur qui s’échappe = un attaquant root sur la machine physique
- Docker est un micro service (un conteneur, une application), pas très facile de gérer des chaines de calcul
- Network namespace et compatibilité matériel réseau pour cluster (Intel OmniPath, Infiniband...)
- Aucun support MPI.
- Image docker : superpositions de couches, pas très portable dans un cluster
- GPU Nvidia supportés par [nvidia-docker](https://github.com/NVIDIA/nvidia-docker)
- Sécurité :
- daemon root à installer sur tous les noeuds de calculs...
- des utilisateurs root dans votre cluster...
.right[![](images/docker-filesystems-multilayer.png)]
---
# Nivida docker
- Permet d'utiliser des GPUs Nvidia avec Docker
- Utilisable comme runtime et comme toolkit
- Prérequis : kernel version > 3.10, Docker >= 19.03, NVIDIA GPU > Fermi, NVIDIA drivers ~= 361.93
<img style="width:40%;float: left;" src="images/nvidia-docker.png" >
<img style="width:40%;float: right;" src="images/nvidia-docker-arch.png" >
.footnote[Source [NVIDIA](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/overview.html)]
---
# Conteneurs orientés calcul
## 4 Conteneurs usermode compatibles HPC
- [Charlie-cloud](https://github.com/hpc/charliecloud) (dernière release 18/12/2020)
- [Singularity](https://github.com/hpcng/singularity) (12/01/2021)
- [Shifter](https://github.com/NERSC/shifter) (01/04/2018)
- [Nvidia enroot](https://github.com/NVIDIA/enroot) (02/12/2020)
<hr />
Nom | Dernière Release | Support | OCI
------------- | ------------- | ------------- | -------------
[Charlie-cloud](https://github.com/hpc/charliecloud) | 18/12/2020 | MPI - GPU - IB | Non
[Singularity](https://github.com/hpcng/singularity) | 12/01/2021 | MPI - GPU - IB | Oui
[Shifter](https://github.com/NERSC/shifter) | 01/04/2018 | MPI - GPU - IB | Non
[Nvidia enroot](https://github.com/NVIDIA/enroot) | 02/12/2020 | GPU - IB | Oui
---
background-image: url(images/charlie.png)
# Charlie-cloud
- Développé à Los Alamos
- Développé à Los Alamos National Laboratory (LANL)
- Univers docker
- nécessite de modifier la configuration kernel (user.max_user_namespaces, namespace.unpriv_enable=1)
- Pas de package, make install uniquement
- Runtime uniquement (pas de construction d'image)
- conteneurs utilisables sans droits root
- un conteneur = un répertoire
......@@ -248,6 +319,7 @@
# Shifter
- Développé au NERSC
- Pas de package
- Images docker converties mais ne nécessite pas docker installé
- Nombreuses dépendances pour l'installation
- Nécessite un Image gateway pour faire lien entre docker et shifter
......@@ -259,40 +331,68 @@
- Libre et gratuit
---
name: inverse
class: center, inverse, middle
# Singularity
---
background-image: url(images/singu.png)
# Singularity
- Développé au Berkeley Lab // Sylabs par GREGORY KURTZER (CentOS, Warewulf)
- Aucune dépendance pour l'installation
- compatible toute distribution linux avec kernel récent
- droits root nécessaires pour créer un conteneur
- compatible avec les images docker, dockerhub, ORAS
- Support GPU : possibilité de monter le GPU dans le conteneur avec les drivers de l'host (--nv)
- Pas de gestion integrée du réseau
- un conteneur = un fichier (meilleures perfs sur fs distribué) ou un répertoire
- Ecrit en Go
- Cloud propriétaire
- Libre et gratuit / Version pro payante
# Historique
* Inventé par Greg Kurtzer (CentOS, Warewulf) au Berkeley Lab pour répondre aux problèmes spécifiques au HPC
* Développement démarré en Octobre 2015
* Première release en Avril 2016
* Les retours de la communauté ont menés à la version 2.0 en Juin 2016
* Sylabs.io en Janvier 2018
* Sortie de la version 3.0 en Octobre 2018 avec une réécriture complète, de nouvelles fonctionalités et une ambition hors HPC
* Support officiel NVIDIA via GPU Cloud
---
background-image: url(images/singu.png)
# Fonctionnalités
* Necessite Golang > 1.13 pour la compilation
* Package RPM uniquement
* Droits root nécessaires pour créer un conteneur localement
* SIF est le format d'image par défaut, apportant chiffrement, signature et vérification
* Fichier image unique, executable
* Infrastructure Cloud (Container Library, Remote Builder, et Keystore)
* Possibilité d’exécuter des images Docker et OCI
* Support/isolation réseau (plugins CNI / root uniquement)
* Support GPU natif avec les drivers de la machine hôte
* Libre et gratuit / Version pro payante
---
background-image: url(images/singu.png)
# Sécurité
* Support des Cgroups
* L’utilisateur root peut définir un set de capabilities à l’exécution
* L’administrateur peut gérer les capabilities des utilisateurs (avec précaution)
* Les utilisateurs peuvent passer un contexte d’exécution SELinux, ou un profil AppArmor
* Les utilisateurs peuvent passer leurs propres filtres d’appel système via seccomp
* Support d’exécution avec des UID/GID différents pour l’utilisateur root
* Conteneurs chiffrés (SIF)
---
background-image: url(images/singu.png)
# Avantages de Singularity
# Avantages de Singularity pour le HPC
- Facile à installer et à déployer sur un cluster de calcul
- Compatibilité avec Docker
- Utilisation de registres Public/Privé dédiés (http://www.singularity-hub.org/)
- Un conteneur est facile à transporter pour l'utilisateur (un fichier à copier)
- Singularity apps
- Compatible tous scheduler (Dans Singularity, pas de démon, vu comme une application
standard par le Job Scheduler. Compatible avec les vieux
noyaux, pas de problèmes de sécurité (ou rarement). Pas de
‘cgroups‘ ; les limites sont fixées par le Job Scheduler.)
- Compatible tous scheduler (Dans Singularity, pas de démon, vu comme une application standard par le Job Scheduler. Compatible avec les vieux noyaux, pas de problèmes de sécurité (ou rarement). Pas de ‘cgroups‘ ; les limites sont fixées par le Job Scheduler.)
- Intégration de tests et d'aide intégrée dans le conteneur
- Accès direct aux GPU de la machine
- Intégration dans Kubernetes
---
name: inverse
class: center, inverse, middle
# Orchestration et scheduling
---
# Orchestrateur de conteneur
......@@ -359,6 +459,8 @@
- mécanismes de files d’attente/de mises en attente ou pause (checkpointing), de priorités / Fair sharing, droits/accès et partages des ressources physiques.
- Intégration dans l’environnement cluster existant
---
# Conclusion
---
# Questions
---
......
style.css
View file @ 22617782
......@@ -48,8 +48,9 @@ code {
padding: 15px;
}
.inverse {
background: #2c2e2c;
color: #777872;
background: #0534b6;
background-image: url(images/hero-bg.png);
color: #fcfdf9;
text-shadow: 0 0 1px rgb(92, 90, 90);
}
.inverse h1, .inverse h2 {
......@@ -107,7 +108,7 @@ code {
padding-top: 12px;
padding-bottom: 12px;
text-align: left;
background-color: #4CAF50;
background-color: #2370c9;
color: white;
}
.remark-slide-content tr:nth-child(even){background-color: #f2f2f2;}
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment