Esegui il modello di previsione meteorologica WRF con Fluid Numerics' Slurm-GCP

1. Introduzione

Ultimo aggiornamento: 2021-05-05

Cosa creerai

In questo codelab, eseguirai il deployment di un cluster HPC (High Performance Computing) a scalabilità automatica su Google Cloud con lo scheduler dei job Slurm. Utilizzerai un deployment Terraform di esempio che esegue il deployment di questo cluster con WRF® installato tramite Spack. Quindi, utilizzerai questa infrastruttura per eseguire il benchmark CONUS 2,5 km o il benchmark CONUS 12 km.

Cosa imparerai a fare

• Come configurare criteri IAM (Identity and Access Management) per il funzionamento di un cluster HPC su Google Cloud Platform
• Eseguire il deployment di un cluster HPC cloud-native con lo scheduler di Slurm
• Come eseguire WRF® in parallelo su Google Cloud utilizzando un job batch Slurm

Che cosa ti serve

• Account Gmail con una chiave SSH collegata oppure Google Workspace, Cloud Identity
• Progetto Google Cloud Platform con fatturazione abilitata
• Ruolo di proprietario del progetto nel tuo progetto Google Cloud
• Quota di Compute Engine sufficiente (480 vCPU c2 e un disco standard da 500 GB per DP)

2. Configurazione

Abilita API Google Cloud

Per creare e utilizzare le API delle risorse Google Cloud, devono essere abilitate.

gcloud services enable compute.googleapis.com 

Imposta criteri IAM

In HPC, esistono chiare differenze tra amministratori di sistema e utenti di sistema. Gli amministratori di sistema di solito dispongono di un "accesso root" consentendo loro di gestire e operare le risorse di computing. Gli utenti del sistema sono generalmente ricercatori, scienziati e tecnici delle applicazioni che devono utilizzare le risorse solo per eseguire i job.

Su Google Cloud, l'API OS Login esegue il provisioning dei dati utente POSIX dagli account Google Workspace, Cloud Identity e Gmail. Inoltre, OS Login si integra con il sistema Identity and Access Management (IAM) di Google Cloud per determinare se agli utenti deve essere consentito aumentare i privilegi sui sistemi Linux.

In questo tutorial, supponiamo che tu stia inserendo i ruoli di amministratore di sistema e amministratore di Compute Engine. Configureremo i criteri IAM per concederti le autorizzazioni sufficienti per svolgere le attività seguenti

• Creare/eliminare istanze VM di Google Compute Engine (GCE)
• Accedi tramite SSH alle istanze VM GCE

Per ottenere i ruoli IAM necessari per completare questo tutorial nella console Google Cloud:

1. Passa a IAM e Amministratore > IAM nel menu Prodotti e servizi.
2. Fai clic su "+Aggiungi" nella parte superiore della pagina.
3. Digita il tuo account Google Workspace, Cloud Identity o Gmail in "Nuovi membri"
4. Aggiungi i ruoli seguenti : Amministratore Compute, OS Login Compute e Utente account di servizio
5. Fai clic su Salva

Opzione: se l'interfaccia utente della console non è allineata a quanto mostrato qui, i seguenti comandi gcloud restituiranno gli stessi risultati, sostituendo YOUR_PROJECT e EMAIL_ADDRESS con il tuo progetto e il tuo indirizzo email.

• 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="utente:EMAIL_ADDRESS"

Il tuo accesso ora dispone delle autorizzazioni necessarie per avviare la creazione del cluster HPC.

Per verificare di aver assegnato i ruoli corretti, apri Cloud Shell ed esegui questo comando, sostituendo YOUR_PROJECT e EMAIL_ADDRESS con il tuo progetto e il tuo indirizzo email.

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

Questo comando restituirà l'output:

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

Attenzione:se prevedi di utilizzare SSH di terze parti (ad es. OpenSSH) per connetterti al cluster, assicurati di collegare una chiave SSH al tuo profilo Cloud Identity utilizzando OS Login. Scopri di più sull'aggiunta di chiavi SSH al profilo Cloud Identity.

3. Quota bassa: esegui il deployment di un cluster HPC a scalabilità automatica con Terraform

In questa sezione eseguirai il deployment di un cluster HPC a scalabilità automatica che include lo scheduler del job Slurm. Questa opzione è identica all'opzione Quota elevata, ad eccezione del fatto che il tipo di macchina utilizzato è inferiore e il numero di vCPU utilizzate è inferiore.

Importante: la quota predefinita per le CPU C2 per un nuovo progetto è in genere di 24 vCPU. Se hai una quota maggiore e vuoi eseguire il benchmark CONUS 2,5 km, puoi saltare questa sezione e quella successiva.

1. Apri Cloud Shell in Google Cloud.
2. Clona il repository FluidNumerics/slurm-gcp

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

3. Passa alla directory WRF:

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

4. Crea e rivedi un piano Terraform. Imposta le variabili di ambiente WRF_NAME, WRF_PROJECT e WRF_ZONE per specificare il nome del cluster, del progetto Google Cloud e della zona in cui vuoi eseguire il deployment.

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

