Solución de problemas de escalar - AWS ParallelCluster

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.

Solución de problemas de escalar

Esta sección es relevante para los clústeres que se instalaron con la AWS ParallelCluster versión 3.0.0 y versiones posteriores con el programador de tareas de Slurm. Para obtener más información acerca de la configuración de colas de consultas, consulte Configuración de varias colas.

Si uno de sus clústeres en ejecución tiene problemas, coloque el clúster en ese STOPPED estado ejecutando el siguiente comando antes de empezar a solucionar el problema. Esto evita incurrir en costes inesperados.

$ pcluster update-compute-fleet --cluster-name mycluster \ --status STOP_REQUESTED

Puede enumerar los flujos de registro disponibles en los nodos del clúster mediante el pcluster list-cluster-log-streams comando y filtrarlos mediante uno private-dns-name de los nodos que fallan o el nodo principal:

$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \ --filters 'Name=private-dns-name,Values=ip-10-0-0-101'

A continuación, puede recuperar el contenido del flujo de registro para analizarlo mediante el pcluster get-cluster-log-events comando y pasar el --log-stream-name correspondiente a uno de los registros clave que se mencionan en la siguiente sección:

$ pcluster get-cluster-log-events --cluster-name mycluster \ --region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init

AWS ParallelClustercrea flujos de CloudWatch registros de clúster en grupos de registros. Puede ver estos registros en los paneles personalizados de la CloudWatch consola o en los grupos de registros. Para obtener más información, consulte Integración con Amazon CloudWatch Logs y Panel de Amazon CloudWatch.

Registros clave para la depuración

En la siguiente tabla se proporciona una descripción general de los registros clave del nodo principal:

  • Este es el registro init del archivo . Contiene todos los comandos que se ejecutaron cuando se configuró una instancia. Se usa para solucionar problemas de inicialización.

  • /var/log/chef-client.log- Este es el registro del cliente de Chef. Contiene todos los comandos que se ejecutaron a través de Chef/CINC. Úselo para solucionar problemas de inicialización.

  • /var/log/parallelcluster/slurm_resume.log- Es un ResumeProgram registro. Lanza instancias para nodos dinámicos. Se usa para solucionar problemas de lanzamiento de nodos dinámicos.

  • Este es el registro de . Se llama cuando se terminan las instancias de los nodos dinámicos. Se usa para solucionar problemas de terminación de nodos dinámicos. Al revisar este registro, también debe comprobarlo. clustermgtd

  • Este es el registro de . Se ejecuta como el daemon centralizado que gestiona la mayoría de las acciones operativas del clúster. Úselo para solucionar cualquier problema de inicio, finalización o funcionamiento del clúster.

  • /var/log/slurmctld.log- Este es el registro del daemon de control de Slurm. AWS ParallelClusterno toma decisiones de escalado. Más bien, solo intenta lanzar recursos para satisfacer los requisitos de Slurm. Es útil para problemas de escalado y asignación, problemas relacionados con el trabajo y cualquier problema de lanzamiento y finalización relacionado con el programador.

  • /var/log/parallelcluster/compute_console_output- Este registro registra la salida de la consola de un subconjunto de ejemplos de nodos de cómputo estáticos que han terminado inesperadamente. Utilice este registro si los nodos de cómputo estáticos terminan y los registros de los nodos de cómputo no están disponibles en CloudWatch él. El compute_console_output log contenido que recibe es el mismo cuando utiliza la consola EC2 o cuando recupera la salida de AWS CLI la consola de la instancia.

Estos son los registros clave de los nodos de cómputo:

  • Este es el registro init del archivo . Contiene todos los comandos que se ejecutaron al configurar una instancia. Se usa para solucionar problemas de inicialización.

  • Este es el registro de . Se ejecuta en cada nodo de cómputo para monitorizarlo en el raro caso de que el clustermgtd daemon del nodo principal esté desconectado. Úselo para solucionar problemas de terminación inesperados.

  • /var/log/slurmd.log- Este es el registro del daemon de cómputo de Slurm. Úselo para solucionar problemas de inicialización y errores de procesamiento.

Aparece un InsufficientInstanceCapacity error slurm_resume.log cuando no puedo ejecutar un trabajo o clustermgtd.log cuando no puedo crear un clúster

Si el clúster usa un Slurm programador, se está produciendo un problema de capacidad insuficiente. Si no hay suficientes instancias disponibles cuando se realiza la solicitud, se devuelve un error InsufficientInstanceCapacity.

Para la capacidad de las instancias estáticas, puedes encontrar el error en el clustermgtd registro de. /var/log/parallelcluster/clustermgtd

En cuanto a la capacidad dinámica de las instancias, puedes encontrar el error en el ResumeProgram registro en/var/log/parallelcluster/slurm_resume.log.

