Conteneurs HPC à grande échelle avec Podman

Cet article décrit des travaux récents effectués au NERSC en collaboration avec Red Hat pour modifier Podman (l’outil de gestion de pod) pour fonctionner à grande échelle, une exigence clé pour le calcul haute performance (HPC). Podman est un outil open source pour développer, gérer et exécuter des conteneurs sur des systèmes Linux. Pour plus de détails sur ces travaux, veuillez consulter notre article qui sera publié dans les actes de CANOPIE-HPC Supercomputing 2022.

Dans ce qui suit vidéo de démonstrationnous passons en revue l’extraction d’une image sur Perlmutter à partir du registre NERSC, la génération d’une version écrasée de l’image à l’aide de podman-hpc et l’exécution du benchmark EXAALT à grande échelle (900 nœuds, 3 600 GPU) via notre podman-exec emballage. Le système de supercalcul phare du NERSC est Perlmutter, actuellement numéro 7 sur la liste des 500 meilleurs. Il possède une partition GPU avec plus de 6000 GPU NVIDIA A100 et une partition CPU avec plus de 6000 processeurs AMD Milan. Tout le travail décrit dans ce billet de blog a été réalisé sur Perlmutter.

NERSC, le National Energy Research Scientific Computing center, est l’installation informatique de la mission de production du Département américain de l’énergie qui dessert le DOE Office of Science, qui finance un large éventail de recherches fondamentales et appliquées. Au premier semestre 2022, plus de 700 utilisateurs uniques ont utilisé Shifterla solution de conteneur actuelle du NERSC, et l’intérêt général des utilisateurs pour les conteneurs est en croissance.

Bien que NERSC ait démontré des performances proches du métal nu avec Shifter à grande échelle, plusieurs lacunes nous ont motivés à explorer Podman. Le principal facteur est que Shifter ne fournit aucun utilitaire de construction. Les utilisateurs doivent créer des conteneurs sur leur propre système local et envoyer leurs images au NERSC via un registre. Un autre obstacle est que Shifter assure la sécurité en limitant le conteneur en cours d’exécution aux privilèges de l’utilisateur qui l’a lancé. Enfin, Shifter est principalement une solution « interne », les utilisateurs doivent donc apprendre une nouvelle technologie, et le personnel du NERSC a la charge supplémentaire de maintenir ce logiciel.

Podman fournit une solution à tous ces principaux points douloureux. Podman est un cadre conforme à l’OCI qui adhère à un ensemble de normes communautaires. Il semblera familier aux utilisateurs qui ont utilisé d’autres outils compatibles OCI comme Docker. Il a également une grande communauté d’utilisateurs et de développeurs avec plus de 15 000 étoiles sur GitHub en octobre 2022. L’innovation majeure qui nous a attirés vers Podman est les conteneurs sans racine. Les conteneurs sans racine limitent élégamment les privilèges en utilisant une carte subuid/subgid pour permettre au conteneur de s’exécuter dans l’espace de noms de l’utilisateur, mais avec ce qui ressemble à des privilèges root complets. Podman fournit également une fonctionnalité de création de conteneurs qui permettra aux utilisateurs de créer des images directement sur les nœuds de connexion Perlmutter, supprimant ainsi un obstacle majeur dans leurs flux de travail de développement.

[ Check out the latest Podman articles on Enable Sysadmin. ]

L’activation de Podman à grande échelle sur Perlmutter avec des performances quasi natives nous a obligés à aborder l’intégration, l’évolutivité et les performances du site. De plus, nous avons développé deux scripts wrapper pour obtenir deux modes de fonctionnement : Podman container-per-process et podman-exec. Podman container-per-process mode décrit la situation dans laquelle de nombreux processus s’exécutent sur le nœud (généralement dans une application MPI), avec un conteneur individuel en cours d’exécution pour chaque processus. Les podman-exec mode décrit la situation dans laquelle un seul conteneur s’exécute par nœud, même s’il existe plusieurs processus MPI.

Nous avons couru plusieurs repères avec podman-hpc sur Perlmutter pour mesurer les performances des implémentations bare metal : Shifter, Podman container-per-processet podman-exec mode. Le benchmark EXAALT exécute l’application de dynamique moléculaire LAMMPS, le benchmark Pynamic simule les importations de packages Python et les invocations de fonctions, et le benchmark DeepCAM est une application d’apprentissage en profondeur de segmentation des données climatiques. En général, les benchmarks suggèrent des performances comparables entre bare metal, Shifter et podman-exec cas. Les frais généraux de démarrage encourus dans Podman container-per-process peut être vu dans les résultats de Pynamic et DeepCAM. En général, podman-exec était notre configuration la plus performante, c’est donc sur ce mode que nous concentrerons nos futurs efforts de développement.

Résultats de notre benchmark EXAALT à forte échelle à 32, 64, 128 et 256 nœuds. La moyenne de deux résultats d’exécution sur métal nu est affichée en rouge, les résultats d’exécution de Shifter sont affichés en bleu, Podman container-per-process les résultats d’exécution sont affichés en vert foncé, et podman-exec les résultats du mode sont affichés en vert clair avec les barres d’erreur correspondantes.

Les résultats du benchmark Pynamic pour le bare metal (rouge), Shifter (bleu), podman-exec mode (vert) et Podman container-per-process mode (vert clair) sur deux tailles de travail (128 et 256 nœuds) utilisant 64 tâches par nœud. Toutes les configurations ont été exécutées trois fois.

Les résultats du benchmark de mise à l’échelle solide MLPerf DeepCAM pour Shifter (bleu), Podman container-per-process (vert clair), et podman-exec mode (vert foncé) sur une plage de tailles de travaux (16, 32, 64 et 128 nœuds GPU Perlmutter). Nous séparons les données de synchronisation en démarrage du conteneur, démarrage de la formation et exécution de la formation.

Nous sommes ravis des résultats que nous avons vus jusqu’à présent, mais nous avons encore du travail à faire avant de pouvoir ouvrir Podman à tous les utilisateurs du NERSC. Pour améliorer l’expérience utilisateur, nous visons à explorer l’ajout de l’intégration Slurm pour supprimer une partie de la complexité de l’utilisation de scripts wrapper imbriqués, en particulier pour le podman-exec Cas. Nous visons également à obtenir notre podman-hpc scripts et binaires dans les images de démarrage Perlmutter de tous les nœuds, de sorte que leur mise en scène sur chaque nœud ne sera plus nécessaire. Nous espérons résoudre certaines des limitations de la fonctionnalité de hook OCI (par exemple, l’impossibilité de définir des variables d’environnement) avec la communauté OCI. Enfin, notre objectif est d’intégrer une grande partie de notre travail en amont dans Podman lui-même afin que la communauté Podman plus large puisse tirer parti de notre travail.