Exécuter le modèle de prévision météorologique WRF avec des valeurs numériques fluides Slurm-GCP

1. Introduction

Dernière mise à jour : 05/05/2021

Objectif de cet atelier

Dans cet atelier de programmation, vous allez déployer un cluster de calcul hautes performances (HPC) à autoscaling sur Google Cloud avec le planificateur de tâches Slurm. Vous allez utiliser un exemple de déploiement Terraform qui déploie ce cluster avec WRF® installé via Spack. Vous utiliserez ensuite cette infrastructure pour exécuter le benchmark CONUS 2, 5 km ou le benchmark CONUS 12 km.

Points abordés

• Configurer des stratégies Identity and Access Management (IAM) pour exploiter un cluster HPC sur Google Cloud Platform
• Déployer un cluster HPC cloud natif avec le planificateur de tâches Slurm
• Exécuter WRF® en parallèle sur Google Cloud à l'aide d'un job par lot Slurm

Ce dont vous aurez besoin

• Compte Gmail avec une clé SSH associée, ou Google Workspace, Cloud Identity
• Projet Google Cloud Platform avec la facturation activée
• Rôle de propriétaire du projet sur votre projet GCP
• Quota Compute Engine suffisant (480 processeurs virtuels c2 et 500 Go de disque PD-Standard)

2. Configuration

Activer les API Google Cloud

Pour créer et utiliser des ressources Google Cloud, les API doivent être activées.

gcloud services enable compute.googleapis.com 

Définir des stratégies IAM

Dans le HPC, il existe des distinctions claires entre les administrateurs système et les utilisateurs du système. Les administrateurs système disposent généralement d'un "accès racine" qui leur permet de gérer et d'exploiter les ressources de calcul. Les utilisateurs du système sont généralement des chercheurs, des scientifiques et des ingénieurs d'application qui n'ont besoin d'utiliser les ressources que pour exécuter des jobs.

Dans Google Cloud, l'API OS Login provisionne les informations utilisateur POSIX à partir des comptes Google Workspace, Cloud Identity et Gmail. De plus, la connexion OS s'intègre au système Identity and Access Management (IAM) de GCP pour déterminer si les utilisateurs doivent être autorisés à élever leurs privilèges sur les systèmes Linux.

Dans ce tutoriel, nous partons du principe que vous remplissez les rôles d'administrateur système et d'administrateur Compute Engine. Nous allons configurer des stratégies IAM pour vous accorder les autorisations suffisantes pour effectuer les tâches suivantes :

• Créer/Supprimer des instances de VM Google Compute Engine (GCE)
• Se connecter en SSH à des instances de VM GCE

Pour vous attribuer les rôles IAM nécessaires pour suivre ce tutoriel, dans la console Google Cloud :

1. Accédez à IAM et administration > IAM dans le menu "Produits et services".
2. Cliquez sur "+ Ajouter" en haut de la page.
3. Saisissez votre compte Google Workspace, Cloud Identity ou Gmail sous "Nouveaux membres".
4. Ajoutez les rôles suivants : Administrateur Compute, OS Login Compute et Utilisateur du compte de service.
5. Cliquez sur "Enregistrer".

Option : Si l'interface utilisateur de la console ne correspond pas à ce qui est affiché ici, les commandes gcloud suivantes donneront les mêmes résultats. Remplacez YOUR_PROJECT et EMAIL_ADDRESS par votre projet et votre adresse e-mail.

• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/iam.serviceAccountUser –member="user:EMAIL_ADDRESS"
• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/compute.osLogin –member="user:EMAIL_ADDRESS"
• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/compute.admin –member="user:EMAIL_ADDRESS"

Votre identifiant de connexion dispose désormais des autorisations nécessaires pour lancer la création du cluster HPC.

Pour vérifier que vous avez attribué les bons rôles, ouvrez Cloud Shell et exécutez la commande suivante, en remplaçant YOUR_PROJECT et EMAIL_ADDRESS par votre projet et votre adresse e-mail.

