Slurmguía para el modo de cola múltiple

AWS ParallelClusterla versión 2.9.0 introdujo el modo de cola múltiple y una nueva arquitectura de escalado paraSlurm Workload Manager (Slurm).

En las siguientes secciones se ofrece una descripción general del uso de unSlurm clúster con la arquitectura de escalado recientemente introducida.

Información general

La nueva arquitectura de escalado se basa en la GuíaSlurm de programación en la nube 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íaSlurm de ahorro de energía. En la nueva arquitectura, los recursos que pueden estar potencialmente disponibles para un clúster suelen estar predefinidos en laSlurm configuración como nodos de nube.

Ciclo de vida del nodo en la nube

A lo largo de su ciclo de vida, los nodos de la nube entran en varios, si no todosPOWER_SAVING,POWER_UP de los siguientes estados:,ALLOCATED (alloc), () yPOWER_DOWN (pow_dn).pow_up En algunos casos, un nodo de nube puede entrar en elOFFLINE estado. La siguiente lista detalla varios aspectos de estos estados en el ciclo de vida de los nodos en la nube.

• Un nodo de unPOWER_SAVING estado aparece con un~ sufijo (por ejemploidle~) ensinfo. En este estado, no hay ninguna instancia de EC2 que respalde el nodo. Sin embargo, aúnSlurm puede asignar trabajos al nodo.

• Un nodo en transición a unPOWER_UP estado aparece con un# sufijo (por ejemploidle#) ensinfo.

• CuandoSlurm asigna un trabajo a un nodo en unPOWER_SAVING estado, el nodo se transfiere automáticamente a unPOWER_UP estado. De lo contrario, los nodos se pueden colocar en elPOWER_UP estado manualmente mediante elscontrol update nodename=nodename state=power_up comando. En esta etapa,ResumeProgram se invoca y las instancias de EC2 se lanzan y configuran para respaldar unPOWER_UP nodo.

• Un nodo que está actualmente disponible para su uso aparece sin ningún sufijo (por ejemploidle) ensinfo. Una vez que el nodo esté configurado y se haya unido al clúster, estará disponible para ejecutar trabajos. En esta etapa, el nodo está configurado correctamente y listo para su uso. Como regla general, se recomienda que el número de instancias en EC2 sea el mismo que el número de nodos disponibles. En la mayoría de los casos, los nodos estáticos siempre están disponibles después de crear el clúster.

• Un nodo que está en transición a unPOWER_DOWN estado aparece con un% sufijo (por ejemploidle%) ensinfo. Los nodos dinámicos entran automáticamente enPOWER_DOWN el estado despuésscaledown_idletime. Por el contrario, los nodos estáticos en la mayoría de los casos no están apagados. Sin embargo, los nodos se pueden colocar en elPOWER_DOWN estado manualmente mediante elscontrol update nodename=nodename state=powering_down comando. En este estado, la instancia asociada a un nodo finaliza y el nodo se restablece alPOWER_SAVING estado para usarlo en el futurescaledown_idletime. Lascaledown-idletime configuración se guarda en laSlurm configuración comoSuspendTimeout ajuste.

• Un nodo que está desconectado aparece con un* sufijo (por ejemplodown*) ensinfo. Un nodo se desconecta si elSlurm controlador no puede contactar con él o si los nodos estáticos están deshabilitados y las instancias de respaldo finalizan.

Ahora considere los estados de los nodos que se muestran en el siguientesinfo ejemplo.

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1  idle% gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite      2   mix# ondemand-dy-c52xlarge-[1-2]
ondemand     up   infinite     18  idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2]

efa-st-c5n18xlarge-1Los nodosspot-st-t2large-[1-2] y ya tienen configuradas las instancias de respaldo y están disponibles para su uso. Losondemand-dy-c52xlarge-[1-2] nodos están enPOWER_UP ese estado y deberían estar disponibles en unos minutos. Elgpu-dy-g38xlarge-1 nodo está en esePOWER_DOWN estado y pasará alPOWER_SAVING estado despuésscaledown_idletime (el valor predeterminado es de 120 segundos).

Todos los demás nodos están enPOWER_SAVING estado sin instancias de EC2 que los respalden.

Trabajando 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 mediante SSH a la instancia (por ejemplossh efa-st-c5n18xlarge-1). La dirección IP privada de la instancia se puede recuperar mediante elscontrol show nodes nodename comando y comprobando elNodeAddr campo. En el caso de los nodos que no estén disponibles, elNodeAddr campo no debe apuntar a una instancia de EC2 en ejecución. Más bien, debe ser el mismo que el nombre del nodo.

Estados de Job y presentación

