Guía de Slurm para el modo de cola múltiple

Aquí puede aprender cómo AWS ParallelCluster Slurm administrar los nodos de cola (partición) y cómo monitorear los estados de las colas y los nodos.

Información general

La arquitectura de escalado se basa en la Guía de programación en la nube de Slurm y en el complemento de ahorro de energía. Para obtener más información sobre el complemento de ahorro de energía, consulte la Guía de ahorro de energía de Slurm. En la arquitectura, los recursos que podrían estar disponibles para un clúster suelen estar predefinidos en la configuración de Slurm como nodos de la nube.

Ciclo de vida de los nodos de la nube

A lo largo de su ciclo de vida, los nodos de la nube entran en varios de los siguientes estados (o en todos): POWER_SAVING, POWER_UP (pow_up), ALLOCATED (alloc) y POWER_DOWN (pow_dn). En algunos casos, un nodo de la nube puede entrar en el estado OFFLINE. La siguiente lista detalla varios aspectos de estos estados en el ciclo de vida de los nodos de la nube.

• Un nodo en un estado POWER_SAVING aparece con un sufijo ~ (por ejemplo idle~) en sinfo. En este estado, ninguna instancia de EC2 respalda al nodo. Sin embargo, Slurm sí puede asignar trabajos al nodo.

• Un nodo en transición a un estado POWER_UP aparece con un sufijo # (por ejemplo idle#) en sinfo. Un nodo pasa automáticamente a un estado POWER_UP cuando Slurm asigna un trabajo a un nodo en estado POWER_SAVING.

  Como alternativa, puede pasar manualmente los nodos al estado POWER_UP como usuario raíz de su con el comando:

  $ scontrol update nodename=nodename state=power_up

  En esta etapa, se invoca a ResumeProgram, se lanzan y configuran las instancias de EC2 y el nodo pasa al estado POWER_UP.

• Un nodo que está actualmente disponible para su uso aparece sin sufijo (por ejemplo idle) en sinfo. Una vez que el nodo se haya configurado y se haya unido al clúster, estará disponible para ejecutar trabajos. En esta etapa, el nodo está correctamente configurado y listo para su uso.

  Como regla general, se recomienda que el número de instancias de EC2 sea el mismo que el número de nodos disponibles. En la mayoría de los casos, los nodos estáticos están disponibles una vez creado el clúster.

• Un nodo que está en transición a un estado POWER_DOWN aparece con un sufijo % (por ejemplo idle%) en sinfo. Los nodos dinámicos entran automáticamente en el estado POWER_DOWN después de ScaledownIdletime. Por el contrario, los nodos estáticos no están apagados en la mayoría de los casos. Sin embargo, como usuario raíz de POWER_DOWN, puede colocar los nodos en el estado su manualmente con el comando:

  $ scontrol update nodename=nodename state=down reason="manual draining"

  En este estado, se finalizan las instancias asociadas a un nodo, y el nodo vuelve a ese estado POWER_SAVING y está disponible para su uso después de ScaledownIdletime.

  El ajuste ScaledownIdletime se guarda en el ajuste SuspendTimeout de la configuración de Slurm.

• Un nodo que esté desconectado aparece con un sufijo * (por ejemplo down*) en sinfo. Un nodo se desconecta si el controlador de Slurm no puede contactar con el nodo o si los nodos estáticos están deshabilitados y las instancias de respaldo se finalizan.

Observe los estados de nodo que se muestran en el siguiente ejemplo de sinfo.

$ sinfo
  PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
  efa          up   infinite      4  idle~ efa-dy-efacompute1-[1-4]
  efa          up   infinite      1   idle efa-st-efacompute1-1
  gpu          up   infinite      1  idle% gpu-dy-gpucompute1-1
  gpu          up   infinite      9  idle~ gpu-dy-gpucompute1-[2-10]
  ondemand     up   infinite      2   mix# ondemand-dy-ondemandcompute1-[1-2]
  ondemand     up   infinite     18  idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10]
  spot*        up   infinite     13  idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
  spot*        up   infinite      2   idle spot-st-spotcompute2-[1-2]

