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, comprenderás por completo 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 de tu clúster existente de forma dinámica cuando necesitas recursos adicionales. Los expertos de SchedMD desarrollaron esta integración de acuerdo con las prácticas recomendadas de Slurm.
Si tienes pensado usar las integraciones de Slurm en Google Cloud Platform o si tienes alguna pregunta, recomendamos que te unas a las capacitaciones de Google Cloud & ¡Grupo de discusión de la comunidad de Slurm!
Acerca de Slurm
Diagrama básico de la arquitectura de un clúster de Slurm independiente en Google Cloud Platform.
Slurm es uno de los principales administradores de cargas de trabajo de clústeres de HPC de 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 pequeños y grandes. Slurm no requiere modificaciones en el kernel para su operación y es relativamente independiente. 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 tiempo para que puedan realizar el trabajo.
- Proporciona un framework para iniciar, ejecutar y supervisar el trabajo (normalmente, un trabajo paralelo) en el conjunto de nodos asignados.
- arbitra la contención de recursos administrando una cola de trabajo pendiente.
Qué aprenderás
- Cómo configurar un clúster de Slurm con Terraform
- Cómo ejecutar un trabajo con SLURM
- Cómo consultar información de clústeres y supervisar los trabajos en ejecución en SLURM
- Cómo realizar un ajuste de escala automático de los nodos para adaptarse a parámetros y requisitos específicos del trabajo
- Dónde encontrar ayuda con Slurm
Requisitos previos
- Cuenta de Google Cloud Platform y un proyecto con facturación
- Experiencia básica de 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 la consola de Google Cloud ( console.cloud.google.com) y abre la página Administrar recursos:
Haz clic en Crear proyecto.
Ingresa un nombre de 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 del proyecto aleatorio según el nombre del proyecto.
A continuación, deberás habilitar la facturación en Developers Console para usar los recursos de Google Cloud.
La ejecución de este codelab no debería costar más que unos pocos dólares, pero podría ser más si decides usar más recursos o si los dejas ejecutándose (consulta la sección “Conclusión” al final de este documento). La calculadora de precios de Google Cloud Platform está disponible aquí.
Los usuarios nuevos de Google Cloud son aptos para una prueba gratuita de$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 mejora considerablemente el rendimiento de la red y simplifica la autenticación. Gran parte de tu trabajo en este lab, si no todo, se puede hacer simplemente con un navegador web o una Google Chromebook.
Una vez conectado a Cloud Shell, deberías ver que ya estás autenticado y que el proyecto ya está configurado 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 Platform:
git clone https://github.com/SchedMD/slurm-gcp.git
Para cambiar al directorio de configuración de la implementación de Slurm, ejecuta el siguiente comando:
cd slurm-gcp
Configura tfvars de Terraform para Slurm
El archivo básico.tfvars.example detalla la configuración de la implementación, incluida la red, las instancias y el almacenamiento que se implementará. Cópialo en un archivo nuevo, al que llamaremos “el archivo tfvars”, y 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 la consola de Cloud 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 el project. Todas las demás configuraciones del ejemplo se pueden usar tal cual, 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: Es el ID del proyecto de Google Cloud en el que se implementarán los recursos.
- zone: Es la zona de Google Cloud que contendrá las instancias de acceso y controlador 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: La subred de la 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: ¿Quieres asignar una IP externa al controlador de Slurm?
- disable_login_public_ips: ¿Quieres asignar una IP externa al nodo de acceso de Slurm?
- disable_compute_login_ips: ¿Quieres asignar una IP externa al nodo de acceso de Slurm?
- suspend_time: Es el tiempo que se debe esperar luego de que un nodo esté inactivo antes de suspenderlo.
- controller_machine_type: Nodo controlador tipo de instancia
- controller_image: Es la imagen de GCP que se usa para crear la instancia de controlador de Slurm.
- controller_disk_type: Tipo del disco de arranque de la instancia del controlador
- controller_disk_size_gb: Es el tamaño del disco de arranque de la instancia del controlador.
- controller_labels: Son las etiquetas que se adjuntarán a la instancia del controlador.
- controller_service_account: Cuenta de servicio que se usará en la instancia del controlador
- controller_scopes: Permiso de acceso de la instancia del controlador
- cloudsql: Es un servidor de Google Cloud SQL para 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 Cloud SQL
- password: Contraseña de Cloud SQL
- db_name: Nombre de la base de datos de Cloud SQL
- controller_secondary_disk: ¿Quieres agregar un disco secundario para el almacenamiento del servidor NFS?
- controller_secondary_disk_type: Es el tipo del disco secundario del controlador.
- controller_secondary_disk_size_gb: Es el 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. Cualquier campo de procesamiento que se especifique anulará las propiedades de la plantilla. P. ej., si se especifica Controller_image, este reemplazará la imagen en la plantilla de instancias.
- login_machine_type: Tipo de instancia del nodo de acceso (con acceso SSH)
- login_image: Es la 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: Son las etiquetas que se adjuntarán a la instancia de acceso.
- 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. Cualquier campo de procesamiento que se especifique anulará las propiedades de la plantilla. P. ej., si se especifica login_image, reemplazará la imagen en la plantilla de instancias.
- network_storage: Almacenamiento en red para activar en todos los nodos. Los campos se agregarán directamente a fstab. Se puede repetir para montajes adicionales.
- server_ip: IP del servidor de almacenamiento
- remote_mount: Nombre de 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 y GCSFuse instalados automáticamente)
- mount_options: Activar opciones (es decir, valores predeterminados,_netdev)
- login_network_storage: Almacenamiento en red para activar en los nodos de acceso y de controlador. NFS, CIFS, Lustre y GCSFuse se instalarán automáticamente. Se puede repetir para montajes adicionales.
- server_ip: IP del servidor de almacenamiento
- remote_mount: Nombre de 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 y GCSFuse instalados automáticamente)
- mount_options: Activar opciones (es decir, valores predeterminados,_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: 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: Número de nodos de procesamiento siempre activos
- max_node_count: Cantidad máxima permitida de nodos de procesamiento; máximo de 64,000
- zone: Zona de Google Cloud que contendrá los recursos de esta partición - Más información
- image: Tipo de máquina de nodo de imagen de procesamiento
- image_hyperthreads: Activar o desactivar hipersubprocesos en la instancia
- compute_disk_type: Tipo de disco de arranque de instancia de procesamiento (pd-standard, pd-ssd)
- compute_disk_size_gb: Tamaño del disco de arranque de una 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: La cantidad de GPU para conectar a cada instancia en la partición
- gpu_type: Tipo de GPU para adjuntar a las instancias de la partición
- network_storage: Es el almacenamiento en red que se activará en todos los nodos de procesamiento de la partición. Los campos se agregarán directamente a fstab. Se puede repetir para montajes adicionales.
- server_ip: IP del servidor de almacenamiento
- remote_mount: Nombre de 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 y GCSFuse instalados 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
- exclusivo: Habilita Slurm para asignar nodos completos a trabajos.
- enable_placement: Habilita las políticas de posición en las que las instancias se ubicarán cerca para obtener una latencia de red baja entre las instancias.
- regional_capacity: Permite que se coloque una instancia en cualquier zona de la región según la disponibilidad.
- regional_policy: Si el valor de regional_capacity es verdadero, esta política determina qué región usar y qué zonas de esa región no se deben usar.
- Instance_template: la plantilla de instancias de GCP que se usará para las instancias de procesamiento. Cualquier campo de procesamiento que se especifique anulará las propiedades de la plantilla. P. ej., Si se especifica la imagen, reemplazará 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 descritas en nuestra sección “Instala apps en un clúster de Slurm en Compute Engine” o personalizando la imagen implementada por 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 su propia imagen, compile una imagen con su configuración basada en la imagen de VM de SchedMD pública que aparece en el archivo tfvars. A continuación, reemplaza el URI de imagen especificado en el archivo tfvars por tu propia imagen y prueba el cambio.
Soluciona 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 son errores cometidos 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 del crédito gratuito de $300 que recibe un usuario nuevo. Si un intento de crear VMs falla, verifica 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 que hayas establecido. 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.
Cuando la implementación se haya completado, 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 instancias 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áquina virtual 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 Editor de código o Cloud Shell. Ejecuta el siguiente comando para acceder a la instancia y reemplaza <ZONE> por la zona del nodo g1-login0 (debe ser us-central1-b):
gcloud compute ssh g1-login0 --zone=<ZONE>
Con este comando, accederás 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 que se muestra a continuación, en el que se te pedirá 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 seleccionar una frase de contraseña, presiona Intro dos veces para dejarla en blanco.
Si aparece el siguiente mensaje durante el acceso:
*** 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 min):
*** Slurm login setup complete ***
Cuando veas el mensaje anterior, deberás salir y volver a acceder a g1-login0 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 en el caso anterior, es posible que debas esperar uno o dos minutos antes de poder conectarte y completar todos los aspectos de la configuración.
Recorrido por las herramientas de la CLI de Slurm
Accediste al nodo de acceso de Slurm de tu clúster. Este es el nodo dedicado a la interacción entre el usuario y el administrador, la programación de trabajos de Slurm y la actividad administrativa.
Vamos a ejecutar 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 resultado de muestra 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 a esos nodos.
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST debug* up infinite 10 idle~ g1-compute-0-[0-9]
Puedes ver nuestros 10 nodos, indicados por “max_node_count” de la partición de depuración. de 10, se marcan como "inactivo~" (el nodo está en modo inactivo y sin asignar, listo para iniciar).
Luego, ejecuta el comando squeue para ver el estado de la cola de nuestro clúster:
squeue
El resultado esperado de squeue aparece a continuación. squeue informa el estado de la cola de un clúster. Esto incluye cada ID de trabajo 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 inició el trabajo, el estado del trabajo, las horas reales durante la ejecución y los nodos a los que está asignado el trabajo. No hay ningún trabajo en ejecución, por lo que el contenido de este comando está vacío.
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
El Slurm ordena "srun" y “sbatch” se usan para ejecutar los trabajos que se ponen en la cola. “srun” ejecuta trabajos paralelos y se puede usar como wrapper de mpirun. “sbatch” se usa para enviar un trabajo por lotes a slurm y puede llamar a srun una o muchas veces en diferentes parámetros de configuración. “sbatch” puede tomar secuencias de comandos por lotes o pueden usarse con la opción –wrap para ejecutar todo el trabajo desde la línea de comandos.
Ejecutemos un trabajo para poder ver a Slurm en acción y conseguir un trabajo en nuestra cola.
6. Ejecuta un trabajo de Slurm y escala el clúster
Ejecuta un trabajo de Slurm y escala el clúster
Ahora que tenemos nuestro clúster de Slurm en ejecución, ejecutemos un trabajo y escalemos el clúster verticalmente.
La “pausa” se usa para ejecutar secuencias de comandos y comandos por lotes de Slurm. Ejecutemos una secuencia de comandos por lotes simple que ejecutará “hostname” en nuestras VMs con ajuste de escala automático.
Accede a g1-login0 y ejecuta el siguiente comando:
sbatch -N2 --wrap="srun hostname"
Este comando ejecuta el comando por lotes de Slurm. Especifica que el lote ejecutará 2 nodos con el prefijo “-N” de 12 a 1 con la nueva opción de compresión. También especifica que cada uno de esos nodos ejecutará un “nombre de host reducido” en el comando "–wrap" de 12 a 1 con la nueva opción de compresión.
De forma predeterminada, el sbatch escribirá su salida en “slurm-%j.out” En el directorio de trabajo desde el que se ejecuta el comando, en el que %j se sustituye por el ID del trabajo según los Patrones de Slurm para nombres de archivos. En nuestro ejemplo, el lote se ejecuta desde la carpeta /home del usuario, que es un sistema de archivos compartidos basado en NFS que se aloja 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 /home para evitar impactos en el rendimiento en las operaciones del clúster. Se pueden especificar activaciones de almacenamiento separadas en el archivo tfvars en el archivo “network_storage” opciones de estado.
Después de ejecutar la secuencia de comandos por lotes con la línea de comandos por lotes, se mostrará un ID de trabajo para el trabajo programado, por ejemplo:
Submitted batch job 2
Podemos usar el ID del trabajo que devuelve el comando sbatch para rastrear y administrar la ejecución del trabajo y los recursos. Ejecuta el siguiente comando para ver la cola de trabajos de Slurm:
squeue
Es probable que veas el trabajo que ejecutaste en la siguiente lista:
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 teníamos aprovisionados nodos de procesamiento, Slurm creará automáticamente instancias de procesamiento de acuerdo con los requisitos del trabajo. La naturaleza automática de este proceso tiene dos beneficios. Primero, elimina el trabajo que normalmente se requiere en un clúster de HPC de 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 porque 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 que se inicia:
sinfo
Se mostrarán los nodos que figuran en squeue en el campo "alloc#" , lo que significa que se asignan 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 Instancias de VM en la consola de Google Cloud para ver los nodos aprovisionados recientemente. Tardará unos minutos en iniciar los nodos y ejecutar Slurm antes de que se asigne el trabajo a los nodos asignados recientemente. Tu lista de instancias de VM pronto se verá de la siguiente manera:
Cuando los nodos estén ejecutando el trabajo, las instancias se moverán a una “asignación” state, 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 completa un trabajo, ya no aparece en squeue, y el estado "alloc" los nodos de sinfo volverán al estado “inactivo” para cada estado. 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 escribirá en tu carpeta /home compartida por NFS y contendrá los nombres de host. Abre o carga el archivo de salida (generalmente slurm-2.out). El contenido del archivo de salida incluirá lo siguiente:
g1-compute-0-0 g1-compute-0-1
Buen trabajo. Ejecutaste un trabajo y escalaste verticalmente tu clúster de Slurm.
7. Ejecuta un trabajo de MPI
Ahora ejecutemos un trabajo de MPI en nuestros nodos. Cuando accedas a g1-login0, usa wget para descargar un programa de la 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 utilizar las herramientas de OpenMPI, debes cargar los módulos de OpenMPI. Para ello, ejecuta el siguiente comando:
module load openmpi
Usaremos la "mpicc" para compilar el código C de la 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 una secuencia de comandos por lotes llamada "helloworld_batch":
vi helloworld_batch
Escribe i para ingresar al modo de inserción vi.
Copia y pega el siguiente texto en el archivo para crear una secuencia de comandos por lotes simple:
#!/bin/bash # #SBATCH --job-name=hello_world #SBATCH --output=hello_world-%j.out # #SBATCH --nodes=2 srun mpi_hello_world
Presiona Escape y escribe ":wq" para guardar y salir del editor de código. sin comillas.
Esta secuencia de comandos define el entorno de ejecución por lotes y las tareas de Slurm. Primero, el entorno de ejecución se define como Bash. A continuación, la secuencia de comandos define las opciones de Slurm primero con el "#SBATCH" a una línea de producción de datos. El nombre del trabajo se define como “hello_world”.
El archivo de salida está configurado como “hello_world_%j.out” donde %j se sustituye por el ID de trabajo según los Patrones de Slurm para nombres de archivos. Este archivo de salida se escribe en el directorio desde el que se ejecuta la secuencia de comandos por lotes. En nuestro ejemplo, esta es la carpeta /home del usuario, que es un sistema de archivos compartidos 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 /home para evitar impactos en el rendimiento en las operaciones del clúster.
Por último, la cantidad de nodos en la que esta secuencia de comandos debería ejecutarse 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 manera paralela con el comando srun, que es un reemplazo directo del comando mpirun.
Luego, ejecuta la secuencia de comandos por lotes mediante la línea de comandos:
sbatch helloworld_batch
La ejecución del sbatch 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, además de 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
Cuando termines, abre el 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 permanecer inactivos durante 5 minutos (configurable con el campo suspend_time de YAML o el campo SuspendTime de slurm.conf), los nodos de procesamiento aprovisionados dinámicamente se desasignarán para liberar recursos. Para validar esto, ejecuta sinfo periódicamente y observa que 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 la MPI.
8. Conclusión
¡Felicitaciones! Creaste un clúster de Slurm en Google Cloud Platform y utilizaste sus funciones más recientes para realizar un ajuste de escala automático en tu clúster a fin de satisfacer la demanda de cargas de trabajo. Puedes usar este modelo para ejecutar cualquier variedad de trabajos y escala a cientos de instancias en minutos con tan solo solicitar los nodos en Slurm.
Si deseas seguir aprendiendo a usar Slurm en GCP, asegúrate de continuar con el " Building Federated HPC Clusters with Slurm" en este codelab. En este codelab, te ayudaremos a configurar dos clústeres de Slurm federados en la nube para representar 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 una sugerencia sobre funciones? Comunícate con el equipo de Google Cloud hoy mismo a través del sitio web de soluciones de computación de alto rendimiento de Google Cloud o chatea con nosotros en el sitio web de Google Cloud y Grupo de discusión de Slurm
Limpia el Deployment de Terraform
Cierra la sesión del nodo de slurm:
exit
Permite que cualquier nodo con ajuste de escala automático reduzca la escala verticalmente 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 usa la GUI de la consola para seleccionar varios nodos y haz clic en “Borrar”.
Puedes limpiar con facilidad la implementación de Terraform luego de terminar 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 realizar la limpieza, simplemente borramos nuestro proyecto.
- En el menú de navegación, selecciona IAM y Administrador
- Luego, haz clic en Configuración en el submenú
- Haz clic en el ícono de la papelera con el texto “Delete Project”.
- Sigue las instrucciones que aparecen.
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 realizar un ajuste de escala automático de los nodos con Slurm en GCP para ajustar parámetros y requisitos específicos del trabajo.
- Cómo compilar y ejecutar aplicaciones de la MPI en Slurm en GCP
Encuentra apoyo para Slurm
Si necesitas asistencia para usar estas integraciones en entornos de pruebas o producción, comunícate directamente con SchedMD a través de su página de contacto: 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 Centro de ayuda El grupo de discusión de Slurm se encuentra aquí: https://groups.google.com/g/google-cloud-slurm-discuss
Más información
Comentarios
Envía comentarios sobre este codelab a través de este vínculo. Tardarás menos de 5 minutos en enviar los comentarios. ¡Gracias!