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. # AWS ParallelCluster solución de problemas La AWS ParallelCluster comunidad mantiene una página wiki que proporciona muchos consejos para solucionar problemas en la [AWS ParallelCluster GitHub wiki](https://github.com/aws/aws-parallelcluster/wiki/). Para obtener una lista de problemas conocidos, consulte [Problemas conocidos](https://github.com/aws/aws-parallelcluster/wiki#known-issues-). **Topics** + [Recuperación y conservación de registros](#retrieving-and-preserve-logs) + [Solución de problemas de implementación de pilas](#troubleshooting-stack-creation-failures) + [Solución de problemas en varios clústeres en modo de cola](#multiple-queue-mode) + [Solución de problemas en clústeres en modo de cola única](#troubleshooting-issues-in-single-queue-clusters) + [Problemas con los grupos de ubicación y el lanzamiento de instancias](#placement-groups-and-instance-launch-issues) + [Directorios que no se pueden reemplazar](#directories-cannot-be-replaced) + [Solución de problemas de Amazon DCV](#nice-dcv-troubleshooting) + [Solución de problemas en clústeres con AWS Batch integración](#clusters-with-aws-batch-integration) + [Solución de problemas cuando un recurso no se crea](#troubleshooting-resource-fails-to-create) + [Solución de problemas de tamaño de políticas de IAM](#troubleshooting-policy-size-issues) + [Compatibilidad adicional](#getting-support) ## Recuperación y conservación de registros Los registros son un recurso útil para solucionar problemas. Antes de poder usar los registros para solucionar problemas con sus recursos de AWS ParallelCluster , primero debe crear un archivo de registros del clúster. Siga los pasos descritos en el tema [Creación de un archivo de registros de un clúster](https://github.com/aws/aws-parallelcluster/wiki/Creating-an-Archive-of-a-Cluster's-Logs) de la [AWS ParallelCluster GitHub wiki](https://github.com/aws/aws-parallelcluster/wiki/) para iniciar este proceso. Si uno de sus clústeres en ejecución tiene problemas, debe colocar el clúster en ese estado `STOPPED` ejecutando el comando ``pcluster stop` ` antes de empezar a solucionar el problema. Esto evita incurrir en costes inesperados. Si `pcluster` deja de funcionar o si desea eliminar un clúster sin dejar de conservar sus registros, ejecute el comando ``pcluster delete` —keep-logs `. Al ejecutar este comando, se elimina el clúster, pero se conserva el grupo de registros que está almacenado en Amazon CloudWatch. Para obtener información sobre este comando, consulte la documentación de [`pcluster delete`](pcluster.delete.md). ## Solución de problemas de implementación de pilas Si el clúster no se puede crear y revierte la creación de la pila, puede revisar los siguientes archivos de registro para diagnosticar el problema. Desea buscar el resultado de `ROLLBACK_IN_PROGRESS` en estos registros. El mensaje de error debe ser similar al siguiente: ``` $ pcluster create mycluster Creating stack named: parallelcluster-mycluster Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::EC2::Instance MasterServer Received FAILURE signal with UniqueId i-07af1cb218dd6a081 ``` Para diagnosticar el problema, vuelva a crear el clúster utilizando [`pcluster create`](pluster.create.md), incluida la marca `--norollback`. A continuación, introduzca SSH en el clúster: ``` $ pcluster create mycluster --norollback ... $ pcluster ssh mycluster ``` Una vez que haya iniciado sesión en el nodo principal, encontrará tres archivos de registro principales que podrá usar para identificar el error. + `/var/log/cfn-init.log` es el registro del script `cfn-init`. Compruebe primero este registro. Es probable que veas un error como `Command chef failed` de este registro. Consulte las líneas inmediatamente anteriores a esta línea para obtener información más específica relacionada con el mensaje de error. Para obtener más información, consulte [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html). + `/var/log/cloud-init.log` es el registro de [cloud-init](https://cloudinit.readthedocs.io/). Si no ve nada en `cfn-init.log`, intente revisar este registro a continuación. + `/var/log/cloud-init-output.log` es el resultado de los comandos ejecutados por [cloud-init](https://cloudinit.readthedocs.io/). Esto incluye el resultado de `cfn-init`. En la mayoría de los casos, no es necesario consultar este registro para solucionar problemas de este tipo. ## Solución de problemas en varios clústeres en modo de cola Esta sección es relevante para los clústeres que se instalaron con la AWS ParallelCluster versión 2.9.0 y versiones posteriores con el programador de Slurm tareas. Para obtener más información sobre el modo de colas múltiples, consulte [Modo de Cola múltiple](queue-mode.md). **Topics** + [Registros clave](#key-logs) + [**Solución de problemas de inicialización de nodos**](#troubleshooting-node-initialization-issues) + [**Solución de problemas de sustituciones y terminaciones inesperadas de nodos**](#troubleshooting-unexpected-node-replacements-and-terminations) + [**Reemplazar, terminar o apagar las instancias y nodos problemáticos**](#replacing-terminating-or-powering-down-problematic-instances-and-nodes) + [**Solución de otros problemas de nodos y trabajos conocidos**](#troubleshooting-other-known-node-and-job-issues) ### Registros clave En la siguiente tabla se proporciona una descripción general de los registros clave del nodo principal: `/var/log/cfn-init.log` Este es el registro de inicio CloudFormation . Contiene todos los comandos que se ejecutaron al configurar una instancia. Es útil 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. Es útil para solucionar problemas de inicialización. `/var/log/parallelcluster/slurm_resume.log` Se trata de un registro `ResumeProgram`. Lanza instancias para nodos dinámicos y es útil para solucionar problemas de lanzamiento de nodos dinámicos. `/var/log/parallelcluster/slurm_suspend.log` Este es el registro de `SuspendProgram`. Se llama cuando las instancias se terminan en el caso de los nodos dinámicos y es útil para solucionar problemas de terminación de los nodos dinámicos. Cuando revise este registro, también debe comprobar el registro de `clustermgtd`. `/var/log/parallelcluster/clustermgtd` Este es el registro de `clustermgtd`. Se ejecuta como el daemon centralizado que gestiona la mayoría de las acciones operativas del clúster. Es útil para solucionar cualquier problema de inicio, finalización o funcionamiento del clúster. `/var/log/slurmctld.log` Este es el registro del daemon Slurm de control. AWS ParallelCluster no 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. Estas son las notas clave para los nodos de cómputo: `/var/log/cloud-init-output.log` Este es el registro de [cloud-init](https://cloudinit.readthedocs.io/). Contiene todos los comandos que se ejecutaron al configurar una instancia. Es útil para solucionar problemas de inicialización. `/var/log/parallelcluster/computemgtd` Este es el registro de `computemgtd`. Se ejecuta en cada nodo de cómputo para monitorizarlo en el raro caso de que el daemon `clustermgtd` del nodo principal esté desconectado. Es útil para solucionar problemas de terminación inesperados. `/var/log/slurmd.log` Este es el registro del daemon de computación de Slurm. Es útil para solucionar problemas relacionados con la inicialización y los errores de computación. ### **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 registros de `/var/log/cfn-init.log` y `/var/log/chef-client.log`. Estos registros deben contener 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 un mensaje de error en el registro de `/var/log/chef-client.log`. Si se especifican scripts previos o posteriores a la instalación 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 lo tanto, si los nodos de computación no se unen al clúster, el nodo principal también falla. Puede seguir uno de estos procedimientos, dependiendo del tipo de notas de computación que utilice para solucionar problemas de este tipo: **Nodos de computación dinámicos:** + Busque en el registro de `ResumeProgram` (`/var/log/parallelcluster/slurm_resume.log`) el nombre de su nodo de computación para ver si alguna vez se llamó a `ResumeProgram` con el nodo. (Si `ResumeProgram` nunca lo llamaron, puede 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 configuración de `ResumeProgram`, compruebe que `ResumeProgram` sea propiedad del usuario de `slurm` 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, debería poder ver 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ía ver la dirección IP privada y el ID de instancia correspondientes en el registro de `ResumeProgram`. Además, puede consultar los registros de configuración correspondientes a la instancia específica. Para obtener más información acerca de la solución de problemas relacionados con un nodo de computación, consulte la siguiente sección. **Nodos de computación 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ía ver la dirección IP privada y el ID de instancia correspondientes en el registro de `ResumeProgram`. Además, puede consultar los registros de configuración correspondientes a la instancia específica. + **Nodos de computación:** + **Registros aplicables:** + `/var/log/cloud-init-output.log` + `/var/log/slurmd.log` + Si se ha lanzado un nodo de computación, compruebe primero que `/var/log/cloud-init-output.log` contenga los registros de configuración similares al registro de `/var/log/chef-client.log` 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 registro de `/var/log/cloud-init-output.log`. 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 configuración de Slurm, es posible que se produzca un error relacionado con Slurm que impida que el nodo de procesamiento se una al clúster. Para ver los errores relacionados con el programador, consulte el registro de `/var/log/slurmd.log`. ### **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**: + Consulte el registro de `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) para ver si `clustermgtd` se tomó la medida necesaria para reemplazar o terminar un nodo. 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 en el que se 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 realizar una acción para cerrar un nodo si `clustermgtd` se determina que está en mal estado. Compruebe el registro de `computemgtd` (`/var/log/parallelcluster/computemgtd`) para ver si `computemgtd` ha terminado el nodo. + **Los nodos fallaron** + Compruebe el registro de `slurmctld` (`/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`), siga estos pasos: + Envía un trabajo para permitir que Slurm 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-xyz --disable-api-termination ``` + Recupere la salida de la consola del nodo con este comando. ``` aws ec2 get-console-output --instance-id i-xyz --output text ``` ### **Reemplazar, terminar o apagar las 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 [`scaledown_idletime`](scaling-section.md#scaledown-idletime), consulte el registro de `SuspendProgram` para ver si lo llamó `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. La terminación de todas las instancias y el restablecimiento de `NodeAddr` los realiza `clustermgtd`. Slurm devuelve automáticamente los nodos a un estado de `POWER_SAVING` después de `SuspendTimeout`. ### **Solución de otros problemas de nodos y trabajos conocidos** Otro tipo de problema conocido es que es AWS ParallelCluster posible que no se puedan asignar los trabajos ni tomar decisiones de escalado. En este tipo de problemas, AWS ParallelCluster solo se inician, finalizan o mantienen los recursos de acuerdo con las Slurm instrucciones. En el caso de estos problemas, consulte el registro de `slurmctld` para solucionarlos. ## Solución de problemas en clústeres en modo de cola única **nota** A partir de la versión 2.11.5, AWS ParallelCluster no admite el uso de SGE nuestros programadores. Torque Esta sección se aplica a los clústeres que no tienen el modo de cola múltiple con una de las dos configuraciones siguientes: + Se lanzó con una AWS ParallelCluster versión anterior a la 2.9.0 o con programadores de trabajosSGE. Torque Slurm + Se lanzó con AWS ParallelCluster la versión 2.9.0 o posterior o con programadores de trabajos. SGE Torque **Topics** + [Registros clave](#key-logs-1) + [**Solución de problemas en las operaciones de inicio y unión fallidas**](#troubleshooting-failed-launch-and-join-operations) + [Solución de problemas de escalar](#troubleshooting-scaling-issues) + [Solución de otros problemas relacionados con el clúster](#troubleshooting-other-cluster-related-issues) ### Registros clave Los siguientes archivos de registro son los registros clave del nodo principal. Para la AWS ParallelCluster versión 2.9.0 o posterior: `/var/log/chef-client.log` Este es el registro del cliente CINC (chef). Contiene todos los comandos que se ejecutaron a través de CINC. Es útil para solucionar problemas de inicialización. Para todas las AWS ParallelCluster versiones: `/var/log/cfn-init.log` Este es el registro de `cfn-init`. Contiene todos los comandos que se ejecutaron al configurar una instancia y, por lo tanto, resulta útil para solucionar problemas de inicialización. Para obtener más información, consulte [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html). `/var/log/clustermgtd.log` Este es el registro de `clustermgtd` para los programadores de Slurm. `clustermgtd` se ejecuta como el daemon centralizado que gestiona la mayoría de las acciones operativas del clúster. Es útil para solucionar cualquier problema de inicio, finalización o funcionamiento del clúster. `/var/log/jobwatcher` Este es el registro de `jobwatcher` para los programadores SGE y Torque. `jobwatcher` supervisa la cola del programador y actualiza el grupo de escalado automático. Es útil para solucionar problemas relacionados con el escalado vertical de los nodos. `/var/log/sqswatcher` Este es el registro de `sqswatcher` para los programadores de SGE y Torque. `sqswatcher` procesa el evento listo para la instancia enviado por una instancia de cómputo tras una inicialización correcta. También agrega nodos de cómputo a la configuración del programador. Este registro es útil para solucionar los motivos por los que uno o varios nodos no pudieron unirse a un clúster. A continuación, se muestran los registros clave de los nodos de procesamiento. AWS ParallelCluster versión 2.9.0 o posterior `/var/log/cloud-init-output.log` Este es el registro de inicio de la nube. Contiene todos los comandos que se ejecutaron al configurar una instancia. Es útil para solucionar problemas de inicialización. AWS ParallelCluster versiones anteriores a la 2.9.0 `/var/log/cfn-init.log` Este es el registro de CloudFormation inicio. Contiene todos los comandos que se ejecutaron al configurar una instancia. Es útil para solucionar problemas de inicialización Todas las versiones `/var/log/nodewatcher` Este es el registro de `nodewatcher`. Los daemons de `nodewatcher` que se ejecutan en cada nodo de computación cuando se utilizan los programadores SGE y Torque. Reducen verticalmente un nodo si está inactivo. Este registro es útil para cualquier problema relacionado con la reducción vertical de los recursos. ### **Solución de problemas en las operaciones de inicio y unión fallidas** + **Registros aplicables:** + `/var/log/cfn-init-cmd.log` (nodo principal y nodo de computación) + `/var/log/sqswatcher` (nodo principal) + Si los nodos no se pudieron iniciar, consulte el registro de `/var/log/cfn-init-cmd.log` para ver el mensaje de error específico. En la mayoría de los casos, los errores en el lanzamiento de los nodos se deben a un error de configuración. + Si los nodos de cómputo no pudieron unirse a la configuración del programador a pesar de haberse configurado correctamente, compruebe en el registro de `/var/log/sqswatcher` si `sqswatcher` procesó el evento. En la mayoría de los casos, estos problemas se deben a `sqswatcher` que no procesó el evento. ### Solución de problemas de escalar + **Registros aplicables:** + `/var/log/jobwatcher` (nodo principal) + `/var/log/nodewatcher` (nodo de computación) + **Problemas de escalado vertical:** en el caso del nodo principal, compruebe el registro de `/var/log/jobwatcher` para ver si el daemon de `jobwatcher` calculó el número correcto de nodos necesarios y actualizó el grupo de escalado automático. Tenga en cuenta que `jobwatcher` monitorea la cola del programador y actualiza el grupo de escalado automático. + **Problemas de reducción de escala vertical:** en el caso de los nodos de cómputo, compruebe el registro de `/var/log/nodewatcher` del nodo problemático para ver por qué se ha reducido verticalmente el nodo. Tenga en cuenta que los daemons de `nodewatcher` reducen la escala de un nodo de computación si está inactivo. ### Solución de otros problemas relacionados con el clúster Un problema conocido es que una nota de cálculo aleatoria falla en los clústeres de gran escala, específicamente en aquellos con 500 o más nodos de procesamiento. Este problema está relacionado con una limitación de la arquitectura de escalado de los clústeres de cola única. Si desea utilizar un clúster a gran escala, utiliza la AWS ParallelCluster versión 2.9.0 o posterior, utiliza y quiere evitar este problemaSlurm, debe actualizar y cambiar a un clúster compatible con el modo de cola múltiple. Puede hacerlo ejecutando [`pcluster-config convert`](pcluster-config.md#pcluster-config-convert). En el caso de ultra-large-scale los clústeres, es posible que sea necesario realizar ajustes adicionales en el sistema. Para obtener más información, póngase en contacto con Soporte. ## Problemas con los grupos de ubicación y el lanzamiento de instancias Para obtener la latencia entre nodos más baja, use un *grupo de ubicación*. Un grupo de ubicación garantiza que las instancias estén en la misma red troncal. Si no hay suficientes instancias disponibles cuando se realiza la solicitud, se devuelve un error `InsufficientInstanceCapacity`. Para reducir la posibilidad de recibir este error al utilizar grupos con ubicación en clúster, establezca el parámetro [`placement_group`](cluster-definition.md#placement-group) en `DYNAMIC` y establezca el parámetro [`placement`](cluster-definition.md#placement) en `compute`. Si necesita un sistema de archivos compartidos de alto rendimiento, considere usarlo [FSx para](https://aws.amazon.com/fsx/lustre/) Lustre. Si el nodo principal debe estar en el grupo de ubicación, utilice el mismo tipo de instancia y subred para los nodos principal y de computación. Al hacer esto, el parámetro [`compute_instance_type`](cluster-definition.md#compute-instance-type) tiene el mismo valor que el parámetro [`master_instance_type`](cluster-definition.md#master-instance-type); el parámetro [`placement`](cluster-definition.md#placement) está establecido en `cluster`; y el parámetro [`compute_subnet_id`](vpc-section.md#compute-subnet-id) no se ha especificado. Con esta configuración, el parámetro [`master_subnet_id`](vpc-section.md#master-subnet-id) se utiliza para los nodos de computación. Para obtener más información, consulte [Solución de problemas de lanzamiento de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) y [Roles y limitaciones de los grupos de ubicación](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups) en la *Guía de usuario de Amazon EC2*. ## Directorios que no se pueden reemplazar Los siguientes directorios se comparten entre los nodos y no se pueden reemplazar. `/home` Esto incluye la carpeta principal del usuario predeterminada (`/home/ec2_user` en Amazon Linux, `/home/centos` en CentOS y `/home/ubuntu` en Ubuntu). `/opt/intel` Esto incluye Intel MPI, Intel Parallel Studio y archivos relacionados. `/opt/sge` A partir de la versión 2.11.5, AWS ParallelCluster no admite el uso de planificadores o. SGE Torque Esto incluye Son of Grid Engine y archivos relacionados. (Condicional, solo si [`scheduler`](cluster-definition.md#scheduler)` = sge`). `/opt/slurm` Esto incluye Slurm Workload Manager y archivos relacionados. (Condicional, solo si [`scheduler`](cluster-definition.md#scheduler)` = slurm`). `/opt/torque` A partir de la versión 2.11.5, AWS ParallelCluster no admite el uso de planificadores o. SGE Torque Esto incluye Torque Resource Manager y archivos relacionados. (Condicional, solo si [`scheduler`](cluster-definition.md#scheduler)` = torque`). ## Solución de problemas de Amazon DCV **Topics** + [Registros para Amazon DCV](#nice-dcv-troubleshooting-logs) + [Memoria de tipo instancia de Amazon DCV](#nice-dcv-troubleshooting-memory) + [Problemas con Ubuntu Amazon DCV](#nice-dcv-troubleshooting-modules) ### Registros para Amazon DCV Los registros de Amazon DCV se escriben en los archivos del directorio `/var/log/dcv/`. Revisar estos registros puede ayudar a solucionar problemas. ### Memoria de tipo instancia de Amazon DCV El tipo de instancia debe tener al menos 1,7 GiB de RAM para ejecutar Amazon DCV. Los tipos de instancia Nano y micro no tienen suficiente memoria para ejecutar Amazon DCV. ### Problemas con Ubuntu Amazon DCV Al ejecutar Gnome Terminal en una sesión de DCV en Ubuntu, es posible que no tengas acceso automáticamente al entorno de usuario que está disponible a través de la consola de inicio de sesión AWS ParallelCluster . El entorno de usuario proporciona módulos de entorno, como openmpi o intelmpi, y otros ajustes de usuario. La configuración predeterminada de la Terminal de Gnome impide que el intérprete de comandos se inicie como un intérprete de comandos de inicio de sesión. Esto significa que los perfiles de shell no se obtienen automáticamente y el entorno de AWS ParallelCluster usuario no está cargado. Para obtener correctamente el perfil de shell y acceder al entorno AWS ParallelCluster de usuario, realice una de las siguientes acciones: + **Cambie la configuración predeterminada del terminal:** 1. Seleccione el menú **Editar** en la terminal de Gnome. 1. Seleccione **Preferencias y**, a continuación, **Perfiles**. 1. Elija **Comando** y seleccione **Ejecutar comando como intérprete de comandos de inicio de sesión**. 1. Abrir una nueva terminal. + **Utilice la línea de comandos para obtener los perfiles disponibles:** ``` $ source /etc/profile && source $HOME/.bashrc ``` ## Solución de problemas en clústeres con AWS Batch integración Esta sección es relevante para los clústeres con integración de AWS Batch planificadores. ### Problemas con el nodo principal Los problemas de configuración relacionados con el nodo principal se pueden solucionar de la misma manera que con un clúster de cola única. Para obtener más información sobre estos problemas, consulte [Solución de problemas en clústeres en modo de cola única](#troubleshooting-issues-in-single-queue-clusters). ### AWS Batch problemas de envío de trabajos paralelos de varios nodos Si tiene problemas para enviar trabajos paralelos de varios nodos al utilizarlos AWS Batch como programador de trabajos, debe actualizar a la AWS ParallelCluster versión 2.5.0. Si eso no es posible, puede utilizar la solución alternativa que se detalla en el tema: [Self patch a cluster used for submitting multi-node parallel jobs through AWS Batch](https://github.com/aws/aws-parallelcluster/wiki/Self-patch-a-Cluster-Used-for-Submitting-Multi-node-Parallel-Jobs-through-AWS-Batch). ### Problemas informáticos AWS Batch gestiona los aspectos de escalado y computación de sus servicios. Si tiene problemas relacionados con la informática, consulte la documentación AWS Batch [de solución de problemas](https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html) para obtener ayuda. ### Errores en los trabajos Si se produce un error en un trabajo, puede ejecutar el comando ``awsbout`` para recuperar el resultado del trabajo. También puedes ejecutar el ``awsbstat` -d` comando para obtener un enlace a los registros de trabajos almacenados por Amazon CloudWatch. ## Solución de problemas cuando un recurso no se crea Esta sección es relevante para los recursos del clúster cuando no se pueden crear. Cuando no se puede crear un recurso, ParallelCluster devuelve un mensaje de error como el siguiente. ``` pcluster create -c config my-cluster Beginning cluster creation for cluster: my-cluster WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet (e.g. a NAT Gateway and a valid route table). Info: There is a newer version 3.0.3 of AWS ParallelCluster available. Creating stack named: parallelcluster-my-cluster Status: parallelcluster-my-cluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::CloudFormation::Stack MasterServerSubstack Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer]. - AWS::CloudFormation::Stack parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL The following resource(s) failed to create: [MasterServer]. - AWS::EC2::Instance MasterServer You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit. (Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null) } ``` Por ejemplo, si ve el mensaje de estado que se muestra en la respuesta del comando anterior, debe usar tipos de instancias que no superen el límite actual de vCPU ni solicitar más capacidad de vCPU. También puede usar la CloudFormation consola para ver información sobre el `"Cluster creation failed"` estado. Vea los mensajes de CloudFormation error de la consola. 1. Inicie sesión en /cloudformation Consola de administración de AWS y diríjase a [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/) 1. Seleccione la pila denominada parallelcluster-. *cluster\$1name* 1. Seleccione la pestaña **Eventos**. 1. Compruebe el **estado** del recurso que no se pudo crear desplazándose por la lista de eventos del recurso por **identificador lógico**. Si no se pudo crear una subtarea, retroceda para encontrar el evento de recurso fallido. 1. Un ejemplo de AWS CloudFormation mensaje de error: ``` 2022-02-07 11:59:14 UTC-0800 MasterServerSubstack CREATE_FAILED Embedded stack arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 was not successfully created: The following resource(s) failed to create: [MasterServer]. ``` ## Solución de problemas de tamaño de políticas de IAM Consulte la [IAM y AWS STS las cuotas, los requisitos de nombres y los límites de caracteres](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) para comprobar las cuotas de las políticas gestionadas asociadas a las funciones. Si el tamaño de una política administrada supera la cuota, divida la política en dos o más políticas. Si supera la cuota de políticas asociadas a un rol de IAM, crea funciones adicionales y distribuye las políticas entre ellas para cumplir con la cuota. ## Compatibilidad adicional Para obtener una lista de problemas conocidos, consulta la página principal de la [GitHubwiki](https://github.com/aws/aws-parallelcluster/wiki) o la página de [problemas](https://github.com/aws/aws-parallelcluster/issues). Para problemas más urgentes, contacta Soporte o abre un [nuevo GitHub número](https://github.com/aws/aws-parallelcluster/issues).