$ gcloud projects get-iam-policy YOUR_PROJECT --flatten="bindings[].members" --format='table(bindings.role)' --filter="bindings.members=user:EMAIL_ADDRESS"

Cette commande générera le résultat suivant :

ROLE
roles/compute.osLogin
roles/iam.serviceAccountUser
roles/compute.admin

Attention : Si vous prévoyez d'utiliser un outil SSH tiers (par exemple, OpenSSH) pour vous connecter à votre cluster, veillez à associer une clé SSH à votre profil Cloud Identity à l'aide de la connexion au système d'exploitation. Découvrez comment ajouter des clés SSH à votre profil Cloud Identity.

3. Quota faible : déployer un cluster HPC d'autoscaling avec Terraform

Dans cette section, vous allez déployer un cluster HPC d'autoscaling, y compris le planificateur de jobs Slurm. Cette option est identique à l'option "Quota élevé", sauf que le type de machine utilisé est plus petit et que le nombre de processeurs virtuels utilisés est plus faible.

Important : Le quota par défaut de processeurs C2 pour un nouveau projet est généralement de 24 processeurs virtuels. Si vous disposez d'un quota plus important et que vous souhaitez exécuter le benchmark CONUS 2,5 km, vous pouvez ignorer cette section et la suivante.

1. Ouvrez Cloud Shell sur GCP.
2. Cloner le dépôt FluidNumerics/slurm-gcp

cd ~
git clone https://github.com/FluidNumerics/slurm-gcp.git

3. Accédez au répertoire WRF :

cd  ~/slurm-gcp/tf/examples/wrf

4. Créez et examinez un plan Terraform. Définissez les variables d'environnement WRF_NAME, WRF_PROJECT et WRF_ZONE pour spécifier le nom de votre cluster, votre projet GCP et la zone dans laquelle vous souhaitez effectuer le déploiement.

export WRF_PROJECT=<PROJECT ID>
export WRF_ZONE=<ZONE>
export WRF_NAME="wrf-small"

5. La première fois que vous exécutez Terraform, vous devez exécuter la commande init :

terraform init

6. Créez le plan avec la commande make, qui exécutera terraform

make plan

Remarque : Pour améliorer les performances des E/S de fichier sur NFS, augmentez la taille du disque du contrôleur à 2,5 To et définissez le type de disque du contrôleur sur "pd-ssd". Vous pouvez modifier la taille du disque en modifiant basic.tfvars.tmpl et en ajoutant controller_disk_size_gb = 2500. Nous vous recommandons également d'utiliser un système de fichiers Lustre.

Attention : Lorsque vous choisissez une zone, assurez-vous de sélectionner une zone dans laquelle les instances C2 sont disponibles. En savoir plus sur les régions et les zones disponibles

Pour en savoir plus sur les limites de quota de votre projet, consultez la page Quotas de la console Google Cloud, qui liste tous les quotas. Recherchez "Nom de la limite : CPU C2". Les processeurs C2 disponibles dans la zone sélectionnée s'affichent.

7. Déployez le cluster. L'installation et la configuration peuvent prendre jusqu'à deux heures. Lors du déploiement, WRF et toutes ses dépendances seront installés.

make apply