En la mayoría de los casos, los trabajos enviados se asignan inmediatamente a los nodos del sistema o se colocan en espera si se han asignado todos los nodos.

Si los nodos asignados a un trabajo incluyen cualquier nodo de unPOWER_SAVING estado, el trabajo comienza con unCFCONFIGURING estado o. En este momento, el trabajo espera a que los nodos delPOWER_SAVING estado pasen alPOWER_UP estado y estén disponibles.

Cuando todos los nodos asignados a un trabajo estén disponibles, el trabajo pasa al estadoRUNNING (R).

De forma predeterminada, todos los trabajos se envían a la cola predeterminada (conocida como partición enSlurm). 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-p trabajos.

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

• Un tipo de instancia (por ejemploc5.xlarge)

• Un tipo de nodo (puede serdynamic ostatic.)

Puede ver todas las funciones disponibles para un nodo concreto mediante elscontrol show nodes nodename comando y consultando laAvailableFeatures lista.

Otra consideración son los empleos. Primero, considere el estado inicial del clúster, que puede ver ejecutando elsinfo comando.

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
efa          up   infinite      4  idle~ efa-dy-c5n18xlarge-[1-4]
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite     10  idle~ gpu-dy-g38xlarge-[1-10]
ondemand     up   infinite     20  idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      2   idle spot-st-t2large-[1-2] 

Tenga en cuenta quespot es la cola predeterminada. Se indica con el* sufijo.

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

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

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

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

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

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

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

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

Ahora considere el estado de los trabajos mediante elsqueue comando.

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

Los trabajos 7 y 8 (en lasefa colasspot y) 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-c5n18xlarge-[2-4]
efa          up   infinite      1    mix efa-dy-c5n18xlarge-1
efa          up   infinite      1   idle efa-st-c5n18xlarge-1
gpu          up   infinite      1   mix~ gpu-dy-g38xlarge-1
gpu          up   infinite      9  idle~ gpu-dy-g38xlarge-[2-10]
ondemand     up   infinite     10   mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2]
ondemand     up   infinite     10  idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10]
spot*        up   infinite     13  idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3]
spot*        up   infinite      1    mix spot-st-t2large-1
spot*        up   infinite      1   idle spot-st-t2large-2 

Estado y características del nodo

En la mayoría de los casos, los estados de los nodos se administran en su totalidad deAWS ParallelCluster acuerdo con los procesos específicos del ciclo de vida de los nodos en la nube que se describen anteriormente en este tema.

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

Estados de partición

AWS ParallelClusteradmite los siguientes estados de partición. UnaSlurm partición es una cola enAWS ParallelCluster.

• UP: indica que la partición está en estado activo. Este es el estado 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 está en estado inactivo. En este estado, se terminan todas las instancias que respaldan los nodos de una partición inactiva. No se lanzan nuevas instancias para los nodos de una partición inactiva.

inicio y parada de pcluster

Cuandopcluster stop se ejecuta, todas las particiones se colocan en elINACTIVE estado y losAWS ParallelCluster procesos mantienen las particiones en eseINACTIVE estado.

Cuandopcluster start se ejecuta, todas las particiones se colocan inicialmente en elUP estado. Sin embargo,AWS ParallelCluster los procesos no mantienen la partición en unUP estado. Debe cambiar los estados de las particiones manualmente. Todos los nodos estáticos se vuelven disponibles al cabo de unos minutos. Tenga en cuenta que configurar una partición enUP no activa ninguna capacidad dinámica. Siinitial_count es mayor quemax_count, esinitial_count posible que no se cumpla cuando el estado de la partición se cambie alUP estado.

Cuando sepcluster stop esté ejecutandopcluster start y esté en ejecución, puede comprobar el estado del clúster ejecutando elpcluster status comando y comprobando laComputeFleetStatus. A continuación se enumeran los estados posibles:

• STOP_REQUESTED: Lapcluster stop solicitud se envía al clúster.

• STOPPING: Elpcluster proceso está deteniendo el clúster en este momento.

• STOPPED: Elpcluster proceso finalizó el proceso de detención, todas las particiones están enINACTIVE estado y todas las instancias de procesamiento finalizadas.

• START_REQUESTED: Lapcluster start solicitud se envía al clúster.

• STARTING: Elpcluster proceso está iniciando actualmente el clúster

• RUNNING: Elpcluster proceso finalizó el proceso de inicio, todas las particiones están enUP estado y los nodos estáticos estarán disponibles después de unos minutos.

Control manual de colas

En algunos casos, es posible que desee tener cierto control manual sobre los nodos o la cola (lo que se conoce como partición enSlurm) de un clúster. Puede administrar los nodos de un clúster mediante los siguientes procedimientos comunes.

