Mini projet HPC

F. Diakhaté, R. Fihue

Date: 18/11/2018

Aperçu et Objectifs

Ce mini projet vous plongera au coeur de monde AWS, et vous permettra de mieux appréhender les différents composants. Vous rencontrerez des difficultés mais ceci donnera un sens à tout ces composants et vous donnera un bonne expérience Cloud à faire valoir plus tard.

L’objectif de ce projet est de vous faire utiliser un outil d’orchestration Cloud. Cet outil, simple d’utilisation, permet d’exprimer une infrastructure avec du code et ainsi d’en contrôler les changements et leurs impacts.

Description du projet

Pour faire le lien avec notre métier, le HPC, nous allons déployer un cluster typique HPC dans le Cloud. Ici ce n’est pas les performance que l’on recherche mais la flexibilité du Cloud pour le rendre plus ou moins gros.

En effet, un cluster HPC est typiquement de taille fixe et ceci entraîne 2 chose : pas assez de charge équivaut à gâcher des ressources (electricité), trop de charge et les utilisateurs voient leur temps d’attente augmenter. Néanmoins ceci permet d’avoir accès à du matériel véritablement orienté HPC (très spécifique)

Avec le Cloud, le matériel n’est plus spécifique mais la flexibilité est présente. Le cluster grandit/réduit en fonction de la charge, ainsi les coûts réels sont en fonction de l’utilisation du cluster. Tout n’est pas parfait néanmoins, la perte de performance peut être significative (réseau notamment) et le coût par coeur de calcul est supérieur.

Outils utilisés

Nous allons utiliser AWS comme plateforme cloud et terraform comme outil d’orchestration.

Vous aurez également accès à des scripts et fichiers de configuration vous permettant de configurer un cluster HPC dans le cloud. Vous aurez ainsi un moyen générique de lancer un cluster HPC, il n’y aura plus qu’à l'orchestrer.

Les liens de documentation suivants seront des aides précieuses:

Terraform Usage : https://www.terraform.io/intro/getting-started/build.html
Terraform AWS provider : https://www.terraform.io/docs/providers/aws/index.html

One-Node cluster

Infrastructure

On commence petit avec un cluster qui n’en est pas un : un seul noeud qui fait controlleur et noeud de calcul.

Le controlleur d’un cluster HPC gère, entres autres, l’allocation des ressources de calcul aux différents utilisateurs à l’aide du produit Slurm un ordonnanceur de job.

Complétez (remplacez les %TODO%) puis lancez le manifest Terraform disponible ici :

https://shell.aimnor.me/tf/1-controller.tf

Vous aurez besoin de :

Credentials AWS
Une paire de clefs SSH

Utilisation

Après avoir lancé votre cluster (terraform apply), vous pouvez lancer des job avec srun.

$ ssh -i %PATH_PRIV_KEY% centos@%IP_CONTROLLER%
$ srun hostname # Lance 1 hostname

ip-172-31-32-17.eu-west-3.compute.internal

# Lance 2 hostname, mais 1 seul coeur dispo

$ srun -n 2 hostname

srun: Requested partition configuration not available now

srun: job 7 queued and waiting for resources

# Lance 2 hostname avec de l’overcommit (2 tâche sur un seul CPU)

$ srun -n 2 --overcommit hostname

ip-172-31-32-17.eu-west-3.compute.internal

Cloud bursting

Infrastructure

Notre petit cluster est loin d’être “HPC” avec 1 seul coeur et 1 seul noeud. Il faut ajouter des noeuds.

Pour cela slurm supporte un mode cloud qui permet de lancer des noeuds à la demande. Si vous demandez des ressources qui ne sont pas disponible, slurm lancera un ou plusieurs noeuds supplémentaires.

Pour cela, ajoutez (wget) les manifests terraform suivants :

Complétez les (remplacez les %TODO%), puis mettez jour votre infrastructure à l’aide de Terraform (terraform apply).

Utilisation

$ ssh -i %PATH_PRIV_KEY% centos@%IP_CONTROLLER%

$ srun hostname # Lance 1 hostname

ip-172-31-32-17.eu-west-3.compute.internal

# Lance 3 hostname ce qui déclenche le déploiement de 3 noeuds

$ srun -n 3 hostname

ip-172-31-37-90.eu-west-3.compute.internal

ip-172-31-38-179.eu-west-3.compute.internal

ip-172-31-46-182.eu-west-3.compute.internal

Industrialisation

Problèmes

Cette infrastructure est certe fonctionne mais possède plusieurs problèmes (dans l’ordre de criticité) :

