1. Descripción general
Te damos la bienvenida al codelab de Google para ejecutar un clúster de Slurm en Google Cloud Platform. Al final de este codelab, deberías tener un conocimiento sólido de la facilidad para aprovisionar y operar un clúster de Slurm con ajuste de escala automático.
Google Cloud se asoció con SchedMD para lanzar un conjunto de herramientas que facilitan el inicio del administrador de cargas de trabajo de Slurm en Compute Engine y la expansión dinámica de tu clúster existente cuando necesitas recursos adicionales. Esta integración fue creada por los expertos de SchedMD de acuerdo con las prácticas recomendadas de Slurm.
Si planeas usar las integraciones de Slurm en Google Cloud o tienes alguna pregunta, considera unirte a nuestro grupo de discusión de la comunidad de Google Cloud y Slurm.
Acerca de Slurm
Diagrama arquitectónico básico de un clúster de Slurm independiente en Google Cloud.
Slurm es uno de los principales administradores de cargas de trabajo para clústeres de HPC en todo el mundo. Slurm proporciona un sistema de administración de cargas de trabajo y programación de trabajos de código abierto, tolerante a errores y altamente escalable para clústeres de Linux grandes y pequeños. Slurm no requiere modificaciones del kernel para su funcionamiento y es relativamente autónomo. Como administrador de la carga de trabajo del clúster, Slurm tiene tres funciones clave:
- Asigna acceso exclusivo o no exclusivo a los recursos (nodos de procesamiento) a los usuarios durante un período determinado para que puedan realizar su trabajo.
- Proporciona un marco de trabajo para iniciar, ejecutar y supervisar el trabajo (normalmente, un trabajo paralelo) en el conjunto de nodos asignados.
- Administra una cola de trabajo pendiente para arbitrar la contención de recursos.
Qué aprenderás
- Cómo configurar un clúster de Slurm con Terraform
- Cómo ejecutar un trabajo con SLURM
- Cómo consultar la información del clúster y supervisar los trabajos en ejecución en SLURM
- Cómo ajustar la escala de manera automática de los nodos para adaptarse a los parámetros y los requisitos específicos del trabajo
- Dónde encontrar ayuda con Slurm
Requisitos previos
- Una cuenta de Google Cloud Platform y un proyecto con facturación
- Experiencia básica en Linux
2. Configuración
Configuración del entorno de autoaprendizaje
Crea un proyecto
Si aún no tienes una Cuenta de Google (Gmail o G Suite), debes crear una. Accede a Google Cloud Platform Console ( console.cloud.google.com) y abre la página Administrar recursos:
Haz clic en Crear proyecto.
Ingresa un nombre para el proyecto. Recuerda el ID del proyecto (destacado en rojo en la captura de pantalla anterior). El ID del proyecto debe ser un nombre único en todos los proyectos de Google Cloud. Si el nombre de tu proyecto no es único, Google Cloud generará un ID de proyecto aleatorio basado en el nombre del proyecto.
A continuación, deberás habilitar la facturación en Developers Console para usar los recursos de Google Cloud.
Ejecutar este codelab debería costar solo unos pocos dólares, pero su costo podría aumentar si decides usar más recursos o si los dejas en ejecución (consulta la sección “Conclusión” al final de este documento). La calculadora de precios de Google Cloud está disponible aquí.
Los usuarios nuevos de Google Cloud Platform son aptos para obtener una prueba gratuita de USD 300.
Google Cloud Shell
Si bien Google Cloud se puede operar de manera remota desde tu laptop, en este codelab usaremos Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.
Inicia Google Cloud Shell
En GCP Console, haga clic en el ícono de Cloud Shell en la barra de herramientas superior derecha:
Luego, haz clic en Iniciar Cloud Shell:
El aprovisionamiento y la conexión al entorno debería llevar solo unos minutos:
Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y simplificar la autenticación. Gran parte de tu trabajo en este lab, si no todo, se puede hacer simplemente con un navegador web o una Chromebook de Google.
Una vez que te conectes a Cloud Shell, deberías ver que ya te autenticaste y que el proyecto ya se configuró con tu PROJECT_ID:
$ gcloud auth list
Resultado del comando:
Credentialed accounts:
- <myaccount>@<mydomain>.com (active)
$ gcloud config list project
Resultado del comando:
[core]
project = <PROJECT_ID>
Si el ID del proyecto no está configurado correctamente, puedes establecerlo con este comando:
$ gcloud config set project <PROJECT_ID>
Resultado del comando:
Updated property [core/project].
3. Prepara y revisa la configuración de Terraform de Slurm
Descarga la configuración de Terraform de Slurm
En la sesión de Cloud Shell, ejecuta el siguiente comando para clonar (descargar) el repositorio de Git que contiene los archivos de Terraform de Slurm para Google Cloud:
git clone https://github.com/SchedMD/slurm-gcp.git
Cambia al directorio de configuración de la implementación de Slurm ejecutando el siguiente comando:
cd slurm-gcp
Configura el archivo tfvars de Terraform de Slurm
El archivo basic.tfvars.example detalla la configuración de la implementación, incluidas la red, las instancias y el almacenamiento que se implementarán. Cópialo en un archivo nuevo, al que llamaremos "el archivo tfvars", y, luego, edítalo según sea necesario.
cd tf/example/basic cp basic.tfvars.example basic.tfvars
En la sesión de Cloud Shell, abre el archivo tfvars basic.tfvars. Puedes usar tu editor de línea de comandos preferido (vi, nano, emacs, etc.) o el editor de código de Cloud Console para ver el contenido del archivo:
Revisa el contenido del archivo 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"
]
Dentro de este archivo tfvars, hay varios campos para configurar. El único campo que se debe configurar es project. Todas las demás configuraciones del ejemplo se pueden usar tal como están, pero modifícalas según sea necesario para tu situación. Para obtener una descripción más detallada de las opciones de configuración, consulta aquí.
- cluster_name: Nombre del clúster de Slurm
- project: ID del proyecto de Google Cloud en el que se implementarán los recursos
- zone: Zona de Google Cloud que contendrá las instancias de controlador y de acceso de este clúster. Más información
- network_name: Red de nube privada virtual en la que se implementará el clúster de Slurm
- subnetwork_name: Subred de nube privada virtual en la que se implementará el clúster de Slurm
- shared_vpc_host_project: Red de VPC compartida en la que se implementará el clúster de Slurm
- disable_controller_public_ips: ¿Asignar IP externa al controlador de Slurm?
- disable_login_public_ips: ¿Asignar IP externa al nodo de acceso de Slurm?
- disable_compute_login_ips: ¿Asignar IP externa al nodo de acceso de Slurm?
- suspend_time: Tiempo de espera después de que un nodo está inactivo antes de suspenderlo
- controller_machine_type: Tipo de instancia del nodo de controlador
- controller_image: Es la imagen de GCP que se usa para crear la instancia del controlador de Slurm.
- controller_disk_type: Tipo de disco de arranque de la instancia del controlador
- controller_disk_size_gb: Tamaño de un disco de arranque de instancia de controlador
- controller_labels: Etiquetas para adjuntar a la instancia del controlador
- controller_service_account: Cuenta de servicio que se usará en la instancia del controlador
- controller_scopes: Alcance de acceso de la instancia del controlador
- cloudsql: Servidor de Google CloudSQL que se usará como la base de datos de Slurm en lugar de alojar una base de datos en la instancia del controlador
- server_ip: IP del servidor de Cloud SQL
- user: Nombre de usuario de CloudSQL
- password: Contraseña de CloudSQL
- db_name: Nombre de la base de datos de CloudSQL
- controller_secondary_disk: ¿Agregar un disco secundario para el almacenamiento del servidor NFS?
- controller_secondary_disk_type: Tipo de disco secundario del controlador
- controller_secondary_disk_size_gb: Tamaño del disco secundario del controlador
- controller_instance_template: Es la plantilla de instancias de GCP que se usará para la instancia del controlador. Los campos de cálculo especificados anularán las propiedades de la plantilla. Por ejemplo, si se especifica controller_image, se anulará la imagen en la plantilla de instancias.
- login_machine_type: Tipo de instancia del nodo de acceso (accesible por SSH)
- login_image: Imagen de GCP que se usa para crear la instancia de acceso de Slurm
- login_disk_type: Tipo de disco de arranque de la instancia de acceso
- login_disk_size_gb: Tamaño del disco de arranque de la instancia de acceso
- login_labels: Etiquetas para adjuntar a la instancia de inicio de sesión
- login_node_count: Cantidad de nodos de acceso que se crearán
- login_node_service_account: Cuenta de servicio que se usará en las instancias de acceso
- login_node_scopes: Permiso de acceso de la instancia de acceso
- login_instance_template: Es la plantilla de instancias de GCP que se usará para la instancia de acceso. Los campos de cálculo especificados anularán las propiedades de la plantilla. p. ej., si se especifica login_image, se reemplazará la imagen en la plantilla de instancias.
- network_storage: Es el almacenamiento de red que se debe activar en todos los nodos. Los campos se agregarán directamente a fstab. Se puede repetir para activaciones adicionales.
- server_ip: IP del servidor de almacenamiento
- remote_mount: Nombre de la activación del almacenamiento (nombre del sistema de archivos)
- local_mount: Directorio de activación local
- fs_type: Tipo de sistema de archivos (NFS, CIFS, Lustre, GCSFuse instalado automáticamente)
- mount_options: Opciones de activación (es decir, defaults,_netdev)
- login_network_storage: Es el almacenamiento de red que se debe activar en los nodos de acceso y del controlador. NFS, CIFS, Lustre y GCSFuse se instalarán automáticamente. Se puede repetir para activaciones adicionales.
- server_ip: IP del servidor de almacenamiento
- remote_mount: Nombre de la activación del almacenamiento (nombre del sistema de archivos)
- local_mount: Directorio de activación local
- fs_type: Tipo de sistema de archivos (NFS, CIFS, Lustre, GCSFuse instalado automáticamente)
- mount_options: Opciones de activación (es decir, defaults,_netdev)
- compute_node_service_account: Cuenta de servicio que se usará en las instancias de procesamiento
- compute_node_scopes: Permiso de acceso de las instancias de procesamiento
- partitions: Es la configuración de la partición de Slurm. Se puede repetir para particiones adicionales.
- name: Nombre de la partición
- machine_type: Tipo de instancia de los nodos de procesamiento
- static_node_count: Cantidad de nodos de procesamiento siempre activos
- max_node_count: Es la cantidad máxima de nodos de procesamiento totales permitidos (64,000 como máximo).
- zone: Zona de Google Cloud que contendrá los recursos de esta partición. Más información
- image: Tipo de máquina del nodo de imagen de procesamiento
- image_hyperthreads: Activa o desactiva los hipersubprocesos en la instancia.
- compute_disk_type: Tipo de disco de arranque de una instancia de procesamiento (pd-standard, pd-ssd)
- compute_disk_size_gb: Tamaño de un disco de arranque de instancia de procesamiento
- compute_labels: Etiquetas para adjuntar a la instancia de procesamiento
- cpu_platform: Plataforma de CPU mínima requerida para todos los nodos de procesamiento
- gpu_count: Es la cantidad de GPUs que se adjuntarán a cada instancia de la partición.
- gpu_type: Tipo de GPU para adjuntar a las instancias de la partición
- network_storage: Es el almacenamiento de red que se debe activar en todos los nodos de procesamiento de la partición. Los campos se agregarán directamente a fstab. Se puede repetir para activaciones adicionales.
- server_ip: IP del servidor de almacenamiento
- remote_mount: Nombre de la activación del almacenamiento (nombre del sistema de archivos)
- local_mount: Directorio de activación local
- fs_type: Tipo de sistema de archivos (NFS, CIFS, Lustre, GCSFuse instalado automáticamente)
- mount_options: Opción de activación
- preemptible_bursting: ¿Las instancias serán interrumpibles?
- vpc_subnet: Subred de nube privada virtual en la que se implementará la partición de Slurm
- exclusive: Habilita Slurm para asignar nodos completos a los trabajos
- enable_placement: Habilita las políticas de posición en las que las instancias se ubicarán cerca unas de otras para obtener una baja latencia de red entre las instancias.
- regional_capacity: Permite que una instancia se coloque en cualquier zona de la región según la disponibilidad.
- regional_policy: Si regional_capacity es verdadero, esta política determina qué región usar y qué zonas de esa región no usar.
- Instance_template: Es la plantilla de instancias de GCP que se usará para las instancias de procesamiento. Los campos de cálculo especificados anularán las propiedades de la plantilla. p. ej., si se especifica una imagen, se sobrescribirá la imagen en la plantilla de instancias.
Configuración avanzada
Si lo deseas, puedes instalar paquetes y software adicionales como parte del proceso de implementación del clúster. Puedes instalar software en tu clúster de Slurm de varias maneras, como se describe en nuestro artículo "Instala apps en un clúster de Slurm en Compute Engine", o bien personalizando la imagen que implementa Slurm. Actualmente, Slurm implementa una imagen de VM proporcionada por SchedMD que se basa en la imagen de VM de HPC de Google Cloud, con Slurm instalado sobre ella.
Para usar tu propia imagen, compila una imagen con tu propia configuración basada en la imagen pública de VM de SchedMD que se indica en el archivo tfvars. A continuación, reemplaza el URI de la imagen especificado en el archivo tfvars por tu propia imagen y prueba el cambio.
Solución de problemas
A lo largo de este codelab, consulta la sección de solución de problemas del archivo ReadMe del repositorio de Slurm-GCP.
Los problemas más comunes que se observan son errores en la configuración del archivo tfvars y restricciones de cuota. Este codelab está diseñado para ejecutarse dentro de la asignación de cuota estándar de un usuario nuevo y dentro de los USD 300 de crédito gratuito que recibe un usuario nuevo. Si falla un intento de crear VMs, revisa el archivo /var/log/slurm/resume.log en el nodo del controlador para verificar si hay errores de API.
4. Implementa y verifica la configuración
Implementa la configuración
En la sesión de Cloud Shell, ejecuta el siguiente comando desde la carpeta slurm-gcp/tf/example:
terraform init terraform apply -var-file=basic.tfvars
Se te pedirá que aceptes las acciones descritas, según la configuración establecida. Ingresa "yes" para comenzar la implementación. También puedes ver la configuración que se implementará ejecutando "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
La operación puede tardar unos minutos en completarse, así que ten paciencia.
Una vez que se complete la implementación, verás un resultado similar al siguiente:
Apply complete! Resources: 8 added, 0 changed, 0 destroyed.
Outputs:
controller_network_ips = [
[
"10.0.0.2",
],
]
login_network_ips = [
[
"10.0.0.3",
],
]
Verifica la creación de la instancia de VM
Abre el menú de navegación y selecciona Compute Engine > Instancias de VM.
Deberías ver un controlador y una instancia de VM de acceso en la lista:
En Instancias de VM, revisa las dos instancias de máquinas virtuales que creó Terraform.
Los nombres serán diferentes si modificaste el campo cluster_name.
- g1-controller
- g1-login0
5. Accede al clúster de Slurm
Accede al clúster de Slurm
Regresa a la pestaña del editor de código o de Cloud Shell. Ejecuta el siguiente comando para acceder a tu instancia y reemplaza <ZONE> por la zona del nodo g1-login0 (debe ser us-central1-b):
gcloud compute ssh g1-login0 --zone=<ZONE>
Este comando te permitirá acceder a la máquina virtual g1-login0.
Otro método para acceder fácilmente al nodo de acceso es hacer clic en el botón "SSH" junto a la VM g1-login0 en la página Instancias de VM para abrir una pestaña nueva con una conexión SSH.
Si es la primera vez que usas Cloud Shell, es posible que veas un mensaje como el siguiente en el que se te solicita que crees una clave 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 es así, ingresa Y. Si se te solicita que selecciones una frase de contraseña, presiona Intro dos veces para dejarla en blanco.
Si aparece el siguiente mensaje cuando accedes:
*** Slurm is currently being configured in the background. *** A terminal broadcast will announce when installation and configuration is complete.
Espera y no continúes con el lab hasta que veas este mensaje (aproximadamente 5 minutos):
*** Slurm login setup complete ***
Una vez que veas el mensaje anterior, deberás salir de g1-login0 y volver a acceder para continuar con el lab. Para ello, presiona CTRL + C para finalizar la tarea.
Luego, ejecuta el siguiente comando para salir de tu instancia:
exit
Ahora, vuelve a conectarte a tu VM de acceso. Ejecuta el siguiente comando para acceder a tu instancia y reemplaza <ZONE> por la zona del nodo g1-login0:
gcloud compute ssh g1-login0 --zone=<ZONE>
Al igual que antes, es posible que debas esperar uno o dos minutos antes de poder conectarte y completar todos los aspectos de la configuración.
Visita guiada por las herramientas de la CLI de Slurm
Ahora accediste al nodo de acceso de Slurm de tu clúster. Este es el nodo dedicado a la interacción del usuario o administrador, la programación de trabajos de Slurm y la actividad administrativa.
Ejecutemos algunos comandos para presentarte la línea de comandos de Slurm.
Ejecuta el comando sinfo para ver el estado de los recursos de nuestro clúster:
sinfo
A continuación, se muestra un ejemplo del resultado de sinfo. sinfo informa los nodos disponibles en el clúster, el estado de esos nodos y otra información, como la partición, la disponibilidad y cualquier limitación de tiempo impuesta en esos nodos.
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Puedes ver que nuestros 10 nodos, determinados por el "max_node_count" de 10 de la partición de depuración, están marcados como "idle~" (el nodo está en un modo inactivo y no asignado, listo para activarse).
A continuación, ejecuta el comando squeue para ver el estado de la cola de nuestro clúster:
squeue
A continuación, se muestra el resultado esperado de squeue. squeue informa el estado de la cola de un clúster. Esto incluye el ID de cada trabajo programado en el clúster, la partición a la que se asigna el trabajo, el nombre del trabajo, el usuario que lo inició, el estado del trabajo, el tiempo de reloj de pared que se ha ejecutado el trabajo y los nodos a los que se asigna el trabajo. No hay trabajos en ejecución, por lo que el contenido de este comando está vacío.
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
Los comandos de Slurm "srun" y "sbatch" se usan para ejecutar trabajos que se colocan en la cola. "srun" ejecuta trabajos paralelos y se puede usar como wrapper para mpirun. "sbatch" se usa para enviar un trabajo por lotes a Slurm y puede llamar a srun una o muchas veces en diferentes configuraciones. "sbatch" puede tomar secuencias de comandos por lotes o usarse con la opción –wrap para ejecutar todo el trabajo desde la línea de comandos.
Ejecutemos un trabajo para ver Slurm en acción y agregar un trabajo a nuestra cola.
6. Ejecuta un trabajo de Slurm y ajusta la escala del clúster
Ejecuta un trabajo de Slurm y ajusta la escala del clúster
Ahora que nuestro clúster de Slurm está en funcionamiento, ejecutemos un trabajo y escalemos nuestro clúster.
El comando "sbatch" se usa para ejecutar comandos y secuencias de comandos por lotes de Slurm. Ejecutemos una secuencia de comandos sbatch simple que ejecute "hostname" en nuestras VMs con ajuste de escala automático.
Mientras accedes a g1-login0, ejecuta el siguiente comando:
sbatch -N2 --wrap="srun hostname"
Este comando ejecuta el comando por lotes de Slurm. Especifica que sbatch ejecutará 2 nodos con la opción "-N". También especifica que cada uno de esos nodos ejecutará un comando "srun hostname" en la opción "–wrap".
De forma predeterminada, sbatch escribirá su salida en "slurm-%j.out" en el directorio de trabajo desde el que se ejecuta el comando, donde %j se sustituye por el ID del trabajo según los patrones de nombres de archivos de Slurm. En nuestro ejemplo, sbatch se ejecuta desde la carpeta /home del usuario, que es un sistema de archivos compartido basado en NFS alojado en el controlador de forma predeterminada. Esto permite que los nodos de procesamiento compartan datos de entrada y salida si lo desean. En un entorno de producción, el almacenamiento de trabajo debe estar separado del almacenamiento de /home para evitar que las operaciones del clúster se vean afectadas por el rendimiento. Se pueden especificar diferentes puntos de montaje de almacenamiento en el archivo tfvars en las opciones de "network_storage".
Después de ejecutar la secuencia de comandos sbatch con la línea de comandos sbatch, se mostrará un ID de trabajo para el trabajo programado, por ejemplo:
Submitted batch job 2
Podemos usar el ID de trabajo que devuelve el comando sbatch para hacer un seguimiento de la ejecución y los recursos del trabajo, y administrarlos. Ejecuta el siguiente comando para ver la cola de trabajos de Slurm:
squeue
Es probable que veas el trabajo que ejecutaste en la lista, como se muestra a continuación:
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]
Como no aprovisionamos ningún nodo de procesamiento, Slurm creará automáticamente instancias de procesamiento según los requisitos del trabajo. La naturaleza automática de este proceso tiene dos beneficios. En primer lugar, elimina el trabajo que suele requerirse en un clúster de HPC para aprovisionar nodos de forma manual, configurar el software, integrar el nodo en el clúster y, luego, implementar el trabajo. En segundo lugar, permite que los usuarios ahorren dinero, ya que los nodos inactivos y sin usar se reducen hasta que se ejecuta la cantidad mínima de nodos.
Puedes ejecutar el comando sinfo para ver el clúster de Slurm en funcionamiento:
sinfo
Esto mostrará los nodos que aparecen en squeue en el estado "alloc#", lo que significa que se están asignando los nodos:
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]
También puedes consultar la sección de instancias de VM en la consola de Google Cloud para ver los nodos aprovisionados recientemente. Los nodos tardarán unos minutos en iniciarse y en ejecutar Slurm antes de que el trabajo se asigne a los nodos recién asignados. Pronto, tu lista de instancias de VM se verá de la siguiente manera:
Una vez que los nodos ejecuten el trabajo, las instancias pasarán a un estado "alloc", lo que significa que los trabajos se asignan a un trabajo:
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]
Una vez que se complete un trabajo, ya no aparecerá en squeue, y los nodos "alloc" en sinfo volverán al estado "idle". Ejecuta "squeue" de forma periódica hasta que se complete el trabajo, después de uno o dos minutos.
El archivo de salida slurm-%j.out se habrá escrito en tu carpeta /home compartida por NFS y contendrá los nombres de host. Abre o muestra el archivo de salida (por lo general, slurm-2.out). Su contenido incluirá lo siguiente:
g1-compute-0-0 g1-compute-0-1
¡Excelente trabajo! Ejecutaste un trabajo y aumentaste la escala de tu clúster de Slurm.
7. Ejecuta un trabajo de MPI
Ahora, ejecutemos un trabajo de MPI en nuestros nodos. Mientras accedes a g1-login0, usa wget para descargar un programa de MPI escrito en el lenguaje de programación C:
wget https://raw.githubusercontent.com/mpitutorial/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c
Para usar las herramientas de OpenMPI, debes cargar los módulos de OpenMPI ejecutando este comando:
module load openmpi
Usaremos la herramienta "mpicc" para compilar el código C de MPI. Ejecuta el siguiente comando:
mpicc mpi_hello_world.c -o mpi_hello_world
Esto compila nuestro código C en código máquina para que podamos ejecutar el código en nuestro clúster a través de Slurm.
A continuación, usa tu editor de texto preferido para crear un script de sbatch llamado "helloworld_batch":
vi helloworld_batch
Escribe i para ingresar al modo de inserción de vi.
Copia y pega el siguiente texto en el archivo para crear una secuencia de comandos sbatch simple:
#!/bin/bash # #SBATCH --job-name=hello_world #SBATCH --output=hello_world-%j.out # #SBATCH --nodes=2 srun mpi_hello_world
Para guardar y salir del editor de código, presiona Escape y escribe ":wq" sin comillas.
Este script define el entorno y las tareas de ejecución por lotes de Slurm. Primero, el entorno de ejecución se define como bash. A continuación, el script define primero las opciones de Slurm con las líneas "#SBATCH". El nombre del trabajo se define como "hello_world".
El archivo de salida se establece como "hello_world_%j.out", donde %j se sustituye por el ID del trabajo según los patrones de nombres de archivo de Slurm. Este archivo de salida se escribe en el directorio desde el que se ejecuta la secuencia de comandos sbatch. En nuestro ejemplo, esta es la carpeta /home del usuario, que es un sistema de archivos compartido basado en NFS. Esto permite que los nodos de procesamiento compartan datos de entrada y salida si lo desean. En un entorno de producción, el almacenamiento de trabajo debe estar separado del almacenamiento de /home para evitar que las operaciones del clúster se vean afectadas por el rendimiento.
Por último, la cantidad de nodos en los que se debe ejecutar este script se define como 2.
Después de definir las opciones, se proporcionan los comandos ejecutables. Esta secuencia de comandos ejecutará el código mpi_hello_world de forma paralela con el comando srun, que es un reemplazo directo del comando mpirun.
Luego, ejecuta la secuencia de comandos sbatch con la línea de comandos sbatch:
sbatch helloworld_batch
Cuando ejecutes sbatch, se mostrará un ID de trabajo para el trabajo programado, por ejemplo:
Submitted batch job 3
Esto ejecutará el comando hostname en 2 nodos, con una tarea por nodo, y también imprimirá el resultado en el archivo hello_world-3.out.
Como ya teníamos 2 nodos aprovisionados, este trabajo se ejecutará rápidamente.
Supervisa squeue hasta que el trabajo se complete y ya no aparezca en la lista:
squeue
Una vez que se complete, abre o muestra el contenido del archivo hello_world-3.out y confirma que se ejecutó en 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
Después de estar inactivos durante 5 minutos (se puede configurar con el campo suspend_time del archivo YAML o el campo SuspendTime de slurm.conf), los nodos de procesamiento aprovisionados de forma dinámica se desasignarán para liberar recursos. Para validar esto, ejecuta sinfo periódicamente y observa cómo el tamaño del clúster vuelve a 0:
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Intenta iniciar más instancias, hasta la cuota permitida en la región en la que implementaste el clúster, y ejecuta diferentes aplicaciones de MPI.
8. Conclusión
¡Felicitaciones! Creaste un clúster de Slurm en Google Cloud y usaste sus funciones más recientes para ajustar automáticamente la escala del clúster y satisfacer la demanda de la carga de trabajo. Puedes usar este modelo para ejecutar cualquier variedad de trabajos, y se ajusta a cientos de instancias en minutos con solo solicitar los nodos en Slurm.
Si quieres seguir aprendiendo a usar Slurm en GCP, asegúrate de continuar con el codelab "Compila clústeres federados de HPC con Slurm". En este codelab, se te guiará para configurar dos clústeres federados de Slurm en la nube, lo que representa cómo podrías lograr una federación de varios clústeres, ya sea de forma local o en la nube.
¿Estás creando algo genial con la nueva funcionalidad nativa de GCP de Slurm? ¿Tienes alguna pregunta? ¿Tienes alguna sugerencia de función? Comunícate hoy mismo con el equipo de Google Cloud a través del sitio web de las soluciones de computación de alto rendimiento de Google Cloud o chatea con nosotros en el grupo de debate de Google Cloud y Slurm.
Limpia la implementación de Terraform
Sal del nodo de Slurm:
exit
Permite que se reduzca la escala de los nodos con ajuste de escala automático antes de borrar la implementación. También puedes borrar estos nodos de forma manual ejecutando "gcloud compute instances delete <Instance Name>" para cada instancia o usando la GUI de la consola para seleccionar varios nodos y hacer clic en "Borrar".
Cuando termines, puedes limpiar fácilmente la implementación de Terraform ejecutando el siguiente comando desde Google Cloud Shell después de salir de g1-login0:
cd ~/slurm-gcp/tf/examples/basic terraform destroy -var-file=basic.tfvars
Cuando se le solicite, escriba yes para continuar. Esta operación puede tardar varios minutos. Ten paciencia.
Borra el proyecto
Para limpiar, simplemente borraremos nuestro proyecto.
- En el menú de navegación, selecciona IAM y administración.
- Luego, haz clic en Configuración en el submenú.
- Haz clic en el ícono de la papelera con el texto "Borrar proyecto".
- Sigue las instrucciones de las indicaciones
Temas abordados
- Cómo implementar Slurm en GCP con Terraform
- Cómo ejecutar un trabajo con Slurm en GCP
- Cómo consultar la información del clúster y supervisar los trabajos en ejecución en Slurm
- Cómo ajustar la escala de manera automática de los nodos con Slurm en GCP para adaptarse a los parámetros y los requisitos específicos del trabajo
- Cómo compilar y ejecutar aplicaciones de MPI en Slurm en GCP
Cómo encontrar asistencia para Slurm
Si necesitas asistencia para usar estas integraciones en entornos de prueba o producción, comunícate directamente con SchedMD a través de su página de contacto aquí: https://www.schedmd.com/contact.php
También puedes usar las guías de solución de problemas disponibles:
- Guía de solución de problemas de Slurm en GCP: https://github.com/SchedMD/slurm-gcp#troubleshooting
- Guía de solución de problemas de SchedMD: https://slurm.schedmd.com/troubleshoot.html
Por último, también puedes publicar tu pregunta en el grupo de debate de Google Cloud y Slurm que se encuentra aquí: https://groups.google.com/g/google-cloud-slurm-discuss
Más información
Comentarios
Envía tus comentarios sobre este codelab a través de este vínculo. Completar los comentarios lleva menos de 5 minutos. ¡Gracias!