El ARN de tema tiene un aspecto similar al del ejemplo siguiente:

An error occurred (InsufficientInstanceCapacity) when calling the RunInstances/CreateFleet operation...

Según su caso de uso, considere la posibilidad de utilizar uno de los siguientes métodos para evitar recibir este tipo de mensajes de error:

Solución de problemas de inicialización de nodos

En esta sección, se explica cómo solucionar los problemas de inicialización de los nodos. Esto incluye los problemas en los que el nodo no puede iniciar, encender o unirse a un clúster.

Nodo principal

Registros aplicables:

  • /var/log/cfn-init.log

  • /var/log/chef-client.log

  • /var/log/parallelcluster/clustermgtd

  • /var/log/parallelcluster/slurm_resume.log

  • /var/log/slurmctld.log

Compruebe los /var/log/chef-client.log registros /var/log/cfn-init.log y o los flujos de registro correspondientes. Estos registros contienen todas las acciones que se ejecutaron cuando se configuró el nodo principal. La mayoría de los errores que se producen durante la configuración deberían incluir mensajes de error en el /var/log/chef-client.log registro. Si OnNodeStart se especifican OnNodeConfigured scripts en la configuración del clúster, compruebe que el script se ejecute correctamente a través de los mensajes de registro.

Cuando se crea un clúster, el nodo principal debe esperar a que los nodos de procesamiento se unan al clúster antes de poder unirse al clúster. Por este motivo, si los nodos informáticos no se unen al clúster, el nodo principal también falla. Puede seguir uno de estos procedimientos, dependiendo del tipo de notas informáticas que utilice, para solucionar este tipo de problemas:

Nodos de computación

  • Registros aplicables:

    • /var/log/cloud-init-output.log

    • /var/log/slurmd.log

  • Si se lanza un nodo de cómputo/var/log/cloud-init-output.log, compruebe primero que contenga los registros de configuración similares al /var/log/chef-client.log registro del nodo principal. La mayoría de los errores que se producen durante la configuración deberían tener mensajes de error ubicados en el /var/log/cloud-init-output.log registro. Si se especifican scripts previos o posteriores a la instalación en la configuración del clúster, compruebe que se hayan ejecutado correctamente.

  • Si utiliza una AMI personalizada con modificaciones en la Slurm configuración, es posible que se produzca un error Slurm relacionado que impida que el nodo de procesamiento se una al clúster. Para ver los errores relacionados con el programador, consulta el registro. /var/log/slurmd.log

Nodos de cómputo dinámico:

  • Busque en el ResumeProgram log (/var/log/parallelcluster/slurm_resume.log) el nombre de su nodo de cómputo para ver si alguna vez ResumeProgram se llamó con el nodo. (Si ResumeProgram nunca lo llamaron, puedes comprobar el slurmctld registro (/var/log/slurmctld.log) para determinar si Slurm alguna vez intentó llamar ResumeProgram con el nodo).

  • Tenga en cuenta que los permisos incorrectos activados en ResumeProgram pueden provocar un error silencioso en ResumeProgram. Si utiliza una AMI personalizada con modificaciones en la ResumeProgram configuración, compruebe que ResumeProgram sea propiedad del slurm usuario y que tenga el permiso 744 (rwxr--r--).

  • Si se llama a ResumeProgram, compruebe si se ha lanzado una instancia para el nodo. Si no se lanzó ninguna instancia, verás un mensaje de error que describe el error de lanzamiento.

  • Si se lanza la instancia, es posible que haya habido un problema durante el proceso de configuración. Deberías ver la dirección IP privada y el ID de instancia correspondientes en el ResumeProgram registro. Además, puedes consultar los registros de configuración correspondientes a la instancia específica. Para obtener más información acerca de resolución de problemas de computación, consulte la siguiente sección de resolución de problemas de computación.

Nodos de cómputo estáticos:

  • Compruebe el registro clustermgtd (/var/log/parallelcluster/clustermgtd) para ver si se han lanzado instancias para el nodo. Si no se lanzaron, debería haber un mensaje de error claro que detalle el error de lanzamiento.

  • Si se lanza la instancia, hay algún problema durante el proceso de configuración. Deberías ver la dirección IP privada y el ID de instancia correspondientes en el ResumeProgram registro. Además, puedes consultar los registros de configuración correspondientes a la instancia específica.