5. La prima volta che esegui Terraform devi eseguire il comando init:

terraform init

6. Crea il piano con il comando make, che eseguirà terraform

make plan

Nota: per ottenere prestazioni migliori da I/O dei file su NFS, aumenta la dimensione del disco del controller a 2,5 TB e modifica il valore controller_disk_type in pd-ssd. Puoi cambiare la dimensione del disco modificando basic.tfvars.tmpl e aggiungendo controller_disk_size_gb = 2500. In alternativa, è consigliabile utilizzare un file system Lustre.

Attenzione: quando scegli una zona, assicurati di selezionare una zona in cui sono disponibili istanze C2. Scopri di più sulle regioni e sulle zone disponibili.

Per ulteriori informazioni sulle limitazioni delle quote nel tuo progetto, consulta la pagina Quote della console Google Cloud in cui sono elencate tutte le quote. Cerca "Limit Name: C2 CPUs" (Nome limite: CPU C2). Verranno visualizzate le CPU C2 disponibili nella zona selezionata.

7. Eseguire il deployment del cluster. Il processo di installazione e configurazione può richiedere fino a 2 ore. Durante il deployment, verranno installati WRF e tutte le sue dipendenze.

make apply

8. Accedi tramite SSH al nodo di accesso creato nel passaggio precedente. Puoi vedere questo nodo nel passaggio precedente (probabilmente chiamato wrf-small-login0). Per farlo, fai clic sul pulsante SSH accanto all'elenco di istanze VM nella voce di menu della console Compute Engine -> di un'istanza VM.

Opzione: questa coppia di comandi gcloud è in grado di determinare il nome del nodo di accesso e accedervi tramite 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. Una volta stabilita la connessione al nodo di accesso, per verificare la configurazione del cluster controlla che il modulo wrf sia disponibile.

$ 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. Verifica che /apps/share/conus-12km includa i contenuti elencati di seguito.

$  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

Nota: questo deployment utilizza un'immagine personalizzata creata utilizzando l'immagine VM schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. Puoi creare WRF per altri sistemi operativi utilizzando il repository Fluidnumerics/hpc-apps-gcp su GitHub.

4. Esegui il benchmark CONUS dei 12 km

Per eseguire il benchmark CONUS dei 12 km, devi inviare un job batch Slurm. Le presentazioni di input per questo benchmark sono incluse nell'immagine VM wrf-gcp in /apps/share/benchmarks/conus-12km.

Per questa sezione, la connessione tramite SSH al nodo di login del cluster

1. Copia il file batch wrf-conus.sh di esempio da /apps/share

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

2. Apri wrf-conus.sh in un editor di testo per verificare che --partition e --ntasks siano impostati correttamente. Il numero di attività deve essere impostato sul numero di livelli MPI che vuoi utilizzare per avviare il job. Per questa dimostrazione, il numero di attività equivale al numero di vCPU utilizzate per il job e non deve superare la quota disponibile.

Nota: puoi elencare le partizioni disponibili nel cluster con sinfo. Il numero di attività in questa dimostrazione equivale al numero di ranking 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. Inviare il job batch utilizzando sbatch.

sbatch wrf-conus12.sh

Nota: i nodi di computing vengono creati secondo necessità quando vengono inviati i job. Per l'invio del primo job, l'avvio del job potrebbe richiedere fino a 3 minuti.

4. Attendi il completamento del job. Questo benchmark è configurato per eseguire una previsione di 6 ore, che richiede circa 3 ore per essere completata con 24 livelli. Puoi monitorare lo stato del job con squeue.
5. Al termine del job, controlla i contenuti di rsl.out.0000 per verificare che sia visualizzata l'istruzione "wrf: SUCCESS COMPLETE WRF". Il suffisso numerico sarà diverso se hai eseguito il job più di una volta, ad esempio se hai un'impostazione di configurazione errata e hai dovuto eseguirlo di nuovo.

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

5. Quota elevata: esegui il deployment di un cluster HPC a scalabilità automatica con Terraform

In questa sezione eseguirai il deployment di un cluster HPC a scalabilità automatica che include lo scheduler del job Slurm in Google Cloud.

Importante: la quota predefinita per le CPU C2 per un nuovo progetto è in genere di 24 vCPU. Ciò non è sufficiente per eseguire il benchmark CONUS più grande di 2,5 km. Se hai una quota elevata per un massimo di 480 vCPU, puoi eseguire questa parte del codelab.

1. Apri Cloud Shell in Google Cloud.
2. Clona il repository FluidNumerics/slurm-gcp

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

3. Passa alla directory WRF:

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

4. Crea e rivedi un piano Terraform. Imposta le variabili di ambiente WRF_NAME, WRF_PROJECT, WRF_ZONE, WRF_MAX_NODE e WRF_MACHINE_TYPE per specificare il nome del cluster, il progetto Google Cloud, la zona in cui eseguire il deployment, il numero massimo di nodi e il tipo di macchina. Per il benchmark CONUS a 2,5 km, consigliamo di utilizzare istanze c2-standard-60 con almeno 8 nodi disponibili per l'esecuzione di job con 480 livelli di 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. Se non l'hai già fatto, devi eseguire terraform init per avviare Terraform:

terraform init

6. Crea il piano con il comando "make".

make plan

Nota: per ottenere prestazioni migliori da I/O dei file su NFS, aumenta la dimensione del disco del controller a 2,5 TB e modifica il valore controller_disk_type in pd-ssd. Puoi cambiare la dimensione del disco modificando basic.tfvars.tmpl e aggiungendo controller_disk_size_gb = 2500. In alternativa, è consigliabile utilizzare un file system Lustre.

Attenzione: quando scegli una zona, assicurati di selezionare una zona in cui sono disponibili istanze C2. Scopri di più sulle regioni e sulle zone disponibili.

Per ulteriori informazioni sulle limitazioni delle quote nel tuo progetto, consulta la pagina Quote della console Google Cloud in cui sono elencate tutte le quote. Cerca "Limit Name: C2 CPUs" (Nome limite: CPU C2). Verranno visualizzate le CPU C2 disponibili nella zona selezionata.

7. Eseguire il deployment del cluster. Il processo di installazione e configurazione può richiedere fino a 2 ore. Durante il deployment, verranno installati WRF e tutte le sue dipendenze.

make apply

8. Accedi tramite SSH al nodo di accesso creato nel passaggio precedente. Puoi vedere questo nodo nel passaggio precedente (probabilmente chiamato wrf-large-login0). Per farlo, fai clic sul pulsante SSH accanto all'elenco di istanze VM nella voce di menu della console Compute Engine -> di un'istanza VM.

Opzione: questa coppia di comandi gcloud è in grado di determinare il nome del nodo di accesso e accedervi tramite 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}

Il secondo comando dovrebbe comportare la connessione al nodo di accesso a Slurm.

9. Una volta stabilita la connessione al nodo di accesso, per verificare la configurazione del cluster controlla che il modulo wrf sia disponibile.

$ 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. Verifica che /apps/share/conus-2.5km includa i contenuti elencati di seguito.

$ 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

Nota: questo deployment utilizza un'immagine personalizzata creata utilizzando l'immagine VM schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. Puoi creare WRF per altri sistemi operativi utilizzando il repository Fluidnumerics/hpc-apps-gcp su GitHub.

6. Esegui il benchmark CONUS 2,5 km

Per eseguire il benchmark CONUS di 2,5 km, devi inviare un job batch Slurm. Le presentazioni di input per questo benchmark sono incluse nell'immagine VM wrf-gcp in /apps/share/benchmarks/conus-2.5km.

Per questa sezione, la connessione tramite SSH al nodo di login del cluster

6. Copia il file batch wrf-conus.sh di esempio da /apps/share

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

7. Apri wrf-conus.sh in un editor di testo per verificare che --partition e --ntasks siano impostati correttamente. La partizione deve essere impostata su c2-60. Il numero di attività deve essere impostato sul numero di livelli MPI che vuoi utilizzare per avviare il job. Per questa dimostrazione, il numero di attività equivale al numero di vCPU utilizzate per il job e non deve superare la quota disponibile.

Nota: puoi elencare le partizioni disponibili nel cluster con sinfo. Il numero di attività in questa dimostrazione equivale al numero di ranking 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. Inviare il job batch utilizzando sbatch.

sbatch wrf-conus2p5.sh

Nota: i nodi di computing vengono creati secondo necessità quando vengono inviati i job. Per l'invio del primo job, l'avvio del job potrebbe richiedere fino a 3 minuti.

9. Attendi il completamento del job. Questo benchmark è configurato per eseguire una previsione di 6 ore, che richiede circa 1 ora per essere completata con 480 livelli. Puoi monitorare lo stato del job con squeue.
10. Al termine del job, controlla i contenuti di rsl.out.0000 per verificare che sia visualizzata l'istruzione "wrf: SUCCESS COMPLETE WRF". Il suffisso numerico sarà diverso se hai eseguito il job più di una volta, ad esempio se hai un'impostazione di configurazione errata e hai dovuto eseguirlo di nuovo.

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

7. Complimenti

In questo codelab, hai creato un cluster HPC cloud-native con scalabilità automatica ed eseguito una simulazione WRF® parallela su Google Cloud Platform.

esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo codelab:

Elimina il progetto

Il modo più semplice per eliminare la fatturazione è quello di eliminare il progetto che hai creato per il codelab.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per questo codelab, quando lo elimini, eliminerai anche qualsiasi altro lavoro che hai svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato il progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se prevedi di esplorare più codelab e guide rapide, il riutilizzo dei progetti può aiutarti a evitare di superare i limiti di quota.

1. Nella console Cloud, vai alla pagina Gestisci risorse. Vai alla pagina Gestisci risorse
2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare e fai clic su Elimina .
3. Nella finestra di dialogo, digita l'ID progetto e fai clic su Chiudi per eliminare il progetto.

Elimina le singole risorse

1. Apri Cloud Shell e vai alla directory di esempio wrf

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

2. Esegui make destroy per eliminare tutte le risorse.

make destroy