Los nodos spot-st-spotcompute2-[1-2] y efa-st-efacompute1-1 ya tienen instancias de respaldo configuradas y están disponibles para su uso. Los nodos ondemand-dy-ondemandcompute1-[1-2] se encuentran en el estado POWER_UP y deberían estar disponibles en unos minutos. El nodo gpu-dy-gpucompute1-1 se encuentra en el estado POWER_DOWN y pasa al estado POWER_SAVING después de ScaledownIdletime (el valor predeterminado es 10 minutos).

Todos los demás nodos se encuentran en el estado POWER_SAVING y no tienen instancias de EC2 que los respalden.

Trabajo con un nodo disponible

Un nodo disponible está respaldado por una instancia de EC2. De forma predeterminada, el nombre del nodo se puede usar para acceder directamente a la instancia mediante SSH (por ejemplo ssh efa-st-efacompute1-1). La dirección IP privada de la instancia se puede recuperar con el comando:

$ scontrol show nodes nodename

Compruebe la dirección IP en el campo NodeAddr devuelto.

En el caso de los nodos que no estén disponibles, el campo NodeAddr no debe apuntar a una instancia de EC2 en ejecución. Más bien, debe ser el mismo que el nombre del nodo.

Estados y envío de los trabajos

En la mayoría de los casos, los trabajos enviados se asignan inmediatamente a los nodos del sistema o se dejan pendientes si se asignan todos los nodos.

Si los nodos asignados a un trabajo incluyen algún nodo en un estado POWER_SAVING, el trabajo comienza con un estado CF o CONFIGURING. En este momento, el trabajo espera a que los nodos del estado POWER_SAVING pasen al estado POWER_UP y estén disponibles.

Una vez que todos los nodos asignados a un trabajo estén disponibles, el trabajo pasa al estado RUNNING (R).

De forma predeterminada, se envían todos los trabajos a la cola predeterminada (conocida como partición en Slurm). Esto se indica con un sufijo * después del nombre de la cola. Puede seleccionar una cola mediante la opción de envío de trabajos -p.

Todos los nodos están configurados con las siguientes características, que se pueden utilizar en los comandos de envío de trabajos:

• Un tipo de instancia (por ejemplo c5.xlarge)

• Un tipo de nodo (puede ser dynamic o static)

Puede ver las características de un nodo en particular mediante el comando:

$ scontrol show nodes nodename

En la devolución, consulte la lista AvailableFeatures.

Tenga en cuenta el estado inicial del clúster, que puede ver ejecutando el comando sinfo.

$ sinfo
  PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
  efa          up   infinite      4  idle~ efa-dy-efacompute1-[1-4]
  efa          up   infinite      1   idle efa-st-efacompute1-1
  gpu          up   infinite     10  idle~ gpu-dy-gpucompute1-[1-10]
  ondemand     up   infinite     20  idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10]
  spot*        up   infinite     13  idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
  spot*        up   infinite      2   idle spot-st-spotcompute2-[1-2]

Tenga en cuenta que la cola predeterminada es spot. Se indica mediante el sufijo *.

Envíe un trabajo a un nodo estático de la cola predeterminada (spot).

$ sbatch --wrap "sleep 300" -N 1 -C static

Envíe un trabajo a un nodo dinámico de la cola EFA.

$ sbatch --wrap "sleep 300" -p efa -C dynamic

Envíe un trabajo a ocho (8) nodos c5.2xlarge y dos (2) nodos t2.xlarge de la cola ondemand.

$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"

Envíe un trabajo a un nodo de GPU de la cola gpu.

$ sbatch --wrap "sleep 300" -p gpu -G 1

Tenga en cuenta el estado de los trabajos mediante el comando squeue.

