Ejecuta el modelo de previsión del clima de la WRF con datos numéricos fluidos' Slurm-GCP

1. Introducción

Última actualización: 5/5/2021

Qué compilarás

En este codelab, implementarás un clúster de computación de alto rendimiento (HPC) con ajuste de escala automático en Google Cloud con el programador de trabajos de Slurm. Usarás una implementación de Terraform de ejemplo que implementa este clúster con WRF® instalado a través de Spack. Luego, usarás esta infraestructura para ejecutar la comparativa CONUS 2.5 km o la comparativa CONUS 12 km.

Qué aprenderá

• Cómo configurar las políticas de Identity and Access Management (IAM) para operar un clúster de HPC en Google Cloud Platform
• Cómo implementar un clúster de HPC nativo de la nube con el programador de trabajos de Slurm
• Cómo ejecutar WRF® en paralelo en Google Cloud con un trabajo por lotes de Slurm

Requisitos

• Cuenta de Gmail con una clave SSH adjunta, o Google Workspace o Cloud Identity
• Proyecto de Google Cloud Platform con la facturación habilitada
• Función de propietario del proyecto en tu proyecto de GCP
• Cuota suficiente de Compute Engine (480 CPU virtuales de c2 y disco estándar de PD de 500 GB)

2. Configuración

Habilita las API de Google Cloud

Para crear y usar recursos de Google Cloud, se deben habilitar las APIs.

gcloud services enable compute.googleapis.com 

Configurar políticas de IAM

En la HPC, existen diferencias claras entre los administradores del sistema y los usuarios del sistema. Los administradores de sistemas generalmente tienen "acceso raíz" lo que les permite administrar y operar los recursos de procesamiento. Los usuarios del sistema suelen ser investigadores, científicos e ingenieros de aplicaciones que solo necesitan usar los recursos para ejecutar trabajos.

En Google Cloud, la API de Acceso al SO aprovisiona información del usuario POSIX de las cuentas de Google Workspace, Cloud Identity y Gmail. Además, Acceso al SO se integra en el sistema de Identity and Access Management (IAM) de GCP para determinar si los usuarios deben tener permitido escalar privilegios en sistemas Linux.

En este instructivo, suponemos que estás ocupando los roles de administrador del sistema y administrador de Compute Engine. Configuraremos las políticas de IAM para que te otorguen los permisos suficientes para realizar las siguientes tareas

• Crear o borrar instancias de VM de Google Compute Engine (GCE)
• Establece una conexión SSH a instancias de VM de GCE

Si quieres otorgarte los roles de IAM necesarios para completar este instructivo, haz lo siguiente en la consola de Google Cloud:

1. Navega a IAM y Administrador > IAM en el menú Products and Services.
2. Haz clic en "+Agregar". cerca de la parte superior de la página.
3. En “Miembros nuevos”, escribe tu cuenta de Google Workspace, Cloud Identity o Gmail
4. Agrega los siguientes roles : Administrador de Compute, Acceso al SO de Compute y Usuario de cuenta de servicio.
5. Haz clic en Guardar

Opción: Si la IU de la consola no está alineada con lo que se muestra aquí, los siguientes comandos de gcloud darán los mismos resultados y reemplazarán YOUR_PROJECT y EMAIL_ADDRESS por tu proyecto y dirección de correo electrónico.

• 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"

Tu acceso ahora tiene los permisos necesarios para iniciar la creación del clúster de HPC.

Para verificar que asignaste los roles correctos, abre Cloud Shell y ejecuta el siguiente comando, pero reemplaza YOUR_PROJECT y EMAIL_ADDRESS por tu proyecto y dirección de correo electrónico.

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

Este comando generará el siguiente resultado:

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

Precaución: Si planeas usar SSH de terceros (p.ej., OpenSSH) para conectarte al clúster, asegúrate de conectar una clave SSH a tu perfil de identidad en la nube a través del Acceso al SO. Obtén más información para agregar claves SSH a tu perfil de Cloud Identity.

3. Cuota baja: Implementa un clúster de HPC con ajuste de escala automático con Terraform

En esta sección, implementarás un clúster de HPC con ajuste de escala automático, incluido el programador de trabajos de Slurm. Esto es idéntico a la opción de cuota alta, con la excepción de que el tipo de máquina que se usa es menor y la cantidad de CPU virtuales usadas es menor.

Importante: La cuota predeterminada para las CPU C2 de un proyecto nuevo suele ser de 24 CPU virtuales. Si tienes una cuota mayor y quieres ejecutar la comparativa de CONUS 2.5 km, puedes omitir esta sección y la siguiente.

1. Abre Cloud Shell en GCP.
2. Clona el repositorio FluidNumerics/slurm-gcp

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

3. Cambia al directorio WRF:

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

4. Crear y revisar un plan de Terraform Configura las variables de entorno WRF_NAME, WRF_PROJECT y WRF_ZONE para especificar el nombre del clúster, el proyecto de GCP y la zona en la que deseas realizar la implementación.

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

5. La primera vez que ejecutes Terraform, debes ejecutar el comando init:

terraform init