8. Connectez-vous en SSH au nœud login créé à l'étape précédente. Vous pouvez voir ce nœud à l'étape précédente (il s'appelle probablement wrf-small-login0). Pour ce faire, cliquez sur le bouton SSH à côté de la liste des instances de VM dans l'élément de menu de la console Compute Engine > Instance de VM.

Option : Cette paire de commandes gcloud permet de déterminer le nom du nœud de connexion et de s'y connecter en SSH :

export CLUSTER_LOGIN_NODE=$(gcloud compute instances list --zones ${WRF_ZONE} --filter="name ~ .*login" --format="value(name)" | head -n1)

gcloud compute ssh ${CLUSTER_LOGIN_NODE} --zone ${WRF_ZONE}

9. Une fois connecté au nœud de connexion, vérifiez que le module WRF est disponible pour valider la configuration de votre cluster.

$ module load gcc && module load openmpi && module avail
-------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/openmpi/4.0.5-eagetxh/gcc/9.2.0 --------------------------------------
   hdf5/1.10.7    netcdf-c/4.7.4    netcdf-fortran/4.5.3    parallel-netcdf/1.12.1    wrf/4.2

------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/gcc/9.2.0 -------------------------------------------------
   hwloc/2.2.0      libiconv/1.16          libpng/1.6.37     nasm/2.15.05            openmpi/4.0.5 (L,D)    time/1.9              zlib/1.2.11
   jasper/2.0.16    libjpeg-turbo/2.0.4    libtirpc/1.2.6    ncurses/5.9.20130511    perl/5.16.3            util-macros/1.19.1
   krb5/1.15.1      libpciaccess/0.16      libxml2/2.9.10    numactl/2.0.14          tcsh/6.22.02           xz/5.2.2

--------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/Core ----------------------------------------------------
   gcc/9.2.0 (L)

---------------------------------------------------------------------- /apps/modulefiles ----------------------------------------------------------------------
   openmpi/v4.1.x

10. Vérifiez que /apps/share/conus-12km contient les éléments listés ci-dessous.

$  ls -1 /apps/share/conus-12km/
FILE:2018-06-17_00
FILE:2018-06-17_03
FILE:2018-06-17_06
FILE:2018-06-17_09
FILE:2018-06-17_12
geo_em.d01.nc
geogrid.log
met_em.d01.2018-06-17_00:00:00.nc
met_em.d01.2018-06-17_03:00:00.nc
met_em.d01.2018-06-17_06:00:00.nc
met_em.d01.2018-06-17_09:00:00.nc
met_em.d01.2018-06-17_12:00:00.nc
metgrid.log
namelist.input
namelist.wps
ungrib.log
wrfbdy_d01
wrfinput_d01

Remarque : Ce déploiement utilise une image personnalisée créée à l'aide de l'image de VM schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. Vous pouvez créer WRF pour d'autres systèmes d'exploitation à l'aide du dépôt fluidnumerics/hpc-apps-gcp sur GitHub.

4. Exécuter le benchmark CONUS 12 km

Pour exécuter le benchmark CONUS 12 km, vous devez envoyer un job par lot Slurm. Les decks d'entrée pour ce benchmark sont inclus dans l'image de VM wrf-gcp sous /apps/share/benchmarks/conus-12km.

Pour cette section, vous devez être connecté en SSH au nœud login du cluster.

1. Copiez l'exemple de fichier de lot wrf-conus.sh depuis /apps/share.

cp /apps/share/wrf-conus12.sh ~/

2. Ouvrez wrf-conus.sh dans un éditeur de texte pour vérifier que --partition et --ntasks sont correctement définis. Le nombre de tâches doit être défini sur le nombre de rangs MPI que vous souhaitez utiliser pour lancer le job. Pour cette démonstration, le nombre de tâches est équivalent au nombre de vCPU utilisés pour le job et ne doit pas dépasser votre quota disponible.

Remarque : Vous pouvez lister les partitions disponibles sur votre cluster avec sinfo. Dans cette démonstration, le nombre de tâches est équivalent au nombre de rangs MPI.

#!/bin/bash
#SBATCH --partition=wrf
#SBATCH --ntasks=24
#SBATCH --ntasks-per-node=8
#SBATCH --mem-per-cpu=2g
#SBATCH --cpus-per-task=1
#SBATCH --account=default
#
# /////////////////////////////////////////////// #

WORK_PATH=${HOME}/wrf-benchmark/
SRUN_FLAGS="-n $SLURM_NTASKS --cpu-bind=threads"

. /apps/share/spack.sh
module load gcc/9.2.0
module load openmpi
module load hdf5 netcdf-c netcdf-fortran wrf

mkdir -p ${WORK_PATH}
cd ${WORK_PATH}
ln -s ${INSTALL_ROOT}/share/conus-12km/* .
ln -s $(spack location -i wrf)/run/* .

srun $MPI_FLAGS ./wrf.exe

3. Envoyez le job par lot à l'aide de sbatch.

sbatch wrf-conus12.sh

Remarque : Les nœuds de calcul sont créés selon les besoins lorsque des jobs sont envoyés. Pour cette première soumission de job, le démarrage peut prendre jusqu'à trois minutes.

4. Attendez que la tâche soit terminée. Ce benchmark est configuré pour exécuter des prévisions sur six heures, ce qui prend environ trois heures avec 24 rangs. Vous pouvez surveiller l'état de votre tâche avec squeue.
5. Une fois le job terminé, vérifiez le contenu de rsl.out.0000 pour vous assurer que l'instruction "wrf: SUCCESS COMPLETE WRF" s'affiche. Le suffixe numérique sera différent si vous avez exécuté le job plusieurs fois (par exemple, si vous avez mal configuré un paramètre et que vous avez dû l'exécuter à nouveau).

$ tail -n1 ${HOME}/wrf-benchmark/rsl.out.0000
d01 2018-06-17_06:00:00 wrf: SUCCESS COMPLETE WRF

5. Quota élevé : déployer un cluster HPC d'autoscaling avec Terraform

Dans cette section, vous allez déployer un cluster HPC d'autoscaling, y compris le planificateur de jobs Slurm dans GCP.

Important : Le quota par défaut de processeurs C2 pour un nouveau projet est généralement de 24 processeurs virtuels. Cela ne suffit pas pour exécuter le benchmark CONUS 2.5km plus volumineux. Si vous disposez d'un quota important (jusqu'à 480 vCPU), vous pouvez exécuter cette partie de l'atelier de programmation.

1. Ouvrez Cloud Shell sur GCP.
2. Cloner le dépôt FluidNumerics/slurm-gcp

cd ~
git clone https://github.com/FluidNumerics/slurm-gcp.git

3. Accédez au répertoire WRF :

cd  ~/slurm-gcp/tf/examples/wrf

4. Créez et examinez un plan Terraform. Définissez les variables d'environnement WRF_NAME, WRF_PROJECT, WRF_ZONE, WRF_MAX_NODE et WRF_MACHINE_TYPE pour spécifier le nom de votre cluster, votre projet GCP, la zone dans laquelle vous souhaitez déployer, le nombre maximal de nœuds et le type de machine. Pour le benchmark CONUS 2,5 km, nous vous recommandons d'utiliser des instances c2-standard-60 avec au moins huit nœuds disponibles pour exécuter des jobs avec 480 rangs MPI.

export WRF_PROJECT=<PROJECT ID>
export WRF_ZONE=<ZONE>
export WRF_NAME=wrf-large
export WRF_MAX_NODE=5
export WRF_MACHINE_TYPE="c2-standard-60"

5. Si vous ne l'avez pas fait ci-dessus, vous devez exécuter terraform init pour démarrer Terraform :

terraform init

6. Créez le plan avec la commande make.

make plan

Remarque : Pour améliorer les performances des E/S de fichier sur NFS, augmentez la taille du disque du contrôleur à 2,5 To et définissez le type de disque du contrôleur sur "pd-ssd". Vous pouvez modifier la taille du disque en modifiant basic.tfvars.tmpl et en ajoutant controller_disk_size_gb = 2500. Nous vous recommandons également d'utiliser un système de fichiers Lustre.

Attention : Lorsque vous choisissez une zone, assurez-vous de sélectionner une zone dans laquelle les instances C2 sont disponibles. En savoir plus sur les régions et les zones disponibles

Pour en savoir plus sur les limites de quota de votre projet, consultez la page Quotas de la console Google Cloud, qui liste tous les quotas. Recherchez "Nom de la limite : CPU C2". Les processeurs C2 disponibles dans la zone sélectionnée s'affichent.

7. Déployez le cluster. L'installation et la configuration peuvent prendre jusqu'à deux heures. Lors du déploiement, WRF et toutes ses dépendances seront installés.

make apply

8. Connectez-vous en SSH au nœud login créé à l'étape précédente. Vous pouvez voir ce nœud à l'étape précédente (il s'appelle probablement wrf-large-login0). Pour ce faire, cliquez sur le bouton SSH à côté de la liste des instances de VM dans l'élément de menu de la console Compute Engine > Instance de VM.

Option : Cette paire de commandes gcloud permet de déterminer le nom du nœud de connexion et de s'y connecter en SSH :

export CLUSTER_LOGIN_NODE=$(gcloud compute instances list --zones ${WRF_ZONE} --filter="name ~ .*login" --format="value(name)" | head -n1)

gcloud compute ssh ${CLUSTER_LOGIN_NODE} --zone ${WRF_ZONE}

La deuxième commande devrait vous permettre de vous connecter au nœud de connexion Slurm.

9. Une fois connecté au nœud de connexion, vérifiez que le module WRF est disponible pour valider la configuration de votre cluster.

$ module load gcc && module load openmpi && module avail
-------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/openmpi/4.0.5-eagetxh/gcc/9.2.0 --------------------------------------
   hdf5/1.10.7    netcdf-c/4.7.4    netcdf-fortran/4.5.3    parallel-netcdf/1.12.1    wrf/4.2

------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/gcc/9.2.0 -------------------------------------------------
   hwloc/2.2.0      libiconv/1.16          libpng/1.6.37     nasm/2.15.05            openmpi/4.0.5 (L,D)    time/1.9              zlib/1.2.11
   jasper/2.0.16    libjpeg-turbo/2.0.4    libtirpc/1.2.6    ncurses/5.9.20130511    perl/5.16.3            util-macros/1.19.1
   krb5/1.15.1      libpciaccess/0.16      libxml2/2.9.10    numactl/2.0.14          tcsh/6.22.02           xz/5.2.2

--------------------------------------------------- /apps/spack/share/spack/lmod/linux-centos7-x86_64/Core ----------------------------------------------------
   gcc/9.2.0 (L)

---------------------------------------------------------------------- /apps/modulefiles ----------------------------------------------------------------------
   openmpi/v4.1.x

10. Vérifiez que /apps/share/conus-2.5km contient les éléments listés ci-dessous.

$ ls -1 /apps/share/conus-2.5km
FILE:2018-06-17_00
FILE:2018-06-17_03
FILE:2018-06-17_06
FILE:2018-06-17_09
FILE:2018-06-17_12
geo_em.d01.nc
geogrid.log
gfs.0p25.2018061700.f000.grib2
gfs.0p25.2018061700.f003.grib2
gfs.0p25.2018061700.f006.grib2
gfs.0p25.2018061700.f009.grib2
gfs.0p25.2018061700.f012.grib2
met_em.d01.2018-06-17_00:00:00.nc
met_em.d01.2018-06-17_03:00:00.nc
met_em.d01.2018-06-17_06:00:00.nc
met_em.d01.2018-06-17_09:00:00.nc
met_em.d01.2018-06-17_12:00:00.nc
metgrid.log
namelist.input
namelist.wps
ungrib.log
wrfbdy_d01
wrfinput_d01

Remarque : Ce déploiement utilise une image personnalisée créée à l'aide de l'image de VM schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. Vous pouvez créer WRF pour d'autres systèmes d'exploitation à l'aide du dépôt fluidnumerics/hpc-apps-gcp sur GitHub.

6. Exécuter le benchmark CONUS 2,5 km

Pour exécuter le benchmark CONUS 2,5 km, vous devez envoyer un job par lot Slurm. Les decks d'entrée pour ce benchmark sont inclus dans l'image de VM wrf-gcp sous /apps/share/benchmarks/conus-2.5km.

Pour cette section, vous devez être connecté en SSH au nœud login du cluster.

6. Copiez l'exemple de fichier de lot wrf-conus.sh depuis /apps/share.

cp /apps/share/wrf-conus2p5.sh ~/

7. Ouvrez wrf-conus.sh dans un éditeur de texte pour vérifier que --partition et --ntasks sont correctement définis. La partition doit être définie sur c2-60. Le nombre de tâches doit être défini sur le nombre de rangs MPI que vous souhaitez utiliser pour lancer le job. Pour cette démonstration, le nombre de tâches est équivalent au nombre de vCPU utilisés pour le job et ne doit pas dépasser votre quota disponible.

Remarque : Vous pouvez lister les partitions disponibles sur votre cluster avec sinfo. Dans cette démonstration, le nombre de tâches est équivalent au nombre de rangs MPI.

#!/bin/bash
#SBATCH --partition=c2-60
#SBATCH --ntasks=480
#SBATCH --ntasks-per-node=60
#SBATCH --mem-per-cpu=2g
#SBATCH --cpus-per-task=1
#SBATCH --account=default
#
# /////////////////////////////////////////////// #

WORK_PATH=${HOME}/wrf-benchmark/
SRUN_FLAGS="-n $SLURM_NTASKS --cpu-bind=threads"

. /apps/share/spack.sh
module load gcc/9.2.0
module load openmpi
module load hdf5 netcdf-c netcdf-fortran wrf

mkdir -p ${WORK_PATH}
cd ${WORK_PATH}
ln -s ${INSTALL_ROOT}/share/conus-2.5km/* .
ln -s $(spack location -i wrf)/run/* .

srun $MPI_FLAGS ./wrf.exe

8. Envoyez le job par lot à l'aide de sbatch.

sbatch wrf-conus2p5.sh

Remarque : Les nœuds de calcul sont créés selon les besoins lorsque des jobs sont envoyés. Pour cette première soumission de job, le démarrage peut prendre jusqu'à trois minutes.

9. Attendez que la tâche soit terminée. Ce benchmark est configuré pour exécuter une prévision de six heures, ce qui prend environ une heure avec 480 rangs. Vous pouvez surveiller l'état de votre tâche avec squeue.
10. Une fois le job terminé, vérifiez le contenu de rsl.out.0000 pour vous assurer que l'instruction "wrf: SUCCESS COMPLETE WRF" s'affiche. Le suffixe numérique sera différent si vous avez exécuté le job plusieurs fois (par exemple, si vous avez mal configuré un paramètre et que vous avez dû l'exécuter à nouveau).

$ tail -n1 ${HOME}/wrf-benchmark/rsl.out.0000
d01 2018-06-17_06:00:00 wrf: SUCCESS COMPLETE WRF

7. Félicitations

Dans cet atelier de programmation, vous avez créé un cluster HPC cloud natif à autoscaling et exécuté une simulation WRF® parallèle sur Google Cloud Platform.

Nettoyer

Pour éviter que les ressources utilisées dans cet atelier de programmation soient facturées sur votre compte Google Cloud Platform :

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour l'atelier de programmation.

Attention : La suppression d'un projet aura les effets suivants :

• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour cet atelier de programmation et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé dont vous souhaitez vous servir par la suite. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs ateliers de programmation et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

1. Dans la console Cloud, accédez à la page Gérer les ressources. Accéder à la page "Gérer les ressources"
2. Dans la liste des projets, sélectionnez celui que vous souhaitez supprimer, puis cliquez sur Supprimer .
3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer les ressources individuelles

1. Ouvrez Cloud Shell et accédez au répertoire d'exemple WRF.

cd  ~/slurm-gcp/tf/examples/wrf

2. Exécutez make destroy pour supprimer toutes les ressources.

make destroy