$ squeue
 JOBID PARTITION    NAME   USER   ST       TIME  NODES NODELIST(REASON)
  12   ondemand     wrap   ubuntu CF       0:36     10 ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
  13        gpu     wrap   ubuntu CF       0:05      1 gpu-dy-gpucompute1-1
   7       spot     wrap   ubuntu  R       2:48      1 spot-st-spotcompute2-1
   8        efa     wrap   ubuntu  R       0:39      1 efa-dy-efacompute1-1

Los trabajos 7 y 8 (en las colas spot y efa) ya se están ejecutando (R). Los trabajos 12 y 13 aún se están configurando (CF), probablemente esperando a que las instancias estén disponibles.

# Nodes states corresponds to state of running jobs
$ sinfo
 PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
 efa          up   infinite      3  idle~ efa-dy-efacompute1-[2-4]
 efa          up   infinite      1    mix efa-dy-efacompute1-1
 efa          up   infinite      1   idle efa-st-efacompute1-1
 gpu          up   infinite      1   mix~ gpu-dy-gpucompute1-1
 gpu          up   infinite      9  idle~ gpu-dy-gpucompute1-[2-10]
 ondemand     up   infinite     10   mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
 ondemand     up   infinite     10  idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10]
 spot*        up   infinite     13  idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
 spot*        up   infinite      1    mix spot-st-spotcompute2-1
 spot*        up   infinite      1   idle spot-st-spotcompute2-2 

Estado y características de los nodos

En la mayoría de los casos, los estados de los nodos se administran completamente de AWS ParallelCluster acuerdo con los procesos específicos del ciclo de vida de los nodos de la nube descritos anteriormente en este tema.

Sin embargo, AWS ParallelCluster también reemplaza o termina los nodos en mal estado y los DRAINED estados DOWN y nodos que tienen instancias de respaldo en mal estado. Para obtener más información, consulte clustermgtd.

Estados de partición

AWS ParallelCluster admite los siguientes estados de partición. Una partición de Slurm es una cola en AWS ParallelCluster.

• UP: indica que la partición se encuentra en estado activo. Es el valor predeterminado de una partición. En este estado, todos los nodos de la partición están activos y disponibles para su uso.

• INACTIVE: indica que la partición se encuentra en estado inactivo. En este estado, se finalizan todas las instancias que respaldan a los nodos de una partición inactiva. No se lanzan nuevas instancias para los nodos de una partición inactiva.

clúster update-compute-fleet

• Detener la flota de procesamiento: cuando se ejecuta el siguiente comando, todas las particiones pasan al INACTIVE estado y AWS ParallelCluster los procesos mantienen las particiones en ese INACTIVE estado.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status STOP_REQUESTED

• Inicio de la flota de computación: cuando se ejecuta el siguiente comando, todas las particiones pasan inicialmente al estado UP. Sin embargo, AWS ParallelCluster los procesos no mantienen la partición en un UP estado. Debe cambiar los estados de las particiones manualmente. Todos los nodos estáticos están disponibles al cabo de unos minutos. Tenga en cuenta que establecer una partición en UP no activa ninguna capacidad dinámica.

  $ pcluster update-compute-fleet --cluster-name testSlurm \
     --region eu-west-1 --status START_REQUESTED

Cuando se ejecuta update-compute-fleet, puede consultar el estado del clúster ejecutando el comando pcluster describe-compute-fleet y comprobando el Status. A continuación, se indican los estados posibles:

• STOP_REQUESTED: la solicitud de detener la flota de computación se envía al clúster.

• STOPPING: el proceso de pcluster detiene actualmente la flota de computación.

• STOPPED: el proceso de pcluster ha finalizado el proceso de detención, todas las particiones están en estado INACTIVE y todas las instancias de procesamiento han finalizado.

• START_REQUESTED: la solicitud de iniciar la flota de computación se envía al clúster.

