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