6. Crea el plan con el comando make, que ejecutará terraform.

make plan

Nota: Para obtener un mejor rendimiento de E/S de archivos en NFS, aumenta el tamaño del disco del controlador a 2.5 TB y cambia Controller_disk_type a pd-ssd. Para cambiar el tamaño del disco, editabasic.tfvars.tmpl y agrega controller_disk_size_gb = 2500. Como alternativa, se recomienda usar un sistema de archivos de Lustre.

Precaución: Cuando elijas una zona, asegúrate de seleccionar una zona en la que estén disponibles las instancias C2. Obtén más información sobre las regiones y zonas disponibles.

Para obtener más información sobre las limitaciones de cuota de tu proyecto, en la página Cuotas de la consola de Google Cloud, se enumeran todas las cuotas. Busca “Nombre del límite: CPU C2”. Esto mostrará las CPU C2 disponibles en la zona seleccionada.

7. Implemente el clúster: El proceso de instalación y configuración puede tardar hasta 2 horas. Durante la implementación, se instalarán WRF y todas sus dependencias.

make apply

8. Establece una conexión SSH al nodo login creado en el paso anterior. Puedes ver este nodo en el paso anterior (probablemente llamado wrf-small-login0). Para ello, haz clic en el botón SSH junto a la lista de instancias de VM en el elemento de menú de la consola Compute Engine -> instancia de VM.

Opción: Este par de comandos de gcloud averiguará el nombre del nodo de acceso y establecerá una conexión SSH a él:

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 vez que te hayas conectado al nodo de acceso, comprueba que el módulo wrf esté disponible para verificar la configuración de tu clúster.

$ 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 que /apps/share/conus-12km tenga el contenido que se indica a continuación.

$  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: Esta implementación utiliza una imagen personalizada compilada mediante la imagen de VM schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. Puedes compilar WRF para otros sistemas operativos mediante el repositorio Fluidnumerics/hpc-apps-gcp en GitHub.

4. Ejecuta la comparativa de CONUS 12 km

Para ejecutar la comparativa de CONUS 12 km, enviarás un trabajo por lotes de Slurm. Las presentaciones de entrada para esta comparativa se incluyen en la imagen de VM wrf-gcp en /apps/share/benchmarks/conus-12km.

Para esta sección, debes tener una conexión SSH al nodo login del clúster.

1. Copia el archivo por lotes wrf-conus.sh de ejemplo de /apps/share

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

2. Abre wrf-conus.sh en un editor de texto para verificar que --partition y --ntasks estén configurados correctamente. La cantidad de tareas debe establecerse con la cantidad de clasificaciones de la MPI que quieres usar para lanzar el trabajo. En esta demostración, la cantidad de tareas es equivalente a la cantidad de CPU virtuales que se usan para el trabajo y no debe exceder tu cuota disponible.

Nota: Puedes enumerar las particiones disponibles en tu clúster con sinfo. La cantidad de tareas, en esta demostración, es equivalente a la cantidad de rangos de la 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. Envía el trabajo por lotes mediante sbatch.

sbatch wrf-conus12.sh

Nota: Los nodos de procesamiento se crean según sea necesario cuando se envían trabajos. Para este primer envío de trabajo, el trabajo puede tardar hasta 3 minutos en comenzar.

4. Espera a que se complete el trabajo. Esta comparativa está configurada para ejecutar una previsión de 6 horas, que tarda alrededor de 3 horas en completarse con 24 clasificaciones. Puedes supervisar el estado de tu trabajo con squeue.
5. Cuando se complete el trabajo, revisa el contenido de rsl.out.0000 para verificar si ves la instrucción “wrf: SUCCESS COMPLETE WRF”. El sufijo numérico será diferente si ejecutaste el trabajo más de una vez, p.ej., si recibiste un parámetro de configuración incorrecto y tuviste que volver a ejecutarlo.

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

5. Cuota alta: Implementa un clúster de HPC con ajuste de escala automático con Terraform

En esta sección, implementarás un clúster de HPC con ajuste de escala automático, incluido el programador de trabajos de Slurm en GCP.

Importante: La cuota predeterminada para las CPU C2 de un proyecto nuevo suele ser de 24 CPU virtuales. Esto no es suficiente para ejecutar la comparativa más grande de CONUS 2.5 km. Si tienes una cuota grande de hasta 480 CPU virtuales, puedes ejecutar esta parte del codelab.

1. Abre Cloud Shell en GCP.
2. Clona el repositorio FluidNumerics/slurm-gcp

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

3. Cambia al directorio WRF:

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

4. Crear y revisar un plan de Terraform Configura las variables de entorno WRF_NAME, WRF_PROJECT, WRF_ZONE, WRF_MAX_NODE y WRF_MACHINE_TYPE para especificar el nombre del clúster, el proyecto de GCP, la zona en la que deseas realizar la implementación, la cantidad máxima de nodos y el tipo de máquina. Para la comparativa de CONUS 2.5 km, recomendamos usar instancias c2-standard-60 con al menos 8 nodos disponibles en trabajos de ejecución con clasificaciones 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 no lo hiciste antes, debes ejecutar terraform init para iniciar Terraform:

terraform init

6. Crea el plan con el comando make.

make plan

Nota: Para obtener un mejor rendimiento de E/S de archivos en NFS, aumenta el tamaño del disco del controlador a 2.5 TB y cambia Controller_disk_type a pd-ssd. Para cambiar el tamaño del disco, editabasic.tfvars.tmpl y agrega controller_disk_size_gb = 2500. Como alternativa, se recomienda usar un sistema de archivos de Lustre.

Precaución: Cuando elijas una zona, asegúrate de seleccionar una zona en la que estén disponibles las instancias C2. Obtén más información sobre las regiones y zonas disponibles.

Para obtener más información sobre las limitaciones de cuota de tu proyecto, en la página Cuotas de la consola de Google Cloud, se enumeran todas las cuotas. Busca “Nombre del límite: CPU C2”. Esto mostrará las CPU C2 disponibles en la zona seleccionada.

7. Implemente el clúster: El proceso de instalación y configuración puede tardar hasta 2 horas. Durante la implementación, se instalarán WRF y todas sus dependencias.

make apply

8. Establece una conexión SSH al nodo login creado en el paso anterior. Puedes ver este nodo en el paso anterior (probablemente llamado wrf-large-login0). Para ello, haz clic en el botón SSH junto a la lista de instancias de VM en el elemento de menú de la consola Compute Engine -> instancia de VM.

Opción: Este par de comandos de gcloud averiguará el nombre del nodo de acceso y establecerá una conexión SSH a él:

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}

Con el segundo comando, se debería conectarte al nodo de acceso de Slurm.

9. Una vez que te hayas conectado al nodo de acceso, comprueba que el módulo wrf esté disponible para verificar la configuración de tu clúster.

$ 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 que /apps/share/conus-2.5km tenga el contenido que se indica a continuación.

$ 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: Esta implementación utiliza una imagen personalizada compilada mediante la imagen de VM schedmd-slurm-public/schedmd-slurm-20-11-4-centos-7. Puedes compilar WRF para otros sistemas operativos mediante el repositorio Fluidnumerics/hpc-apps-gcp en GitHub.

6. Ejecuta la comparativa de CONUS 2.5 km

Para ejecutar la comparativa de CONUS 2.5 km, enviarás un trabajo por lotes de Slurm. Las presentaciones de entradas para estas comparativas se incluyen en la imagen de VM wrf-gcp en /apps/share/benchmarks/conus-2.5km.

Para esta sección, debes tener una conexión SSH al nodo login del clúster.

6. Copia el archivo por lotes wrf-conus.sh de ejemplo de /apps/share

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

7. Abre wrf-conus.sh en un editor de texto para verificar que --partition y --ntasks estén configurados correctamente. La partición debe establecerse en c2-60. La cantidad de tareas debe establecerse con la cantidad de clasificaciones de la MPI que quieres usar para lanzar el trabajo. En esta demostración, la cantidad de tareas es equivalente a la cantidad de CPU virtuales que se usan para el trabajo y no debe exceder tu cuota disponible.

Nota: Puedes enumerar las particiones disponibles en tu clúster con sinfo. La cantidad de tareas, en esta demostración, es equivalente a la cantidad de rangos de la 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. Envía el trabajo por lotes mediante sbatch.

sbatch wrf-conus2p5.sh

Nota: Los nodos de procesamiento se crean según sea necesario cuando se envían trabajos. Para este primer envío de trabajo, el trabajo puede tardar hasta 3 minutos en comenzar.

9. Espera a que se complete el trabajo. Esta comparativa está configurada para ejecutar una previsión de 6 horas, que tarda alrededor de 1 hora en completarse con 480 clasificaciones. Puedes supervisar el estado de tu trabajo con squeue.
10. Cuando se complete el trabajo, revisa el contenido de rsl.out.0000 para verificar si ves la instrucción “wrf: SUCCESS COMPLETE WRF”. El sufijo numérico será diferente si ejecutaste el trabajo más de una vez, p.ej., si recibiste un parámetro de configuración incorrecto y tuviste que volver a ejecutarlo.

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

7. Felicitaciones

En este codelab, creaste un clúster de HPC nativo de la nube con ajuste de escala automático y ejecutaste una simulación de WRF® paralela en Google Cloud Platform.

Realice una limpieza

Sigue estos pasos para evitar que se apliquen cargos a tu cuenta de Google Cloud Platform por los recursos que usaste en este codelab:

Borra el proyecto

La manera más fácil de eliminar la facturación es borrar el proyecto que creaste para el codelab.

Precaución: Borrar un proyecto tiene las siguientes consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para este codelab, cuando lo borres, también borrarás cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL de appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varios codelabs y guías de inicio rápido, la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

1. En la consola de Cloud, ve a la página Administrar recursos. Ir a la página Administrar recursos
2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar .
3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrarlo.

Borra los recursos individuales

1. Abre Cloud Shell y navega al directorio de ejemplo de wrf.

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

2. Ejecuta make destroy para borrar todos los recursos.

make destroy