• STARTING: el proceso de pcluster está iniciando actualmente el clúster.

• RUNNING: el proceso de pcluster ha finalizado el proceso de inicio, todas las particiones están en estado UP y los nodos estáticos están disponibles después de unos minutos.

• PROTECTED: este estado indica que algunas particiones tienen errores de arranque constantes. Las particiones afectadas están inactivas. Investigue el problema y, a continuación, ejecuta update-compute-fleet para volver a activar la flota.

Control manual de las colas

En algunos casos, es posible que quiera tener un control manual sobre los nodos o la cola (lo que se conoce como partición en Slurm) de un clúster. Puede administrar los nodos de un clúster mediante los siguientes procedimientos comunes usando el comando scontrol.

• Encienda los nodos dinámicos en estado POWER_SAVING

  Ejecute el comando como usuario raíz de su:

  $ scontrol update nodename=nodename state=power_up

  También puede enviar un trabajo sleep 1 de marcador de posición solicitando un número determinado de nodos y, a continuación, confíe en que Slurm activará el número de nodos requerido.

• Apague los nodos dinámicos antes de ScaledownIdletime

  Se recomienda establecer los nodos dinámicos en DOWN como usuario raíz de su con el comando:

  $ scontrol update nodename=nodename state=down reason="manually draining"

  AWS ParallelCluster termina y restablece automáticamente los nodos dinámicos caídos.

  En general, no es recomendable establecer nodos en POWER_DOWN directamente con el comando scontrol update nodename=nodename state=power_down. Esto se debe a que AWS ParallelCluster administra automáticamente el proceso de apagado.

• Deshabilite una cola (partición) o detenga todos los nodos estáticos de una partición específica

  Establezca una cola específica en INACTIVE como usuario raíz de su con el comando:

  $ scontrol update partition=queuename state=inactive

  De este modo, se finalizan todas las instancias que respaldan a los nodos de la partición.

• Habilite una cola (partición)

  Establezca una cola específica en UP como usuario raíz de su con el comando:

  $ scontrol update partition=queuename state=up

Comportamiento y ajustes del escalado

A continuación, se muestra un ejemplo del flujo de trabajo del escalado normal:

• El programador recibe un trabajo que requiere dos nodos.

• El programador pasa dos nodos a un estado POWER_UP y llama a ResumeProgram con los nombres de los nodos (por ejemplo queue1-dy-spotcompute1-[1-2]).

• ResumeProgram lanza dos instancias de EC2 y asigna las direcciones IP privadas y los nombres de host de queue1-dy-spotcompute1-[1-2], a la espera de ResumeTimeout (el periodo predeterminado es de 30 minutos antes de restablecer los nodos).

• Las instancias se configuran y se unen al clúster. Un trabajo comienza a ejecutarse en las instancias.

• El trabajo finaliza y deja de ejecutarse.

• Una vez transcurrido el SuspendTime configurado (que está establecido en ScaledownIdletime), el programador establece las instancias en el estado POWER_SAVING. A continuación, el programador establece queue1-dy-spotcompute1-[1-2] en el estado POWER_DOWN y llama a SuspendProgram con los nombres de los nodos.

• Se llama a SuspendProgram para dos nodos. Los nodos permanecen en el estado POWER_DOWN, por ejemplo, permaneciendo idle% durante un SuspendTimeout (el periodo predeterminado es de 120 segundos, es decir, 2 minutos). Cuando clustermgtd detecta que los nodos se están apagando, finaliza las instancias de respaldo. Luego, pasa queue1-dy-spotcompute1-[1-2] al estado inactivo y restablece la dirección IP privada y el nombre de host para que estén listos para funcionar en futuros trabajos.

Si algo sale mal y no se puede lanzar una instancia para un nodo concreto por algún motivo, ocurre lo siguiente:

• El programador recibe un trabajo que requiere dos nodos.