Aucune facturation des ressource n’est possible (accounting)
Le contrôleur est critique et non-redondé
Les noeuds de calcul sont adressés publiquement et dans une même zone de disponibilité (availability zone)
Les noeuds de calcul sont strictement indépendants, une système de fichier partagé entre eux est nécessaire
L’utilisateur doit se connecter en SSH pour soumettre ses jobs

Solutions

Toutes ces solutions sont à implémenter avec Terraform, l’ordre d’implémentation n’est pas important. Afin de bien suivre les différentes étapes, implémenter chaque solution dans des fichiers différents en utilisant (entre autres) des fichier *_override surchangeant les ressources dejà présentes (cf. fichiers override déjà présents). Par exemple:

$ ls

-rw-rw-r--. 1 fihuer fihuer 5,7K 17 nov. 16:07 1-controller.tf
-rw-rw-r--. 1 fihuer fihuer 4,2K 17 nov. 15:35 2-compute.tf
-rw-rw-r--. 1 fihuer fihuer 1,1K 17 nov. 09:54 2-controller-burst.tf
-rw-rw-r--. 1 fihuer fihuer 3,9K 17 nov. 10:46 2-controller_override.tf
-rw-rw-r--. 1 fihuer fihuer 872 17 nov. 11:33 3-accounting_db.tf
-rw-rw-r--. 1 fihuer fihuer 4,7K 17 nov. 15:35 3-controller_override.tf
-rw-rw-r--. 1 fihuer fihuer 5,0K 17 nov. 16:22 4-controller_override.tf
-rw-rw-r--. 1 fihuer fihuer 2,9K 17 nov. 16:22 4-isolated-computes.tf

Accounting

A l’aide du service RDS d’AWS, et des fichiers de configuration suivants installez slurm-slurmdbd, configurez et lancez le service slurmdbd sur le noeud controleur..

#/etc/slurm/slurmdbd.conf
AuthType=auth/munge
AuthInfo=/var/run/munge/munge.socket.2
DbdAddr=localhost
DbdHost=localhost
DbdPort=6819
DebugLevel=3
LogFile=/var/log/slurmdbd.log
PidFile=/var/run/slurmdbd.pid
StorageType=accounting_storage/mysql
StorageHost=%DB_ADDR%
StoragePort=%DB_PORT%
StoragePass=%DB_PASS%
StorageUser=%DB_USER
StorageLoc=%DB_NAME%

#/etc/slurm/slurm.conf
[...]
AccountingStorageType=accounting_storage/slurmdbd

Adressage privé

A l’aide de nouveaux sous-réseaux, isolez les noeuds de calcul d’un accès direct depuis Internet. Un schéma du réseau attendu :

Les sous-réseaux des différents noeuds de calcul doivent être distincts et dans des zones de disponibilité distinctes. La configuration de slurm pourra ressembler à :

#/etc/slurm/slurm.conf.d/slurm_nodes.conf

[...]
NodeName=compute-a-[1-100] Features=${aws_subnet.comp_a.id} State=Cloud
NodeName=compute-b-[1-100] Features=${aws_subnet.comp_b.id} State=Cloud NodeName=compute-c-[1-100] Features=${aws_subnet.comp_c.id} State=Cloud

Le script de lancement (start_ec2_compute) est à adapter également.

Espace partagé entre les noeuds de calcul

A l’image des contrôleurs et leur système de fichier partagé, ajoutez un espace partagé AWS FSx entre tous les noeuds de calcul et montez le au démarrage.

Vous pourrez vérifier le bon fonctionnement avec

srun -n 3 df -h

Votre filesystem devrait apparaître dans la sortie.

Soumission avec une API

A l’aide d’API Gateway, Lambda et SSM implémentez une façon de soumettre des jobs avec une interface REST minimale ie.

curl -X POST -d @- https://????.execute-api.eu-west-1.amazonaws.com/prod/submit
#!/bin/bash -x
#SBATCH -n 10
#SBATCH -o /nfs/toto

date

hostname
sleep 60

Pour soumettre un job avec slurm :

sbatch %BATCH_FILE%

echo -e '#!/bin/bash -x\nsleep 30' | sbatch

Réponse

Le résultat de ce TP devra être sous la forme de plusieurs fichiers Terraform (.tf). Versionnez ces fichiers et soumettez les nous à chaque version fonctionnelle ie. pour chaque amélioration que vous aurez implémenté avec une description sommaire de l’infrastructure déployée.

Assistance

Ne restez pas coincés, ce n’est pas l’objectif de ce TP. En cas de problème ou si vous avez questions, contactez nous. Dans certains cas, nous pourrons vous donner des indices ou un bout de la réponse.