1. Présentation
Bienvenue dans l'atelier de programmation Google consacré à l'exécution d'un cluster Slurm sur Google Cloud Platform. À la fin de cet atelier de programmation, vous devriez avoir une bonne compréhension de 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 facilitant le lancement du gestionnaire de charges de travail Slurm sur Compute Engine et pour étendre votre cluster existant de manière dynamique 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 programme Google Cloud Groupe de discussion de la communauté Slurm !
À propos de Slurm
Schéma de l'architecture de base d'un cluster Slurm autonome dans Google Cloud Platform.
Slurm est l'un des principaux gestionnaires de charges de travail pour les clusters HPC du monde entier. Slurm fournit un système Open Source de gestion des charges de travail et de planification des tâches hautement évolutif et tolérant aux pannes pour les clusters Linux petits et grands. Slurm ne nécessite aucune modification du noyau pour son fonctionnement et est relativement autonome. En tant que gestionnaire de charge de travail de cluster, Slurm remplit trois fonctions clés:
- Il attribue un accès exclusif ou non exclusif aux ressources (nœuds de calcul) aux utilisateurs pendant un certain temps afin qu'ils puissent effectuer des tâches.
- Il fournit un framework pour le démarrage, l'exécution et la surveillance des tâches (généralement un job parallèle) sur l'ensemble des nœuds alloués.
- Il arbitre les conflits pour les ressources en gérant une file d'attente de tâches en attente.
Points abordés
- Configurer un cluster Slurm à l'aide de Terraform
- Exécuter un job avec SLURM
- Comment interroger les informations sur le cluster et surveiller les jobs en cours d'exécution dans SLURM
- Comment procéder à l'autoscaling des nœuds pour répondre aux exigences et aux paramètres spécifiques d'un job
- Où obtenir de l'aide concernant Slurm
Prérequis
- Un compte Google Cloud Platform et un projet avec facturation
- Expérience de base sur Linux
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 un nom de projet. Mémorisez l'ID du projet (mis en surbrillance 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ère un ID de projet aléatoire basé sur le nom du projet.
Vous devez ensuite activer la facturation dans la Play Console pour pouvoir utiliser les ressources Google Cloud.
L'exécution de cet atelier de programmation ne devrait pas vous coûter plus que quelques dollars, mais ce montant peut être plus élevé si vous décidez d'utiliser plus de ressources ou de continuer à les exécuter (consultez la section "Conclusion" à la fin de ce 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 de 300$.
Google Cloud Shell
Google Cloud peut être utilisé à distance depuis votre ordinateur portable. Toutefois, dans cet atelier de programmation, nous allons utiliser Google Cloud Shell, 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 considérablement les performances du réseau et simplifie l'authentification. Vous pouvez réaliser une grande partie, voire la totalité, de votre travail dans cet atelier à l'aide d'un simple navigateur Web ou d'un Chromebook Google.
Une fois connecté à Cloud Shell, vous êtes en principe authentifié et le projet PROJECT_ID est déjà défini:
$ 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 du projet n'est pas défini correctement, vous pouvez le définir à l'aide de la commande suivante:
$ gcloud config set project <PROJECT_ID>
Résultat de la commande :
Updated property [core/project].
3. Préparer et examiner la configuration Terraform 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 qui contient les fichiers Terraform Slurm pour Google Cloud Platform:
git clone https://github.com/SchedMD/slurm-gcp.git
Accédez au répertoire de configuration de déploiement Slurm en exécutant la commande suivante:
cd slurm-gcp
Configurer les tfvars Terraform pour Slurm
Le fichier "basic.tfvars.example" détaille la configuration du déploiement, y compris le réseau, les instances et l'espace de 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. 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 pour afficher le contenu du fichier:
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 comporte 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 selon les besoins. 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. Plus de détails
- network_name: : réseau cloud privé virtuel dans lequel 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 avant la suspension d'un nœud une fois qu'il est inactif.
- controller_machine_type::type d'instance du nœud 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 d'un disque de démarrage d'instance de contrôleur
- controller_labels::libellé(s) à associer à l'instance de manette
- controller_service_account: : compte de service à utiliser sur l'instance de contrôleur
- controller_scopes: : champ d'application 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 du contrôleur
- server_ip::adresse IP du serveur Cloud SQL
- user:nom d'utilisateur Cloud SQL
- password:mot de passe Cloud SQL
- db_name::nom de la base de données Cloud SQL
- 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 écrasera l'image dans le modèle d'instance.
- login_machine_type::type d'instance du nœud (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: : compte de service à utiliser sur la ou les instances de connexion
- login_node_scopes: : niveau d'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é, l'image du modèle d'instance sera écrasée.
- network_storage::stockage réseau à installer sur tous les nœuds. Les champs seront ajoutés directement à fstab. Peut être répété pour des montages supplémentaires.
- server_ip::IP du serveur de stockage
- remote_mount::nom de l'installation de l'espace de 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 d'installation (par exemple, default,_netdev)
- login_network_storage::stockage réseau à installer sur les nœuds de connexion et les nœuds de contrôleur. NFS, CIFS, Lustre et GCSFuse seront installés automatiquement. Peut être répété pour des montages supplémentaires.
- server_ip::IP du serveur de stockage
- remote_mount::nom de l'installation de l'espace de 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 d'installation (par exemple, default,_netdev)
- compute_node_service_account: : compte de service à utiliser sur la ou les instances de calcul
- compute_node_scopes: : champ d'application d'accès des instances de calcul
- partitions:configuration de partition Slurm. Peut être répété pour des partitions supplémentaires.
- name:nom de la partition
- machine_type::le 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é : 64 000 maximum
- zone:zone Google Cloud qui contiendra les ressources de cette partition. Plus de détails
- image:type de machine du nœud d'image Compute
- image_hyperthreads::active ou désactive l'hyperthreading 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 d'un disque de démarrage d'instance de calcul
- compute_labels::étiquette(s) à associer à l'instance de calcul
- cpu_platform::configuration minimale de la plate-forme de 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 à installer sur tous les nœuds de calcul de la partition. Les champs seront ajoutés directement à fstab. Peut être répété pour des montages supplémentaires.
- server_ip::IP du serveur de stockage
- remote_mount::nom de l'installation de l'espace de 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
- exclusif:active Slurm pour allouer des nœuds entiers aux tâches
- enable_placement::active les règles d'emplacement où les instances sont proches les unes des autres pour réduire la latence du réseau entre les instances.
- regional_capacity::permet de placer une instance dans n'importe quelle zone de la région en fonction de sa disponibilité.
- regional_policy::si la valeur deregional_capacity est définie 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 image est spécifiée, elle écrasera l'image dans le modèle d'instance.
Configuration avancée
Si vous le souhaitez, vous pouvez choisir d'installer des packages et des logiciels supplémentaires dans le cadre du processus de déploiement du cluster. Vous pouvez installer un logiciel sur votre cluster Slurm de plusieurs manières décrites dans notre page "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 sur laquelle est installé Slurm.
Pour utiliser votre propre image, créez une image avec votre propre configuration basée sur l'image de VM SchedMD publique indiquée dans le fichier tfvars. Remplacez ensuite l'URI d'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 consulter la section Dépannage du fichier ReadMe du dépôt Slurm-GCP.
Les problèmes les plus courants concernent les erreurs de configuration du fichier tfvars et les restrictions de quota. Cet atelier de programmation est conçu pour s'exécuter dans les limites du quota d'attribution standard d'un nouvel utilisateur et des 300 $de crédit sans frais qu'il reçoit. Si une tentative de création de VM échoue, recherchez les erreurs d'API dans le fichier /var/log/slurm/resume.log sur le nœud du contrôleur.
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 qui ont été définies. Saisissez yes (oui). pour commencer le déploiement. Vous pouvez également afficher la configuration à déployer en exécutant la commande "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. Veuillez patienter.
Une fois le déploiement terminé, un résultat semblable au suivant 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.
Vous devriez voir un contrôleur et une instance de VM de connexion listés:
Dans la section Instances de VM, passez en revue les deux instances de machine virtuelle créées par Terraform.
Les noms seront différents si vous avez modifié le champ cluster_name.
- contrôleur-g1
- g1-login0
5. Se connecter au cluster Slurm
Accéder au cluster Slurm
Revenez à l'onglet É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 devrait être us-central1-b):
gcloud compute ssh g1-login0 --zone=<ZONE>
Cette commande vous connectera à la machine virtuelle g1-login0.
Une autre méthode pour accéder facilement au nœud de connexion consiste à cliquer sur le bouton « SSH » situé à 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, vous demandant 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 ce champ vide en appuyant sur Entrée.
Si le message suivant apparaît à la connexion:
*** Slurm is currently being configured in the background. *** A terminal broadcast will announce when installation and configuration is complete.
Attendez et ne poursuivez pas l'atelier tant que ce message s'affiche (environ cinq minutes):
*** Slurm login setup complete ***
Lorsque le message ci-dessus s'affiche, vous devez vous déconnecter, puis vous reconnecter à g1-login0 pour poursuivre l'atelier. Pour ce faire, appuyez sur CTRL+C.
Exécutez ensuite la commande suivante pour vous déconnecter de votre instance:
exit
Maintenant, reconnectez-vous à 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 attendre une ou deux minutes 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é aux interactions utilisateur/administrateur, à la planification des tâches Slurm et aux activités d'administration.
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 résultat de sinfo apparaît 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 nos 10 nœuds, dictés par la valeur "max_node_count" de la partition de débogage. sur 10, sont marqués comme "inactifs~" (le nœud est en mode inactif et non alloué, prêt à être créé).
Ensuite, exécutez la commande squeue pour afficher l'état de la file d'attente de notre cluster:
squeue
Le résultat attendu de la file d'attente s'affiche ci-dessous. "squeue" indique l'état de la file d'attente d'un cluster. Ces informations incluent l'ID de chaque job planifié sur le cluster, la partition à laquelle la tâche est attribuée, le nom de la tâche, l'utilisateur qui a lancé la tâche, l'état de la tâche, la durée d'exécution de la tâche et les nœuds auxquels la tâche est allouée. Aucun job n'est en cours d'exécution. Le contenu de cette commande est donc vide.
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
Slurm commande "srun" et "sbatch" sont utilisés pour exécuter des jobs mis dans la file d'attente. "srun" exécute des jobs parallèles et peut servir de wrapper pour mpirun. "sbatch" permet d'envoyer un job par lot à l'exécution Slurm et peut appeler la commande srun une ou plusieurs fois dans différentes configurations. "sbatch" peuvent prendre en charge des scripts par lot ou être utilisées 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 obtenir un job dans notre file d'attente.
6. Exécuter un job Slurm et effectuer le scaling du cluster
Exécuter un job Slurm et effectuer le scaling du cluster
Maintenant que notre cluster Slurm est en cours d'exécution, nous allons exécuter un job et effectuer un scaling à la hausse.
La couche "sbatch" est utilisée pour exécuter des commandes par lot et des scripts Slurm. Exécutons un simple script sbatch qui exécutera "hostname" sur nos VM avec autoscaling.
Une fois connecté à g1-login0, exécutez la commande suivante:
sbatch -N2 --wrap="srun hostname"
Cette commande exécute la commande par lot Slurm. Il spécifie que sbatch exécutera deux nœuds avec le signe "-N" . Il spécifie également que chacun de ces nœuds exécutera un "nom d'hôte srun" dans la commande "–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 de tâche conformément aux formats 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 et hébergé par défaut sur le contrôleur. Cela permet aux nœuds de calcul de partager des données d'entrée et de sortie s'ils le souhaitent. Dans un environnement de production, le stockage de travail doit être distinct de l'espace de stockage /home pour éviter tout impact sur les performances des opérations du cluster. Vous pouvez spécifier des montages de stockage distincts dans le fichier tfvars de la section "network_storage" options.
Après avoir exécuté le script sbatch à l'aide de la ligne de commande sbatch, il renvoie un ID de tâche pour la tâche planifiée, 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 du job ainsi que les ressources associées. Exécutez la commande suivante pour afficher la file d'attente de tâches Slurm:
squeue
La tâche que vous avez exécutée 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 aucun nœud de calcul n'est provisionné, Slurm créera automatiquement des instances de calcul en fonction des exigences du job. La nature automatique de ce processus présente deux avantages. Tout d'abord, cela élimine le travail généralement requis dans un cluster HPC consistant à provisionner manuellement des nœuds, à configurer le logiciel, à intégrer le nœud dans le cluster, puis à déployer le job. Deuxièmement, elle permet aux utilisateurs d'économiser de l'argent, car le nombre de nœuds inactifs et inutilisés est réduit jusqu'à atteindre le nombre minimal de nœuds en cours d'exécution.
Vous pouvez exécuter la commande sinfo pour afficher le cluster Slurm en cours de lancement:
sinfo
Les nœuds répertoriés dans la file d'attente "alloc#" s'affichent. ce qui signifie que les nœuds sont alloués:
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 prennent quelques minutes avant que le job ne soit alloué aux nœuds nouvellement alloués. La liste de vos instances de VM se présentera bientôt comme suit:
Une fois que les nœuds exécutent la tâche, les instances passent à une "allocation" ce qui signifie que les jobs sont alloués à une tâche:
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 qu'un job est terminé, il n'est plus répertorié dans la file d'attente, et l'allocation les nœuds dans sinfo retourneront à l'état "inactif" de l'état. Exécuter "squeue" périodiquement jusqu'à ce que la tâche soit terminée, au bout d'une ou deux minutes.
Le fichier de sortie slurm-%j.out sera écrit dans votre dossier NFS-shared /home et contiendra les noms d'hôte. Ouvrez ou chattez le fichier de sortie (généralement slurm-2.out). Son contenu contiendra:
g1-compute-0-0 g1-compute-0-1
Bravo ! Vous avez exécuté un job et effectué le scaling à la hausse de votre cluster Slurm.
7. Exécuter une tâche 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 le « 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 nommé "helloworld_batch" :
vi helloworld_batch
Saisissez i pour activer le mode d'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 d'exécution par lot et les tâches Slurm. Tout d'abord, l'environnement d'exécution est défini comme bash. Ensuite, le script définit d'abord les options Slurm avec le hashtag "#SBATCH". lignes. Le nom du job est alors défini comme "hello_world".
Le fichier de sortie est défini sur "hello_world_%j.out" où %j est remplacé par l'ID de la 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 des données d'entrée et de sortie s'ils le souhaitent. Dans un environnement de production, le stockage de travail doit être distinct de l'espace de stockage /home pour éviter tout impact sur les performances des opérations du cluster.
Enfin, le nombre de nœuds sur lequel ce script doit s'exécuter est défini comme suit : 2.
Une fois les options définies, les commandes exécutables sont fournies. Ce script exécute le code mpi_hello_world en 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 la commande sbatch renvoie un ID de tâche pour la tâche planifiée, par exemple:
Submitted batch job 3
La commande hostname est exécutée sur deux nœuds, avec une tâche par nœud, et la sortie est affichée dans le fichier hello_world-3.out.
Comme deux nœuds sont déjà provisionnés, ce job va s'exécuter rapidement.
Surveillez squeue jusqu'à ce que la tâche soit terminée et ne soit plus répertoriée:
squeue
Une fois que vous avez terminé, ouvrez ou chattez le fichier hello_world-3.out, puis vérifiez qu'il s'est bien 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 cinq minutes d'inactivité (configurable avec le champ "suspend_time" de YAML ou le champ "SuspendTime" de slurm.conf), les nœuds de calcul provisionnés dynamiquement sont désaffectés pour libérer des ressources. Vous pouvez vérifier cela en exécutant régulièrement sinfo et en observant que la taille du cluster revient à 0:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Essayez de démarrer d'autres instances, dans la limite du quota autorisé dans la région dans laquelle 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 procéder à l'autoscaling de votre cluster afin de répondre à la demande de charge de travail. Vous pouvez utiliser ce modèle pour exécuter toutes sortes de jobs. Il s'adapte à des centaines d'instances en quelques minutes, simplement en demandant les nœuds dans Slurm.
Si vous souhaitez continuer à apprendre à utiliser Slurm sur GCP, passez à la section " Building Federated HPC Clusters with Slurm" (Créer des clusters HPC fédérés avec Slurm) dans cet atelier de programmation. Cet atelier de programmation vous explique comment configurer deux clusters Slurm fédérés dans le cloud afin de déterminer comment mettre en place une fédération multicluster, sur site ou dans le cloud.
Vous développez quelque chose d'intéressant à 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 chattez avec nous sur la page Google Cloud & Groupe de discussion Slurm !
Nettoyer le déploiement Terraform
Déconnectez-vous du nœud Slurm:
exit
Autorisez tous les nœuds faisant l'objet d'un autoscaling à effectuer un scaling à la baisse avant de supprimer le déploiement. Vous pouvez également supprimer ces nœuds manuellement en exécutant la commande "gcloud compute instances delete <Nom de l'instance>" pour chaque instance, ou utilisez l'IUG de la console pour sélectionner plusieurs nœuds et cliquez sur "Supprimer".
Une fois terminé, vous pouvez facilement nettoyer le déploiement Terraform. Pour ce faire, exécutez la commande suivante depuis 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 un nettoyage, il nous suffit de supprimer le projet.
- Dans le menu de navigation, sélectionnez "IAM et Administrateur
- Cliquez ensuite sur "Paramètres" dans le sous-menu.
- Cliquez sur l'icône de la corbeille avec le texte "Supprimer le projet".
- Suivez les instructions.
Points abordés
- Utiliser le déploiement Slurm sur GCP avec Terraform
- Exécuter un job à l'aide de Slurm sur GCP
- Comment interroger des informations sur le cluster et surveiller les jobs en cours d'exécution dans Slurm.
- Comment procéder à l'autoscaling des nœuds avec Slurm sur GCP pour répondre aux exigences et aux paramètres spécifiques d'un job
- Découvrez comment compiler et exécuter des applications MPI sur Slurm sur GCP.
Trouver l'aide Slurm
Si vous avez besoin d'aide pour utiliser ces intégrations dans des environnements de test ou de production, veuillez contacter SchedMD directement via la page de contact suivante: 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 publier votre question sur le forum Google Cloud Le groupe de discussion Slurm a été trouvé ici: https://groups.google.com/g/google-cloud-slurm-discuss
En savoir plus
Commentaires
Pour nous envoyer vos commentaires sur cet atelier de programmation, cliquez ici. Les commentaires prennent moins de cinq minutes. Merci !