1. Présentation
Bienvenue dans l'atelier de programmation Google pour exécuter un cluster Slurm sur Google Cloud Platform. À la fin de cet atelier de programmation, vous devriez bien comprendre la facilité de provisionnement et de fonctionnement d'un cluster Slurm avec autoscaling.
Google Cloud s'est associé à SchedMD pour lancer un ensemble d'outils qui facilitent le lancement du gestionnaire de charge de travail Slurm sur Compute Engine et l'extension dynamique de votre cluster existant lorsque vous avez besoin de ressources supplémentaires. Cette intégration a été conçue par les experts de SchedMD conformément aux bonnes pratiques de Slurm.
Si vous prévoyez d'utiliser les intégrations Slurm sur Google Cloud Platform ou si vous avez des questions, n'hésitez pas à rejoindre notre groupe de discussion de la communauté Google Cloud et Slurm.
À propos de Slurm
Diagramme d'architecture de base d'un cluster Slurm autonome dans Google Cloud Platform.
Slurm est l'un des principaux gestionnaires de charge de travail pour les clusters HPC dans le monde. Slurm est un système de gestion de charges de travail et de planification de jobs Open Source, tolérant aux pannes et hautement évolutif pour les clusters Linux de toutes tailles. Slurm ne nécessite aucune modification du noyau pour fonctionner et est relativement autonome. En tant que gestionnaire de charge de travail de cluster, Slurm assure trois fonctions clés :
- Il alloue aux utilisateurs un accès exclusif ou non exclusif aux ressources (nœuds de calcul) pendant une certaine durée afin qu'ils puissent effectuer leur travail.
- Il fournit un framework pour démarrer, exécuter et surveiller le travail (normalement un job parallèle) sur l'ensemble des nœuds alloués.
- Il arbitre la contention des ressources en gérant une file d'attente des tâches en attente.
Points abordés
- Configurer un cluster Slurm à l'aide de Terraform
- Exécuter une tâche avec SLURM
- Demander des informations au cluster et surveiller les tâches en cours d'exécution dans SLURM
- Autoscaler les nœuds pour s'adapter aux paramètres et aux exigences spécifiques des tâches
- Où trouver de l'aide pour Slurm
Prérequis
- Compte Google Cloud Platform et projet avec facturation
- Expérience Linux de base
2. Configuration
Configuration de l'environnement au rythme de chacun
Créer un projet
Si vous ne possédez pas encore de compte Google (Gmail ou G Suite), vous devez en créer un. Connectez-vous à la console Google Cloud Platform ( console.cloud.google.com) et ouvrez la page Gérer les ressources :
Cliquez sur Créer un projet.
Saisissez le nom du projet. Retenez l'ID du projet (mis en évidence en rouge dans la capture d'écran ci-dessus). L'ID du projet doit être un nom unique parmi tous les projets Google Cloud. Si le nom de votre projet n'est pas unique, Google Cloud générera un ID de projet aléatoire basé sur le nom du projet.
Vous devez ensuite activer la facturation dans la console Developers pour pouvoir utiliser les ressources Google Cloud.
Suivre cet atelier de programmation ne devrait pas vous coûter plus d'un euro. Cependant, cela peut s'avérer plus coûteux si vous décidez d'utiliser davantage de ressources ou si vous n'interrompez pas les ressources (voir la section "Conclusion" à la fin du présent document). Le simulateur de coût Google Cloud Platform est disponible sur cette page.
Les nouveaux utilisateurs de Google Cloud Platform peuvent bénéficier d'un essai sans frais avec 300$de crédits.
Google Cloud Shell
Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.
Lancer Google Cloud Shell
Depuis la console GCP, cliquez sur l'icône Cloud Shell de la barre d'outils située dans l'angle supérieur droit :
Cliquez ensuite sur Démarrer Cloud Shell :
Le provisionnement de l'environnement et la connexion ne devraient pas prendre plus de quelques minutes :
Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et simplifie l'authentification. Vous pouvez réaliser une grande partie, voire la totalité, des activités de cet atelier dans un simple navigateur Web ou sur un Google Chromebook.
Une fois connecté à Cloud Shell, vous êtes en principe authentifié, et le projet est déjà défini sur votre PROJECT_ID :
$ gcloud auth list
Résultat de la commande :
Credentialed accounts:
- <myaccount>@<mydomain>.com (active)
$ gcloud config list project
Résultat de la commande :
[core]
project = <PROJECT_ID>
Si l'ID de projet n'est pas défini correctement, vous pouvez le définir avec cette commande :
$ gcloud config set project <PROJECT_ID>
Résultat de la commande :
Updated property [core/project].
3. Préparer et examiner la configuration Terraform de Slurm
Télécharger la configuration Terraform Slurm
Dans la session Cloud Shell, exécutez la commande suivante pour cloner (télécharger) le dépôt Git contenant les fichiers Terraform de Slurm pour Google Cloud Platform :
git clone https://github.com/SchedMD/slurm-gcp.git
Passez au répertoire de configuration du déploiement Slurm en exécutant la commande suivante :
cd slurm-gcp
Configurer les tfvars Terraform Slurm
Le fichier basic.tfvars.example détaille la configuration du déploiement, y compris le réseau, les instances et le stockage à déployer. Copiez-le dans un nouveau fichier, que nous appellerons "fichier tfvars", puis modifiez-le si nécessaire.
cd tf/example/basic cp basic.tfvars.example basic.tfvars
Dans la session Cloud Shell, ouvrez le fichier tfvars basic.tfvars. Pour afficher le contenu du fichier, vous pouvez utiliser l'éditeur de ligne de commande de votre choix (vi, nano, emacs, etc.) ou l'éditeur de code de la console Cloud :
Examinez le contenu du fichier tfvars.
cluster_name = "g1"
project = "<project>"
zone = "us-west1-b"
# network_name = "<existing network name>"
# subnetwork_name = "<existing subnetwork name>"
# shared_vpc_host_project = "<vpc host project>"
# disable_controller_public_ips = true
# disable_login_public_ips = true
# disable_compute_public_ips = true
# suspend_time = 300
controller_machine_type = "n1-standard-2"
controller_image = "projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
controller_disk_type = "pd-standard"
controller_disk_size_gb = 50
# controller_labels = {
# key1 = "val1"
# key2 = "val2"
# }
# controller_service_account = "default"
# controller_scopes = ["https://www.googleapis.com/auth/cloud-platform"]
# cloudsql = {
# server_ip = "<cloudsql ip>"
# user = "slurm"
# password = "verysecure"
# db_name = "slurm_accounting"
# }
# controller_secondary_disk = false
# controller_secondary_disk_size = 100
# controller_secondary_disk_type = "pd-ssd"
#
# When specifying an instance template, specified controller fields will
# override the template properites.
# controller_instance_template = null
login_machine_type = "n1-standard-2"
login_image = "projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
login_disk_type = "pd-standard"
login_disk_size_gb = 20
# login_labels = {
# key1 = "val1"
# key2 = "val2"
# }
# login_node_count = 1
# login_node_service_account = "default"
# login_node_scopes = [
# "https://www.googleapis.com/auth/monitoring.write",
# "https://www.googleapis.com/auth/logging.write"
# ]
#
# When specifying an instance template, specified login fields will
# override the template properties.
# login_instance_template = null
# Optional network storage fields
# network_storage is mounted on all instances
# login_network_storage is mounted on controller and login instances
# network_storage = [{
# server_ip = "<storage host>"
# remote_mount = "/home"
# local_mount = "/home"
# fs_type = "nfs"
# mount_options = null
# }]
#
# login_network_storage = [{
# server_ip = "<storage host>"
# remote_mount = "/net_storage"
# local_mount = "/shared"
# fs_type = "nfs"
# mount_options = null
# }]
# compute_node_service_account = "default"
# compute_node_scopes = [
# "https://www.googleapis.com/auth/monitoring.write",
# "https://www.googleapis.com/auth/logging.write"
# ]
partitions = [
{ name = "debug"
machine_type = "n1-standard-2"
static_node_count = 0
max_node_count = 10
zone = "us-west1-b"
image ="projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
image_hyperthreads = false
compute_disk_type = "pd-standard"
compute_disk_size_gb = 20
compute_labels = {}
cpu_platform = null
gpu_count = 0
gpu_type = null
network_storage = []
preemptible_bursting = false
vpc_subnet = null
exclusive = false
enable_placement = false
regional_capacity = false
regional_policy = {}
instance_template = null
},
# { name = "partition2"
# machine_type = "n1-standard-16"
# static_node_count = 0
# max_node_count = 20
# zone = "us-west1-b"
# image = "projects/schedmd-slurm-public/global/images/family/schedmd-slurm-20-11-4-hpc-centos-7"
# image_hyperthreads = false
#
# compute_disk_type = "pd-ssd"
# compute_disk_size_gb = 20
# compute_labels = {
# key1 = "val1"
# key2 = "val2"
# }
# cpu_platform = "Intel Skylake"
# gpu_count = 8
# gpu_type = "nvidia-tesla-v100"
# network_storage = [{
# server_ip = "none"
# remote_mount = "<gcs bucket name>"
# local_mount = "/data"
# fs_type = "gcsfuse"
# mount_options = "file_mode=664,dir_mode=775,allow_other"
# }]
# preemptible_bursting = true
# vpc_subnet = null
# exclusive = false
# enable_placement = false
#
# ### NOTE ####
# # regional_capacity is under development. You may see slowness in
# # deleting lots of instances.
# #
# # With regional_capacity : True, the region can be specified in the zone.
# # Otherwise the region will be inferred from the zone.
# zone = "us-west1"
# regional_capacity = True
# # Optional
# regional_policy = {
# locations = {
# "zones/us-west1-a" = {
# preference = "DENY"
# }
# }
# }
#
# When specifying an instance template, specified compute fields will
# override the template properties.
# instance_template = "my-template"
]
Ce fichier tfvars contient plusieurs champs à configurer. Le seul champ à configurer est project. Toutes les autres configurations de l'exemple peuvent être utilisées telles quelles, mais modifiez-les si nécessaire pour votre situation. Pour obtenir une description plus détaillée des options de configuration, cliquez ici.
- cluster_name: : nom du cluster Slurm
- project : ID du projet Google Cloud dans lequel les ressources seront déployées
- zone : zone Google Cloud qui contiendra les instances de contrôleur et de connexion de ce cluster. En savoir plus
- network_name: Virtual Private Cloud network pour déployer le cluster Slurm
- subnetwork_name: : sous-réseau de cloud privé virtuel dans lequel déployer le cluster Slurm
- shared_vpc_host_project: Réseau VPC partagé dans lequel déployer le cluster Slurm
- disable_controller_public_ips: : attribuer une adresse IP externe au contrôleur Slurm ?
- disable_login_public_ips: : attribuer une adresse IP externe au nœud de connexion Slurm ?
- disable_compute_login_ips: : attribuer une adresse IP externe au nœud de connexion Slurm ?
- suspend_time: : délai d'attente après l'inactivité d'un nœud avant de le suspendre
- controller_machine_type: Type d'instance du nœud de contrôleur
- controller_image: : image GCP utilisée pour créer l'instance de contrôleur Slurm
- controller_disk_type: : type du disque de démarrage de l'instance de contrôleur
- controller_disk_size_gb: : taille du disque de démarrage d'une instance de contrôleur
- controller_labels: libellé(s) à associer à l'instance de contrôleur
- controller_service_account: Compte de service à utiliser sur l'instance de contrôleur
- controller_scopes: Niveau d'accès de l'instance de contrôleur
- cloudsql : serveur Google Cloud SQL à utiliser comme base de données Slurm au lieu d'héberger une base de données sur l'instance de contrôleur
- server_ip: : adresse IP du serveur Cloud SQL
- user : nom d'utilisateur CloudSQL
- password : mot de passe CloudSQL
- db_name: : nom de la base de données CloudSQL
- controller_secondary_disk: : ajouter un disque secondaire pour le stockage du serveur NFS ?
- controller_secondary_disk_type: : type du disque secondaire du contrôleur
- controller_secondary_disk_size_gb: : taille du disque secondaire du contrôleur
- controller_instance_template: : modèle d'instance GCP à utiliser pour l'instance de contrôleur. Tous les champs de calcul spécifiés remplaceront les propriétés du modèle. Par exemple, si controller_image est spécifié, il remplacera l'image dans le modèle d'instance.
- login_machine_type: : type d'instance du nœud de connexion (accessible via SSH)
- login_image: : image GCP utilisée pour créer l'instance de connexion Slurm
- login_disk_type: : type du disque de démarrage de l'instance de connexion
- login_disk_size_gb: : taille du disque de démarrage de l'instance de connexion
- login_labels: : libellé(s) à associer à l'instance de connexion
- login_node_count: : nombre de nœuds de connexion à créer
- login_node_service_account: Service account to be used on the login instance(s)
- login_node_scopes: : champ d'application de l'accès de l'instance de connexion
- login_instance_template: : modèle d'instance GCP à utiliser pour l'instance de connexion. Tous les champs de calcul spécifiés remplaceront les propriétés du modèle. Par exemple, si login_image est spécifié, il remplacera l'image dans le modèle d'instance.
- network_storage: : stockage réseau à monter sur tous les nœuds. Les champs seront ajoutés directement à fstab. Peut être répété pour les montages supplémentaires.
- server_ip: : adresse IP du serveur de stockage
- remote_mount: : nom du point de montage du stockage (nom du système de fichiers)
- local_mount: : répertoire d'installation local
- fs_type: : type de système de fichiers (NFS, CIFS, Lustre, GCSFuse installé automatiquement)
- mount_options: : options de montage (par exemple, defaults,_netdev)
- login_network_storage: : stockage réseau à monter sur les nœuds de connexion et de contrôleur. NFS, CIFS, Lustre et GCSFuse seront installés automatiquement. Peut être répété pour les montages supplémentaires.
- server_ip: : adresse IP du serveur de stockage
- remote_mount: : nom du point de montage du stockage (nom du système de fichiers)
- local_mount: : répertoire d'installation local
- fs_type: : type de système de fichiers (NFS, CIFS, Lustre, GCSFuse installé automatiquement)
- mount_options: : options de montage (par exemple, defaults,_netdev)
- compute_node_service_account: Compte de service à utiliser sur les instances de calcul
- compute_node_scopes: : champ d'application de l'accès des instances de calcul
- partitions : configuration de la partition Slurm. Peut être répété pour d'autres partitions.
- name : nom de la partition
- machine_type: : type d'instance du ou des nœuds de calcul
- static_node_count: : nombre de nœuds de calcul toujours activés
- max_node_count: : nombre maximal de nœuds de calcul autorisés (64 000 maximum)
- zone : zone Google Cloud qui contiendra les ressources de cette partition. En savoir plus
- image : type de machine du nœud d'image de calcul
- image_hyperthreads: : activez ou désactivez l'hyper-threading sur l'instance.
- compute_disk_type : type de disque de démarrage d'une instance de calcul (pd-standard, pd-ssd)
- compute_disk_size_gb: : taille du disque de démarrage d'une instance de calcul
- compute_labels: : libellé(s) à associer à l'instance de calcul
- cpu_platform: : configuration minimale de la plate-forme du processeur requise pour tous les nœuds de calcul
- gpu_count: : nombre de GPU à associer à chaque instance de la partition
- gpu_type: : type de GPU à associer aux instances de la partition
- network_storage: : stockage réseau à monter sur tous les nœuds de calcul de la partition. Les champs seront ajoutés directement à fstab. Peut être répété pour les montages supplémentaires.
- server_ip: : adresse IP du serveur de stockage
- remote_mount: : nom du point de montage du stockage (nom du système de fichiers)
- local_mount: : répertoire d'installation local
- fs_type: : type de système de fichiers (NFS, CIFS, Lustre, GCSFuse installé automatiquement)
- mount_options: : option d'installation
- preemptible_bursting: : les instances seront-elles des instances préemptives ?
- vpc_subnet: : sous-réseau de cloud privé virtuel dans lequel déployer la partition Slurm
- exclusive : permet à Slurm d'allouer des nœuds entiers aux jobs.
- enable_placement: : activez les stratégies d'emplacement qui permettent de placer les instances à proximité les unes des autres pour obtenir une faible latence réseau entre les instances.
- regional_capacity: : autorise le placement d'une instance dans n'importe quelle zone de la région en fonction de la disponibilité.
- regional_policy: : si regional_capacity est défini sur "true", cette règle permet de déterminer la région à utiliser et les zones de cette région à ne pas utiliser.
- Instance_template: : modèle d'instance GCP à utiliser pour les instances de calcul. Tous les champs de calcul spécifiés remplaceront les propriétés du modèle. Par exemple, si une image est spécifiée, elle remplacera celle du modèle d'instance.
Configuration avancée
Si vous le souhaitez, vous pouvez choisir d'installer des packages et des logiciels supplémentaires lors du déploiement du cluster. Vous pouvez installer des logiciels sur votre cluster Slurm de plusieurs manières, comme indiqué dans notre guide "Installer des applications dans un cluster Slurm sur Compute Engine", ou en personnalisant l'image déployée par Slurm. Actuellement, Slurm déploie une image de VM fournie par SchedMD, basée sur l'image de VM HPC Google Cloud, avec Slurm installé par-dessus.
Pour utiliser votre propre image, créez-en une avec votre propre configuration basée sur l'image de VM SchedMD publique listée dans le fichier tfvars. Ensuite, remplacez l'URI de l'image spécifié dans le fichier tfvars par votre propre image, puis testez la modification.
Dépannage
Tout au long de cet atelier de programmation, veuillez vous référer à la section "Dépannage" du fichier ReadMe du dépôt Slurm-GCP.
Les problèmes les plus courants sont les erreurs de configuration du fichier tfvars et les restrictions de quota. Cet atelier de programmation est conçu pour s'exécuter dans la limite du quota standard d'un nouvel utilisateur et dans la limite des 300 $de crédits sans frais qu'il reçoit. Si une tentative de création de VM échoue, consultez le fichier /var/log/slurm/resume.log sur le nœud de contrôleur pour vérifier s'il y a des erreurs d'API.
4. Déployer et vérifier la configuration
Déployer la configuration
Dans la session Cloud Shell, exécutez la commande suivante à partir du dossier slurm-gcp/tf/example :
terraform init terraform apply -var-file=basic.tfvars
Vous serez invité à accepter les actions décrites, en fonction des configurations définies. Saisissez yes pour lancer le déploiement. Vous pouvez également afficher la configuration à déployer en exécutant "terraform plan".
Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes
Cette opération peut prendre quelques minutes. Merci de patienter.
Une fois le déploiement terminé, un résultat semblable à celui-ci s'affiche :
Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
Outputs:
controller_network_ips = [
[
"10.0.0.2",
],
]
login_network_ips = [
[
"10.0.0.3",
],
]
Vérifier la création de l'instance de VM
Ouvrez le menu de navigation et sélectionnez Compute Engine > Instances de VM.
Un contrôleur et une instance de VM de connexion doivent s'afficher :
Sous Instances de VM, examinez les deux instances de machine virtuelle créées par Terraform.
Les noms seront différents si vous avez modifié le champ cluster_name.
- g1-controller
- g1-login0
5. Se connecter au cluster Slurm
Accéder au cluster Slurm
Revenez à l'onglet de l'éditeur de code/Cloud Shell. Exécutez la commande suivante pour vous connecter à votre instance, en remplaçant <ZONE> par la zone du nœud g1-login0 (qui doit être us-central1-b) :
gcloud compute ssh g1-login0 --zone=<ZONE>
Cette commande vous connecte à la machine virtuelle g1-login0.
Une autre méthode pour accéder facilement au nœud de connexion consiste à cliquer sur le bouton "SSH" à côté de la VM g1-login0 sur la page "Instances de VM" pour ouvrir un nouvel onglet avec une connexion SSH.
Si vous utilisez Cloud Shell pour la première fois, un message semblable à celui ci-dessous peut s'afficher pour vous demander de créer une clé SSH :
WARNING: The public SSH key file for gcloud does not exist. WARNING: The private SSH key file for gcloud does not exist. WARNING: You do not have an SSH key for gcloud. WARNING: SSH keygen will be executed to generate a key. This tool needs to create the directory [/home/user/.ssh] before being able to generate SSH keys. Do you want to continue (Y/n)?
Si c'est le cas, saisissez Y. Si vous êtes invité à sélectionner une phrase secrète, laissez le champ vide en appuyant deux fois sur Entrée.
Si le message suivant s'affiche lors de la connexion :
*** Slurm is currently being configured in the background. *** A terminal broadcast will announce when installation and configuration is complete.
Attendez que ce message s'affiche avant de poursuivre l'atelier (environ cinq minutes) :
*** Slurm login setup complete ***
Une fois le message ci-dessus affiché, vous devrez vous déconnecter de g1-login0, puis vous reconnecter pour poursuivre l'atelier. Pour ce faire, appuyez sur CTRL+C pour mettre fin à la tâche.
Exécutez ensuite la commande suivante pour vous déconnecter de votre instance :
exit
Reconnectez-vous maintenant à votre VM de connexion. Exécutez la commande suivante pour vous connecter à votre instance, en remplaçant <ZONE> par la zone du nœud g1-login0 :
gcloud compute ssh g1-login0 --zone=<ZONE>
Comme ci-dessus, vous devrez peut-être patienter une minute ou deux avant de pouvoir vous connecter et que tous les aspects de la configuration soient terminés.
Visite guidée des outils CLI Slurm
Vous êtes maintenant connecté au nœud de connexion Slurm de votre cluster. Il s'agit du nœud dédié à l'interaction utilisateur/administrateur, à la planification des jobs Slurm et à l'activité administrative.
Exécutons quelques commandes pour vous présenter la ligne de commande Slurm.
Exécutez la commande sinfo pour afficher l'état des ressources de notre cluster :
sinfo
Un exemple de sortie sinfo est présenté ci-dessous. sinfo indique les nœuds disponibles dans le cluster, l'état de ces nœuds et d'autres informations telles que la partition, la disponibilité et toute limite de temps imposée à ces nœuds.
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Vous pouvez voir que nos 10 nœuds, dictés par le "max_node_count" de 10 de la partition de débogage, sont marqués comme "idle~" (le nœud est en mode inactif et non alloué, prêt à être lancé).
Ensuite, exécutez la commande squeue pour afficher l'état de la file d'attente de notre cluster :
squeue
Le résultat attendu de squeue est affiché ci-dessous. squeue indique l'état de la file d'attente pour un cluster. Cela inclut l'ID de chaque job planifié sur le cluster, la partition à laquelle le job est attribué, le nom du job, l'utilisateur qui a lancé le job, l'état du job, le temps d'exécution du job et les nœuds auxquels le job est attribué. Comme aucun job n'est en cours d'exécution, le contenu de cette commande est vide.
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
Les commandes Slurm "srun" et "sbatch" sont utilisées pour exécuter les jobs mis en file d'attente. "srun" exécute des jobs en parallèle et peut être utilisé comme wrapper pour mpirun. "sbatch" est utilisé pour envoyer un job par lot à Slurm. Il peut appeler srun une ou plusieurs fois dans différentes configurations. "sbatch" peut accepter des scripts de traitement par lot ou être utilisé avec l'option "–wrap" pour exécuter l'intégralité du job à partir de la ligne de commande.
Exécutons un job pour voir Slurm en action et ajouter un job à notre file d'attente.
6. Exécuter un job Slurm et mettre à l'échelle le cluster
Exécuter un job Slurm et mettre à l'échelle le cluster
Maintenant que notre cluster Slurm est en cours d'exécution, exécutons un job et augmentons la taille de notre cluster.
La commande "sbatch" permet d'exécuter des commandes et des scripts de traitement par lot Slurm. Exécutons un script sbatch simple qui exécutera "hostname" sur nos VM autoscalées.
Une fois connecté à g1-login0, exécutez la commande suivante :
sbatch -N2 --wrap="srun hostname"
Cette commande exécute la commande de lot Slurm. Il indique que sbatch exécutera deux nœuds avec l'option "-N". Il précise également que chacun de ces nœuds exécutera une commande "srun hostname" dans l'option "–wrap".
Par défaut, sbatch écrit sa sortie dans "slurm-%j.out " dans le répertoire de travail à partir duquel la commande est exécutée, où %j est remplacé par l'ID du job conformément aux modèles de nom de fichier Slurm. Dans notre exemple, sbatch est exécuté à partir du dossier /home de l'utilisateur, qui est un système de fichiers partagé basé sur NFS hébergé sur le contrôleur par défaut. Cela permet aux nœuds de calcul de partager les données d'entrée et de sortie, si vous le souhaitez. Dans un environnement de production, le stockage de travail doit être séparé du stockage /home pour éviter tout impact sur les performances des opérations du cluster. Des points de montage de stockage distincts peuvent être spécifiés dans le fichier tfvars dans les options "network_storage".
Après avoir exécuté le script sbatch à l'aide de la ligne de commande sbatch, un Job ID (ID de job) est renvoyé pour le job planifié. Par exemple :
Submitted batch job 2
Nous pouvons utiliser l'ID de job renvoyé par la commande sbatch pour suivre et gérer l'exécution et les ressources du job. Exécutez la commande suivante pour afficher la file d'attente des tâches Slurm :
squeue
Le job que vous avez exécuté devrait s'afficher comme suit :
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
2 debug g1-compute-0-[0-1] username R 0:10 2 g1-compute-0-[0-1]
Comme nous n'avons provisionné aucun nœud de calcul, Slurm créera automatiquement des instances de calcul en fonction des exigences du job. Le caractère automatique de ce processus présente deux avantages. Tout d'abord, il élimine le travail généralement requis dans un cluster HPC pour provisionner manuellement les nœuds, configurer le logiciel, intégrer le nœud au cluster, puis déployer le job. Deuxièmement, il permet aux utilisateurs de faire des économies, car les nœuds inactifs et inutilisés sont mis à l'échelle jusqu'à ce que le nombre minimal de nœuds soit en cours d'exécution.
Vous pouvez exécuter la commande sinfo pour afficher le démarrage du cluster Slurm :
sinfo
Les nœuds listés dans squeue s'affichent dans l'état "alloc#", ce qui signifie qu'ils sont en cours d'allocation :
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 8 idle~ g1-compute-0-[2-9] debug* up infinite 2 alloc# g1-compute-0-[0-1]
Vous pouvez également consulter la section "Instances de VM" de la console Google Cloud pour afficher les nœuds nouvellement provisionnés. Le lancement des nœuds et l'exécution de Slurm prendront quelques minutes avant que le job ne soit attribué aux nœuds nouvellement alloués. Votre liste d'instances de VM ressemblera bientôt à ce qui suit :
Une fois que les nœuds exécutent le job, les instances passent à l'état "alloc", ce qui signifie que les jobs sont attribués à un job :
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 8 idle~ g1-compute-0-[2-9] debug* up infinite 2 alloc g1-compute-0-[0-1]
Une fois un job terminé, il n'est plus listé dans squeue et les nœuds "alloc" dans sinfo reviennent à l'état "idle". Exécutez "squeue" périodiquement jusqu'à ce que le job soit terminé, après une ou deux minutes.
Le fichier de sortie slurm-%j.out aura été écrit dans votre dossier /home partagé sur NFS et contiendra les noms d'hôte. Ouvrez ou concaténez le fichier de sortie (généralement slurm-2.out). Son contenu doit inclure les éléments suivants :
g1-compute-0-0 g1-compute-0-1
Bravo, vous avez exécuté un job et mis à l'échelle votre cluster Slurm !
7. Exécuter un job MPI
Exécutons maintenant un job MPI sur nos nœuds. Une fois connecté à g1-login0, utilisez wget pour télécharger un programme MPI écrit en langage de programmation C :
wget https://raw.githubusercontent.com/mpitutorial/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c
Pour utiliser les outils OpenMPI, vous devez charger les modules OpenMPI en exécutant la commande suivante :
module load openmpi
Nous utiliserons l'outil "mpicc" pour compiler le code MPI C. Exécutez la commande suivante :
mpicc mpi_hello_world.c -o mpi_hello_world
Cela compile notre code C en code machine afin que nous puissions exécuter le code sur notre cluster via Slurm.
Ensuite, utilisez l'éditeur de texte de votre choix pour créer un script sbatch appelé helloworld_batch :
vi helloworld_batch
Saisissez i pour passer en mode insertion de vi.
Copiez et collez le texte suivant dans le fichier pour créer un script sbatch simple :
#!/bin/bash # #SBATCH --job-name=hello_world #SBATCH --output=hello_world-%j.out # #SBATCH --nodes=2 srun mpi_hello_world
Enregistrez et quittez l'éditeur de code en appuyant sur Échap et en saisissant ":wq" sans guillemets.
Ce script définit l'environnement et les tâches d'exécution par lot Slurm. Tout d'abord, l'environnement d'exécution est défini sur bash. Ensuite, le script définit d'abord les options Slurm avec les lignes "#SBATCH". Le nom du job est défini sur "hello_world".
Le fichier de sortie est défini sur "hello_world_%j.out", où %j est remplacé par l'ID de tâche conformément aux formats de nom de fichier Slurm. Ce fichier de sortie est écrit dans le répertoire à partir duquel le script sbatch est exécuté. Dans notre exemple, il s'agit du dossier /home de l'utilisateur, qui est un système de fichiers partagé basé sur NFS. Cela permet aux nœuds de calcul de partager les données d'entrée et de sortie, si vous le souhaitez. Dans un environnement de production, le stockage de travail doit être séparé du stockage /home pour éviter tout impact sur les performances des opérations du cluster.
Enfin, le nombre de nœuds sur lesquels ce script doit s'exécuter est défini sur 2.
Une fois les options définies, les commandes exécutables sont fournies. Ce script exécutera le code mpi_hello_world de manière parallèle à l'aide de la commande srun, qui remplace la commande mpirun.
Exécutez ensuite le script sbatch à l'aide de la ligne de commande sbatch :
sbatch helloworld_batch
L'exécution de sbatch renvoie un ID de tâche pour la tâche planifiée, par exemple :
Submitted batch job 3
Cette commande exécutera la commande hostname sur deux nœuds, avec une tâche par nœud, et imprimera le résultat dans le fichier hello_world-3.out.
Étant donné que deux nœuds sont déjà provisionnés, ce job s'exécutera rapidement.
Surveillez squeue jusqu'à ce que le job soit terminé et ne figure plus dans la liste :
squeue
Une fois l'opération terminée, ouvrez ou affichez le fichier hello_world-3.out et vérifiez qu'il s'est exécuté sur g1-compute-0-[0-1]:
Hello world from processor g1-compute-0-0, rank 0 out of 2 processors Hello world from processor g1-compute-0-1, rank 1 out of 2 processors
Après 5 minutes d'inactivité (configurable avec le champ "suspend_time" du fichier YAML ou le champ "SuspendTime" de slurm.conf), les nœuds de calcul provisionnés de manière dynamique sont libérés pour libérer des ressources. Vous pouvez le vérifier en exécutant sinfo régulièrement et en observant la taille du cluster revenir à 0 :
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Essayez de lancer davantage d'instances, jusqu'à la limite de votre quota dans la région où vous avez déployé le cluster, et d'exécuter différentes applications MPI.
8. Conclusion
Félicitations ! Vous avez créé un cluster Slurm sur Google Cloud Platform et utilisé ses dernières fonctionnalités pour effectuer un scaling automatique de votre cluster en fonction de la demande de charge de travail. Vous pouvez utiliser ce modèle pour exécuter n'importe quel type de job. Il peut être mis à l'échelle sur des centaines d'instances en quelques minutes en demandant simplement les nœuds dans Slurm.
Si vous souhaitez continuer à apprendre à utiliser Slurm sur GCP, assurez-vous de poursuivre l'atelier de programmation Créer des clusters HPC fédérés avec Slurm. Cet atelier de programmation vous guidera dans la configuration de deux clusters Slurm fédérés dans le cloud, pour vous montrer comment créer une fédération multicluster, que ce soit sur site ou dans le cloud.
Vous créez quelque chose de cool à l'aide de la nouvelle fonctionnalité native GCP de Slurm ? Vous avez des questions ? Vous avez une suggestion de fonctionnalité ? Contactez l'équipe Google Cloud dès aujourd'hui sur le site Web des solutions de calcul hautes performances de Google Cloud ou discutez avec nous dans le groupe de discussion Google Cloud et Slurm.
Nettoyer le déploiement Terraform
Déconnectez-vous du nœud Slurm :
exit
Laissez les nœuds autoscalés se réduire avant de supprimer le déploiement. Vous pouvez également supprimer ces nœuds manuellement en exécutant "gcloud compute instances delete <Instance Name>" pour chaque instance, ou en utilisant l'interface utilisateur de la console pour sélectionner plusieurs nœuds et cliquer sur "Supprimer".
Vous pouvez facilement nettoyer le déploiement Terraform une fois que vous avez terminé en exécutant la commande suivante depuis votre Google Cloud Shell, après vous être déconnecté de g1-login0 :
cd ~/slurm-gcp/tf/examples/basic terraform destroy -var-file=basic.tfvars
Lorsque vous y êtes invité, saisissez yes (oui) pour continuer. Cette opération peut prendre plusieurs minutes. Veuillez patienter.
Supprimer le projet
Pour effectuer le nettoyage, il suffit de supprimer notre projet.
- Dans le menu de navigation, sélectionnez "IAM et administration".
- Cliquez ensuite sur "Paramètres" dans le sous-menu.
- Cliquez sur l'icône en forme de corbeille avec le texte "Supprimer le projet".
- Suivez les instructions.
Points abordés
- Comment déployer Slurm sur GCP à l'aide de Terraform
- Découvrez comment exécuter une tâche avec Slurm sur GCP.
- Comment interroger des informations sur le cluster et surveiller les tâches en cours d'exécution dans Slurm.
- Découvrez comment effectuer un autoscaling des nœuds avec Slurm sur GCP pour s'adapter aux paramètres et aux exigences spécifiques des tâches.
- Découvrez comment compiler et exécuter des applications MPI sur Slurm sur GCP.
Obtenir de l'aide pour Slurm
Si vous avez besoin d'aide pour utiliser ces intégrations dans des environnements de test ou de production, veuillez contacter directement SchedMD sur sa page de contact : https://www.schedmd.com/contact.php.
Vous pouvez également utiliser les guides de dépannage disponibles :
- Guide de dépannage de Slurm sur GCP : https://github.com/SchedMD/slurm-gcp#troubleshooting
- Guide de dépannage de SchedMD : https://slurm.schedmd.com/troubleshoot.html
Enfin, vous pouvez également poser votre question au groupe de discussion Google Cloud et Slurm, disponible à l'adresse https://groups.google.com/g/google-cloud-slurm-discuss.
En savoir plus
Commentaires
Veuillez nous faire part de vos commentaires sur cet atelier de programmation en cliquant sur ce lien. Il ne vous faudra pas plus de cinq minutes pour nous faire part de vos commentaires. Merci !