• Encienda los nodos dinámicos enPOWER_SAVING estado: ejecute elscontrol update nodename=nodename state=power_up comando o envíe una solicitud desleep 1 trabajo de marcador de posición para una cantidad determinada de nodos y confíe enSlurm ella para encender la cantidad requerida de nodos.

• Apague los nodos dinámicos antesscaledown_idletime: configure los nodos dinámicos enDOWN con elscontrol update nodename=nodename state=down comando. AWS ParallelClustertermina y restablece automáticamente los nodos dinámicos desactivados. En general, no recomendamos configurar los nodos para quePOWER_DOWN utilicen directamente elscontrol update nodename=nodename state=power_down comando. Esto se debe a que gestionaAWS ParallelCluster automáticamente el proceso de apagado. No es necesaria la intervención manual. Por lo tanto, se recomienda que intente configurar los nodos enDOWN siempre que sea posible.

• Desactive una cola (partición) o detenga todos los nodos estáticos en una partición específica: defina la cola en forma específicaINACTIVE con elscontrol update partition=queue name state=inactive comando. Al hacer esto, se terminan todas las instancias que respaldan los nodos de la partición.

• Habilitar una cola (partición): defina la cola de forma específicaINACTIVE con elscontrol update partition=queue name state=up comando.

Comportamiento y ajustes de escalado

Aquí hay un ejemplo del flujo de trabajo de escalado normal:

• El planificador recibe un trabajo que requiere dos nodos.

• El programador pasa dos nodos a unPOWER_UP estado y llamaResumeProgram con los nombres de los nodos (por ejemploqueue1-dy-c5xlarge-[1-2]).

• ResumeProgramlanza dos instancias de EC2 y asigna las direcciones IP privadas y los nombres de host dequeue1-dy-c5xlarge-[1-2], esperandoResumeTimeout (el período predeterminado es de 60 minutos (1 hora)) antes de restablecer los nodos.

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

• El Job está hecho.

• Una vez queSuspendTime haya transcurrido la configuración (que está establecida enscaledown_idletime), el programador pone las instancias en esePOWER_SAVING estado. El programador colocaqueue1-dy-c5xlarge-[1-2] enPOWER_DOWN estado y llamaSuspendProgram con los nombres de los nodos.

• SuspendProgramse requiere de dos nodos. Los nodos permanecen en esePOWER_DOWN estado, por ejemplo, si permanecenidle% durante un períodoSuspendTimeout (el período predeterminado es de 120 segundos (2 minutos)). Trasclustermgtd detectar que los nodos se están apagando, finaliza las instancias de respaldo. Luego, se configuraqueue1-dy-c5xlarge-[1-2] en estado inactivo y restablece la dirección IP privada y el nombre de host para que puedan volver a encenderse para future trabajos.

Ahora, si las cosas van mal y no se puede lanzar una instancia para un nodo en particular por alguna razón, ocurre lo siguiente.

• El programador recibe un trabajo que requiere dos nodos.

• El programador coloca dos nodos que explotan la nube enPOWER_UP estado y llamaResumeProgram con los nombres de los nodos (por ejemploqueue1-dy-c5xlarge-[1-2]).

• ResumeProgramlanza solo una (1) instancia de EC2 y la configuraqueue1-dy-c5xlarge-1, pero no pudo lanzar una instancia paraqueue1-dy-c5xlarge-2.

• queue1-dy-c5xlarge-1no se verá afectado y se conectará al llegar alPOWER_UP estado.

• queue1-dy-c5xlarge-2se coloca enPOWER_DOWN estado y el trabajo se pone en cola automáticamente porqueSlurm detecta un error en el nodo.

• queue1-dy-c5xlarge-2pasa a estar disponible despuésSuspendTimeout (el valor predeterminado es 120 segundos (2 minutos)). Mientras tanto, el trabajo se pone 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 60 minutos (1 hora)):ResumeTimeout controla el tiempo deSlurm espera antes de poner el nodo en estado inactivo.

  • Podría ser útil ampliar esta opción si el proceso previo o posterior a la instalación lleva casi ese tiempo.

  • Este también es el tiempo máximo que seAWS ParallelCluster espera antes de reemplazar o restablecer un nodo si hay algún problema. Los nodos de procesamiento se autoterminan si se produce algún error durante el lanzamiento o la configuración. A continuación,AWS ParallelCluster los procesos también reemplazan al nodo cuando ven que la instancia ha terminado.

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

  • Un valor más cortoSuspendTimeout significaría que los nodos se restablecerán más rápidamente ySlurm podrán intentar lanzar instancias con más frecuencia.

  • Un tiempo más largoSuspendTimeout hace que los nodos fallidos se reinicien más lentamente. Mientras tanto, seSlurm cansa de usar otros nodos. SiSuspendTimeout son más de unos minutos,Slurm intenta recorrer todos los nodos del sistema. Un período más largoSuspendTimeout podría resultar beneficioso para los sistemas a gran escala (más de 1000 nodos), ya que reduce el stress al volver a poner enSlurm cola con frecuencia las tareas que fallan.

  • Tenga en cuenta queSuspendTimeout esto no se refiere al tiempoAWS ParallelCluster esperado para terminar una instancia de respaldo para un nodo. Las instancias de respaldo depower down los nodos se cancelan inmediatamente. El proceso de finalización suele finalizar en unos minutos. Sin embargo, durante este tiempo, el nodo permanece en estado de apagado y no está disponible para su uso en el planificador.