• El programador pasa dos nodos de ampliación en la nube al estado POWER_UP y llama a ResumeProgram con los nombres de los nodos (por ejemplo queue1-dy-spotcompute1-[1-2]).

• ResumeProgram lanza solo una (1) instancia de EC2 y configura queue1-dy-spotcompute1-1, con una (1) instancia, queue1-dy-spotcompute1-2, que no se puede lanzarse.

• queue1-dy-spotcompute1-1 no se ve afectado y entra en funcionamiento después de llegar al estado POWER_UP.

• queue1-dy-spotcompute1-2 pasa al estado POWER_DOWN y el trabajo se vuelve a poner en cola automáticamente porque Slurm detecta un fallo en el nodo.

• queue1-dy-spotcompute1-2 pasa a estar disponible después de SuspendTimeout (el valor predeterminado es 120 segundos, es decir, 2 minutos). Mientras tanto, el trabajo se vuelve a poner en cola y puede empezar a ejecutarse en otro nodo.

• El proceso anterior se repite hasta que el trabajo se pueda ejecutar en un nodo disponible sin que se produzca ningún error.

Hay dos parámetros de temporización que se pueden ajustar si es necesario:

• ResumeTimeout (el valor predeterminado es 30 minutos): ResumeTimeout controla el tiempo que Slurm espera antes de que el nodo pase al estado inactivo.

  • Podría ser útil ampliar el ResumeTimeout si el proceso previo o posterior a la instalación tiene una duración similar.

  • ResumeTimeout también es el tiempo máximo que AWS ParallelCluster espera antes de reemplazar o restablecer un nodo en caso de que haya algún problema. Los nodos de cómputo se autofinalizan si se produce algún error durante el inicio o la configuración. AWS ParallelCluster los procesos sustituyen a un nodo al detectar una instancia terminada.

• SuspendTimeout (el valor predeterminado es 120 segundos, es decir, 2 minutos): SuspendTimeout controla la rapidez con la que los nodos se vuelven a colocar en el sistema y están listos para volver a usarse.

  • Un valor más bajo de SuspendTimeout significa que los nodos se restablecen más rápido y Slurm puede intentar lanzar instancias con más frecuencia.

  • Un valor más alto de SuspendTimeout significa que los nodos que han fallado se restablecen más lento. Mientras tanto, Slurm intenta usar otros nodos. Si SuspendTimeout es más de unos minutos, Slurm intenta recorrer todos los nodos del sistema. Un valor más alto de SuspendTimeout podría ser beneficioso para que los sistemas a gran escala (más de 1000 nodos) reduzcan el stress en Slurm cuando trata de volver a poner en cola los trabajos que fallan con frecuencia.

  • Ten en cuenta que SuspendTimeout esto no se refiere al tiempo de AWS ParallelCluster espera para finalizar una instancia de respaldo de un nodo. Las instancias de respaldo de los nodos POWER_DOWN finalizan inmediatamente. El proceso de finalización por lo general se completa en unos minutos. Sin embargo, durante este tiempo, el nodo permanece en el estado POWER_DOWN y no está disponible para que lo utilice el programador.

Registros para la arquitectura

La siguiente lista contiene los registros clave. El nombre del flujo de registro utilizado con Amazon CloudWatch Logs tiene el formato{hostname}.{instance_id}.{logIdentifier}, donde Logidentifier sigue a los nombres de los registros.

• ResumeProgram: /var/log/parallelcluster/slurm_resume.log (slurm_resume)

• SuspendProgram: /var/log/parallelcluster/slurm_suspend.log (slurm_suspend)

• clustermgtd: /var/log/parallelcluster/clustermgtd.log (clustermgtd)

• computemgtd: /var/log/parallelcluster/computemgtd.log (computemgtd)

• slurmctld: /var/log/slurmctld.log (slurmctld)

• slurmd: /var/log/slurmd.log (slurmd)

Problemas frecuentes y cómo depurarlos:

Nodos que no se iniciaron o encendieron o que no se unieron al clúster

• Nodos dinámicos:

  • Compruebe el registro ResumeProgram para ver si se ha llamado a ResumeProgram con el nodo. Si no es así, compruebe el registro slurmctld para determinar si Slurm intentó llamar a ResumeProgram con el nodo. Tenga en cuenta que los permisos incorrectos activados en ResumeProgram pueden provocar un error silencioso.

  • Si se llama a ResumeProgram, compruebe si se ha lanzado una instancia para el nodo. Si la instancia no se ha lanzado, debería mostrarse un mensaje de error claro que explique por qué no se ha podido lanzar la instancia.

  • Si se ha lanzado una instancia, es posible que se haya producido algún problema durante el proceso de arranque. Busque la dirección IP privada y el ID de instancia correspondientes en el ResumeProgram registro y busque los registros de arranque correspondientes a la instancia específica en Logs. CloudWatch

• Nodos estáticos:

  • Compruebe el registro clustermgtd para ver si se han lanzado instancias para el nodo. Si no se han lanzado instancias, deberían mostrarse mensajes de error claros que expliquen por qué no se han podido lanzar las instancias.

  • Si se ha lanzado una instancia, se ha producido algún problema en el proceso de arranque. Busca la IP privada y el ID de instancia correspondientes en el clustermgtd registro y busca los registros de arranque correspondientes a la instancia específica en CloudWatch Logs.

Los nodos se han sustituido o finalizado de forma inesperada y han fallado

• Nodos sustituidos o finalizados de forma inesperada:

  • En la mayoría de los casos, clustermgtd administra todas las acciones de mantenimiento de los nodos. Para comprobar si clustermgtd ha sustituido o finalizado un nodo, compruebe el registro clustermgtd.

  • Si clustermgtd sustituye o finaliza el nodo, debería mostrarse un mensaje que indique el motivo de la acción. Si el motivo está relacionado con el programador (por ejemplo, el nodo estaba DOWN), consulte el registro slurmctld para obtener más información. Si el motivo está relacionado con EC2, utilice herramientas como Amazon CloudWatch o la consola, la CLI o los SDK de AWS EC2 para comprobar el estado o los registros de esa instancia. Por ejemplo, puede comprobar si la instancia tenía eventos programados o no pasó las comprobaciones de estado de EC2.

  • Si clustermgtd no finalizó el nodo, compruebe si computemgtd lo ha hecho o si EC2 ha finalizado la instancia para recuperar una instancia de spot.

• Fallos de nodo:

  • En la mayoría de los casos, los trabajos se vuelven a poner en cola automáticamente si se produce un error en un nodo. Consulte el registro slurmctld para ver por qué ha fallado un trabajo o un nodo y evalúe la situación a partir de ahí.

Fallo al sustituir o finalizar instancias, error al apagar los nodos

• En general, clustermgtd administra todas las acciones de finalización de instancias esperadas. Consulte el registro clustermgtd para ver por qué no se ha podido sustituir o finalizar un nodo.

• En el caso de los nodos dinámicos que no superan el ScaledownIdletime, consulte el registro de SuspendProgram para ver si los procesos de slurmctld realizaron llamadas con el nodo específico como argumento. Tenga en cuenta que SuspendProgram no realiza ninguna acción específica. Más bien, solo se encarga de registrar cuando se le llama. Todas las finalizaciones y los restablecimientos de NodeAddr de las instancias los completa clustermgtd. Slurm pasa los nodos a IDLE después de SuspendTimeout.

Otros problemas:

• AWS ParallelCluster no toma decisiones de asignación de puestos ni de escalamiento. Solo intenta lanzar, finalizar y mantener los recursos de acuerdo con las instrucciones de Slurm.

  Si tiene problemas relacionados con la asignación de trabajos, la asignación de nodos y la decisión de escalado, consulte el registro slurmctld para ver si hay errores.