Slurmmodo protegido por clústeres

Cuando un clúster se ejecuta con el modo protegido activado,AWS ParallelCluster monitorea y rastrea los errores de arranque del nodo de procesamiento a medida que se inician para detectar si los errores se producen de forma continua o no.

Si se detecta alguna de las siguientes situaciones, el clúster entra en modo protegido:

1. Se producen errores de arranque consecutivos de forma continua sin que los nodos de procesamiento se lancen correctamente.

2. El recuento de errores de una cola alcanza un umbral predefinido.

Cuando el clúster entre en modo protegido,AWS ParallelCluster desactiva la cola o las colas con errores iguales o superiores al umbral predefinido.

SlurmEl modo protegido por clústeres se agregó enAWS ParallelCluster la versión 3.0.0.

Puede usar el modo protegido para reducir el tiempo y los recursos que se invierten en el ciclo de errores de arranque del nodo de procesamiento.

Parámetro de nodo protegido

bootstrap_failure_count

bootstrap_failure_countespecifica el número de errores consecutivos que activan el nodo protegido del clúster.

El valor predeterminadobootstrap_failure_count es 10 y el modo protegido está activado.

Sibootstrap_failure_count es menor o igual a cero, el modo protegido está desactivado.

Puede cambiar elbootstrap_failure_count valor añadiendo el parámetro en el archivo declustermgtd configuración que se encuentra/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf enHeadNode.

Puede actualizar este parámetro en cualquier momento y no necesita detener la flota de procesamiento para hacerlo. Si un lanzamiento se realiza correctamente en una cola antes de que llegue el recuento de erroresbootstrap_failure_count, el recuento de errores se restablece a cero.

Compruebe el estado del clúster en modo protegido

Cuando un clúster está en modo protegido, puede comprobar el estado de la flota de procesamiento y los estados de los nodos.

Calcule el estado de la flota

El estado de la flota de procesamiento se encuentraPROTECTED en un clúster que se ejecuta en modo protegido.

$ pcluster describe-compute-fleet --cluster-name <cluster-name> --region <region-id>
{
   "status": "PROTECTED",
   "lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}

Estado del nodo

Para saber qué colas (particiones) tienen errores de arranque que han activado el modo protegido, inicie sesión en el clúster y ejecute elsinfo comando. Las particiones con errores de arranque iguales o superioresbootstrap_failure_count se encuentran enINACTIVE state. Las particiones sin errores de arranque iguales o superioresbootstrap_failure_count están en elUP estado esperado y funcionan según lo esperado.

PROTECTEDel estado no afecta a los trabajos en ejecución. Si los trabajos se ejecutan en una partición con errores de arranque iguales o superioresbootstrap_failure_count, la partición se establece unaINACTIVE vez finalizados los trabajos en ejecución.

Tenga en cuenta 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]

queue1La partición seINACTIVE debe a que se detectaron 10 errores de arranque continuos consecutivos.

Sequeue1-dy-c5xlarge-[1-10] lanzaron las instancias detrás de los nodos, pero no pudieron unirse al clúster porque no estaban en buen estado.

El clúster está en modo protegido.

La particiónqueue2 no se ve afectada por los errores de arranque enqueue1. Está en elUP estado y aún puede ejecutar trabajos.

Cómo desactivar el modo protegido

Una vez resuelto el error de arranque, puede ejecutar el siguiente comando para sacar el clúster del modo protegido.

$ pcluster update-compute-fleet --cluster-name <cluster-name> \
  --region <region-id> \
  --status START_REQUESTED

Fallos de Bootstrap que activan el modo protegido

Los errores de Bootstrap que activan el modo protegido se subdividen en los tres tipos siguientes. Para identificar el tipo y el problema, puede comprobar siAWS ParallelCluster se generaron registros. Si se generaron los registros, puede comprobarlos para ver los detalles del error. Para obtener más información, consulte Recuperación y conservación de registros.

1. Error de arranque que provoca que una instancia se autotermine.

   Una instancia falla al principio del proceso de arranque, como una instancia que termina automáticamente debido a errores en el OnNodeConfiguredscript SlurmQueuesCustomActions\\ OnNodeStart|.

   Para nodos dinámicos, busque errores similares a los siguientes.

   Node bootstrap error: Node ... is in power up state without valid backing instance

   Para los nodos estáticos, busque en elclustermgtd registro (/var/log/parallelcluster/clustermgtd) errores similares a los siguientes.

   Node bootstrap error: Node ... is in power up state without valid backing instance

2. Noderesume_timeout onode_replacement_timeout caduca.

   Una instancia no puede unirse a un clúster dentro delresume_timeout (para nodos dinámicos) onode_replacement_timeout (para nodos estáticos). No se autotermina antes de que se agote el tiempo de espera. Por ejemplo, las redes no están configuradas correctamente para el clúster y el nodo se establece en elDOWN estado anterior una vezSlurm transcurrido el tiempo de espera.

   Para nodos dinámicos, busque errores similares a los siguientes.

   Node bootstrap error: Resume timeout expires for node

   Para los nodos estáticos, busque en elclustermgtd registro (/var/log/parallelcluster/clustermgtd) errores similares a los siguientes.

   Node bootstrap error: Replacement timeout expires for node ... in replacement.

3. Los nodos no superan la comprobación de estado.

   Una instancia situada detrás del nodo no pasa por alto una comprobación de estado de EC2 o una comprobación de estado de un evento programado, y los nodos se tratan como nodos con errores de arranque. En este caso, la instancia se termina por un motivo ajeno a nuestroAWS ParallelCluster control.

   Busque en elclustermgtd registro (/var/log/parallelcluster/clustermgtd) errores similares a los siguientes.

   Node bootstrap error: Node %s failed during bootstrap when performing health check.

Cómo depurar el modo protegido

Cuando sepa que su clúster está en estado protegido y siAWS ParallelCluster ha generadoclustermgtd registros a partir de nodos de procesamiento problemáticosHeadNode y loscloud-init-output registros de los nodos de procesamiento problemáticos, puede comprobar los registros para ver los detalles de los errores. Para obtener más información acerca de cómo recuperar registros, consulteRecuperación y conservación de registros.

clustermgtdlog (/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 elclustermgtd registro, busqueFound the following bootstrap failure nodes el nodo que no pudo arrancar.

[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 elclustermgtd registro, busqueNode bootstrap error 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

cloud-init-outputlog (/var/log/cloud-init-output.log) en los nodos de cómputos

Tras obtener la dirección IP privada del nodo de error de arranque en elclustermgtd registro, puede encontrar el registro del nodo de procesamiento correspondiente iniciando sesión en el nodo de procesamiento o siguiendo las instrucciones deRecuperación y conservación de registros para recuperar los registros. En la mayoría de los casos, el/var/log/cloud-init-output registro del nodo problemático muestra el paso que provoca el error de arranque del nodo de procesamiento.