Registros para la nueva arquitectura

La siguiente lista contiene los registros de claves de la arquitectura de colas múltiples. El nombre del flujo de registro que se utiliza en Amazon CloudWatch Logs tiene el formato{hostname}.{instance_id}.{logIdentifier}, en el que logIdentifier sigue a los nombres de registro. Para obtener más información, consulte Integración con Amazon CloudWatch Logs.

• 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 comunes y cómo depurar:

Nodos que no se pudieron iniciar, encender o unirse al clúster:

• Nodos dinámicos:

  • Consulte elResumeProgram registro para ver si alguna vezResumeProgram se llamó con el nodo. De lo contrario, compruebe elslurmctld registro para determinar siSlurm alguna vez intentó llamarResumeProgram con el nodo. Tenga en cuenta que los permisos incorrectos en esta opciónResumeProgram pueden provocar un error silencioso.

  • SiResumeProgram se llama, compruebe si se lanzó una instancia para el nodo. Si no se puede lanzar la instancia, debería aparecer un mensaje de error claro que explique por qué no se pudo lanzar la instancia.

  • Si se lanzó una instancia, es posible que haya habido algún problema durante el proceso de arranque. Busque la dirección IP privada y el ID de instancia correspondientes en elResumeProgram registro y consulte los registros de arranque correspondientes a la instancia específica en CloudWatch Registros.

• Nodos estáticos:

  • Compruebe elclustermgtd registro para ver si se han lanzado instancias para el nodo. De lo contrario, debería haber errores claros sobre el motivo por el que no se pudieron lanzar las instancias.

  • Si se lanzó una instancia, hay algún problema durante el proceso de arranque. Busque la IP privada y el ID de instancia correspondientes en elclustermgtd registro y consulte los registros de arranque correspondientes a la instancia específica en CloudWatch Registros.

Nodos reemplazados o terminados inesperadamente, errores de nodo

• Los nodos se reemplazaron o terminaron inesperadamente

  • En la mayoría de los casos,clustermgtd gestiona todas las acciones de mantenimiento de los nodos. Para comprobar siclustermgtd se reemplazó o finalizó un nodo, consulte elclustermgtd registro.

  • Siclustermgtd se reemplaza o termina el nodo, debe aparecer un mensaje que indique el motivo de la acción. Si el motivo está relacionado con el programador (por ejemplo, el nodo lo estabaDOWN), consulte elslurmctld registro para obtener más detalles. Si el motivo está relacionado con EC2, utilice herramientas para comprobar el estado o los registros de esa instancia. Por ejemplo, puede comprobar si la instancia tenía eventos programados o si no se habían realizado las comprobaciones del estado de funcionamiento de EC2.

  • Siclustermgtd no ha terminado el nodo, compruebe sicomputemgtd ha terminado el nodo o si EC2 ha cancelado la instancia para recuperar una instancia puntual.

• Fallos de nodo

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

Fallo al reemplazar o terminar instancias, error al apagar nodos

• En general,clustermgtd gestiona todas las acciones de terminación de instancias esperadas. Consulte elclustermgtd registro para ver por qué no pudo reemplazar o terminar un nodo.

• En el caso de los nodos dinámicos que fallanscaledown_idletime, consulte elSuspendProgram registro para ver si un programa tiene el nodo específico como argumento.slurmctld En realidad, NoteSuspendProgram no realiza ninguna acción específica. Más bien, solo registra cuando se llama. La terminación y elNodeAddr restablecimiento de todas las instancias se completan conclustermgtd. Slurmcoloca los nodosIDLE despuésSuspendTimeout.

Otras cuestiones

• AWS ParallelClusterno toma decisiones de asignación de puestos ni de escalado. Simplemente intenta lanzar, finalizar y mantener los recursosSlurm de acuerdo con sus instrucciones.

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