Nodos de cómputo respaldados por instancias puntuales:

  • Si es la primera vez que utiliza instancias puntuales y el trabajo permanece en estado de PD (pendiente), compruebe el /var/log/parallelcluster/slurm_resume.log archivo. Probablemente encuentre un error como el siguiente:

    2022-05-20 13:06:24,796 - [slurm_plugin.common:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['spot-dy-t2micro-2']: An error occurred (AuthFailure.ServiceLinkedRoleCreationNotPermitted) when calling the RunInstances operation: The provided credentials do not have permission to create the service-linked role for EC2 Spot Instances.

    Al utilizar instancias puntuales, en la cuenta se debe incluir un rol vinculado a un servicio AWSServiceRoleForEC2Spot. Para crear este rol en la cuenta con AWS CLI, ejecute el siguiente comando:

    $ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com

    Para obtener más información, consulte Uso de Instancias de spot y AWS ParallelClusterRol vinculado al servicio para solicitudes de instancias de spot en la Guía del usuario de Amazon EC2 para instancias de Linux.

Solución de problemas de sustituciones y terminaciones inesperadas de nodos

En esta sección se continúa analizando cómo puede solucionar problemas relacionados con los nodos, específicamente cuando un nodo se reemplaza o se cierra inesperadamente.

  • Registros aplicables:

    • /var/log/parallelcluster/clustermgtd(nodo principal)

    • /var/log/slurmctld.log(nodo principal)

    • /var/log/parallelcluster/computemgtd (nodo de computación)

Nodos sustituidos o finalizados de forma inesperada:

  • Para comprobar si clustermgtd ha sustituido o finalizado un nodo, compruebe el registro . Tenga en cuenta que clustermgtd gestiona todas las acciones normales de mantenimiento del nodo.

  • Si clustermgtd se reemplaza o se cierra el nodo, debería haber un mensaje que detalle por qué se realizó esta acción en el nodo. Si el motivo está relacionado con el programador (por ejemplo, el nodo está en DOWN), consulte el registro slurmctld para obtener más detalles. Si el motivo está relacionado con Amazon EC2, debería haber un mensaje informativo que detalle el problema relacionado con Amazon EC2 que requirió la sustitución.

  • Si clustermgtd no terminó el nodo, compruebe primero si se trataba de una terminación prevista por parte de Amazon EC2, más específicamente una terminación puntual. computemgtd, que se ejecuta en un nodo de cómputo, también puede cerrar un nodo si clustermgtd se determina que está en mal estado. Compruebe computemgtd log (/var/log/parallelcluster/computemgtd) para ver si computemgtd ha terminado el nodo.

Los nodos fallaron

  • Compruebe slurmctld log (/var/log/slurmctld.log) para ver por qué ha fallado un trabajo o un nodo. Tenga en cuenta que los trabajos se vuelven a poner en cola automáticamente si se produce un error en un nodo.

  • Si slurm_resume informa de que el nodo se ha lanzado y, después de varios minutos, clustermgtd informa de que no hay ninguna instancia correspondiente en Amazon EC2 para ese nodo, es posible que el nodo produzca un error durante la configuración. Para recuperar el registro de un compute (/var/log/cloud-init-output.log), sigue estos pasos:

    • Envía un trabajo para permitir que Slurm se active un nuevo nodo.

    • Una vez que se inicie el nodo, habilite la protección de terminación mediante este comando.

      $ aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --disable-api-termination
    • Recupere la salida de la consola del nodo con este comando.

      $ aws ec2 get-console-output --instance-id i-1234567890abcdef0 --output text

Reemplazar, terminar o apagar instancias y nodos problemáticos

  • Registros aplicables:

    • /var/log/parallelcluster/clustermgtd(nodo principal)

    • /var/log/parallelcluster/slurm_suspend.log(nodo principal)

  • En la mayoría, 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 Propiedades de SlurmSettings, consulte el registro SuspendProgram para ver si fue llamado por slurmctld 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. Toda la terminación y el NodeAddr restablecimiento de la instancia se realizan medianteclustermgtd. Slurm vuelve a poner los nodos en un POWER_SAVING estado posterior SuspendTimeout automáticamente.

  • Si los nodos de cómputo fallan continuamente debido a errores de arranque, compruebe si se están iniciando con la tecla Enabled. Modo protegido de clúster Slurm Si el modo protegido no está activado, modifique la configuración del modo protegido para activarlo. Solucione los problemas y corrija el script de arranque.

Estado de la cola (partición) Inactive

Si ejecuta sinfo y el resultado muestra colas con el AVAIL estado deinact, es posible que su clúster Modo protegido de clúster Slurm esté habilitado y que la cola se haya establecido en ese INACTIVE estado durante un período de tiempo predefinido.

Solución de otros problemas conocidos de nodos y trabajos

Otro tipo de problema conocido es que es AWS ParallelCluster posible que no se puedan asignar las tareas ni tomar decisiones de escalado. En este tipo de problemas, AWS ParallelCluster solo se inician, finalizan o mantienen los recursos de acuerdo con las instrucciones de Slurm. En el caso de estos problemas, consulte el slurmctld registro para solucionarlos.