Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Guía de Slurm para el modo de cola múltiple
AWS ParallelCluster la versión 2.9.0 introdujo el modo de cola múltiple y una nueva arquitectura de escalado para Slurm Workload Manager ()Slurm.
En las siguientes secciones se proporciona una descripción general del uso de un Slurm clúster con la nueva arquitectura de escalado.
## Descripción general de
La arquitectura de escalado se basa en la [Guía de programación en la nube](https://slurm.schedmd.com/elastic_computing.html) 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](https://slurm.schedmd.com/power_save.html). 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 Slurm cuando `POWER_SAVING` asigna un trabajo a un nodo en estado `POWER_UP`. De lo contrario, los nodos se pueden colocar en el `POWER_UP` estado manualmente mediante el `scontrol update nodename=nodename state=power_up` comando. 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 ) en . 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 [`scaledown_idletime`](scaling-section.md#scaledown-idletime). Por el contrario, los nodos estáticos no están apagados en la mayoría de los casos. Sin embargo, los nodos se pueden colocar en el `POWER_DOWN` estado manualmente mediante el `scontrol update nodename=nodename state=powering_down` comando. 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 [`scaledown_idletime`](scaling-section.md#scaledown-idletime). El ajuste `scaledown-idletime` 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 los nodos que se muestran en el siguiente ejemplo de `sinfo`.
```
$ 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]
```
Los nodos `spot-st-t2large-[1-2]` y `efa-st-c5n18xlarge-1` ya tienen instancias de respaldo configuradas y están disponibles para su uso. Los nodos `ondemand-dy-c52xlarge-[1-2]` se encuentran en el estado `POWER_UP` y deberían estar disponibles en unos minutos. El nodo `gpu-dy-g38xlarge-1` se encuentra en el estado `POWER_DOWN` y pasa al estado `POWER_SAVING` después de [`scaledown_idletime`](scaling-section.md#scaledown-idletime) (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-c5n18xlarge-1`). La dirección IP privada de la instancia se puede recuperar usando el comando `scontrol show nodes nodename` y comprobando el campo `NodeAddr`: 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 todas las funciones disponibles para un nodo concreto utilizando el `scontrol show nodes nodename` comando y consultando la `AvailableFeatures` lista.
Otra consideración son los puestos de trabajo. 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-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 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-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 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-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 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`](processes.md#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.
## pcluster: iniciar y detener
Cuando [`pcluster stop`](pcluster.stop.md) se ejecuta, todas las particiones se colocan en `INACTIVE` ese estado y los AWS ParallelCluster procesos mantienen las particiones en ese `INACTIVE` estado.
Cuando [`pcluster start`](pcluster.start.md) se ejecuta, todas las particiones se colocan inicialmente en el `UP` estado. 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. Si [`initial_count`](compute-resource-section.md#compute-resource-initial-count) es mayor que[`max_count`](compute-resource-section.md#compute-resource-max-count), es [`initial_count`](compute-resource-section.md#compute-resource-initial-count) posible que no se satisfaga cuando el estado de la partición cambie al `UP` estado.
Cuando se ejecuta [`pcluster start`](pcluster.start.md) y [`pcluster stop`](pcluster.stop.md), puede consultar el estado del clúster ejecutando el comando [`pcluster status`](pcluster.status.md) y comprobando el `ComputeFleetStatus`. A continuación, se indican los estados posibles:
+ `STOP_REQUESTED`: La [`pcluster stop`](pcluster.stop.md) solicitud se envía al clúster.
+ `STOPPING`: el proceso de `pcluster` está iniciando actualmente el clúster.
+ `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 [`pcluster start`](pcluster.start.md) solicitud 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.
## 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 .
+ Encienda los nodos dinámicos en `POWER_SAVING` estado: ejecute el `scontrol update nodename=nodename state=power_up` comando o envíe una solicitud de `sleep 1` trabajo provisional para un número determinado de nodos y espere Slurm a que se encienda el número de nodos requerido.
+ Apague los nodos dinámicos antes[`scaledown_idletime`](scaling-section.md#scaledown-idletime): establezca los nodos dinámicos en `DOWN` con el `scontrol update nodename=nodename state=down` comando. AWS ParallelCluster termina y restablece automáticamente los nodos dinámicos desactivados. 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. No es necesario realizar una intervención manual. Por lo tanto, se recomienda intentar configurar nodos en `DOWN`
+ Desactive una cola (partición) o detenga todos los nodos estáticos de una partición específica: defina la cola en un valor específico `INACTIVE` con el `scontrol update partition=queue name state=inactive` comando. De este modo, se finalizan todas las instancias que respaldan a los nodos de la partición.
+ Habilitar una cola (partición): defina una cola específica `INACTIVE` con el comando. `scontrol update partition=queue name 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-c5xlarge-[1-2]`).
+ `ResumeProgram` lanza dos instancias de EC2 y asigna las direcciones IP privadas y los nombres de host de `queue1-dy-c5xlarge-[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.
+ Job está hecho.
+ Una vez transcurrido el `SuspendTime` configurado (que está establecido en [`scaledown_idletime`](scaling-section.md#scaledown-idletime)), el programador establece las instancias en el estado `POWER_SAVING`. El programador lo coloca `queue1-dy-c5xlarge-[1-2]` en `POWER_DOWN` estado y llama `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, se configura `queue1-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 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-c5xlarge-[1-2]`).
+ `ResumeProgram` lanza solo una (1) instancia de EC2 y configura `queue1-dy-c5xlarge-1`, con una (1) instancia, `queue1-dy-c5xlarge-2`, que no se puede lanzarse.
+ `queue1-dy-c5xlarge-1`no se verá afectada y se pondrá en línea cuando alcance `POWER_UP` el estado.
+ `queue1-dy-c5xlarge-2`se coloca en `POWER_DOWN` estado y el trabajo se vuelve a poner en cola automáticamente porque Slurm detecta un fallo en el nodo.
+ `queue1-dy-c5xlarge-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 espera antes de que el nodo pase al estado inactivo.
+ Podría ser útil ampliarlo si el proceso de pre/post instalación tarda casi tanto tiempo.
+ Este es también el tiempo máximo que se AWS ParallelCluster debe esperar antes de reemplazar o restablecer un nodo si hay algún problema. Los nodos de computación se autofinalizan si se produce algún error durante el inicio o la configuración. A continuación, el AWS ParallelCluster proceso también reemplaza al nodo cuando ve que la instancia ha terminado.
+ `SuspendTimeout` (el valor predeterminado es 120 segundos, es decir, 2 minutos): 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 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 y no está disponible para que lo utilice el programador.
## Registros para la arquitectura
La siguiente lista contiene los registros clave de la arquitectura de colas múltiples. El nombre del flujo de registro utilizado con Amazon CloudWatch Logs tiene el formato `{hostname}.{instance_id}.{logIdentifier}` *logIdentifier* siguiente: los nombres de registro. Para obtener más información, consulte [Integración con Amazon CloudWatch Logs](cloudwatch-logs.md).
+ `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 consulte los registros de arranque correspondientes a la instancia específica en CloudWatch Logs.
+ 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 inesperados replaced/terminated
+ 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 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 [`scaledown_idletime`](scaling-section.md#scaledown-idletime), 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 o 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.