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.
# Programadores compatibles con AWS ParallelCluster
AWS ParallelCluster soportes Slurm y AWS Batch planificadores, que se configuran mediante la configuración. [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) En los siguientes temas se explica cada uno de los programadores y cómo usarlos.
**Topics**
+ [Slurm Workload Manager (`slurm`)](slurm-workload-manager-v3.md)
+ [Usar el planificador AWS Batch (`awsbatch`) con AWS ParallelCluster](awsbatchcli-v3.md)
# Slurm Workload Manager (`slurm`)
## Tamaño y actualización de la capacidad del clúster
La capacidad del clúster se define por la cantidad de nodos de computación que es capaz de escalar. Los nodos de cómputo están respaldados por instancias de Amazon EC2 definidas dentro de los recursos de cómputo de la AWS ParallelCluster configuración `(Scheduling/SlurmQueues/`ComputeResources`)` y están organizados en colas `(Scheduling/SlurmQueues)` que se asignan 1:1 a las particiones. Slurm
Dentro de un recurso de cómputo, es posible configurar el número mínimo de nodos de cómputo (instancias) que deben mantenerse siempre en ejecución en el clúster (`MinCount`) y el número máximo de instancias al que el recurso de cómputo puede escalar ([`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)).
En el momento de la creación del clúster, o tras una actualización del clúster, AWS ParallelCluster lanza tantas instancias de Amazon EC2 como estén configuradas `MinCount` para cada recurso informático (`Scheduling/SlurmQueues/ ComputeResources`) definido en el clúster. Las instancias lanzadas para cubrir la cantidad mínima de nodos de un recurso de computación del clúster se denominan ***nodos estáticos***. Una vez iniciados, los nodos estáticos deben permanecer en el clúster y el sistema no los termina a menos que se produzca un evento o una condición en particular. Estos eventos incluyen, por ejemplo, el fallo de las comprobaciones de estado de Slurm o Amazon EC2 y el cambio del estado del nodo de Slurm a DRAIN (vaciado) o DOWN (inactivo).
Las instancias de Amazon EC2, en el rango de `1` a `‘MaxCount - MinCount’` (`MaxCount ` *menos* ` MinCount)`, publicadas bajo demanda para hacer frente al aumento de carga del clúster, se denominan ***nodos dinámicos***. Su naturaleza es efímera: se lanzan para atender trabajos pendientes y se finalizan una vez que permanecen inactivas durante un período de tiempo definido por `Scheduling/SlurmSettings/ScaledownIdletime` en la configuración del clúster (predeterminado: 10 minutos).
Los nodos estáticos y los nodos dinámicos cumplen con el siguiente esquema de nomenclatura:
+ Nodos estáticos `-st--`, en los que ` = 1..ComputeResource/MinCount`
+ Nodos dinámicos `-dy--`, donde ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Por ejemplo, dada la siguiente AWS ParallelCluster configuración:
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
Los siguientes nodos se definirán en Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Cuando un recurso de cómputo lo tenga`MinCount == MaxCount`, todos los nodos de cómputo correspondientes serán estáticos y todas las instancias se lanzarán en el creation/update momento del clúster y se mantendrán en funcionamiento. Por ejemplo:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Actualización de la capacidad del clúster
La actualización de la capacidad del clúster incluye añadir o eliminar colas, recursos de computación o cambiar el parámetro `MinCount/MaxCount` de un recurso de computación. A partir de la AWS ParallelCluster versión 3.9.0, para reducir el tamaño de una cola es necesario detener la flota de cómputo o [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)configurarla en TERMINATE antes de que se lleve a cabo la actualización del clúster. No es necesario detener la flota de cómputo ni configurarla en TERMINATE [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)cuando:
+ Adición de nuevas colas en Programación/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Adición de nuevos recursos de computación `Scheduling/SlurmQueues/ComputeResources` a una cola
+ Aumento de `MaxCount` de un recurso de computación
+ Aumento MinCount de un recurso informático y aumento MaxCount del mismo recurso informático en al menos la misma cantidad
## Consideraciones y limitaciones
El objetivo de esta sección es explicar los factores, restricciones o limitaciones importantes que se deben tener en cuenta al cambiar el tamaño de la capacidad del clúster.
+ Al eliminar una cola de `Scheduling/SlurmQueues`, todos los nodos de computación con el nombre `-*`, tanto estáticos como dinámicos, se eliminarán de la configuración de Slurm y finalizarán las instancias de Amazon EC2 correspondientes.
+ Al eliminar un recurso de computación de `Scheduling/SlurmQueues/ComputeResources` de una cola, todos los nodos de computación con el nombre `-*--*`, tanto estáticos como dinámicos, se eliminarán de la configuración de Slurm y finalizarán las instancias de Amazon EC2 correspondientes.
Al cambiar el parámetro `MinCount` de un recurso de computación, podemos distinguir dos escenarios diferentes: si `MaxCount` es igual que `MinCount` (solo capacidad estática) y si `MaxCount` es mayor que `MinCount` (capacidad estática y dinámica mixta).
### Cambios en la capacidad solo con los nodos estáticos
+ Si `MinCount == MaxCount`, al aumentar la `MinCount` (y la `MaxCount`), el clúster se configurará ampliando el número de nodos estáticos hasta el nuevo valor de `MinCount` `-st--` y el sistema seguirá intentando lanzar instancias de Amazon EC2 para cumplir con la nueva capacidad estática requerida.
+ Si `MinCount == MaxCount`, al disminuir la `MinCount` (y el `MaxCount`) de la cantidad N, el clúster se configurará eliminando los últimos N nodos estáticos `-st--...]` y el sistema finalizará las instancias de Amazon EC2 correspondientes.
+ Estado inicial `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualización de `-30` en `MinCount` y `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Cambios en la capacidad con nodos mixtos
Si `MinCount < MaxCount`, al aumentar la `MinCount` de una cantidad N (suponiendo que `MaxCount` se mantenga sin cambios), el clúster se configurará ampliando el número de nodos estáticos hasta el nuevo valor de `MinCount` (`old_MinCount + N`): `-st--` y el sistema seguirá intentando lanzar instancias de Amazon EC2 para cumplir con la nueva capacidad estática requerida. Además, para respetar la capacidad de `MaxCount` del recurso de computación, la configuración del clúster se actualiza *eliminando los últimos N nodos dinámicos*: `-dy--[...]` y el sistema finalizará las instancias de Amazon EC2 correspondientes.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualice a \$130 en `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Si `MinCount < MaxCount`, al aumentar la `MinCount` y la `MaxCount` de la misma cantidad N, el clúster se configurará ampliando el número de nodos estáticos hasta el nuevo valor de `MinCount` (`old_MinCount + N`): `-st--` y el sistema seguirá intentando lanzar instancias de Amazon EC2 para cumplir con la nueva capacidad estática requerida. Además, no se realizará ningún cambio en el número de nodos dinámicos para adaptarlo al nuevo
valor de `MaxCount`.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualice a \$130 en `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Si `MinCount < MaxCount`, al disminuir la `MinCount` de la cantidad N (suponiendo que `MaxCount` se mantenga sin cambios), el clúster se configurará eliminando los últimos N nodos estáticos `-st--[...` y el sistema finalizará las instancias de Amazon EC2 correspondientes. Además, para respetar la capacidad `MaxCount` del recurso de computación, la configuración del clúster se actualiza ampliando el número de nodos dinámicos para cubrir el vacío `MaxCount - new_MinCount: -dy--[1..]`. En este caso, dado que se trata de nodos dinámicos, no se lanzará ninguna nueva instancia de Amazon EC2 a menos que el programador tenga trabajos pendientes en los nuevos nodos.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualización de -30 en `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Si `MinCount < MaxCount`, al disminuir la `MinCount` y la `MaxCount` de la misma cantidad N, el clúster se configurará eliminando los últimos N nodos estáticos `-st--...]` y el sistema finalizará las instancias de Amazon EC2 correspondientes.
Además, no se realizará ningún cambio en el número de nodos dinámicos para adaptarlo al nuevo valor de `MaxCount`.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualización de -30 en `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Si `MinCount < MaxCount`, al disminuir la `MaxCount` de la cantidad N (suponiendo que `MinCount` se mantenga sin cambios), el clúster se configurará eliminando los últimos N nodos dinámicos`-dy--]` y el sistema finalizará las instancias de Amazon EC2 correspondientes si se estuviesen ejecutando. No habrá ningún impacto en los nodos estáticos.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualización de -30 en `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Impactos en los trabajos
En todos los casos en los que se eliminen nodos y se finalicen instancias de Amazon EC2, si había un trabajo sbatch en los nodos eliminados se volverá a poner en cola, a menos que no haya otros nodos que cumplan con los requisitos del trabajo. En este último caso, el trabajo falla con el estado NODE\$1FAIL y desaparece de la cola, por lo que debe volver a enviarse manualmente.
Si planea realizar una actualización de tamaño del clúster, puede impedir que los trabajos se ejecuten en nodos que se vayan a eliminar durante la actualización planificada. Esto se puede hacer configurando los nodos que se eliminarán durante el mantenimiento. Tenga en cuenta que poner un nodo en mantenimiento no afectaría a los trabajos que se estuviesen ejecutando en ese momento en el nodo.
Supongamos que con la actualización planificada para cambiar el tamaño del clúster se va a eliminar el nodo`qeueu-st-computeresource-[9-10`]. Puede crear una reserva de Slurm con el siguiente comando
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Esto creará una reserva de Slurm con el nombre `maint_for_update` en los nodos `qeueu-st-computeresource-[9-10]`. Desde el momento en que se crea la reserva, no se pueden ejecutar más trabajos en los nodos `qeueu-st-computeresource-[9-10]`. Tenga en cuenta que la reserva no impedirá que haya trabajos que acaben asignándose a los nodos `qeueu-st-computeresource-[9-10]`.
Tras actualizar el tamaño del clúster, si la reserva de Slurm se estableció solo en los nodos que se eliminaron durante la actualización del cambio de tamaño, se eliminará automáticamente. Si, por el contrario, ha creado una reserva de Slurm en nodos que siguen presentes tras la actualización del cambio de tamaño del clúster, es posible que quiera eliminar dicha reserva de mantenimiento de los nodos tras la actualización de tamaño mediante el siguiente comando
```
sudo -i scontrol delete ReservationName=maint_for_update
```
Para obtener más información sobre la reserva de Slurm, consulte el documento oficial de SchedMD [aquí](https://slurm.schedmd.com/reservations.html).
## Proceso de actualización de un clúster con cambios de capacidad
Tras un cambio en la configuración del programador, se ejecutan los siguientes pasos durante el proceso de actualización del clúster:
+ ¡Deténgase AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Se genera una configuración de particiones de Slurm actualizada a partir de la configuración de AWS ParallelCluster
+ Se reinicia `slurmctld` (mediante la receta del servicio Chef)
+ Se comprueba el estado de `slurmctld` `(systemctl is-active --quiet slurmctld.service)`
+ Se recarga la configuración de Slurm `(scontrol reconfigure)`
+ Se inicia `clustermgtd (supervisorctl start clustermgtd)`
Para obtener más información sobre Slurm, consulte [https://slurm.schedmd.com](https://slurm.schedmd.com). Para ver las descargas, consulta [https://github.com/SchedMD/slurm/tags](https://github.com/SchedMD/slurm/tags). [Para ver el código fuente, consulte slurm. https://github.com/SchedMD/](https://github.com/SchedMD/slurm)
## Versiones de clúster y SLURM compatibles
En la siguiente tabla se enumeran las versiones compatibles AWS ParallelCluster y Slurm las versiones compatibles AWS .
| AWS ParallelCluster versión (es) | Versión de Slurm compatible |
| --- | --- |
| 3.13.0 | 24,05,07 |
| 3.12.0 | 23,11,10 |
| 3.11.0 | 23,11,10 |
| 3.9.2, 3.9.3, 3.10.0 | 23,11,7 |
| 3.9.0, 3.9.1 | 23,11,4 |
| 3.8.0 | 23.02.7 |
| 3.7.2 | 23.02.6 |
| 3.7.1 | 23,02.5 |
| 3.7.0 | 23,02.4 |
| 3.6.0, 3.6.1 | 23.02.2 |
| 3.5.0, 3.5.1 | 22.05.8 |
| 3.4.0, 3.4.1 | 22.05.7 |
| 3.3.0, 3.3.1 | 22.05.5 |
| 3.1.4, 3.1.5, 3.2.0, 3.2.1 | 21.08.8-2 |
| 3.1.2, 3.1.3 | 21,08.6 |
| 3.1.1 | 21.08.5 |
| 3.0.0 | 20,11,8 |
**Topics**
+ [Tamaño y actualización de la capacidad del clúster](#cluster-capacity-size-and-update)
+ [Actualización de la capacidad del clúster](#cluster-capacity-update)
+ [Consideraciones y limitaciones](#considerations-limitations)
+ [Impactos en los trabajos](#impacts-on-jobs)
+ [Proceso de actualización de un clúster con cambios de capacidad](#cluster-update-process)
+ [Versiones de clúster y SLURM compatibles](#cluster-slurm-version-table)
+ [Configuración de varias colas](configuration-of-multiple-queues-v3.md)
+ [Guía de Slurm para el modo de cola múltiple](multiple-queue-mode-slurm-user-guide-v3.md)
+ [Slurm modo protegido de clúster](slurm-protected-mode-v3.md)
+ [Conmutación por error rápida de capacidad insuficiente en el clúster de Slurm](slurm-short-capacity-fail-mode-v3.md)
+ [Slurm programación basada en memoria](slurm-mem-based-scheduling-v3.md)
+ [Asignación de varios tipos de instancias con Slurm](slurm-multiple-instance-allocation-v3.md)
+ [Escalado de clústeres para nodos dinámicos](scheduler-node-allocation-v3.md)
+ [Slurmcontabilidad con AWS ParallelCluster](slurm-accounting-v3.md)
+ [Slurm personalización de la configuración](slurm-configuration-settings-v3.md)
+ [Slurm y `prolog``epilog`](slurm-prolog-epilog-v3.md)
+ [Tamaño y actualización de la capacidad del clúster](slurm-cluster-capacity-size-and-update.md)
# Configuración de varias colas
Con AWS ParallelCluster la versión 3, puede configurar varias colas estableciendo `slurm` y especificando más de una cola en el [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)archivo de configuración. [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) En este modo, coexisten diferentes tipos de instancias en los nodos de computación que se especifican en la sección [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) del archivo de configuración. [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) con diferentes tipos de instancias se escalan o reducen verticalmente según sea necesario para [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues).
Por lo general, se prefieren *las colas* múltiples dentro de un solo clúster en lugar de múltiples clústeres cuando las cargas de trabajo comparten la misma infraestructura y los mismos recursos subyacentes (como almacenamiento compartido, redes o nodos de inicio de sesión). Si las cargas de trabajo tienen necesidades informáticas, de almacenamiento y de red similares, usar varias colas en un solo clúster es más eficiente porque permite compartir recursos y evita la duplicación innecesaria. Este enfoque simplifica la administración y reduce los gastos generales, a la vez que permite una programación de tareas y una asignación de recursos eficientes. Por otro lado, se deben utilizar varios *clústeres* cuando existan requisitos estrictos de seguridad, datos o aislamiento operativo entre las cargas de trabajo. Por ejemplo, si necesita administrar y operar las cargas de trabajo de forma independiente, con diferentes programas, ciclos de actualización o políticas de acceso, es más adecuado tener varios clústeres.
**Cuotas de recursos de computación y de colas de clúster**
| Recurso | Cuota |
| --- | --- |
| [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | 50 colas por clúster |
| [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 50 recursos de computación por cola 50 recursos de computación por clúster |
**Recuentos de nodos**
Cada recurso de computación de [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) para una cola debe tener valores de [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name), [`InstanceType`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType), [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) y [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) únicos. [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) y [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) tienen valores predeterminados que definen el rango de instancias de un recurso de computación de [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) para una cola. También puede especificar sus propios valores para [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) y [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount). Cada recurso de computación en [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) está compuesto por nodos estáticos numerados del 1 al valor de [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) y nodos dinámicos numerados del valor de [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) al valor de [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount).
**Configuración de ejemplo**
A continuación, se muestra un ejemplo de una sección de [programación](Scheduling-v3.md) para un archivo de configuración de clúster. En esta configuración, hay dos colas denominadas `queue1` y `queue2` y cada una de ellas tiene un [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) con un [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) especificado.
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
- InstanceType: c4.xlarge
MaxCount: 5
Name: c4xlarge
- Name: queue2
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
```
**Nombres de hosts**
Las instancias que se lanzan a la flota de computación se asignan de forma dinámica. Se generan nombres de host para cada nodo. De forma predeterminada AWS ParallelCluster , utilizará el siguiente formato de nombre de host:
`$HOSTNAME=$QUEUE-$STATDYN-$COMPUTE_RESOURCE-$NODENUM`
+ `$QUEUE` es el nombre de la cola. Por ejemplo, si la sección [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) tiene una entrada con el valor [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Name) establecido en “`queue-name`”, entonces “`$QUEUE`” es “`queue-name`”.
+ `$STATDYN` es `st` para nodos estáticos o `dy` para dinámicos.
+ `$COMPUTE_RESOURCE` es el [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name) del recurso de computación [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) correspondiente a este nodo.
+ `$NODENUM` es el número del nodo. `$NODENUM` está entre uno (1) y el valor de [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) para los nodos estáticos y entre uno (1) y [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)-[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) para los dinámicos.
En el ejemplo del archivo de configuración anterior, un nodo determinado de `queue1` y un recurso de computación `c5xlarge` tiene como nombre de host: `queue1-dy-c5xlarge-1`.
Tanto los nombres de host como los nombres de dominio completos (FQDN) se crean mediante las zonas alojadas de Amazon Route 53. El FQDN es `$HOSTNAME.$CLUSTERNAME.pcluster`, donde `$CLUSTERNAME` está el nombre del clúster.
Tenga en cuenta que también se utilizará el mismo formato para los nombres de los nodos de Slurm.
Los usuarios pueden optar por utilizar el EC2 nombre de host de Amazon predeterminado de la instancia que alimenta el nodo de procesamiento en lugar del formato de nombre de host predeterminado que utiliza. AWS ParallelCluster Para ello, defina el parámetro [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) como verdadero. Sin embargo, los nombres de los Slurm nodos seguirán utilizando el formato predeterminado AWS ParallelCluster .
# Guía de Slurm para el modo de cola múltiple
Aquí puede aprender cómo AWS ParallelCluster Slurm administrar los nodos de colas (particiones) y cómo monitorear los estados de las colas y los nodos.
## 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 `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 Amazon 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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime).
El ajuste [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 Amazon 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 Amazon 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`](processes-v3.md#clustermgtd-v3).
## 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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 Amazon EC2 y asigna las direcciones IP privadas y los nombres de host de `queue1-dy-spotcompute1-[1-2]`, a la espera de `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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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 Amazon 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 ampliarlo `ResumeTimeout` si el proceso de pre/post instalación tarda casi tanto tiempo.
+ `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}` *logIdentifier* siguiente: los nombres de registro.
+ `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 replaced/terminated inesperados:
+ 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 Amazon EC2, utilice herramientas como Amazon CloudWatch o la consola, la CLI o los SDK de Amazon 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 Amazon 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`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-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.
# Slurm modo protegido de clúster
Cuando un clúster se ejecuta con el modo protegido activado, AWS ParallelCluster supervisa y rastrea los errores de arranque de los nodos de cómputo a medida que se lanzan los nodos de cómputo. Lo hace para detectar si estos errores se producen de forma continua.
Si se detecta lo siguiente en una cola (partición), el clúster pasa al estado protegido:
1. Los errores de arranque consecutivos de los nodos de cómputo se producen de forma continua y no se inicia correctamente el nodo de cómputo.
1. El recuento de errores alcanza un umbral predefinido.
Cuando el clúster pasa al estado protegido, AWS ParallelCluster deshabilita las colas con errores iguales o superiores al umbral predefinido.
Slurm el modo protegido de clúster se agregó en la AWS ParallelCluster versión 3.0.0.
Puede usar el modo protegido para reducir el tiempo y los recursos que se gastan en el ciclo de errores de arranque de los nodos de cómputo.
## Parámetro de modo de modo protegido
**`protected_failure_count`**
`protected_failure_count` especifica el número de errores consecutivos en una cola (partición) que activan el estado de protección del clúster.
El valor predeterminado `protected_failure_count` es 10 y el modo protegido está activado.
Si `protected_failure_count` es mayor que cero, el modo protegido está activado.
Si `protected_failure_count` es inferior o igual a cero, el modo protegido está deshabilitado.
Puede cambiar el valor `protected_failure_count` añadiendo el parámetro en el archivo de configuración `clustermgtd` que se encuentra en `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` en el `HeadNode`.
Puede actualizar este parámetro en cualquier momento y no necesita detener la flota de computación para hacerlo. Si un lanzamiento se realiza correctamente en una cola antes de que llegue el recuento de errores`protected_failure_count`, el recuento de errores se restablece a cero.
## Compruebe el estado del clúster en estado protegido
Cuando un clúster está en estado protegido, puede consultar el estado de la flota de computación y los estados de los nodos.
### Estado de la flota de computación
El estado de la flota de computación es `PROTECTED` en un clúster que se ejecuta en estado protegido.
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### Estado del nodo
Para saber qué colas (particiones) tienen errores de arranque y tienen activado el estado de protección, inicie sesión en el clúster y ejecute el `sinfo` comando. Las particiones con errores de arranque iguales o superiores `protected_failure_count` están en ese estado. `INACTIVE` Las particiones sin errores de arranque iguales o superiores `protected_failure_count` se encuentran en ese `UP` estado y funcionan según lo previsto.
El estado de `PROTECTED` no afecta a los trabajos en ejecución. Si los trabajos se ejecutan en una partición con errores de arranque iguales o superiores`protected_failure_count`, la partición se establece en una `INACTIVE` vez finalizados los trabajos en ejecución.
Observe los estados de nodo que se muestran en el siguiente ejemplo.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
La partición `queue1` es `INACTIVE` debido a que se detectaron 10 errores consecutivos de arranque de nodos de cómputo.
Las instancias situadas detrás de los nodos `queue1-dy-c5xlarge-[1-10]` se lanzaron pero no pudieron unirse al clúster debido a un estado incorrecto.
El clúster se encuentra en estado protegido.
Los errores de arranque `queue2` no afectan a la partición `queue1`. Está en el `UP` estado y aún puede ejecutar trabajos.
## ¿Cómo desactivar el estado de protección
Una vez resuelto el error de arranque, puede ejecutar el siguiente comando para que el clúster deje de estar protegido.
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## Fallos de Bootstrap que activan el estado protegido
Los errores de Bootstrap que activan el estado protegido se subdividen en los tres tipos siguientes. Para identificar el tipo y el problema, puedes comprobar si se AWS ParallelCluster generaron registros. Si se generaron registros, puede consultarlos para ver los detalles del error. Para obtener más información, consulte [Recuperación y conservación de registros](troubleshooting-v3-get-logs.md).
1. **Error de Bootstrap que provoca que una instancia se cierre automáticamente**.
Una instancia falla al principio del proceso de arranque, como una instancia que se cierra automáticamente debido a errores en el script [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) \$1 [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions) \$1 [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart) \$1 [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured).
En el caso de los nodos dinámicos, busque errores similares a estos:
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
Para los nodos estáticos, busque errores similares a los siguientes en el registro de `clustermgtd` (`/var/log/parallelcluster/clustermgtd`):
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. **El nodo `resume_timeout` o `node_replacement_timeout` caduca**.
Una instancia no puede unirse al clúster dentro de `resume_timeout` (para nodos dinámicos) o `node_replacement_timeout` (para nodos estáticos). No se autofinaliza antes de que se agote el tiempo de espera. Por ejemplo, la red no está configurada correctamente para el clúster y el nodo está configurado en ese `DOWN` estado mediante Slurm una vez transcurrido el tiempo de espera.
En el caso de los nodos dinámicos, busque errores similares a estos:
```
Node bootstrap error: Resume timeout expires for node
```
Para los nodos estáticos, busque errores similares a los siguientes en el registro de `clustermgtd` (`/var/log/parallelcluster/clustermgtd`):
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. **Los nodos no pasan la comprobación de estado**.
Una instancia detrás del nodo no pasa una comprobación de EC2 estado de Amazon o una comprobación de estado de un evento programado, y los nodos se tratan como nodos de fallo de arranque. En este caso, la instancia finaliza por un motivo ajeno al control de. AWS ParallelCluster
Busque errores similares a los siguientes en el registro de `clustermgtd` (`/var/log/parallelcluster/clustermgtd`):
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. **Los nodos de computación fallan Slurm registro**.
El registro del `slurmd` daemon en el Slurm el daemon de control (`slurmctld`) falla y hace que el estado del nodo de cómputo cambie a ese estado. `INVALID_REG` Configurado incorrectamente Slurm los nodos de cómputo pueden provocar este error, como los nodos computados configurados con errores de especificación de nodos de [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)cómputo.
Busque errores similares a los siguientes en el archivo de registro `slurmctld` (`/var/log/slurmctld.log`) del nodo principal o en el archivo de registro `slurmd` (`/var/log/slurmd.log`) del nodo de cómputo fallido:
```
Setting node %s to INVAL with reason: ...
```
## Cómo depurar el modo protegido
Si el clúster se encuentra en estado protegido y AWS ParallelCluster ha generado `clustermgtd` registros a partir de ellos `HeadNode` y de `cloud-init-output` los nodos de procesamiento problemáticos, puede comprobar los registros para ver los detalles del error. Para obtener más información acerca de la recuperación de registros, consulte [Recuperación y conservación de registros](troubleshooting-v3-get-logs.md).
**Registro `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) en el nodo principal**
Los mensajes de registro muestran qué particiones tienen errores de arranque y el recuento de errores de arranque correspondiente.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
En el registro `clustermgtd`, busque en `Found the following bootstrap failure nodes` qué nodo no se pudo iniciar.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
En el registro de `clustermgtd`, busque `Node bootstrap error` para conocer el motivo del error.
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
**Registro `cloud-init-output` (`/var/log/cloud-init-output.log`) en los nodos de cómputo**
Tras obtener la dirección IP privada del nodo de error de arranque en el registro `clustermgtd`, puede encontrar el registro del nodo de procesamiento correspondiente iniciando sesión en el nodo de procesamiento o siguiendo las instrucciones [Recuperación y conservación de registros](troubleshooting-v3-get-logs.md) para recuperar los registros. En la mayoría de los casos, el registro `/var/log/cloud-init-output` del nodo problemático muestra el paso que provocó el error de arranque del nodo de cómputo.
# Conmutación por error rápida de capacidad insuficiente en el clúster de Slurm
A partir de la AWS ParallelCluster versión 3.2.0, los clústeres se ejecutan con el modo de conmutación por error rápida y con capacidad insuficiente activado de forma predeterminada. Esto minimiza el tiempo que se tarda en volver a poner en cola un trabajo cuando se detectan errores de capacidad insuficiente de Amazon EC2. Esto resulta especialmente eficaz cuando se configura la cola con varios recursos informáticos que utilizan distintos tipos de instancias.
**Amazon EC2 detectó fallos por capacidad insuficiente:**
+ `InsufficientInstanceCapacity`
+ `InsufficientHostCapacity`
+ `InsufficientReservedInstanceCapacity`
+ `MaxSpotInstanceCountExceeded`
+ `SpotMaxPriceTooLow`: se activa si el precio de solicitud de spot es menor que el precio mínimo requerido de cumplimiento de la solicitud de spot.
+ `Unsupported`: Se activa con el uso de un tipo de instancia que no es compatible con un tipo específico Región de AWS.
En el modo de conmutación rápida por error con capacidad insuficiente, si se detecta un error de capacidad insuficiente al asignar una tarea a [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`compute resource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources), AWS ParallelCluster hace lo siguiente:
1. Establece el recurso de computación en un estado deshabilitado (`DOWN`) durante un periodo de tiempo predefinido.
1. Utiliza `POWER_DOWN_FORCE` para cancelar los trabajos de los nodos fallidos del recurso de computación y para suspender el nodo fallido. Establece el nodo fallido en el estado `IDLE` y `POWER_DOWN (!)` y, después, en `POWERING_DOWN (%)`.
1. Vuelve a poner el trabajo en cola para enviarlo a otro recurso de computación.
Los nodos estáticos y encendidos del recurso de computación deshabilitado no se ven afectados. Los trabajos se pueden completar en estos nodos.
Este ciclo se repite hasta que el trabajo se asigne correctamente a uno o varios nodos de recursos de computación. Para obtener más información sobre los estados de los nodos, consulte [Guía de Slurm para el modo de cola múltiple](multiple-queue-mode-slurm-user-guide-v3.md).
Si no se encuentra ningún recurso de computación para ejecutar el trabajo, el trabajo se establece en el estado `PENDING` hasta que transcurra el periodo de tiempo predefinido. En este caso, puede modificar el periodo de tiempo predefinido tal y como se describe en la siguiente sección.
## Parámetro de tiempo de espera de capacidad insuficiente
**`insufficient_capacity_timeout`**
`insufficient_capacity_timeout` especifica el periodo de tiempo (en segundos) durante el que el recurso de computación permanece en estado deshabilitado (`down`) cuando se detecta un error de capacidad insuficiente.
De forma predeterminada, `insufficient_capacity_timeout` está habilitado.
El valor predeterminado de `insufficient_capacity_timeout` es 600 segundos (10 minutos).
Si el valor de `insufficient_capacity_timeout` es menor o igual a cero, se deshabilita el modo de conmutación por error rápida con capacidad insuficiente.
Puede cambiar el valor de `insufficient_capacity_timeout` añadiendo el parámetro en el archivo de configuración `clustermgtd` ubicado en `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` en el `HeadNode`.
Se puede actualizar el parámetro en cualquier momento sin detener la flota de computación.
Por ejemplo:
+ `insufficient_capacity_timeout=600`:
Si se detecta un error por capacidad insuficiente, el recurso de computación se establece como deshabilitado (`DOWN`). Transcurridos 10 minutos, el nodo fallido se establece en el estado `idle~` (`POWER_SAVING`).
+ `insufficient_capacity_timeout=60`:
Si se detecta un error por capacidad insuficiente, el recurso de computación se establece como deshabilitado (`DOWN`). Transcurrido 1 minutos, su nodo fallido se establece en el estado `idle~`.
+ `insufficient_capacity_timeout=0`:
El modo de conmutación por error rápida con capacidad insuficiente está deshabilitado. El recurso de computación no está deshabilitado.
**nota**
Es posible que haya un retraso de hasta un minuto entre el momento en que los nodos fallan debido a errores de capacidad insuficiente y el momento en que el daemon de administración de clústeres detecta los errores de los nodos. Esto se debe a que el daemon de administración de clústeres comprueba si hay errores de capacidad insuficiente en los nodos y establece el `down` estado de los recursos informáticos en intervalos de un minuto.
## Estado del modo de conmutación por error rápida de capacidad insuficiente
Cuando un clúster se encuentra en el modo de conmutación por error rápida con capacidad insuficiente, puede comprobar su estado y los estados de los nodos.
### Estados de los nodos
Cuando se envía un trabajo a un nodo dinámico de recursos de computación y se detecta un error de capacidad insuficiente, el nodo se coloca en el estado `down#` con el motivo.
```
(Code:InsufficientInstanceCapacity)Failure when resuming nodes.
```
A continuación, los nodos apagados (nodos en estado `idle~`) se establecen en `down~` con el motivo.
```
(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity.
```
El trabajo se vuelve a poner en cola en otros recursos de computación de la cola.
Los nodos estáticos del recurso de computación y los nodos que son `UP` no se ven afectados por el modo de conmutación por error rápida y con capacidad insuficiente.
Observe los estados de nodo que se muestran en el siguiente ejemplo.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Enviamos un trabajo a queue1 que requiere un nodo.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 1 down# queue1-dy-c-1-1
queue1* up infinite 15 idle~ queue1-dy-c-2-[1-15]
queue1* up infinite 14 down~ queue1-dy-c-1-[2-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Se lanza el nodo `queue1-dy-c-1-1` para ejecutar el trabajo. Sin embargo, no se pudo iniciar la instancia debido a un error de capacidad insuficiente. El nodo `queue1-dy-c-1-1` está configurado en `down`. El nodo dinámico apagado dentro del recurso de computación (`queue2-dy-c-1`) está establecido en `down`.
Puede consultar el motivo del nodo con `scontrol show nodes`.
```
$ scontrol show nodes queue1-dy-c-1-1
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Failure when resuming nodes [root@2022-03-10T22:17:50]
$ scontrol show nodes queue1-dy-c-1-2
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity [root@2022-03-10T22:17:50]
```
El trabajo está en cola para otro tipo de instancias dentro de los recursos de computación de la cola.
Una vez transcurrido `insufficient_capacity_timeout`, los nodos del recurso de computación se restablecen a su estado `idle~`.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Una vez transcurrido `insufficient_capacity_timeout` y que los nodos del recurso de computación se hayan restablecido al estado `idle~`, el programador Slurm asigna a los nodos una prioridad inferior. El programador sigue seleccionando nodos de otros recursos de computación de cola con pesos más altos, a menos que se produzca una de las siguientes situaciones:
+ Los requisitos de envío de un trabajo coinciden con el recurso de computación recuperado.
+ No hay otros recursos de computación disponibles porque están al límite de su capacidad.
+ `slurmctld` se reinicia.
+ La flota AWS ParallelCluster informática se detiene y comienza a apagar y encender todos los nodos.
### Registros relacionados
Los registros relacionados con los errores de capacidad insuficiente y el modo de conmutación rápida por error con capacidad insuficiente se encuentran en el registro `resume` y el registro `clustermgtd` de Slurm del nodo principal.
**Slurm `resume` (`/var/log/parallelcluster/slurm_resume.log`)**
Mensajes de error cuando un nodo no se inicia debido a una capacidad insuficiente.
```
[slurm_plugin.instance_manager:_launch_ec2_instances] - ERROR - Failed RunInstances request: dcd0c252-90d4-44a7-9c79-ef740f7ecd87
[slurm_plugin.instance_manager:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['queue1-dy-c-1-1']: An error occurred
(InsufficientInstanceCapacity) when calling the RunInstances operation (reached max retries: 1): We currently do not have sufficient p4d.24xlarge capacity in the
Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get p4d.24xlarge capacity by not
specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
```
**Slurm `clustermgtd` (`/var/log/parallelcluster/clustermgtd`)**
El recurso de computación c-1 de la queue1 está deshabilitado debido a una capacidad insuficiente.
```
[slurm_plugin.clustermgtd:_reset_timeout_expired_compute_resources] - INFO - The following compute resources are in down state
due to insufficient capacity: {'queue1': {'c-1': ComputeResourceFailureEvent(timestamp=datetime.datetime(2022, 4, 14, 23, 0, 4, 769380, tzinfo=datetime.timezone.utc),
error_code='InsufficientInstanceCapacity')}}, compute resources are reset after insufficient capacity timeout (600 seconds) expired
```
Una vez transcurrido el tiempo de espera de capacidad insuficiente, el recurso de computación se restablece y los nodos de los recursos de computación se establecen en `idle~`.
```
[root:_reset_insufficient_capacity_timeout_expired_nodes] - INFO - Reset the following compute resources because insufficient capacity
timeout expired: {'queue1': ['c-1']}
```
# Slurm programación basada en memoria
A partir de la versión 3.2.0, admite AWS ParallelCluster Slurm programación basada en memoria con el parámetro de configuración [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)cluster.
**nota**
[A partir de AWS ParallelCluster la versión 3.7.0, se `EnableMemoryBasedScheduling` puede habilitar si configuras varios tipos de instancias en Instances.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Para AWS ParallelCluster las versiones 3.2.0 a 3.6. *x*, no se `EnableMemoryBasedScheduling` puede habilitar si configuras varios tipos de [instancias en Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
**aviso**
Cuando especificas varios tipos de instancias en un Slurm coloque un recurso de cómputo en cola con la `EnableMemoryBasedScheduling` opción habilitada, el `RealMemory` valor es la cantidad mínima de memoria disponible para todos los tipos de instancias. Si especificas tipos de instancias con capacidades de memoria muy diferentes, esto podría provocar que se desperdicie una cantidad significativa de memoria.
Con`EnableMemoryBasedScheduling: true`, el Slurm el programador rastrea la cantidad de memoria que requiere cada trabajo en cada nodo. Luego, el Slurm el programador usa esta información para programar varios trabajos en el mismo nodo de cómputo. La cantidad total de memoria que requieren los trabajos en un nodo no puede ser mayor que la memoria de nodo disponible. El programador evita que un trabajo utilice más memoria de la que se solicitó cuando se envió el trabajo.
Con `EnableMemoryBasedScheduling: false`, los trabajos podrían competir por la memoria en un nodo compartido y provocar errores y `out-of-memory` eventos en los trabajos.
**aviso**
Slurm utiliza una notación de potencia de 2 para sus etiquetas, como MB o GB. Lea estas etiquetas como MiB y GiB, respectivamente.
## Slurm configuración y programación basada en memoria
Con, `EnableMemoryBasedScheduling: true` Slurm establece lo siguiente Slurm parámetros de configuración:
+ [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory) en la `slurm.conf`. Esta opción configura la memoria del nodo para que sea un recurso consumible en Slurm.
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)en el Slurm `cgroup.conf`. Con esta opción, el acceso de un trabajo a la memoria se limita a la cantidad de memoria que el trabajo solicitó cuando se envió.
**nota**
Varios otros Slurm los parámetros de configuración pueden afectar al comportamiento del Slurm programador y administrador de recursos cuando se configuran estas dos opciones. Para obtener más información, consulte la [.Slurm Documentación. ](https://slurm.schedmd.com/documentation.html)
## Slurm programador y programación basada en memoria
**`EnableMemoryBasedScheduling: false` (predeterminado)**
De forma predeterminada, `EnableMemoryBasedScheduling` se establece en "false". Si es falsa, Slurm no incluye la memoria como recurso en su algoritmo de programación y no rastrea la memoria que utilizan los trabajos. Los usuarios pueden especificar la `--mem MEM_PER_NODE` opción de establecer la cantidad mínima de memoria por nodo que requiere un trabajo. Esto obliga al programador a elegir nodos con un `RealMemory` valor de al menos `MEM_PER_NODE` al programar el trabajo.
Por ejemplo, supongamos que un usuario envía dos trabajos con `--mem=5GB`. Si los recursos solicitados, por ejemplo, GPUs están disponibles CPUs o están disponibles, los trabajos se pueden ejecutar al mismo tiempo en un nodo con 8 GiB de memoria. Los dos trabajos no están programados en nodos de procesamiento con menos de 5 GiB de `RealMemory`.
**aviso**
Cuando la programación basada en memoria está desactivada, Slurm no registra la cantidad de memoria que utilizan los trabajos. Los trabajos que se ejecutan en el mismo nodo pueden competir por los recursos de memoria y provocar que el otro trabajo falle.
Cuando la programación basada en memoria está deshabilitada, se recomienda a los usuarios que no especifiquen las opciones [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu) o [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu). Estas opciones pueden provocar un comportamiento diferente al que se describe en la [Slurm Documentación](https://slurm.schedmd.com/documentation.html).
**`EnableMemoryBasedScheduling: true`**
Cuando `EnableMemoryBasedScheduling` se establece en verdadero, Slurm realiza un seguimiento del uso de memoria de cada trabajo y evita que los trabajos consuman más memoria de la solicitada con las opciones de `--mem` envío.
En el ejemplo anterior, un usuario envía dos trabajos con`--mem=5GB`. Los trabajos no se pueden ejecutar al mismo tiempo en un nodo con 8 GiB de memoria. Esto se debe a que la cantidad total de memoria necesaria es mayor que la memoria disponible en el nodo.
Con la programación basada en la memoria habilitada `--mem-per-cpu` y `--mem-per-gpu` compórtese de forma coherente con lo que se describe en la Slurm . Por ejemplo, un trabajo se envía con `--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB`. En este caso, Slurm asigna al trabajo un total de 4 GiB para cada nodo.
**aviso**
Cuando la programación basada en memoria está habilitada, recomendamos que los usuarios incluyan una especificación `--mem` al enviar un trabajo. Con el valor predeterminado Slurm la configuración que se incluye AWS ParallelCluster, si no se incluye ninguna opción de memoria (`--mem`,`--mem-per-cpu`, o`--mem-per-gpu`), Slurm asigna toda la memoria de los nodos asignados a la tarea, incluso si solo solicita una parte de los demás recursos, como CPUs o GPUs. De esta forma, se evita que se compartan nodos hasta que finalice el trabajo, ya que no hay memoria disponible para otros trabajos. Esto sucede porque Slurm establece la memoria por nodo para el trabajo en caso de que no [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)se proporcionen especificaciones de memoria en el momento de enviar el trabajo. El valor predeterminado de este parámetro es 0 y especifica un acceso ilimitado a la memoria de un nodo.
Si hay varios tipos de recursos informáticos con diferentes cantidades de memoria disponibles en la misma cola, es posible que a un trabajo enviado sin opciones de memoria se le asignen diferentes cantidades de memoria en distintos nodos. Esto depende de los nodos que el programador ponga a disposición del trabajo. Los usuarios pueden definir un valor personalizado para las opciones, por ejemplo [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU), `DefMemPerNode` o, a nivel de clúster o partición en el Slurm archivos de configuración para evitar este comportamiento.
## Slurm RealMemory y AWS ParallelCluster SchedulableMemory
Con el Slurm configuración que se suministra con AWS ParallelCluster, Slurm se interpreta [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)como la cantidad de memoria por nodo disponible para las tareas. A partir de la versión 3.2.0, de forma predeterminada, se AWS ParallelCluster establece `RealMemory` en el 95 por ciento de la memoria que aparece en [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types) y que devuelve la EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)de Amazon.
Cuando la programación basada en memoria está inhabilitada, Slurm el planificador se utiliza `RealMemory` para filtrar los nodos cuando los usuarios envían un trabajo con una especificación. `--mem`
Cuando la programación basada en memoria está habilitada, Slurm el planificador se interpreta como la cantidad máxima de memoria disponible `RealMemory` para los trabajos que se ejecutan en el nodo de cómputo.
Es posible que la configuración predeterminada no sea óptima para todos los tipos de instancias:
+ Esta configuración puede ser superior a la cantidad de memoria a la que realmente pueden acceder los nodos. Esto puede suceder cuando los nodos de cómputo son tipos de instancias pequeñas.
+ Esta configuración puede ser superior a la cantidad de memoria a la que realmente pueden acceder los nodos. Esto puede ocurrir cuando los nodos de cómputo son tipos de instancias grandes y puede generar una cantidad significativa de memoria no utilizada.
Puede usar [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)para ajustar el valor de `RealMemory` configurado por AWS ParallelCluster para los nodos de cómputo. Para anular el valor predeterminado, defina un valor personalizado específico para `SchedulableMemory` para la configuración de su clúster.
Para comprobar la memoria disponible real de un nodo de cómputo, ejecuta el `/opt/slurm/sbin/slurmd -C` comando en el nodo. Este comando devuelve la configuración de hardware del nodo, incluido el [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)valor. Para obtener más información, consulte [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C).
Asegúrese de que los procesos del sistema operativo del nodo de cómputo tengan suficiente memoria. Para ello, limite la memoria disponible para los trabajos configurando el `SchedulableMemory` valor en un valor inferior al `RealMemory` valor devuelto por el comando `slurmd -C`.
# Asignación de varios tipos de instancias con Slurm
A partir de AWS ParallelCluster la versión 3.3.0, puedes configurar tu clúster para que se asigne a partir del conjunto de tipos de instancias definidos de un recurso informático. La asignación puede basarse en estrategias de bajo coste o de capacidad óptima de la EC2 flota de Amazon.
Este conjunto de tipos de instancias definidos debe tener todos el mismo número de v CPUs o, si el multiproceso está desactivado, el mismo número de núcleos. Además, este conjunto de tipos de instancias debe tener el mismo número de aceleradores de los mismos fabricantes. Si [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa)/[`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa-Enabled) se establece en `true`, las instancias deben ser compatibles con EFA. Para obtener más información y conocer los requisitos, consulte [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy) y [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Puede [`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)configurarlo en `lowest-price` o en `capacity-optimized` función de su [CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType)configuración.
En [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances), puede configurar un conjunto de tipos de instancias.
**nota**
A partir de AWS ParallelCluster la versión 3.7.0, se `EnableMemoryBasedScheduling` puede habilitar si configuras varios tipos de [instancias en Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Para AWS ParallelCluster las versiones 3.2.0 a 3.6. *x*, no se `EnableMemoryBasedScheduling` puede habilitar si configuras varios tipos de [instancias en Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Los siguientes ejemplos muestran cómo puedes consultar los tipos de instancias para vCPUs, la compatibilidad con EFA y la arquitectura.
Consultar InstanceTypes con arquitectura 96 v CPUs y x86\$164.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-vcpus,Values=96" "Name=processor-info.supported-architecture,Values=x86_64" \
--query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
Consultar InstanceTypes con 64 núcleos, compatibilidad con EFA y arquitectura arm64.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-cores,Values=64" "Name=processor-info.supported-architecture,Values=arm64" "Name=network-info.efa-supported,Values=true" --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
El siguiente ejemplo de fragmento de configuración de clústeres muestra cómo puede utilizarlos InstanceType y AllocationStrategy propiedades.
```
...
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-1
CapacityType: ONDEMAND
AllocationStrategy: lowest-price
...
ComputeResources:
- Name: computeresource1
Instances:
- InstanceType: r6g.2xlarge
- InstanceType: m6g.2xlarge
- InstanceType: c6g.2xlarge
MinCount: 0
MaxCount: 500
- Name: computeresource2
Instances:
- InstanceType: m6g.12xlarge
- InstanceType: x2gd.12xlarge
MinCount: 0
MaxCount: 500
...
```
# Escalado de clústeres para nodos dinámicos
ParallelCluster admite Slurm métodos para escalar clústeres de forma dinámica mediante el Slurm complemento Power Saver. Para obtener más información, consulte la [Guía de programación en la nube](https://slurm.schedmd.com/elastic_computing.html) y la [Guía de ahorro de energía de Slurm](https://slurm.schedmd.com/power_save.html) en la documentación de Slurm. En las siguientes secciones se describen las estrategias de cada versión de Slurm.
**Topics**
+ [Estrategias de asignación de nodos dinámicos en Slurm 3.8.0](scheduler-node-allocation-v3-3.8.0.md)
+ [Estrategias de asignación de nodos dinámicos en Slurm 3.7.x](scheduler-dynamic-node-allocation-v3-3.7.x.md)
+ [Estrategias de asignación de nodos dinámicos en Slurm 3.6.x y versiones anteriores](scheduler-dynamic-node-allocation-v3-3.6.x.md)
# Estrategias de asignación de nodos dinámicos en Slurm 3.8.0
A partir de la ParallelCluster versión 3.8.0, ParallelCluster utiliza la **reanudación a nivel** de **trabajo o el escalado a nivel** de trabajo como estrategia de asignación dinámica de nodos predeterminada para escalar el clúster: ParallelCluster amplía el clúster en función de los requisitos de cada trabajo, la cantidad de nodos asignados al trabajo y los nodos que deben reanudarse. ParallelCluster obtiene esta información de la variable de entorno SLURM\$1RESUME\$1FILE.
El escalado de nodos dinámicos es un proceso de dos pasos que implica el lanzamiento de instancias de EC2 y la asignación de las instancias de Amazon EC2 lanzadas a los nodos de Slurm. **Cada uno de estos dos pasos se puede realizar utilizando una o más lógicas. **all-or-nothing****
Al iniciar instancias de Amazon EC2:
+ **all-or-nothing**llama a la API Amazon EC2 de lanzamiento con un objetivo mínimo igual a la capacidad total del objetivo
+ **óptimo** llama al lanzamiento de la API de Amazon EC2 con un destino mínimo igual a 1 y una capacidad de destino total equivalente a la capacidad solicitada
Al asignar las instancias de Amazon EC2 a los nodos de Slurm:
+ **all-or-nothing**asigna instancias de Amazon EC2 Slurm a los nodos solo si es posible asignar una instancia de Amazon EC2 a cada nodo solicitado
+ **óptimo** asigna instancias de Amazon EC2 a los nodos de Slurm incluso si alguno de los nodos solicitados no está cubierto por la capacidad de instancias de Amazon EC2
Las posibles combinaciones de las estrategias anteriores se traducen en estrategias de ParallelCluster lanzamiento.
**Example** [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)
**all-or-nothing**escalado:
Esta estrategia implica AWS ParallelCluster iniciar una llamada a la API de la instancia de lanzamiento de Amazon EC2 para cada trabajo, que requiere todas las instancias necesarias para que los nodos de cómputo solicitados se lancen correctamente. Así se garantiza que el clúster se escale solo cuando esté disponible la capacidad necesaria para el trabajo, lo que evita que queden instancias inactivas al final del proceso de escalado.
La estrategia utiliza una **all-or-nothing**lógica para el lanzamiento de las instancias de Amazon EC2 para cada trabajo y una **all-or-nothing**lógica para la asignación de las instancias de Amazon EC2 a los nodos. Slurm
Esta estrategia agrupa las solicitudes de lanzamiento en lotes, uno por cada recurso de computación solicitado y hasta 500 nodos cada uno. Para las solicitudes que abarcan varios recursos informáticos o que superan los 500 nodos, procesa varios lotes de ParallelCluster forma secuencial.
Si se produce un error en un lote de un solo recurso, finaliza toda la capacidad no utilizada asociada, de manera que no quede ninguna instancia inactiva al final del proceso de escalado.
Limitaciones
+ El tiempo que se necesita para escalar es directamente proporcional al número de trabajos enviados por cada ejecución del programa de reanudación de Slurm.
+ La operación de escalado está limitada por el límite de la cuenta de RunInstances recursos, establecido en 1000 instancias de forma predeterminada. Esta limitación está de acuerdo con las políticas de regulación AWS de las API de EC2. Para obtener más información, consulte la documentación de regulación de las API de [Amazon](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html) EC2.
+ Cuando envía un trabajo en un recurso informático con un solo tipo de instancia, en una cola que abarca varias zonas de disponibilidad, la llamada a la API de lanzamiento de **all-or-nothing**EC2 solo se realiza correctamente si se puede proporcionar toda la capacidad en una sola zona de disponibilidad.
+ Al enviar un trabajo en un recurso informático con varios tipos de instancias, en una cola con una única zona de disponibilidad, la llamada a la API de lanzamiento de **all-or-nothing**Amazon EC2 solo se realiza correctamente si un único tipo de instancia puede proporcionar toda la capacidad.
+ Cuando envías un trabajo en un recurso informático con varios tipos de instancias, en una cola que abarca varias zonas de disponibilidad, no se admite la llamada a la **all-or-nothing**API de lanzamiento de Amazon EC2 ParallelCluster y, en cambio, **realiza** el escalado al máximo.
**greedy-all-or-nothing**escalado:
Esta variante de la all-or-nothing estrategia sigue garantizando que el clúster escale solo cuando esté disponible la capacidad requerida por trabajo, lo que evita las instancias inactivas al final del proceso de escalado, pero implica ParallelCluster iniciar una llamada a la API de la instancia de lanzamiento de Amazon EC2 que apunta a una capacidad objetivo mínima de 1, con el fin de maximizar el número de nodos lanzados hasta la capacidad solicitada. La estrategia utiliza una lógica de máximo esfuerzo para el lanzamiento de las instancias EC2 para todos los trabajos, además de la **all-or-nothing**lógica para la asignación de las instancias de Amazon EC2 Slurm a los nodos de cada trabajo.
Esta estrategia agrupa las solicitudes de lanzamiento en lotes, uno por cada recurso de computación solicitado y hasta 500 nodos cada uno. Para las solicitudes que abarcan varios recursos informáticos o que superan los 500 nodos, procesa varios lotes de ParellelCluster forma secuencial.
Así, se garantiza que no queda ninguna instancia inactiva al final del proceso de escalado, maximizando el rendimiento a costa de una sobreescalabilidad temporal durante el proceso de escalado.
Limitaciones
+ Es posible que se produzca un sobreescalado temporal, lo que conllevará costos adicionales para las instancias que pasen a un estado de ejecución antes de completar el escalado.
+ Se aplica el mismo límite de instancias que en la all-or-nothing estrategia, sujeto al límite AWS de la cuenta de RunInstances recursos.
Escalado **óptimo**:
Esta estrategia hace una llamada a la API de instancia de lanzamiento de Amazon EC2 con una capacidad mínima de 1 y tiene como objetivo alcanzar la capacidad total solicitada a costa de dejar las instancias inactivas tras la ejecución del proceso de escalado si no está disponible toda la capacidad solicitada. La estrategia utiliza una lógica óptima para lanzar instancias de Amazon EC2 para todos los trabajos y una lógica **óptima** para asignar las instancias de Amazon EC2 a los nodos de Slurm de cada trabajo.
Esta estrategia agrupa las solicitudes de lanzamiento en lotes, uno por cada recurso de computación solicitado y hasta 500 nodos cada uno. Para las solicitudes que abarcan varios recursos informáticos o que superan los 500 nodos, procesa varios lotes de ParallelCluster forma secuencial.
Esta estrategia permite escalar mucho más allá del límite predeterminado de 1000 instancias en varias ejecuciones de procesos de escalado, a costa de tener instancias inactivas en los diferentes procesos de escalado.
Limitaciones
+ Es posible que las instancias estén inactivas al final del proceso de escalado, en el caso de que no sea posible asignar todos los nodos solicitados por los trabajos.
**El siguiente es un ejemplo que muestra cómo se comporta el escalado de los nodos dinámicos utilizando las diferentes ParallelCluster estrategias de lanzamiento.** Supongamos que ha enviado dos trabajos en los que se solicitaban 20 nodos para cada uno, es decir, un total de 40 nodos del mismo tipo, pero solo hay 30 instancias de Amazon EC2 disponibles para cubrir la capacidad solicitada en EC2.
**all-or-nothing**escalado:
+ Para el primer trabajo, se llama a una API de instancia de lanzamiento de ** all-or-nothing**Amazon EC2, que solicita 20 instancias. Si la llamada es correcta, se lanzarán 20 instancias.
+ **all-or-nothing **La asignación de las 20 instancias lanzadas a Slurm los nodos para el primer trabajo se realizó correctamente
+ Se llama a otra API de instancia de lanzamiento de **all-or-nothing**Amazon EC2, que solicita 20 instancias para el segundo trabajo. La llamada no se realiza correctamente, ya que solo hay capacidad para otras 10 instancias. Así pues, en este caso no se lanza ninguna instancia.
**greedy-all-or-nothing**escalado:
+ Se llama a una API de instancia de lanzamiento de Amazon EC2 de tipo **óptimo**, que solicita 40 instancias, que es la capacidad total solicitada por todos los trabajos. Esto hace que se lancen 30 instancias.
+ La **all-or-nothing**asignación de 20 de las instancias lanzadas a Slurm los nodos para el primer trabajo se realiza correctamente
+ Se intenta volver a **all-or-nothing**asignar las instancias lanzadas restantes a Slurm los nodos para el segundo trabajo, pero dado que solo hay 10 instancias disponibles del total de 20 solicitadas por el trabajo, la asignación no se realiza correctamente
+ Las 10 instancias lanzadas que no se han asignado finalizan.
Escalado **óptimo**:
+ Se llama a una API de instancia de lanzamiento de Amazon EC2 de tipo **óptimo**, que solicita 40 instancias, que es la capacidad total solicitada por todos los trabajos. Esto hace que se lancen 30 instancias.
+ Se realiza correctamente una asignación de tipo **óptimo** de las 20 instancias lanzadas a los nodos de Slurm para el primer trabajo.
+ Se lanza una segunda asignación de tipo **óptimo** con las 10 instancias restantes a los nodos de Slurm para el segundo trabajo, aunque la capacidad total solicitada fuera de 20. Sin embargo, como el trabajo requería 20 nodos y solo era posible asignar instancias de Amazon EC2 a 10 de ellos, el trabajo no puede iniciarse y las instancias se quedan inactivas hasta que se encuentre la capacidad suficiente para iniciar las 10 instancias restantes en una llamada posterior del proceso de escalado, o cuando el programador programe el trabajo en otros nodos de computación que ya estén ejecutándose.
# Estrategias de asignación de nodos dinámicos en Slurm 3.7.x
ParallelCluster utiliza dos tipos de estrategias de asignación dinámica de nodos para escalar el clúster:
+
**Asignación basada en la información de nodos solicitada disponible:**
+ **Reanudación de todos los nodos** o escalado de **lista de nodos**:
ParallelCluster amplía el clúster basándose únicamente en los nombres Slurm de la lista de nodos solicitada cuando Slurm `ResumeProgram` se ejecuta. Asigna recursos de computación a los nodos solo por nombre de nodo. La lista de nombres de nodos puede abarcar varios trabajos.
+ **Reanudación a nivel de trabajo** o escalado **a nivel de trabajo**:
ParallelCluster amplía el clúster en función de los requisitos de cada trabajo, el número actual de nodos que están asignados al trabajo y los nodos que deben reanudarse. ParallelCluster obtiene esta información de la variable de `SLURM_RESUME_FILE` entorno.
+
**Asignación con una estrategia de lanzamiento de Amazon EC2:**
+ Escalado **óptimo**:
ParallelCluster amplía el clúster mediante una llamada a la API de la instancia de lanzamiento de Amazon EC2 con una capacidad de destino mínima igual a 1, para lanzar algunas instancias, pero no necesariamente todas, necesarias para admitir los nodos solicitados.
+ **Un ll-or-nothing** escalamiento:
ParallelCluster amplía el clúster mediante una llamada a la API de la instancia de lanzamiento de Amazon EC2 que solo tiene éxito si se lanzan todas las instancias necesarias para admitir los nodos solicitados. En este caso, llama a la API de la instancia de lanzamiento de Amazon EC2 con una capacidad de destino mínima igual a la capacidad total solicitada.
De forma predeterminada, ParallelCluster utiliza el escalado de **listas** de nodos con la **mejor** estrategia de lanzamiento de Amazon EC2 para lanzar algunas instancias, pero no necesariamente todas, necesarias para admitir los nodos solicitados. Intenta proporcionar la mayor capacidad posible para atender la carga de trabajo enviada.
**A partir de la ParallelCluster versión 3.7.0, ParallelCluster utiliza el escalado a **nivel de trabajo con una estrategia** de lanzamiento de **all-or-nothing**EC2 para los trabajos enviados en modo exclusivo.** Cuando envía un trabajo en modo exclusivo, el trabajo tiene acceso exclusivo a los nodos asignados. Para obtener más información, consulte [EXCLUSIVE](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE) en la documentación de Slurm.
Para enviar un trabajo en modo exclusivo:
+ Pase la marca de exclusividad al enviar un trabajo de Slurm al clúster. Por ejemplo, `sbatch ... --exclusive`.
OR
+ Envíe un trabajo a una cola de clústeres que se haya configurado con el valor [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation) establecido en `true`.
Al enviar un trabajo en modo exclusivo:
+ ParallelCluster actualmente, agrupa las solicitudes de lanzamiento por lotes para incluir hasta 500 nodos. Si un trabajo solicita más de 500 nodos, ParallelCluster realiza una solicitud de **all-or-nothing**lanzamiento para cada conjunto de 500 nodos y una solicitud de lanzamiento adicional para el resto de los nodos.
+ Si la asignación de nodos se realiza en un único recurso informático, ParallelCluster realiza una solicitud de **all-or-nothing**lanzamiento para cada conjunto de 500 nodos y una solicitud de lanzamiento adicional para el resto de los nodos. Si se produce un error en una solicitud de lanzamiento, ParallelCluster cancela la capacidad no utilizada creada por todas las solicitudes de lanzamiento.
+ Si la asignación de nodos abarca varios recursos informáticos, ParallelCluster debe realizar una solicitud de **all-or-nothing**lanzamiento para cada recurso informático. Estas solicitudes también se agrupan en lotes. Si se produce un error en una solicitud de lanzamiento para uno de los recursos informáticos, ParallelCluster se cancela la capacidad no utilizada creada por todas las solicitudes de lanzamiento de los recursos informáticos.
escalamiento a **nivel de trabajo** con limitaciones conocidas de la estrategia de **all-or-nothing**lanzamiento:
+ Al enviar un trabajo en un recurso informático con un solo tipo de instancia, en una cola que abarca varias zonas de disponibilidad, la llamada a la API de lanzamiento de **all-or-nothing**EC2 solo se realiza correctamente si se puede proporcionar toda la capacidad en una sola zona de disponibilidad.
+ Al enviar un trabajo en un recurso informático con varios tipos de instancias, en una cola con una única zona de disponibilidad, la llamada a la API de lanzamiento de **all-or-nothing**Amazon EC2 solo se realiza correctamente si un único tipo de instancia puede proporcionar toda la capacidad.
+ Cuando envías un trabajo en un recurso informático con varios tipos de instancias, en una cola que abarca varias zonas de disponibilidad, no se admite la llamada a la **all-or-nothing**API de lanzamiento de Amazon EC2 ParallelCluster y, en cambio, **realiza** el escalado al máximo.
# Estrategias de asignación de nodos dinámicos en Slurm 3.6.x y versiones anteriores
AWS ParallelCluster utiliza solo un tipo de estrategia de asignación dinámica de nodos para escalar el clúster:
+ Asignación basada en la información de nodos solicitada disponible:
+ **Reanudación de todos los nodos** **o escalado de la lista** de nodos: cuando Slurm se ejecuta, ParallelCluster amplía el clúster basándose únicamente en los nombres Slurm de la lista de nodos solicitada. `ResumeProgram` Asigna recursos de computación a los nodos solo por nombre de nodo. La lista de nombres de nodos puede abarcar varios trabajos.
+ Asignación con una estrategia de lanzamiento de Amazon EC2:
+ **Escalado** óptimo: ParallelCluster amplía el clúster mediante una llamada a la API de una instancia de lanzamiento de Amazon EC2 con una capacidad de destino mínima igual a 1, para lanzar algunas instancias, pero no necesariamente todas, necesarias para admitir los nodos solicitados.
ParallelCluster utiliza el escalado de **listas** de nodos con una estrategia **de** lanzamiento de Amazon EC2 que hace todo lo posible para lanzar algunas instancias, pero no necesariamente todas, necesarias para admitir los nodos solicitados. Intenta proporcionar la mayor capacidad posible para atender la carga de trabajo enviada.
Limitaciones
+ Es posible que las instancias estén inactivas al final del proceso de escalado, en el caso de que no sea posible asignar todos los nodos solicitados por los trabajos.
# Slurmcontabilidad con AWS ParallelCluster
A partir de la versión 3.3.0, AWS ParallelCluster admite la Slurm contabilidad con el parámetro de configuración del clúster [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Base de datos](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database).
A partir de la versión 3.10.0, AWS ParallelCluster admite la Slurm contabilidad con un Slurmdbd externo con el parámetro de configuración del clúster/. [SlurmSettings[ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)](Scheduling-v3.md#Scheduling-v3-SlurmSettings) Se recomienda usar un Slurmdbd externo si hay varios clústeres que comparten la misma base de datos.
Con la contabilidad de Slurm, puede integrar una base de datos contable externa para hacer lo siguiente:
+ Administre los usuarios o grupos de usuarios del clúster y otras entidades. Con esta capacidad, puede utilizar las funciones más avanzadas, como Slurm la aplicación de los límites de recursos, el reparto justo y. QOSs
+ Recopile y guarde datos del trabajo, como el usuario que lo ejecutó, la duración del trabajo y los recursos que utiliza. Puede ver los datos guardados con la utilidad `sacct`.
**nota**
AWS ParallelCluster admite la Slurm contabilidad de los [servidores de bases de datos MySQL Slurm compatibles](https://slurm.schedmd.com/accounting.html#mysql-configuration).
## Trabajando con la Slurm contabilidad mediante funciones externas Slurmdbd en la AWS ParallelCluster versión 3.10.0 y versiones posteriores
Antes de configurar la contabilidad de Slurm, debe disponer de un servidor de bases de datos de Slurmdbd externo, que se conecte a un servidor de base de datos externo existente.
Para configurarlo, defina lo siguiente:
+ [La dirección del Slurmdbd servidor externo en [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)/Host.](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ExternalSlurmdbd-Host) El servidor debe existir y ser accesible desde el nodo principal.
+ La tecla munge para comunicarse con el Slurmdbd servidor externo. [MungeKeySecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-MungeKeySecretArn)
Para ver un tutorial, consulte [Crear un clúster con un externo Slurmdbd contabilidad](external-slurmdb-accounting.md).
**nota**
Usted es responsable de administrar las entidades contables de la base de datos de Slurm.
La arquitectura de la función de SlurmDB soporte AWS ParallelCluster externo permite que varios clústeres compartan la misma SlurmDB base de datos.
![\[\]](http://docs.aws.amazon.com/es_es/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png)
**aviso**
El tráfico entre AWS ParallelCluster y el externo no SlurmDB está cifrado. Se recomienda ejecutar el clúster y el SlurmDB externo en una red de confianza.
## Trabajar con la Slurm contabilidad mediante el nodo principal Slurmdbd en la AWS ParallelCluster versión 3.3.0 y versiones posteriores
Antes de configurar la contabilidad de Slurm, debe disponer de un servidor de base de datos externo y de una base de datos que utilice el protocolo `mysql`.
Para configurar la Slurm contabilidad con AWS ParallelCluster, debe definir lo siguiente:
+ La URI del servidor de base de datos externo en [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri). El servidor debe existir y ser accesible desde el nodo principal.
+ Credenciales para acceder a la base de datos externa que se definen en [Base de datos](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn)y [Base de datos](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName). AWS ParallelCluster utiliza esta información para configurar la contabilidad a Slurm nivel y el `slurmdbd` servicio en el nodo principal. `slurmdbd`es el daemon que gestiona la comunicación entre el clúster y el servidor de la base de datos.
Para ver un tutorial, consulte [Crear un clúster con Slurm contabilidad](tutorials_07_slurm-accounting-v3.md).
**nota**
AWS ParallelCluster realiza un arranque básico de la base de datos de Slurm contabilidad al configurar el usuario predeterminado del clúster como administrador de la Slurm base de datos. AWS ParallelCluster no añade ningún otro usuario a la base de datos de contabilidad. El cliente debe encargarse de administrar las entidades de contabilidad de la base de datos de Slurm.
AWS ParallelCluster se configura [https://slurm.schedmd.com/slurmdbd.html](https://slurm.schedmd.com/slurmdbd.html)para garantizar que un clúster tenga su propia Slurm base de datos en el servidor de bases de datos. El mismo servidor de base de datos se puede utilizar en varios clústeres, pero cada clúster tiene su propia base de datos independiente. AWS ParallelCluster usa el nombre del clúster para definir el nombre de la base de datos en el [https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc)parámetro del archivo de `slurmdbd` configuración. Tenga en cuenta la siguiente situación. Una base de datos que está presente en el servidor de bases de datos incluye un nombre de clúster que no se corresponde con un nombre de clúster activo. En este caso, puede crear un clúster nuevo con ese nombre para asignarlo a esa base de datos. Slurm reutiliza la base de datos para el nuevo clúster.
**aviso**
No recomendamos configurar más de un clúster para usar la misma base de datos a la vez. Si lo hace, puede provocar problemas de rendimiento o incluso situaciones de bloqueo de la base de datos.
Si la contabilidad de Slurm está habilitada en el nodo principal de un clúster, recomendamos usar un tipo de instancia con una CPU potente, más memoria y un mayor ancho de banda de la red. La contabilidad de Slurm puede aumentar la presión sobre el nodo principal del clúster.
En la arquitectura actual de la función de AWS ParallelCluster Slurm contabilidad, cada clúster tiene su propia instancia del `slurmdbd` daemon, como se muestra en el siguiente diagrama de configuraciones de ejemplo.
![\[\]](http://docs.aws.amazon.com/es_es/parallelcluster/latest/ug/images/slurm-acct-arch.png)
Si va a añadir funcionalidades personalizadas de varios clústeres o de federación de Slurm a su entorno de clústeres, todos los clústeres deben hacer referencia a la misma instancia de `slurmdbd`. Como alternativa, le recomendamos que habilite la AWS ParallelCluster Slurm contabilidad en un clúster y que configure manualmente los demás clústeres para que se conecten a los `slurmdbd` que están alojados en el primer clúster.
Si utilizas AWS ParallelCluster versiones anteriores a la versión 3.3.0, consulta el método alternativo para implementar la Slurm contabilidad que se describe en esta entrada del [blog sobre HPC](https://aws.amazon.com/blogs/compute/enabling-job-accounting-for-hpc-with-aws-parallelcluster-and-amazon-rds/).
## Consideraciones sobre la contabilidad de Slurm
### La base de datos y el clúster son diferentes VPCs
Para habilitar la contabilidad de Slurm, se necesita un servidor de base de datos que sirva de backend para las operaciones de lectura y escritura que realiza el daemon `slurmdbd`. Antes de crear o actualizar el clúster para habilitar la contabilidad de Slurm, el nodo principal debe poder acceder al servidor de base de datos.
Si necesita implementar el servidor de base de datos en una VPC distinta de la que usa el clúster, tenga en cuenta lo siguiente:
+ Para habilitar la comunicación entre `slurmdbd` el servidor del clúster y el de la base de datos, debe configurar la conectividad entre ambos VPCs. Para obtener más información, consulte [Interconexión de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) en la *Guía del usuario de Amazon Virtual Private Cloud*.
+ Debe crear el grupo de seguridad que desee asociar al nodo principal de la VPC del clúster. Una vez sincronizados VPCs los dos, está disponible la reticulación entre los grupos de seguridad del lado de la base de datos y del lado del clúster. Para obtener más información, consulte [Reglas del grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules) en la *Guía del usuario de Amazon Virtual Private Cloud*.
### Configuración del cifrado TLS entre `slurmdbd` y el servidor de la base de datos
Con la configuración de Slurm contabilidad predeterminada que se AWS ParallelCluster proporciona, `slurmdbd` establece una conexión cifrada con TLS con el servidor de la base de datos, si el servidor admite el cifrado con TLS. AWS servicios de bases de datos como Amazon RDS y Amazon Aurora admiten el cifrado TLS de forma predeterminada.
Puede requerir conexiones seguras en el servidor configurando el parámetro `require_secure_transport` en el servidor de la base de datos. Esto se configura en la plantilla proporcionada CloudFormation .
Siguiendo las prácticas recomendadas de seguridad, le recomendamos que habilite también la verificación de identidad del servidor en el cliente de `slurmdbd`. Para ello, configure el [StorageParameters](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters)en`slurmdbd.conf`. Cargue el certificado de entidad de certificación del servidor en el nodo principal del clúster. A continuación, defina la opción [SSL\$1CA](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) de `StorageParameters` en `slurmdbd.conf` como la ruta del certificado de entidad de certificación del servidor en el nodo principal. De este modo, se habilita la verificación de la identidad del servidor en `slurmdbd`. Tras realizar estos cambios, reinicie el servicio `slurmdbd` para volver a establecer la conectividad con el servidor de la base de datos con la verificación de identidad habilitada.
### Actualización de credenciales de la base de datos
Para actualizar los valores de [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName)o [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn), primero debe detener la flota de cómputo. Supongamos que el valor secreto que está almacenado en el AWS Secrets Manager secreto cambia y su ARN no cambia. En esta situación, el clúster no actualiza automáticamente la contraseña de la base de datos con el nuevo valor. Para actualizar el clúster con el nuevo valor secreto, ejecute el siguiente comando desde el nodo principal.
```
$ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh
```
**aviso**
Para evitar perder datos de contabilidad, le recomendamos que cambie únicamente la contraseña de la base de datos cuando la flota de computación esté detenida.
### Supervisión de la base de datos
Se recomienda activar las funciones de supervisión de los servicios de AWS base de datos. Para obtener más información, consulte la documentación sobre el [monitoreo de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) o el [monitoreo de Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/MonitoringAurora.html).
# Slurm personalización de la configuración
A partir de AWS ParallelCluster la versión 3.6.0, puede personalizar la `slurm.conf` Slurm configuración en una configuración de AWS ParallelCluster clúster.
En la configuración del clúster, puede personalizar Slurm los parámetros de configuración mediante los siguientes ajustes de configuración del clúster:
+ Personalización Slurm parámetros para todo el clúster mediante el [`CustomSlurmSettingsIncludeFile`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettingsIncludeFile)parámetro [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings)o. AWS ParallelCluster se produce un error si se especifican ambos.
+ Personalización Slurm parámetros de una cola mediante [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomSlurmSettings)(mapeados a Slurm particiones).
+ Personalización Slurm parámetros de un recurso de cómputo mediante [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)(mapeado a Slurm nodos).
## Slurm límites de personalización de la configuración y consideraciones al usar AWS ParallelCluster
+ En `CustomSlurmSettings` el `CustomSlurmSettingsIncludeFile` caso de la configuración, solo puede especificar y actualizar `slurm.conf` los parámetros que estén incluidos en [Slurm versión ](slurm-workload-manager-v3.md) compatible con la AWS ParallelCluster versión que está utilizando para configurar un clúster.
+ Si especifica una personalizada Slurm configura cualquiera de los `CustomSlurmSettings` parámetros, AWS ParallelCluster realiza comprobaciones de validación e impide su configuración o actualización Slurm parámetros de configuración que entran en conflicto con AWS ParallelCluster la lógica. La Slurm los parámetros de configuración con los que se sabe que entran en conflicto AWS ParallelCluster se identifican en las listas de denegación. Las listas de denegación pueden cambiar en futuras AWS ParallelCluster versiones si hay otras Slurm se añaden funciones. Para obtener más información, consulte [Listado de denegaciones Slurm parámetros de configuración para `CustomSlurmSettings`](#slurm-configuration-denylists-v3).
+ AWS ParallelCluster solo comprueba si un parámetro está en una lista de denegaciones. AWS ParallelCluster no valida tu personalización Slurm sintaxis o semántica de los parámetros de configuración. Usted es responsable de validar su personalización Slurm parámetros de configuración. Personalización no válida Slurm Los parámetros de configuración pueden provocar Slurm errores de daemon que pueden provocar errores de creación y actualización del clúster.
+ Si especifica personalizado Slurm configuraciones en`CustomSlurmSettingsIncludeFile`, AWS ParallelCluster no realiza ninguna validación.
+ Puede actualizar `CustomSlurmSettings` y `CustomSlurmSettingsIncludeFile` sin detener ni iniciar la flota de computación. En este caso, AWS ParallelCluster reinicia el `slurmctld` daemon y ejecuta el `scontrol reconfigure` comando.
Alguno Slurm Es posible que los parámetros de configuración requieran operaciones diferentes antes de que se registre un cambio en todo el clúster. Por ejemplo, es posible que requieran el reinicio de todos los daemons del clúster. Usted es responsable de comprobar si AWS ParallelCluster las operaciones son suficientes para propagar su personalización Slurm ajustes de los parámetros de configuración durante las actualizaciones. Si considera que AWS ParallelCluster las operaciones no son suficientes, es su responsabilidad realizar las acciones adicionales necesarias para propagar la configuración actualizada, tal como se recomienda en la [Slurm documentación. ](https://slurm.schedmd.com/documentation.html)
## Listado de denegaciones Slurm parámetros de configuración para `CustomSlurmSettings`
En las tablas siguientes se enumeran los parámetros con las AWS ParallelCluster versiones que deniegan su uso, empezando por la versión 3.6.0. `CustomSlurmSettings`no es compatible con AWS ParallelCluster versiones anteriores a la 3.6.0.
**Parámetros de la lista de denegaciones a nivel de clúster:**
| Slurm parameter | Incluido en las versiones Deny AWS ParallelCluster |
| --- | --- |
| CommunicationParameters | 3.6.0 |
| Epilog | 3.6.0 |
| GresTypes | 3.6.0 |
| LaunchParameters | 3.6.0 |
| Prolog | 3.6.0 |
| ReconfigFlags | 3.6.0 |
| ResumeFailProgram | 3.6.0 |
| ResumeProgram | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| SlurmctldHost | 3.6.0 |
| SlurmctldLogFile | 3.6.0 |
| SlurmctldParameters | 3.6.0 |
| SlurmdLogfile | 3.6.0 |
| SlurmUser | 3.6.0 |
| SuspendExcNodes | 3.6.0 |
| SuspendProgram | 3.6.0 |
| SuspendTime | 3.6.0 |
| TaskPlugin | 3.6.0 |
| TreeWidth | 3.6.0 |
**Los parámetros de la lista rechazan a nivel de clúster cuando son nativos [Slurm La integración contable](slurm-accounting-v3.md) se configura en la configuración del clúster:**
| Slurm parameter | Deny aparece en las versiones AWS ParallelCluster |
| --- | --- |
| AccountingStorageType | 3.6.0 |
| AccountingStorageHost | 3.6.0 |
| AccountingStoragePort | 3.6.0 |
| AccountingStorageUser | 3.6.0 |
| JobAcctGatherType | 3.6.0 |
**Parámetros de lista denegada a nivel de cola (partición) para las colas gestionadas por: AWS ParallelCluster**
| Slurm parameter | Listado AWS ParallelCluster de denegación en las versiones |
| --- | --- |
| Nodos | 3.6.0 |
| PartitionName | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| Estado | 3.6.0 |
| SuspendTime | 3.6.0 |
**Parámetros de lista denegada a nivel de recurso informático (nodo) para el recurso informático gestionado por: AWS ParallelCluster**
| Slurm parameter | Incluido en la versión denegada y en las versiones posteriores AWS ParallelCluster |
| --- | --- |
| CPUs | 3.6.0 |
| Características | 3.6.0 |
| Gres | 3.6.0 |
| NodeAddr | 3.6.0 |
| NodeHostname | 3.6.0 |
| NodeName | 3.6.0 |
| Peso | 3.7.0 |
# Slurm y `prolog``epilog`
A partir de la AWS ParallelCluster versión 3.6.0, la Slurm configuración que se implementa AWS ParallelCluster incluye los siguientes parámetros `Prolog` de `Epilog` configuración:
```
# PROLOG AND EPILOG
Prolog=/opt/slurm/etc/scripts/prolog.d/*
Epilog=/opt/slurm/etc/scripts/epilog.d/*
SchedulerParameters=nohold_on_prolog_fail
BatchStartTimeout=180
```
Para obtener más información, consulte la [Guía de Prólogo y Epílogo](https://slurm.schedmd.com/prolog_epilog.html) en la documentación de Slurm.
AWS ParallelCluster incluye los siguientes scripts de prólogo y epílogo:
+ `90_plcuster_health_check_manager` (en la carpeta `Prolog`)
+ `90_pcluster_noop` (en la carpeta `Epilog`)
**nota**
Tanto la carpeta `Prolog` como la `Epilog` deben contener un archivo como mínimo.
Puede utilizar sus propios scripts `prolog` o `epilog` scripts añadiéndolos a las carpetas `Prolog` y `Epilog` correspondientes.
**aviso**
Slurm ejecuta todos los scripts de las carpetas, en orden alfabético inverso.
La duración del tiempo de ejecución de los scripts `prolog` y `epilog` afecta al tiempo necesario para ejecutar un trabajo. Actualice el ajuste `BatchStartTimeout` de configuración cuando ejecute varios scripts o scripts `prolog` de ejecución prolongada. El valor predeterminado es de 3 minutos.
Si utiliza scripts `prolog` y `epilog` personalizados, localice los scripts en las carpetas `Prolog` y `Epilog` correspondientes. Le recomendamos que mantenga el script `90_plcuster_health_check_manager` que se ejecuta antes de cada script personalizado. Para obtener más información, consulte [Slurm personalización de la configuración](slurm-configuration-settings-v3.md).
# Tamaño y actualización de la capacidad del clúster
La capacidad del clúster se define por la cantidad de nodos de computación que es capaz de escalar. Los nodos de cómputo están respaldados por EC2 instancias de Amazon definidas dentro de los recursos de cómputo de la AWS ParallelCluster configuración `(Scheduling/SlurmQueues/ ComputeResources)` y están organizados en colas `(Scheduling/SlurmQueues)` que se asignan 1:1 a Slurm particiones.
Dentro de un recurso de computación, es posible configurar el número mínimo de nodos de computación (instancias) que deben mantenerse siempre en ejecución en el clúster (`MinCount`) y el número máximo de instancias al que el recurso de computación puede escalar ([`MaxCount`: 3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)).
En el momento de la creación del clúster, o tras una actualización del clúster, AWS ParallelCluster lanza tantas EC2 instancias de Amazon como estén configuradas `MinCount` para cada recurso informático (`Scheduling/SlurmQueues/ ComputeResources`) definido en el clúster. Las instancias lanzadas para cubrir la cantidad mínima de nodos de un recurso de computación del clúster se denominan ***nodos estáticos***. Una vez iniciados, los nodos estáticos deben permanecer en el clúster y el sistema no los termina a menos que se produzca un evento o una condición en particular. Estos eventos incluyen, por ejemplo, el fallo de Slurm o los controles EC2 de salud de Amazon y el cambio de Slurm el estado del nodo es DRAIN o DOWN.
Las EC2 instancias de Amazon, en el rango de `1` 0 a `‘MaxCount - MinCount’` (`MaxCount `*menos*)` MinCount)`, lanzadas bajo demanda para hacer frente al aumento de carga del clúster, se denominan ***nodos dinámicos***. Su naturaleza es efímera: se lanzan para atender tareas pendientes y se cancelan una vez que permanecen inactivas durante un período de tiempo definido `Scheduling/SlurmSettings/ScaledownIdletime` en la configuración del clúster (predeterminado: 10 minutos).
Los nodos estáticos y los nodos dinámicos cumplen con el siguiente esquema de nomenclatura:
+ Nodos estáticos `-st--`, en los que ` = 1..ComputeResource/MinCount`
+ Nodos dinámicos `-dy--`, donde ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Por ejemplo, dada la siguiente configuración: AWS ParallelCluster
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
Los siguientes nodos se definirán en Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Cuando un recurso de computación tiene `MinCount == MaxCount`, todos los nodos de computación correspondientes serán estáticos y todas las instancias se lanzarán en el momento de la creación o actualización del clúster y se mantendrán en funcionamiento. Por ejemplo:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Actualización de la capacidad del clúster
La actualización de la capacidad del clúster incluye añadir o eliminar colas, recursos de computación o cambiar el parámetro `MinCount/MaxCount` de un recurso de computación. A partir de la AWS ParallelCluster versión 3.9.0, para reducir el tamaño de una cola es necesario detener la flota informática o [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)configurarla en TERMINATE antes de que se lleve a cabo la actualización del clúster. No es necesario detener la flota de cómputo ni configurarla en TERMINATE [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)cuando:
+ Adición de nuevas colas en Programación/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Adición de nuevos recursos de computación `Scheduling/SlurmQueues/ComputeResources` a una cola
+ Aumento de `MaxCount` de un recurso de computación
+ Aumento MinCount de un recurso informático y aumento MaxCount del mismo recurso informático en al menos la misma cantidad
## Consideraciones y limitaciones
El objetivo de esta sección es explicar los factores, restricciones o limitaciones importantes que se deben tener en cuenta al cambiar el tamaño de la capacidad del clúster.
+ Al eliminar una cola de `Scheduling/SlurmQueues` todos los nodos de cómputo con su nombre`-*`, tanto estático como dinámico, se eliminará del Slurm la configuración y las EC2 instancias de Amazon correspondientes se cancelarán.
+ Al eliminar un recurso `Scheduling/SlurmQueues/ComputeResources` de cómputo de una cola, todos los nodos de cómputo con su nombre`-*--*`, tanto estáticos como dinámicos, se eliminarán del Slurm la configuración y las EC2 instancias de Amazon correspondientes se cancelarán.
Al cambiar el parámetro `MinCount` de un recurso de computación, podemos distinguir dos escenarios diferentes: si `MaxCount` es igual que `MinCount` (solo capacidad estática) y si `MaxCount` es mayor que `MinCount` (capacidad estática y dinámica mixta).
### Cambios en la capacidad solo con los nodos estáticos
+ Si`MinCount == MaxCount`, al aumentar `MinCount` (y`MaxCount`), el clúster se configurará ampliando el número de nodos estáticos hasta el nuevo valor de `MinCount` `-st--` y el sistema seguirá intentando lanzar EC2 instancias de Amazon para cumplir con la nueva capacidad estática requerida.
+ Si`MinCount == MaxCount`, al disminuir `MinCount` (y`MaxCount`) la cantidad N, el clúster se configurará eliminando los últimos N nodos estáticos `-st--...]` y el sistema cancelará las EC2 instancias de Amazon correspondientes.
+ Estado inicial `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualización de `-30` en `MinCount` y `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Cambios en la capacidad con nodos mixtos
Si`MinCount < MaxCount`, al aumentar `MinCount` en una cantidad N (suponiendo que `MaxCount` se mantenga sin cambios), el clúster se configurará ampliando el número de nodos estáticos hasta el nuevo valor de `MinCount` (`old_MinCount + N`): `-st--` y el sistema seguirá intentando lanzar EC2 instancias de Amazon para cumplir con la nueva capacidad estática requerida. Además, para respetar la `MaxCount` capacidad del recurso informático, la configuración del clúster se actualiza *eliminando los últimos N nodos dinámicos* `-dy--[...]` y el sistema finalizará las EC2 instancias de Amazon correspondientes.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualice a \$130 en `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Si`MinCount < MaxCount`, al aumentar N `MinCount` y en `MaxCount` la misma cantidad, el clúster se configurará ampliando el número de nodos estáticos hasta el nuevo valor de `MinCount` (`old_MinCount + N`): `-st--` y el sistema seguirá intentando lanzar EC2 instancias de Amazon para cumplir con la nueva capacidad estática requerida. Además, no se realizará ningún cambio en el número de nodos dinámicos para adaptarlo al nuevo
valor de `MaxCount`.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualice a \$130 en `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Si`MinCount < MaxCount`, al disminuir la `MinCount` cantidad N (suponiendo que `MaxCount` se mantenga sin cambios), el clúster se configurará eliminando los últimos N nodos estáticos de los últimos N nodos estáticos `-st--[...` y el sistema cancelará las EC2 instancias de Amazon correspondientes. Además, para respetar la `MaxCount` capacidad del recurso informático, la configuración del clúster se actualiza ampliando el número de nodos dinámicos para cubrir el vacío. `MaxCount - new_MinCount: -dy--[1..]` En este caso, dado que se trata de nodos dinámicos, no se lanzará ninguna nueva EC2 instancia de Amazon a menos que el planificador tenga tareas pendientes en los nuevos nodos.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualización de -30 en `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Si`MinCount < MaxCount`, al disminuir `MinCount` y `MaxCount` de la misma cantidad N, el clúster se configurará eliminando los últimos N nodos estáticos `-st--...]` y el sistema cancelará las EC2 instancias de Amazon correspondientes.
Además, no se realizará ningún cambio en el número de nodos dinámicos para adaptarlo al nuevo valor de `MaxCount`.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualización de -30 en `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Si`MinCount < MaxCount`, al disminuir la `MaxCount` cantidad N (suponiendo que `MinCount` se mantenga sin cambios), el clúster se configurará eliminando los últimos N nodos dinámicos `-dy--]` y el sistema cancelará las EC2 instancias de Amazon correspondientes en caso de que se estuvieran ejecutando. No se espera ningún impacto en los nodos estáticos.
+ Estado inicial: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Actualización de -30 en `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Impactos en los trabajos
En todos los casos en los que se eliminen los nodos y se cancelen EC2 las instancias de Amazon, se volverá a poner en cola un trabajo por lotes que se ejecute en los nodos eliminados, a menos que no haya otros nodos que cumplan con los requisitos del trabajo. En este último caso, el trabajo falla con el estado NODE\$1FAIL y desaparece de la cola, por lo que debe volver a enviarse manualmente.
Si planea realizar una actualización de tamaño del clúster, puede impedir que los trabajos se ejecuten en nodos que se vayan a eliminar durante la actualización planificada. Esto se puede hacer configurando los nodos que se eliminarán durante el mantenimiento. Tenga en cuenta que poner un nodo en mantenimiento no afectaría a los trabajos que se estuviesen ejecutando en ese momento en el nodo.
Supongamos que con la actualización planificada para cambiar el tamaño del clúster se va a eliminar el nodo`qeueu-st-computeresource-[9-10`]. Puede crear un Slurm reserva con el siguiente comando
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Esto creará un Slurm reserva nombrada `maint_for_update` en los nodos`qeueu-st-computeresource-[9-10]`. Desde el momento en que se crea la reserva, no se pueden ejecutar más trabajos en los nodos `qeueu-st-computeresource-[9-10]`. Tenga en cuenta que la reserva no impedirá que haya trabajos que acaben asignándose a los nodos `qeueu-st-computeresource-[9-10]`.
Tras la actualización del tamaño del clúster, si Slurm la reserva se estableció solo en los nodos que se eliminaron durante la actualización del cambio de tamaño, la reserva de mantenimiento se eliminará automáticamente. Si, por el contrario, hubieras creado un Slurm reserva en los nodos que aún están presentes después de la actualización de cambio de tamaño del clúster, es posible que deseemos eliminar la reserva de mantenimiento en los nodos una vez realizada la actualización de cambio de tamaño mediante el siguiente comando
```
sudo -i scontrol delete ReservationName=maint_for_update
```
Para obtener información adicional sobre Slurm [Para hacer su reserva, consulte el documento oficial de SchedMD aquí.](https://slurm.schedmd.com/reservations.html)
## Proceso de actualización de un clúster con cambios de capacidad
Tras un cambio en la configuración del programador, se ejecutan los siguientes pasos durante el proceso de actualización del clúster:
+ ¡Pare AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Generar actualizaciones Slurm particiona la configuración a partir de AWS ParallelCluster la configuración
+ Se reinicia `slurmctld` (mediante la receta del servicio Chef)
+ Se comprueba el estado de `slurmctld` `(systemctl is-active --quiet slurmctld.service)`
+ Reload (Volver a cargar) Slurm configuración `(scontrol reconfigure)`
+ Se inicia `clustermgtd (supervisorctl start clustermgtd)`
# Usar el planificador AWS Batch (`awsbatch`) con AWS ParallelCluster
**aviso**
AWS CodeBuild no se admite en las regiones de Asia Pacífico (Malasia) `ap-southeast-5` () y Asia Pacífico (Tailandia) `ap-southeast-7` (). Por lo tanto, no se admite la ParallelCluster AWS Batch integración en esas regiones.
AWS ParallelCluster también es compatible con los AWS Batch programadores. Los siguientes temas describen cómo usar AWS Batch. Para obtener información al respecto AWS Batch, consulte. [AWS Batch](https://aws.amazon.com/batch/) Para ver la documentación, consulte la [Guía del usuario de AWS Batch](https://docs.aws.amazon.com/batch/latest/userguide/).
**AWS ParallelCluster Comandos CLI para AWS Batch**
Cuando utiliza el `awsbatch` programador, los comandos AWS ParallelCluster CLI para AWS Batch se instalan automáticamente en el nodo AWS ParallelCluster principal. La CLI usa operaciones de AWS Batch API y permite las siguientes operaciones:
+ Enviar y administrar trabajos
+ Monitorear trabajos, colas y hosts
+ Crear un reflejo de los comandos del programador tradicionales
**importante**
AWS ParallelCluster no admite trabajos de GPU para AWS Batch. Para obtener más información, consulte [GPU jobs](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html).
Esta CLI se distribuye como un paquete independiente. Para obtener más información, consulte [Compatibilidad con el programador](moving-from-v2-to-v3.md#scheduler_support).
**Topics**
+ [`awsbsub`](awsbatchcli.awsbsub-v3.md)
+ [`awsbstat`](awsbatchcli.awsbstat-v3.md)
+ [`awsbout`](awsbatchcli.awsbout-v3.md)
+ [`awsbkill`](awsbatchcli.awsbkill-v3.md)
+ [`awsbqueues`](awsbatchcli.awsbqueues-v3.md)
+ [`awsbhosts`](awsbatchcli.awsbhosts-v3.md)
# `awsbsub`
Envía trabajos a la cola de trabajos del clúster.
```
awsbsub [-h] [-jn JOB_NAME] [-c CLUSTER] [-cf] [-w WORKING_DIR]
[-pw PARENT_WORKING_DIR] [-if INPUT_FILE] [-p VCPUS] [-m MEMORY]
[-e ENV] [-eb ENV_DENYLIST] [-r RETRY_ATTEMPTS] [-t TIMEOUT]
[-n NODES] [-a ARRAY_SIZE] [-d DEPENDS_ON]
[command] [arguments [arguments ...]]
```
**importante**
AWS ParallelCluster no admite trabajos de GPU para AWS Batch. Para obtener más información, consulte [Trabajos de la GPU](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html).
## Argumentos de posición
***command***
Envía el trabajo (el comando especificado debe estar disponible en las instancias de computación) o el nombre de archivo que se va a transferir. Véase también `--command-file`.
**arguments**
(Opcional) Especifica argumentos para el comando o el archivo de comandos.
## Argumentos con nombre
**-jn *JOB\$1NAME*, --job-name *JOB\$1NAME***
Asigna un nombre al trabajo. El primer carácter debe ser una letra o un número. El nombre del trabajo puede contener letras (mayúsculas y minúsculas), números, guiones (-) y guiones bajos (\$1), y puede tener una longitud máxima de 128 caracteres.
**-c *CLUSTER*, --cluster *CLUSTER***
Especifica el clúster que se va a utilizar.
**-cf, --command-file**
Indica que el comando es una archivo que se va a transferir a las instancias de informática.
Valor predeterminado: False
**-w *WORKING\$1DIR*, --working-dir *WORKING\$1DIR***
Especifica la carpeta que se va a usar como directorio de trabajo del trabajo. Si no se especifica un directorio de trabajo, el trabajo se ejecuta en la subcarpeta `job-` del directorio de inicio del usuario. Puede utilizar este parámetro o el parámetro `--parent-working-dir`.
**-pw *PARENT\$1WORKING\$1DIR*, --parent-working-dir *PARENT\$1WORKING\$1DIR***
Especifica la carpeta principal del directorio de trabajo del trabajo. Si no se especifica un directorio de trabajo principal, el valor predeterminado es el directorio de inicio del usuario. Una subcarpeta llamada `job-` se crea en el directorio de trabajo principal. Puede utilizar este parámetro o el parámetro `--working-dir`.
**-if *INPUT\$1FILE*, --input-file *INPUT\$1FILE***
Especifica el archivo que se va a transferir a las instancias de computación, en el directorio de trabajo de la tarea. Puede especificar varios parámetros de archivo de entrada.
**-p *VCPUS*, --vcpus *VCPUS***
Especifica el número de v CPUs que se va a reservar para el contenedor. Cuando se usa junto con`–nodes`, identifica el número de v CPUs para cada nodo.
Valor predeterminado: 1
**-m *MEMORY*, --memory *MEMORY***
Especifica el límite máximo de memoria (en MiB) que se va a proporcionar para el trabajo. Si su trabajo intenta superar el límite de memoria especificado aquí, se finaliza el trabajo.
Valor predeterminado: 128
**-e *ENV*, --env *ENV***
Especifica una lista de nombres de variable de entorno separados por comas que se van a exportar al entorno de trabajo. Para exportar todas las variables de entorno, especifique "todas". Tenga en cuenta que una lista de “todas” las variables de entorno no incluyen aquellas que figuren en el parámetro `–env-blacklist` ni tampoco variables que empiecen por el prefijo `PCLUSTER_*` o `AWS_*`.
**-eb *ENV\$1DENYLIST*, --env-blacklist *ENV\$1DENYLIST***
Especifica una lista de nombres de variable de entorno separados por comas que **no** se van a exportar al entorno de trabajo. De forma predeterminada, no se exportan `HOME`, `PWD`, `USER`, `PATH`, `LD_LIBRARY_PATH`, `TERM` ni `TERMCAP`.
**-r *RETRY\$1ATTEMPTS*, --retry-attempts *RETRY\$1ATTEMPTS***
Especifica la cantidad de veces que toma pasar un trabajo al estado `RUNNABLE`. Puede especificar entre 1 y 10 intentos. Si el valor de los intentos es superior a 1, el trabajo se reintenta si produce un error, hasta que haya pasado al estado `RUNNABLE`, que especificaba la cantidad de veces.
Valor predeterminado: 1
**-t *TIMEOUT*, --timeout *TIMEOUT***
Especifica la duración en segundos (medida a partir de la `startedAt` marca de tiempo del intento de trabajo) tras la cual AWS Batch finaliza el trabajo si no lo ha terminado. El valor del tiempo de inactividad debe ser al menos 60 segundos.
**-n *NODES*, --nodes *NODES***
Especifica el número de nodos que quiere reservar para el trabajo. Especifique un valor para que este parámetro habilite el envío paralelo de varios nodos.
Cuando el parámetro [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)/[`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues)/[`CapacityType`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-CapacityType) está establecido en `SPOT`, *no* se admiten los trabajos paralelos de varios nodos. Además, debe haber un rol vinculado a servicios `AWSServiceRoleForEC2Spot` en su cuenta. Puede crear este rol con el siguiente comando: AWS CLI
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
Para obtener más información, consulte [Rol vinculado al servicio para solicitudes de instancias de spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) en la *Guía del usuario de Amazon Elastic Compute Cloud para instancias de Linux*.
**-a *ARRAY\$1SIZE*, --array-size *ARRAY\$1SIZE***
Indica el tamaño de la matriz. Puede especificar un valor comprendido entre 2 y 10 000. Si especifica las propiedades de matriz para un trabajo, pasa a ser un trabajo de matriz.
**-d *DEPENDS\$1ON*, --depends-on *DEPENDS\$1ON***
Especifica una lista de dependencias separadas por puntos y coma para un trabajo. Un trabajo puede depender de un máximo de 20 trabajos. Puede especificar una dependencia de tipo `SEQUENTIAL` sin especificar un ID de trabajo para los trabajos de matriz. Una dependencia SEQUENTIAL permite que cada trabajo de matriz secundario se complete de forma secuencial, a partir del índice 0. También puede especificar una dependencia de tipo N\$1TO\$1N con un ID de trabajo para los trabajos de matriz. Una dependencia N\$1TO\$1N conlleva que cada índice secundario de este trabajo deba esperar a que se complete el índice secundario correspondiente de cada dependencia antes de comenzar. La sintaxis de este parámetro es «JobID=**, type=**;...».
# `awsbstat`
Muestra los trabajos que se envían en la cola de trabajos del clúster.
```
awsbstat [-h] [-c CLUSTER] [-s STATUS] [-e] [-d] [job_ids [job_ids ...]]
```
## Argumentos de posición
***job\$1ids***
Especifica la lista de trabajos separados por espacios IDs que se mostrará en la salida. Si el trabajo es una matriz de trabajo, se muestran todos los trabajos secundarios. Si se solicita un solo trabajo, se muestra en una versión detallada.
## Argumentos con nombre
**-c *CLUSTER*, --cluster *CLUSTER***
Indica el clúster que se va a utilizar.
**-s *STATUS*, --status *STATUS***
Especifica una lista de estados de los trabajos separados por comas que se van a incluir. El estado del trabajo predeterminado es "activo". Los valores aceptados son: `SUBMITTED`, `PENDING`, `RUNNABLE`, `STARTING`, `RUNNING`, `SUCCEEDED`, `FAILED` y `ALL`.
Valor predeterminado: “`SUBMITTED`,`PENDING`,`RUNNABLE`,`STARTING` y `RUNNING`”
**-e, --expand-children**
Amplía los trabajos con elementos secundarios (tanto los de matriz como los paralelos de varios nodos).
Valor predeterminado: False
**-d, --details**
Muestra detalles de los trabajos.
Valor predeterminado: False
# `awsbout`
Muestra la salida de un trabajo especificado.
```
awsbout [-h] [-c CLUSTER] [-hd HEAD] [-t TAIL] [-s] [-sp STREAM_PERIOD] job_id
```
## Argumentos de posición
***job\$1id***
Especifica el ID de trabajo.
## Argumentos con nombre
**-c *CLUSTER*, --cluster *CLUSTER***
Indica el clúster que se va a utilizar.
**-hd *HEAD*, --head *HEAD***
Obtiene las primeras *HEAD* líneas del resultado del trabajo.
**-t *TAIL*, --tail *TAIL***
Obtiene las últimas líneas de la salida del trabajo.
**-s, --stream**
Obtiene la salida del trabajo y, a continuación, espera a que se produzca una salida adicional. Este argumento puede usarse junto a –tail para comenzar desde las últimas líneas de la salida del trabajo.
Valor predeterminado: False
**-sp *STREAM\$1PERIOD*, --stream-period *STREAM\$1PERIOD***
Establece el periodo de streaming.
Valor predeterminado: 5
# `awsbkill`
Cancela o termina trabajos enviados en el clúster.
```
awsbkill [-h] [-c CLUSTER] [-r REASON] job_ids [job_ids ... ]
```
## Argumentos de posición
***job\$1ids***
Especifica la lista de tareas separadas por espacios que se van IDs a cancelar o terminar.
## Argumentos con nombre
**-c *CLUSTER*, --cluster *CLUSTER***
Indica el nombre del clúster que se va a utilizar.
**-r *REASON*, --reason *REASON***
Indica el mensaje que se asociará a un trabajo, en el cual se explica el motivo de su cancelación.
Predeterminado:»Terminated by the user”
# `awsbqueues`
Muestra la cola de trabajos que se asocia al clúster.
```
awsbqueues [-h] [-c CLUSTER] [-d] [job_queues [job_queues ... ]]
```
## Argumentos de posición
***job\$1queues***
Especifica la lista de nombres de colas separados por espacios que se van a mostrar. Si se solicita una sola cola, se muestra en una versión detallada.
## Argumentos con nombre
**-c *CLUSTER*, --cluster *CLUSTER***
Especifica el nombre del clúster que se va a utilizar.
**-d, --details**
Indica si se deben mostrar los detalles de las colas.
Valor predeterminado: False
# `awsbhosts`
Muestra los hosts que pertenecen al entorno informático del clúster.
```
awsbhosts [-h] [-c CLUSTER] [-d] [instance_ids [instance_ids ... ]]
```
## Argumentos de posición
***instance\$1ids***
Especifica una lista de instancias separadas por espacios. IDs Si se solicita una sola instancia, se muestra en una versión detallada.
## Argumentos con nombre
**-c *CLUSTER*, --cluster *CLUSTER***
Especifica el nombre del clúster que se va a utilizar.
**-d, --details**
Indica si se deben mostrar los detalles de los hosts.
Valor predeterminado: False