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

• Un nodo en un estado POWER_SAVING aparece con un sufijo ~ (por ejemplo idle~) en sinfo. En este estado, ninguna EC2 instancia respalda el nodo. Sin embargo, Slurm aún 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 POWER_UP estado cuando Slurm asigna una tarea a un nodo en un POWER_SAVING estado.

  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, ResumeProgram se invoca, se lanzan y configuran las EC2 instancias y el nodo pasa al POWER_UP estado.

• 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, recomendamos que el número de EC2 instancias de Amazon 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.

  La ScaledownIdletimeconfiguración se guarda en Slurm SuspendTimeoutajuste de configuración.

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

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

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

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

• 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

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

• 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 sleep 1 trabajo provisional solicitando un número determinado de nodos y, a continuación, confiar en Slurm para activar la cantidad requerida de nodos.

• 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

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]).

• ResumeProgramlanza dos EC2 instancias de Amazon y asigna las direcciones IP privadas y los nombres de host dequeue1-dy-spotcompute1-[1-2], esperando ResumeTimeout (el período 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]).

• ResumeProgramlanza solo una (1) EC2 instancia de Amazon y configuraqueue1-dy-spotcompute1-1, con una (1) instanciaqueue1-dy-spotcompute1-2, al no poder lanzarse.

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

• queue1-dy-spotcompute1-2pasa al POWER_DOWN estado 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 la hora Slurm espera antes de pasar el nodo 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 finalizada.

• 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 corto SuspendTimeout significa que los nodos se restablecen más rápidamente, 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 son más de unos pocos minutos, Slurm intenta recorrer todos los nodos del sistema. Un tiempo más prolongado SuspendTimeout podría ser beneficioso para los sistemas a gran escala (más de 1000 nodos) para reducir el stress en Slurm cuando intenta volver a poner en cola con frecuencia los trabajos que no funcionan.

  • Tenga en cuenta que SuspendTimeout esto no se refiere al tiempo de AWS ParallelCluster espera para finalizar una instancia de respaldo para 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.

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

• Nodos dinámicos:

  • Compruebe el registro ResumeProgram para ver si se ha llamado a ResumeProgram con el nodo. Si no es así, compruebe el slurmctld registro para determinar si Slurm intentó llamar 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 consulte los registros de arranque correspondientes a la instancia específica en CloudWatch los registros.

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

• 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á EC2 relacionado con Amazon, utiliza herramientas como Amazon CloudWatch o la EC2 consola de Amazon, o bien CLISDKs, para comprobar el estado o los registros de esa instancia. Por ejemplo, puedes comprobar si la instancia tenía eventos programados o no pasó las comprobaciones de EC2 estado de Amazon.

  • Si clustermgtd no ha cerrado el nodo, compruebe si computemgtd ha terminado el nodo o si EC2 ha terminado la instancia para recuperar una instancia puntual.

• 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í.

• 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. La finalización y el NodeAddr restablecimiento de todas las instancias se completan antes de. clustermgtd Slurm hace la transición de los nodos a los IDLE siguientes. SuspendTimeout

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

  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.