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) avec autoscaling sur Google Cloud à l'aide du 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 les tests CONUS de 2, 5 km ou CONUS sur 12 km.

Points abordés

• Configurer des stratégies de gestion de l'authentification et des accès (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 avez besoin

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

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 système. Les administrateurs système ont généralement un « accès racine » ce qui leur permet de gérer et d'exploiter des ressources de calcul. Les utilisateurs système sont généralement des chercheurs, des scientifiques et des ingénieurs d'applications qui n'ont besoin d'utiliser les ressources que pour exécuter des tâches.

Sur Google Cloud, l'API OS Login provisionne les informations sur les utilisateurs POSIX à partir des comptes Google Workspace, Cloud Identity et Gmail. De plus, OS Login 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 avez les rôles d'administrateur système et d'administrateur Compute Engine. Nous configurerons des stratégies IAM pour vous donner les autorisations suffisantes pour accomplir les tâches suivantes

• Créer ou supprimer des instances de VM Google Compute Engine (GCE)
• Se connecter en SSH aux instances de VM GCE

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

1. Accéder à IAM et Admin > IAM dans le menu "Produits et services".
2. Cliquez sur "+ Ajouter". en haut de la page.
3. Saisissez votre compte Google Workspace, votre compte Cloud Identity ou votre compte Gmail sous "Nouveaux membres".
4. Ajoutez les rôles suivants : Administrateur de Compute, Connexion au système d'exploitation Compute et Utilisateur du compte de service.
5. Cliquez sur "Enregistrer".

Option:Si l'interface utilisateur de la console n'est pas alignée sur ce qui est affiché ici, les commandes gcloud suivantes donneront les mêmes résultats, en remplaçant 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="utilisateur:EMAIL_ADDRESS"
• gcloud projects add-iam-policy-binding YOUR_PROJECT –role roles/compute.admin –member="user:EMAIL_ADDRESS"

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

Pour vérifier que vous avez attribué les rôles appropriés, ouvrez Cloud Shell, puis 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"

La commande suivante permet d'obtenir le résultat suivant:

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

Attention:Si vous envisagez d'utiliser un protocole SSH tiers (par exemple, OpenSSH) pour vous connecter à votre cluster, veillez à associer une clé SSH à votre profil Cloud Identity à l'aide d'OS Login. En savoir plus sur l'ajout de 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 incluant le planificateur de tâches Slurm. Cette option est identique à l'option "Quota élevé", si ce n'est que le type de machine est plus petit et que le nombre de vCPU utilisés est moins important.

Important:Dans un nouveau projet, le quota par défaut pour les processeurs C2 est généralement de 24 processeurs virtuels. Si vous disposez d'un quota plus important et souhaitez exécuter le benchmark de 2,5 km du CONUS, 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 plan". 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 de meilleures performances d'E/S de fichiers par rapport à NFS, augmentez la taille de disque du contrôleur à 2,5 To et définissez le paramètre "controller_disk_type" sur pd-ssd. Vous pouvez changer la taille du disque en modifiant le fichier "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, veillez à sélectionner une zone dans laquelle des instances C2 sont disponibles. Découvrez les régions et les zones disponibles.

La page Quotas de la console Google Cloud répertorie tous les quotas pour en savoir plus sur les limites de quota applicables à votre projet. Recherchez "Limit Name: C2 CPUs" (Nom de limite : CPU C2). Les processeurs C2 disponibles dans la zone sélectionnée s'affichent.

7. Déployez le cluster. Le processus d'installation et de configuration peut prendre jusqu'à deux heures. Pendant le 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 (probablement appelé 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:La paire de commandes gcloud ci-dessous 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 vérifier 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 comporte le contenu indiqué 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 un code WRF pour d'autres systèmes d'exploitation à l'aide du dépôt fluidnumerics/hpc-apps-gcp sur GitHub.

4. Course de 12 km CONUS

Pour exécuter le benchmark 12 km CONUS, vous devez envoyer un job par lot Slurm. Les decks d'entrée de 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 par lot wrf-conus.sh depuis /apps/share

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

2. Ouvrez le fichier 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 classements MPI que vous souhaitez utiliser pour lancer la tâche. Dans cette démonstration, le nombre de tâches équivaut au nombre de vCPU utilisés pour la tâche. Il ne doit pas dépasser votre quota disponible.

Remarque:Vous pouvez répertorier les partitions disponibles sur votre cluster avec sinfo. Dans cette démonstration, le nombre de tâches est équivalent au nombre de classements 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 la commande sbatch.

sbatch wrf-conus12.sh

Remarque:Les nœuds de calcul sont créés en fonction des besoins lors de l'envoi des tâches. Le démarrage de ce premier job peut prendre jusqu'à trois minutes.

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

$ 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 incluant le planificateur de tâches Slurm dans GCP.

Important:Dans un nouveau projet, le quota par défaut pour les processeurs C2 est généralement de 24 processeurs virtuels. Ce n'est pas suffisant pour exécuter la mesure CONUS de 2,5 km. Si vous disposez d'un quota important pour 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 plan". 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 effectuer le déploiement, le nombre maximal de nœuds et le type de machine. Pour la référence CONUS sur 2,5 km, nous vous recommandons d'utiliser des instances c2-standard-60 avec au moins 8 nœuds disponibles et des jobs d'exécution avec des rangs de 480 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 de meilleures performances d'E/S de fichiers par rapport à NFS, augmentez la taille de disque du contrôleur à 2,5 To et définissez le paramètre "controller_disk_type" sur pd-ssd. Vous pouvez changer la taille du disque en modifiant le fichier "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, veillez à sélectionner une zone dans laquelle des instances C2 sont disponibles. Découvrez les régions et les zones disponibles.

La page Quotas de la console Google Cloud répertorie tous les quotas pour en savoir plus sur les limites de quota applicables à votre projet. Recherchez "Limit Name: C2 CPUs" (Nom de limite : CPU C2). Les processeurs C2 disponibles dans la zone sélectionnée s'affichent.

7. Déployez le cluster. Le processus d'installation et de configuration peut prendre jusqu'à deux heures. Pendant le 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 (probablement appelé 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:La paire de commandes gcloud ci-dessous 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 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 vérifier 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 comporte le contenu indiqué 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 un code WRF pour d'autres systèmes d'exploitation à l'aide du dépôt fluidnumerics/hpc-apps-gcp sur GitHub.

6. Défiez les 2,5 km de la CONUS

Pour exécuter le benchmark de 2,5 km CONUS, vous devez envoyer un job par lot Slurm. Les decks d'entrée de 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 par lot wrf-conus.sh depuis /apps/share

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

7. Ouvrez le fichier 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 classements MPI que vous souhaitez utiliser pour lancer la tâche. Dans cette démonstration, le nombre de tâches équivaut au nombre de processeurs virtuels utilisés pour la tâche. Il ne doit pas dépasser votre quota disponible.

Remarque:Vous pouvez répertorier les partitions disponibles sur votre cluster avec sinfo. Dans cette démonstration, le nombre de tâches est équivalent au nombre de classements 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 la commande sbatch.

sbatch wrf-conus2p5.sh

Remarque:Les nœuds de calcul sont créés en fonction des besoins lors de l'envoi des tâches. Le démarrage de ce premier job peut prendre jusqu'à trois minutes.

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

$ 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 avec 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 cet 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 prévoyez d'explorer plusieurs ateliers de programmation et guides de démarrage rapide, réutiliser des projets peut vous aider à éviter de dépasser les limites de quota 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