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
Las siguientes secciones proporcionan consejos para la solución de problemas que pueden producirse al utilizar AWS ParallelCluster. La AWS ParallelCluster comunidad mantiene una página wiki que proporciona muchos consejos para la solución de 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**
+ [Intentando crear un clúster](troubleshooting-fc-v3-create-cluster.md)
+ [Intentando ejecutar un trabajo](troubleshooting-fc-v3-run-job.md)
+ [Intentando actualizar un clúster](troubleshooting-fc-v3-update-cluster.md)
+ [¿Estás intentando acceder al almacenamiento](troubleshooting-fc-v3-access-storage.md)
+ [¿Está intentando eliminar un clúster](troubleshooting-fc-v3-delete-cluster.md)
+ [¿Estás intentando actualizar la pila AWS ParallelCluster de API](troubleshooting-fc-v3-upgrade-stack-v3.md)
+ [Visualización de errores en las inicializaciones de los nodos de computación](troubleshooting-fc-v3-compute-node-initialization-v3.md)
+ [Solución de problemas de estado del clúster](troubleshooting-v3-cluster-health-metrics.md)
+ [Solución de problemas de implementación del clúster](troubleshooting-v3-cluster-deployment.md)
+ [Solución de problemas de implementación del clúster con Terraform](troubleshooting-v3-terraform.md)
+ [Solución de problemas de escalar](troubleshooting-v3-scaling-issues.md)
+ [Problemas con los grupos de ubicación y el lanzamiento de instancias](troubleshooting-v3-placemment-groups.md)
+ [Sustitución de directorios](troubleshooting-v3-dirs-must-keep.md)
+ [Solución de problemas de Amazon DCV](troubleshooting-v3-nice-dcv.md)
+ [Solución de problemas en los clústeres con AWS Batch integración](troubleshooting-v3-batch.md)
+ [Solución de problemas de integración multiusuario con Active Directory](troubleshooting-v3-multi-user.md)
+ [Solución de problemas con las AMI de](troubleshooting-v3-custom-amis.md)
+ [Solución de problemas cuando se agota el tiempo de espera de una actualización del clúster cuando no se está ejecutando `cfn-hup`](troubleshooting-v3-cluster-update-timeout.md)
+ [Solución de problemas de redes en bastidor](troubleshooting-v3-networking.md)
+ [No se pudo actualizar el clúster al realizar una acción `onNodeUpdated` personalizada](troubleshooting-v3-on-node-updated.md)
+ [Visualización de errores en la configuración personalizada de Slurm](troubleshooting-v3-custom-slurm-config.md)
+ [Alarmas de clústeres](troubleshooting-v3-cluster-alarms.md)
+ [Resolver los cambios en la configuración del sistema operativo que provocan errores o fallas](resolving-os-configuration-changes.md)
# Intentando crear un clúster
Si utiliza la AWS ParallelCluster versión 3.5.0 y versiones posteriores para crear un clúster y se produce un error en la creación de un clúster con el `--rollback-on-failure` valor establecido en`false`, utilice el comando [`pcluster describe-cluster`](pcluster.describe-cluster-v3.md) CLI para obtener información sobre el estado y el error. En este caso, lo que se espera `clusterStatus` del `pcluster describe-cluster` resultado es`CREATE_FAILED`. Compruebe la `failures` sección de la salida para encontrar el `failureCode` y`failureReason`. Luego, en la siguiente sección, busque la solución adecuada `failureCode` para obtener ayuda adicional sobre la solución de problemas. Para obtener más información, consulte [`pcluster describe-cluster`](pcluster.describe-cluster-v3.md).
En las siguientes secciones, le recomendamos que compruebe los registros del nodo principal, como los `/var/log/chef-client.log` archivos `/var/log/cfn-init.log` and. Para obtener más información sobre AWS ParallelCluster los registros y cómo verlos, consulte [Registros clave para la depuración](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs) y[Recuperación y conservación de registros](troubleshooting-v3-get-logs.md).
Si no tiene uno`failureCode`, vaya a la CloudFormation consola para ver la pila de clústeres. Compruebe si hay errores en otros recursos para obtener información adicional sobre los errores. `Status Reason` `HeadNodeWaitCondition` Para obtener más información, consulte [Vea CloudFormation los eventos en `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events). Compruebe los `/var/log/chef-client.log` archivos `/var/log/cfn-init.log` y del nodo principal. Si la creación del clúster falla debido a un error en la creación del nodo principal y los registros del clúster no están disponibles en el grupo de registros del clúster, debe conservar el clúster en caso de error, especificar `--rollback-on-failure` = `True` y recuperar los registros desde el propio nodo principal.
## `failureCode` es `OnNodeConfiguredExecutionFailure`
+ **¿Por qué falló?**
Proporcionó un script personalizado en la sección `OnNodeConfigured` del nodo principal de la configuración para crear un clúster. Sin embargo, el script personalizado no se pudo ejecutar.
+ **¿Cómo resolverlo?**
Consulte el `/var/log/cfn-init.log` archivo para obtener más información sobre el error y cómo solucionar el problema en su script personalizado. Cerca del final de este registro, es posible que veas información de ejecución relacionada con el `OnNodeConfigured` script después del `Running command runpostinstall` mensaje.
## `failureCode` es `OnNodeConfiguredDownloadFailure`
+ **¿Por qué falló?**
Proporcionó un script personalizado en la sección `OnNodeConfigured` del nodo principal de la configuración para crear un clúster. Sin embargo, no se pudo descargar el script personalizado.
+ **¿Cómo resolverlo?**
Asegúrese de que la URL sea válida y de que el acceso esté configurado correctamente. Para obtener más información sobre la configuración de los scripts de arranque personalizados, consulte[Acciones de arranque personalizadas](custom-bootstrap-actions-v3.md).
Compruebe los archivos en `/var/log/cfn-init.log`. Al final de este registro, es posible que, después del `Running command runpostinstall` mensaje, aparezca información sobre la ejecución relacionada con el procesamiento de los `OnNodeConfigured` scripts, incluida la descarga.
## `failureCode` es `OnNodeConfiguredFailure`
+ **¿Por qué falló?**
Proporcionó un script personalizado en la sección `OnNodeConfigured` del nodo principal de la configuración para crear un clúster. Sin embargo, el uso del script personalizado falló en la implementación del clúster. No se puede determinar una causa inmediata y es necesaria una investigación adicional.
+ **¿Cómo resolverlo?**
Compruebe los archivos en `/var/log/cfn-init.log`. Cerca del final de este registro, es posible que vea información de ejecución relacionada con el procesamiento de `OnNodeConfigured` scripts después del `Running command runpostinstall` mensaje.
## `failureCode` es `OnNodeStartExecutionFailure`
+ **¿Por qué falló?**
Proporcionó un script personalizado en la sección `OnNodeStart` del nodo principal de la configuración para crear un clúster. Sin embargo, el script personalizado no se pudo ejecutar.
+ **¿Cómo resolverlo?**
Consulte el `/var/log/cfn-init.log` archivo para obtener más información sobre el error y cómo solucionar el problema en su script personalizado. Cerca del final de este registro, es posible que veas información de ejecución relacionada con el `OnNodeStart` script después del `Running command runpreinstall` mensaje.
## `failureCode` es `OnNodeStartDownloadFailure`
+ **¿Por qué falló?**
Proporcionó un script personalizado en la sección `OnNodeStart` del nodo principal de la configuración para crear un clúster. Sin embargo, no se pudo descargar el script personalizado.
+ **¿Cómo resolverlo?**
Asegúrese de que la URL sea válida y de que el acceso esté configurado correctamente. Para obtener más información sobre la configuración de los scripts de arranque personalizados, consulte[Acciones de arranque personalizadas](custom-bootstrap-actions-v3.md).
Compruebe los archivos en `/var/log/cfn-init.log`. Al final de este registro, es posible que, después del `Running command runpreinstall` mensaje, aparezca información sobre la ejecución relacionada con el procesamiento de los `OnNodeStart` scripts, incluida la descarga.
## `failureCode` es `OnNodeStartFailure`
+ **¿Por qué falló?**
Proporcionó un script personalizado en la sección `OnNodeStart` del nodo principal de la configuración para crear un clúster. Sin embargo, el uso del script personalizado falló en la implementación del clúster. No se puede determinar una causa inmediata y es necesaria una investigación adicional.
+ **¿Cómo resolverlo?**
Compruebe los archivos en `/var/log/cfn-init.log`. Cerca del final de este registro, es posible que vea información de ejecución relacionada con el procesamiento de `OnNodeStart` scripts después del `Running command runpreinstall` mensaje.
## `failureCode` es `EbsMountFailure`
+ **¿Por qué falló?**
No se pudo montar el volumen de EBS definido en la configuración del clúster.
+ **¿Cómo resolverlo?**
Consulte el archivo `/var/log/chef-client.log` para conocer los detalles del error.
## `failureCode` es `EfsMountFailure`
+ **¿Por qué falló?**
No se pudo montar el volumen de Amazon EFS definido en la configuración del clúster.
+ **¿Cómo resolverlo?**
Si ha definido un sistema de archivos Amazon EFS existente, asegúrese de que se permita el tráfico entre el clúster y el sistema de archivos. Para obtener más información, consulte [`SharedStorage`](SharedStorage-v3.md). [`EfsSettings`](SharedStorage-v3.md#SharedStorage-v3-EfsSettings) [`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId).
Consulte el archivo `/var/log/chef-client.log` para conocer los detalles del error.
## `failureCode` es `FsxMountFailure`
+ **¿Por qué falló?**
No se pudo montar el sistema de FSx archivos de Amazon definido en la configuración del clúster.
+ **¿Cómo resolverlo?**
Si has definido un sistema de FSx archivos de Amazon existente, asegúrate de que se permita el tráfico entre el clúster y el sistema de archivos. Para obtener más información, consulte [`SharedStorage`](SharedStorage-v3.md). [`FsxLustreSettings`](SharedStorage-v3.md#SharedStorage-v3-FsxLustreSettings) [`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId).
Consulte el archivo `/var/log/chef-client.log` para conocer los detalles del error.
## `failureCode` es `RaidMountFailure`
+ **¿Por qué falló?**
No se pudieron montar los volúmenes RAID definidos en la configuración del clúster.
+ **¿Cómo resolverlo?**
Consulte el archivo `/var/log/chef-client.log` para conocer los detalles del error.
## `failureCode` es `AmiVersionMismatch`
+ **¿Por qué falló?**
La AWS ParallelCluster versión utilizada para crear la AMI personalizada es diferente de la AWS ParallelCluster versión utilizada para configurar el clúster. En la CloudFormation consola, consulte los detalles de la CloudFormation `Status Reason` pila de clústeres y compruebe si `HeadNodeWaitCondition` desea obtener información adicional sobre las AWS ParallelCluster versiones y la AMI. Para obtener más información, consulte [Vea CloudFormation los eventos en `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events).
+ **¿Cómo resolverlo?**
Asegúrese de que la AWS ParallelCluster versión utilizada para crear la AMI personalizada sea la misma AWS ParallelCluster que se utilizó para configurar el clúster. Puede cambiar la versión de la AMI personalizada o la versión de la `pcluster` CLI para que sean iguales.
## `failureCode` es `InvalidAmi`
+ **¿Por qué falló?**
La AMI personalizada no es válida porque no se creó con AWS ParallelCluster.
+ **¿Cómo resolverlo?**
Use el `pcluster build-image` comando para crear una AMI haciendo que su AMI sea la imagen principal. Para obtener más información, consulte [`pcluster build-image`](pcluster.build-image-v3.md).
## `failureCode`está `HeadNodeBootstrapFailure` con `failureReason` No se pudo configurar el nodo principal.
+ **¿Por qué falló?**
No se puede determinar una causa inmediata y es necesaria una investigación adicional. Por ejemplo, podría ser que el clúster esté en estado protegido y esto podría deberse a un fallo en el aprovisionamiento de la flota de computación estática.
+ **¿Cómo resolverlo?**
Consulte el archivo `/var/log/chef-client.log.` para conocer los detalles del error.
**nota**
Si ve la excepción de `RuntimeError` `Cluster state has been set to PROTECTED mode due to failures detected in static node provisioning`, el clúster está en estado protegido. Para obtener más información, consulte [Cómo depurar el modo protegido](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3).
## `failureCode`está `HeadNodeBootstrapFailure` agotando el tiempo de espera para la creación del `failureReason` clúster.
+ **¿Por qué falló?**
De forma predeterminada, hay un límite de 30 minutos para que se complete la creación del clúster. Si la creación del clúster no se ha completado dentro de este período de tiempo, se produce un error de tiempo de espera. La creación del clúster puede agotarse por diferentes motivos. Por ejemplo, los errores de tiempo de espera pueden deberse a un error en la creación del nodo principal, a un problema de red, a scripts personalizados que tardan demasiado en ejecutarse en el nodo principal, a un error en un script personalizado que se ejecuta en los nodos de procesamiento o a tiempos de espera prolongados para el aprovisionamiento del nodo de procesamiento. No se puede determinar una causa inmediata y es necesaria una investigación adicional.
+ **¿Cómo resolverlo?**
Consulte los archivos `/var/log/cfn-init.log` y `/var/log/chef-client.log` para conocer los detalles del error. Para obtener más información sobre los registros de AWS ParallelCluster y cómo obtenerlos, consulte [Registros clave para la depuración](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs) y [Recuperación y conservación de registros](troubleshooting-v3-get-logs.md).
Puede que descubra lo siguiente en estos registros.
+ **Visualización de `Waiting for static fleet capacity provisioning` cerca del final del `chef-client.log`**
Esto indica que se agotó el tiempo de espera para la creación del clúster al esperar a que se enciendan los nodos estáticos. Para obtener más información, consulte [Visualización de errores en las inicializaciones de los nodos de computación](troubleshooting-fc-v3-compute-node-initialization-v3.md).
+ **La visualización del script del nodo principal de `OnNodeConfigured` o `OnNodeStart` no ha finalizado al final del `cfn-init.log`**
Esto indica que el script `OnNodeConfigured` o el script `OnNodeStart` personalizado tardaron mucho en ejecutarse y provocaron un error de tiempo de espera. Compruebe si su script personalizado tiene problemas que puedan provocar que se ejecute durante mucho tiempo. Si el script personalizado tarda mucho en ejecutarse, considere la posibilidad de cambiar el límite de tiempo de espera añadiendo una `DevSettings` sección al archivo de configuración del clúster, como se muestra en el siguiente ejemplo:
```
DevSettings:
Timeouts:
HeadNodeBootstrapTimeout: 1800 # default setting: 1800 seconds
```
+ **No se encuentran los registros o el nodo principal no se creó correctamente**
Es posible que el nodo principal no se haya creado correctamente y que no se puedan encontrar los registros. En este caso, puede obtener información adicional sobre el error consultando los eventos de la CloudFormation pila y el registro de la consola del nodo principal. Puede recuperar el registro de la consola del nodo principal a través de la consola de Amazon EC2 o ejecutando el siguiente comando de la CLI de Amazon EC2:
```
aws ec2 get-console-output --instance-id HEAD_NODE_INSTANCE_ID --output text
```
## `failureCode`está `HeadNodeBootstrapFailure` con `failureReason` No se pudo iniciar el nodo principal.
+ **¿Por qué falló?**
No se puede determinar una causa inmediata y es necesaria una investigación adicional.
+ **¿Cómo resolverlo?**
Compruebe los campos `/var/log/cfn-init.log` y `/var/log/chef-client.log`.
## `failureCode` es `ResourceCreationFailure`
+ **¿Por qué falló?**
La creación de algunos recursos falló durante el proceso de creación del clúster. El fallo puede producirse por varias razones: Por ejemplo, los errores en la creación de recursos pueden deberse a problemas de capacidad o a una política de IAM mal configurada.
+ **¿Cómo resolverlo?**
En la CloudFormation consola, consulte la pila de clústeres para comprobar si hay más detalles sobre el error de creación de recursos.
## `failureCode` es `ClusterCreationFailure`
+ **¿Por qué falló?**
No se puede determinar una causa inmediata y es necesaria una investigación adicional.
+ **¿Cómo resolverlo?**
En la CloudFormation consola, visualice la pila de clústeres y compruebe si hay más detalles sobre el `HeadNodeWaitCondition` error. `Status Reason`
Compruebe los campos `/var/log/cfn-init.log` y `/var/log/chef-client.log`.
## ¿Está viendo `WaitCondition timed out...` en la CloudFormation pila
Para obtener más información, consulte [`failureCode`está `HeadNodeBootstrapFailure` agotando el tiempo de espera para la creación del `failureReason` clúster.](#create-cluster-head-node-bootstrap-timeout-failure-v3).
## Ver `Resource creation cancelled` en CloudFormation pila
Para obtener más información, consulte [`failureCode` es `ResourceCreationFailure`](#create-cluster-resource-creation-failure-v3).
## `Failed to run cfn-init...`¿Ve u otros errores en la CloudFormation pila
Compruebe los detalles adicionales del fallo `/var/log/cfn-init.log` y `/var/log/chef-client.log` compruebe si hay más detalles.
## Visualización de cómo `chef-client.log` termina con `INFO: Waiting for static fleet capacity provisioning`
Esto está relacionado con el tiempo de espera para la creación del clúster cuando se espera a que se enciendan los nodos estáticos. Para obtener más información, consulte [Visualización de errores en las inicializaciones de los nodos de computación](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Visualización de `Failed to run preinstall or postinstall in cfn-init.log`
Tiene un `OnNodeStart` script `OnNodeConfigured` or en la `HeadNode` sección de configuración del clúster. El script no funciona correctamente. Compruebe el `/var/log/cfn-init.log` archivo para ver los detalles de error del script personalizado.
## ¿Está viendo `This AMI was created with xxx, but is trying to be used with xxx...` en la CloudFormation pila
Para obtener más información, consulte [`failureCode` es `AmiVersionMismatch`](#create-cluster-ami-version-mismatch-v3).
## Ver `This AMI was not baked by AWS ParallelCluster...` en CloudFormation pila
Para obtener más información, consulte [`failureCode` es `InvalidAmi`](#create-cluster-invalid-ami-v3).
## Visualización de cómo el comando `pcluster create-cluster` no se ejecuta localmente
Consulte el `~/.parallelcluster/pcluster-cli.log` en su sistema de archivos local para conocer los detalles del error.
## Compatibilidad adicional
Siga las instrucciones de solución de problemas que se indican en[Solución de problemas de implementación del clúster](troubleshooting-v3-cluster-deployment.md).
Comprueba si tu situación está incluida en la sección [Problemas GitHub conocidos](https://github.com/aws/aws-parallelcluster/wiki), en la parte AWS ParallelCluster superior GitHub.
# Intentando ejecutar un trabajo
En la siguiente sección se proporcionan posibles soluciones a problemas que puedan surgir al intentar ejecutar un trabajo.
## `srun`el trabajo interactivo falla con un error `srun: error: fwd_tree_thread: can't find address for , check slurm.conf`
+ **¿Por qué falló?**
Ejecutaste el `srun` comando para enviar un trabajo y, a continuación, aumentaste el tamaño de la cola utilizando el `pcluster update-cluster` comando sin reiniciar los Slurm daemons una vez finalizada la actualización.
Slurm organiza los daemons de Slurm en una jerarquía de árbol para optimizar la comunicación. Esta jerarquía solo se actualiza cuando se inician los daemons.
Supongamos que se inicia un trabajo y, `srun` a continuación, se ejecuta el `pcluster update-cluster` comando para aumentar el tamaño de la cola. Como parte de la actualización, se lanzan nuevos nodos de cómputo. A continuación, Slurm coloca el trabajo en cola en uno de los nuevos nodos de cómputo. En este caso, tanto los daemons de Slurm como `srun` no detectan los nuevos nodos de computación. `srun` devuelve un error porque no detecta los nuevos nodos.
+ **¿Cómo resolverlo?**
Reinicia los daemons de Slurm en todos los nodos de procesamiento y use `srun` para enviar su trabajo. Para programar el reinicio de los Slurm daemons, ejecute el `scontrol reboot` comando que reinicia los nodos de procesamiento. Para obtener más información, consulte [Paquetes de conformidad](https://slurm.schedmd.com/scontrol.html#OPT_reboot) en la documentación de Slurm. También puede reiniciar manualmente los daemons de Slurm de los nodos de computación solicitando el reinicio de los servicios de `systemd` correspondientes.
## Job está atascado en el `CF` estado con `squeue` el comando
Esto podría deberse a que los nodos dinámicos se están encendiendo. Para obtener más información, consulte [Visualización de errores en las inicializaciones de los nodos de computación](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Ejecución de trabajos a gran escala y visualización de `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`
Con un sistema de archivos en red, cuando se alcanzan los límites de la red, el tiempo de I/O espera también aumenta. Esto puede provocar bloqueos temporales, ya que la red se utiliza para escribir datos tanto para la red como para las métricas. I/O
En el caso de las instancias de quinta generación, utilizamos el controlador ENA para exponer los contadores de paquetes. Estos contadores cuentan los paquetes a los que se da forma AWS cuando la red alcanza los límites de ancho de banda de la instancia. Puede consultar estos contadores para ver si son mayores que 0. Si lo son, significa que ha superado los límites de ancho de banda. Puede ver estos contadores corriendo`ethtool -S eth0 | grep exceeded`.
Superar los límites de la red suele deberse a que se admiten demasiadas conexiones NFS. Esta es una de las primeras cosas que hay que comprobar cuando se alcanzan o se superan los límites de la red.
Por ejemplo, el siguiente resultado muestra los paquetes descartados:
```
$ ethtool -S eth0 | grep exceeded
bw_in_allowance_exceeded: 38750610
bw_out_allowance_exceeded: 1165693
pps_allowance_exceeded: 103
conntrack_allowance_exceeded: 0
linklocal_allowance_exceeded: 0
```
Para evitar recibir este mensaje, considere la posibilidad de cambiar el tipo de instancia del nodo principal por un tipo de instancia con más rendimiento. Considere la posibilidad de trasladar su almacenamiento de datos a sistemas de archivos de almacenamiento compartido que no se exporten como un recurso compartido de NFS, como Amazon EFS o Amazon FSx. Para obtener más información, consulte [Almacenamiento compartido](shared-storage-quotas-integration-v3.md) las [prácticas recomendadas](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) en la AWS ParallelCluster wiki sobre GitHub.
## Ejecución de trabajos de MPI
### Cómo habilitar el modo de depuración
Para habilitar el modo de depuración de OpenMPI, [consulte ¿Qué controles tiene Open MPI](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls) que ayudan a depurar?
[Para habilitar el modo de depuración de IntelMPI, consulte Otras variables de entorno.](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html)
### Visualización de `MPI_ERRORS_ARE_FATAL` y `OPAL ERROR` en el resultado del trabajo
Estos códigos de error provienen de la capa MPI de su aplicación. Para obtener información sobre cómo obtener los registros de depuración de MPI de su aplicación, consulte. [Cómo habilitar el modo de depuración](#run-job-mpi-enable-v3)
Una posible causa de este error es que la aplicación se ha compilado para una implementación de MPI específica, como OpenMPI, y está intentando ejecutarla con una implementación de MPI diferente, como IntelMPI. Asegúrese de compilar y ejecutar la aplicación con la misma implementación de MPI.
### Se utiliza `mpirun` con el DNS administrado desactivado
En el caso de los clústeres creados con [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/Dns/[DisableManagedDns](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns)y [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) configurados en`true`, el [DNS](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns) no resuelve el nombre del Slurm nodo. Slurmpuede iniciar procesos de MPI cuando `nodenames` no están habilitados y si el trabajo de MPI se ejecuta en un contexto. Slurm Recomendamos seguir las instrucciones de la Guía del [usuario de Slurm MPI para ejecutar trabajos de](https://slurm.schedmd.com/mpi_guide.html) MPI con él. Slurm
# Intentando actualizar un clúster
En la siguiente sección se proporcionan posibles soluciones a problemas que puedan ocurrir al intentar actualizar un clúster.
## `pcluster update-cluster`el comando no se ejecuta localmente
Consulte el `~/.parallelcluster/pcluster-cli.log` en su sistema de archivos local para conocer los detalles del error.
## Visualización de `clusterStatus` como `UPDATE_FAILED` con el comando `pcluster describe-cluster`
### Causa raíz
Para identificar la causa raíz del error, el punto de partida es observar los eventos de la pila de clústeres y `/var/log/chef-client.log` el nodo principal.
Una posible causa es que al menos un nodo del clúster no aplicó la actualización. Para recuperar la lista de nodos que no se pudieron actualizar `/var/log/chef-client.log` en el nodo principal, busque `Check cluster readiness` en el registro.
Comprueba si tu problema aparece en la sección [Problemas GitHub conocidos](https://github.com/aws/aws-parallelcluster/wiki), en la sección AWS ParallelCluster correspondiente GitHub.
### Prevenir
La actualización de un clúster puede fallar si al menos un nodo del clúster no la aplicó correctamente. Para reducir el riesgo de que se produzca un error en la actualización del clúster, recomendamos cerrar los nodos dañados antes de iniciar la actualización. Un ejemplo de nodos que podrían romperse son los nodos de cómputo que permanecen inactivos `COMPLETING` durante más tiempo del esperado en el epílogo. Para detectar esos nodos, puede ejecutar el siguiente comando, adaptando el `threshold` valor a sus necesidades (el valor debe ser superior a la duración máxima esperada para los epílogos).
```
$ scontrol show nodes --json | jq -r --argjson threshold 60 '
.nodes[] | select(.state | index("COMPLETING")) |
select((now - .last_busy.number) > $threshold) |
.name
'
```
### ¿Recuperando
Si la actualización falló, se espera que la reversión recupere el estado del clúster.
Si la reversión falló, el estado del clúster no es determinista. En este caso, es posible que se haya `clustermgtd` detenido para evitar la amplificación de las fallas. Recomendamos iniciarlo ejecutando el siguiente comando en el nodo principal. Adapte la versión de Python a la que viene con su AWS ParallelCluster versión:
```
$ /opt/parallelcluster/pyenv/versions/3.12.11/envs/cookbook_virtualenv/bin/supervisorctl start clustermgtd
```
## Se agotó el tiempo de espera de la actualización del clúster
Podría deberse a un problema relacionado con la falta de `cfn-hup` ejecución. Si el daemon de `cfn-hup` se elimina por una causa externa, no se reinicia automáticamente. Si `cfn-hup` no se está ejecutando, durante una actualización del clúster, la CloudFormation pila inicia el proceso de actualización según lo previsto, pero el procedimiento de actualización no se activa en el nodo principal y, finalmente, se agota el tiempo de espera para el despliegue de la pila. Para obtener más información, consulte [Solución de problemas cuando se agota el tiempo de espera de una actualización del clúster cuando no se está ejecutando `cfn-hup`](troubleshooting-v3-cluster-update-timeout.md) para solucionar el problema y recuperarse de él.
# ¿Estás intentando acceder al almacenamiento
Obtén información sobre los consejos de solución de problemas para intentar acceder al almacenamiento.
## Uso de un sistema de archivos Amazon FSx for Lustre externo
Asegúrese de que se permita el tráfico entre el clúster y el sistema de archivos. Si se usa un sistema de archivos ya existente, debe asociarse a un grupo de seguridad que permita el tráfico TCP de entrada y salida desde a través del puerto . Para obtener más información sobre cómo configurar grupos de seguridad, consulte [FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId).
## Uso de un sistema de archivos externo de Amazon Elastic File System
Asegúrese de que se permita el tráfico entre el clúster y el sistema de archivos. Si se usa un sistema de archivos ya existente, debe asociarse a un grupo de seguridad que permita el tráfico TCP de entrada y salida desde a través del puerto . Para obtener más información sobre cómo configurar grupos de seguridad, consulte [FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId).
# ¿Está intentando eliminar un clúster
Si recibes un error al intentar eliminar un clúster, en las siguientes secciones se proporcionan consejos para solucionar los problemas más comunes.
## El `pcluster delete-cluster` comando no se puede ejecutar localmente
Compruebe el `~/.parallelcluster/pcluster-cli.log` archivo en su sistema de archivos local.
## La pila de clústeres no se puede eliminar
Si la pila de clústeres no se elimina, compruebe el mensaje de eventos de la CloudFormation pila.
Comprueba si tu problema aparece en la sección [Problemas GitHub conocidos](https://github.com/aws/aws-parallelcluster/wiki), AWS ParallelCluster en la sección correspondiente GitHub.
# ¿Estás intentando actualizar la pila AWS ParallelCluster de API
Si recibes un error, por ejemplo, al intentar actualizar la pila de AWS ParallelCluster API, te recomendamos que busques una solución en las secciones sobre **problemas conocidos** de la [AWS ParallelCluster wiki](https://github.com/aws/aws-parallelcluster/wiki) GitHub. `UPDATE_FAILED` Por ejemplo, consulta el artículo No se [puede actualizar la pila de ParallelCluster API para ver los recursos de ECR](https://github.com/aws/aws-parallelcluster/wiki/(3.0.0-3.1.4)-ParallelCluster-API-Stack-Upgrade-Fails-for-ECR-resources), donde se identifica un posible problema y se proporcionan opciones de mitigación.
# Visualización de errores en las inicializaciones de los nodos de computación
En las siguientes secciones, se proporcionan consejos para solucionar problemas cuando se detectan errores en las inicializaciones de los nodos de computación. Esto incluye los errores de arranque, la detección de errores en los registros y el lugar al que acudir si ninguno de los escenarios se aplica a su situación concreta.
**Topics**
+ [Visualización de `Node bootstrap error` en `clustermgtd.log`](compute-node-initialization-bootstrap-error-v3.md)
+ [He configurado reservas de capacidad bajo demanda (ODCRs) o instancias reservadas zonales](compute-node-initialization-odcr-v3.md)
+ [Visualización de `An error occurred (VcpuLimitExceeded)` en `slurm_resume.log` cuando no puedo ejecutar un trabajo o en `clustermgtd.log` cuando no puedo crear un clúster](compute-node-initialization-vpc-limit-v3.md)
+ [Visualización de `An error occurred (InsufficientInstanceCapacity)` en `slurm_resume.log` cuando no puedo ejecutar un trabajo o en `clustermgtd.log` cuando no puedo crear un clúster](compute-node-initialization-ice-failure-v3.md)
+ [Visualización de los nodos que están en estado `DOWN` con `Reason (Code:InsufficientInstanceCapacity)...`](compute-node-initialization-down-nodes-v3.md)
+ [Visualización de `cannot change locale (en_US.utf-8) because it has an invalid name` en `slurm_resume.log`](compute-node-initialization-locale-v3.md)
+ [Ninguno de los escenarios anteriores se aplica a mi situación](compute-node-initialization-not-found-v3.md)
# Visualización de `Node bootstrap error` en `clustermgtd.log`
El problema está relacionado con la falla del arranque de los nodos de cómputo. Para obtener información sobre cómo depurar un problema relacionado con el modo protegido de un clúster, consulte. [Cómo depurar el modo protegido](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3)
# He configurado reservas de capacidad bajo demanda (ODCRs) o instancias reservadas zonales
## ODCRs que incluyen instancias que tienen varias interfaces de red, como P4d, P4de y AWS Trainium (Trn)
En el archivo de configuración del clúster, compruebe que `HeadNode` se encuentre en una subred pública y que los nodos de procesamiento estén en una subred privada.
## ODCRs están dirigidos a los ODCRS
### Visualización de `Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'.` a pesar de que ya he implementado `/opt/slurm/etc/pcluster/run_instances_overrides.json` siguiendo las instrucciones que dadas en [Inicio de instancias con reservas de capacidad bajo demanda (ODCR)](launch-instances-odcr-v3.md)
Si utilizas AWS ParallelCluster las versiones 3.1.1 a 3.2.1 con target ODCRs y también utilizas el archivo JSON de [anulación de instancias de ejecución, es posible que el archivo JSON](launch-instances-odcr-v3.md) no tenga el formato correcto. Es posible que aparezca un error en`clustermgtd.log`, por ejemplo, el siguiente:
```
Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'.
Using default: {} in /var/log/parallelcluster/clustermgtd.
```
Compruebe que el formato del archivo JSON es correcto ejecutando lo siguiente:
```
$ echo /opt/slurm/etc/pcluster/run_instances_overrides.json | jq
```
### Visualización de `Found RunInstances parameters override.` en `clustermgtd.log` cuando falló la creación del clúster o en `slurm_resume.log` cuando falló la tarea de ejecución
Si utiliza [instancias de ejecución que anulan el archivo JSON](launch-instances-odcr-v3.md), compruebe que ha establecido correctamente el nombre de la cola y el nombre de los recursos de cómputo en el archivo `/opt/slurm/etc/pcluster/run_instances_overrides.json`.
### Visualización de `An error occurred (InsufficientInstanceCapacity)` en `slurm_resume.log` cuando no puedo ejecutar un trabajo o en `clustermgtd.log` cuándo no puedo crear un clúster
#### Uso de PG-ODCR (grupo de ubicación ODCR)
Al crear un ODCR con un grupo de ubicación asociado, se debe utilizar el mismo nombre de grupo de ubicación en el archivo de configuración. Establezca el [nombre del grupo de ubicación](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup) correspondiente en la configuración del clúster.
#### Uso de instancias reservadas
Si utiliza instancias reservadas zonales con`PlacementGroup`/`Enabled`to `true` en la configuración del clúster, es posible que aparezca un error como el siguiente:
```
We currently do not have sufficient trn1.32xlarge capacity in the Availability Zone you requested (us-east-1d). Our system will be working on provisioning additional capacity.
You can currently get trn1.32xlarge capacity by not specifying an Availability Zone in your request or choosing us-east-1a, us-east-1b, us-east-1c, us-east-1e, us-east-1f.
```
Es posible que esto se deba a que las instancias reservadas zonales no están ubicadas en la misma UC (o columna vertebral), lo que puede provocar errores de capacidad insuficiente (ICEs) al utilizar grupos de ubicación. Para comprobar este caso, inhabilite la configuración de `PlacementGroup` grupo en la configuración del clúster para determinar si el clúster puede asignar las instancias.
# Visualización de `An error occurred (VcpuLimitExceeded)` en `slurm_resume.log` cuando no puedo ejecutar un trabajo o en `clustermgtd.log` cuando no puedo crear un clúster
Compruebe los límites de vCPU de su cuenta para el tipo de instancia de Amazon EC2 específico que esté utilizando. Si ve cero o CPUs menos v de lo que solicita, solicite un aumento de sus límites. Para obtener información acerca de cómo consultar los límites actuales y solicitar nuevos límites, consulte las [cuotas de servicio de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) en la *Guía del usuario de Amazon EC2*.
# Visualización de `An error occurred (InsufficientInstanceCapacity)` en `slurm_resume.log` cuando no puedo ejecutar un trabajo o en `clustermgtd.log` cuando no puedo crear un clúster
Tiene un problema de capacidad insuficiente. Siga [https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/)para solucionar el problema.
# Visualización de los nodos que están en estado `DOWN` con `Reason (Code:InsufficientInstanceCapacity)...`
Tiene un problema de capacidad insuficiente. Siga [https://aws.amazon.com/premiumsupport/knowledge-center/ec2](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/) -/para solucionar el problema. insufficient-capacity-errors Para obtener más información sobre AWS ParallelCluster el modo de conmutación por error rápida y con capacidad insuficiente, consulte. [Conmutación por error rápida de capacidad insuficiente en el clúster de Slurm](slurm-short-capacity-fail-mode-v3.md)
# Visualización de `cannot change locale (en_US.utf-8) because it has an invalid name` en `slurm_resume.log`
Esto puede ocurrir si el proceso de `yum` instalación no se ha realizado correctamente y ha dejado la configuración regional en un estado incoherente. Por ejemplo, esto puede producirse cuando un usuario finaliza el proceso de instalación.
**Para verificar la causa, realice las siguientes acciones:**
+ Ejecute `su - pcluster-admin`.
El intérprete de comandos muestra un error, como `cannot change locale...no such file or directory`.
+ Ejecute `localedef --list`.
Devuelve una lista vacía o no contiene la configuración regional predeterminada.
+ Marque el último `yum` comando con `yum history` y. `yum history info #ID` ¿La última identificación tiene`Return-Code: Success`?
Si el último identificador no lo tiene `Return-Code: Success`, es posible que los scripts posteriores a la instalación no se hayan ejecutado correctamente.
Para solucionar el problema, intenta volver a crear la configuración regional con. `yum reinstall glibc-all-langpacks` Tras la reconstrucción, `su - pcluster-admin` no muestra ningún error o advertencia si el problema se ha solucionado.
# Ninguno de los escenarios anteriores se aplica a mi situación
Para solucionar problemas de inicialización de los nodos de procesamiento, consulte. [Solución de problemas de inicialización de nodos](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init)
Comprueba si tu situación está incluida en la sección [Problemas GitHub conocidos](https://github.com/aws/aws-parallelcluster/wiki), en la sección AWS ParallelCluster correspondiente GitHub.
# Solución de problemas de estado del clúster
Las métricas de estado del clúster se añaden al CloudWatch panel de AWS ParallelCluster Amazon a partir de la AWS ParallelCluster versión 3.6.0. En las siguientes secciones, puede obtener información sobre las métricas de estado del panel y las acciones que puede seguir para solucionar y solucionar problemas.
**Topics**
+ [Visualización del gráfico de **errores de aprovisionamiento de instancias**](#troubleshooting-v3-cluster-health-metrics-instance-provisioning)
+ [Visualización del gráfico de **errores de instancias en mal estado**](#troubleshooting-v3-cluster-health-metrics-unhealthy-instance)
+ [Visualización del gráfico de **tiempo de inactividad de la flota de computación**](#troubleshooting-v3-cluster-health-metrics-idle-time-errors)
## Visualización del gráfico de **errores de aprovisionamiento de instancias**
Si ve un valor distinto de cero en el gráfico `Instance Provisioning Errors`, significa que la instancia de Amazon EC2 que respalda los nodos de slurm no se pudo lanzar en la API de `CreateFleet` o `RunInstance`.
### Visualización de `IAMPolicyErrors`
+ **¿Qué ha pasado?**
No se pudieron iniciar varias instancias, lo que se debió a que los permisos eran insuficientes y el código de error era insuficiente `UnauthorizedOperation`.
+ **¿Cómo resolverlo?**
Si ha configurado una personalizada [`InstanceRole`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceRole)o [`InstanceProfile`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceProfile), compruebe sus políticas de IAM y compruebe que está utilizando las credenciales correctas.
Compruebe el `clustermgtd` archivo para ver los detalles de los errores de los nodos estáticos. Compruebe el `slurm_resume.log` archivo para ver los detalles de los errores de los nodos dinámicos. Utilice los detalles para obtener más información sobre los permisos que faltan y que se deben añadir.
### Visualización de `VcpuLimitErrors`
+ **¿Qué ha pasado?**
AWS ParallelCluster no pudo lanzar instancias porque alcanzó el límite de vCPU Cuenta de AWS para un tipo específico de instancia de Amazon EC2 que configuró para los nodos de cómputo del clúster.
+ **¿Cómo resolverlo?**
Compruebe si hay `VcpuLimitExceeded` algún error en el `clustermgtd` archivo para los nodos estáticos y compruebe si hay nodos dinámicos en el `slurm_resume.log` archivo para obtener información adicional. Para resolver este problema, puede solicitar un aumento de los límites de vCPU. Para obtener más información acerca de cómo ver los límites actuales y solicitar nuevos límites, consulte [Cuotas de servicio de Amazon Elastic Compute Cloud](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-resource-limits.html) en la *Guía del usuario de Elastic Compute Cloud para instancias de Linux*.
### Visualización de `VolumeLimitErrors`
+ **¿Qué ha pasado?**
Ha alcanzado el límite de volumen de Amazon EBS y AWS ParallelCluster no puede lanzar instancias con el código de error `InsufficientVolumeCapacity` o`VolumeLimitExceeded`. Cuenta de AWS
+ **¿Cómo resolverlo?**
Compruebe si hay nodos estáticos en el `slurm_resume.log` archivo y si hay nodos dinámicos para obtener detalles adicionales sobre el límite de volumen. `clustermgtd` Para resolver este problema, puede utilizar otro Región de AWS, limpiar los volúmenes existentes o ponerse en contacto con el AWS Support Center para enviar una solicitud para aumentar el límite de volumen de Amazon EBS.
### Visualización de `InsufficientCapacityErrors`
+ **¿Qué ha pasado?**
AWS ParallelCluster no tiene la capacidad suficiente para lanzar instancias de Amazon EC2 en los nodos secundarios.
+ **¿Cómo resolverlo?**
Compruebe si hay nodos estáticos en el archivo `clustermgtd` y el archivo `slurm_resume.log` por si hay nodos dinámicos para obtener los detalles del error de capacidad insuficiente. Para solucionar el problema, siga las instrucciones que se encuentran en [https://aws.amazon.com/premiumsupport/knowledge-center/ec2](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/) -/. insufficient-capacity-errors
### `OtherInstanceLaunchFailures`
+ **¿Qué ha pasado?**
La instancia de Amazon EC2 para respaldar los nodos de cómputo no se pudo iniciar con la API de `CreateFleet` o`RunInstance`.
+ **¿Cómo resolverlo?**
Compruebe si hay nodos estáticos en el archivo `clustermgtd` y el archivo `slurm_resume.log` por si hay nodos dinámicos para obtener los detalles del error.
## Visualización del gráfico de **errores de instancias en mal estado**
+ **¿Qué ha pasado?**
Se lanzaron varias instancias de cómputo, pero más tarde se cancelaron por estar en mal estado.
+ **¿Cómo resolverlo?**
Para obtener más información acerca de la solución de problemas de nodos dañados, consulte [**Solución de problemas de sustituciones y terminaciones inesperadas de nodos**](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-unexpected-node-replacements-and-terminations).
### Visualización de `InstanceBootstrapTimeoutError`
+ **¿Qué ha pasado?**
Una instancia no puede unirse al clúster dentro de `resume_timeout` (para nodos dinámicos) o `node_replacement_timeout` (para nodos estáticos). Esto puede ocurrir si la red no está configurada correctamente para los nodos de cómputo o si los scripts personalizados que se ejecutan en el nodo de cómputo tardan demasiado en finalizar.
+ **¿Cómo resolverlo?**
En el caso de los nodos dinámicos, compruebe en el `clustermgtd` registro (`/var/log/parallelcluster/clustermgtd`) la dirección IP del nodo de procesamiento y errores como los siguientes:
```
Node bootstrap error: Resume timeout expires for node
```
En el caso de los nodos estáticos, compruebe en el `clustermgtd` registro (`/var/log/parallelcluster/clustermgtd`) la dirección IP del nodo de procesamiento y errores como los siguientes:
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
Para obtener más información, compruebe si hay errores en el `/var/log/cloud-init-output.log` archivo. Puede recuperar las direcciones IP de los nodos de cómputo problemáticos de `clustermgtd` los archivos de `slurm_resume` registro.
### Visualización de `EC2HealthCheckErrors`
+ **¿Qué ha pasado?**
Una instancia no pasó una comprobación de estado de Amazon EC2.
+ **¿Cómo resolverlo?**
Para obtener información acerca de cómo solucionar este problema, consulte [Solución de problemas de las instancias con comprobaciones de estado no superadas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html).
### Visualización de `ScheduledEventHealthCheckErrors`
+ **¿Qué ha pasado?**
Una instancia no pasó la comprobación de estado de un evento programado de Amazon EC2 y no está en buen estado.
+ **¿Cómo resolverlo?**
Para obtener información sobre cómo solucionar este problema, consulte [Eventos programados para sus instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html).
### Visualización de `NoCorrespondingInstanceErrors`
+ **¿Qué ha pasado?**
AWS ParallelCluster no puedo encontrar instancias que respalden los nodos. Es probable que los nodos se hayan autofinalizado durante las operaciones de arranque. El script [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)/[`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)\$1[`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured) o los errores de red pueden generar `NoCorrespondingInstanceErrors`.
+ **¿Cómo resolverlo?**
Para obtener más información, compruebe el nodo `/var/log/cloud-init-output.log` de cómputo.
## Visualización del gráfico de **tiempo de inactividad de la flota de computación**
### Visualización de un `MaxDynamicNodeIdleTime` significativamente más largo que el umbral de **reducción del tiempo de inactividad**
+ **¿Qué ha pasado?**
La instancia no está finalizando correctamente. `MaxDynamicNodeIdleTime` muestra el tiempo máximo en segundos que un nodo dinámico, respaldado por una instancia de Amazon EC2, permanece inactivo. El umbral de reducción del **tiempo de inactividad se** deriva del parámetro de configuración del clúster [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime). Cuando un nodo de cómputo ha estado inactivo durante más de unos segundos con la **reducción del tiempo de inactividad**, se Slurm apaga el nodo y se AWS ParallelCluster termina la instancia de respaldo. En este caso, algo impide la finalización de la instancia.
+ **¿Cómo resolverlo?**
Para obtener información acerca de este problema, consulte [**Reemplazar, terminar o apagar instancias y nodos problemáticos**](troubleshooting-v3-scaling-issues.md#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3) en [Solución de problemas de escalar](troubleshooting-v3-scaling-issues.md).
# Solución de problemas de implementación del clúster
Si el clúster no se crea y revierte la creación de la pila, puede revisar los archivos de registro para diagnosticar el problema. El mensaje de error debe ser similar al siguiente:
```
$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \
--cluster-configuration cluster-config.yaml
{
"cluster": {
"clusterName": "mycluster",
"cloudformationStackStatus": "CREATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"region": "eu-west-1",
"version": "3.15.0",
"clusterStatus": "CREATE_IN_PROGRESS"
}
}
$ pcluster describe-cluster --cluster-name mycluster --region eu-west-1
{
"creationTime": "2021-09-06T11:03:47.696Z",
...
"cloudFormationStackStatus": "ROLLBACK_IN_PROGRESS",
"clusterName": "mycluster",
"computeFleetStatus": "UNKNOWN",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"lastUpdatedTime": "2021-09-06T11:03:47.696Z",
"region": "eu-west-1",
"clusterStatus": "CREATE_FAILED"
}
```
**Topics**
+ [Vea CloudFormation los eventos en `CREATE_FAILED`](#troubleshooting-v3-cluster-deployment-events)
+ [Utilice la CLI para ver los flujos de registro](#troubleshooting-v3-cluster-deployment-cli-logstreams)
+ [Vuelva a crear el clúster fallido con `rollback-on-failure`](#troubleshooting-v3-cluster-deployment-cli-fail-rollback)
## Vea CloudFormation los eventos en `CREATE_FAILED`
Puede usar la consola o la AWS ParallelCluster CLI para ver CloudFormation los eventos de los `CREATE_FAILED` errores y ayudar a encontrar la causa raíz.
**Topics**
+ [Vea los eventos en la CloudFormation consola](#troubleshooting-v3-cluster-deployment-cloudformation)
+ [Utilice la CLI para ver y filtrar CloudFormation eventos en `CREATE_FAILED`](#troubleshooting-v3-cluster-deployment-cli-events)
### Vea los eventos en la CloudFormation consola
Para obtener más información sobre la causa del `"CREATE_FAILED"` estado, puedes usar la CloudFormation consola.
**Consulta los mensajes de CloudFormation error de la consola.**
1. Inicie sesión en [https://console.aws.amazon.com/cloudformation Consola de administración de AWS y navegue hasta él](https://console.aws.amazon.com/cloudformation/).
1. Seleccione la pila denominada *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. Por ejemplo, si ve el siguiente mensaje de estado, debe usar tipos de instancia que no superen el límite de vCPU actual ni solicitar más capacidad de vCPU.
```
2022-02-04 16:09:44 UTC-0800 HeadNode CREATE_FAILED 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).
```
### Utilice la CLI para ver y filtrar CloudFormation eventos en `CREATE_FAILED`
Para diagnosticar el problema de creación del clúster, puede usar el [`pcluster get-cluster-stack-events`](pcluster.get-cluster-stack-events-v3.md) comando filtrando por `CREATE_FAILED` estado. Para obtener más información, consulte [Filtrar los AWS CLI resultados](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-filter.html) en la *Guía del AWS Command Line Interface usuario*.
```
$ pcluster get-cluster-stack-events --cluster-name mycluster --region eu-west-1 \
--query 'events[?resourceStatus==`CREATE_FAILED`]'
[
{
"eventId": "3ccdedd0-0f03-11ec-8c06-02c352fe2ef9",
"physicalResourceId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"resourceStatus": "CREATE_FAILED",
"resourceStatusReason": "The following resource(s) failed to create: [HeadNode]. ",
"stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"stackName": "mycluster",
"logicalResourceId": "mycluster",
"resourceType": "AWS::CloudFormation::Stack",
"timestamp": "2021-09-06T11:11:51.780Z"
},
{
"eventId": "HeadNode-CREATE_FAILED-2021-09-06T11:11:50.127Z",
"physicalResourceId": "i-04e91cc1f4ea796fe",
"resourceStatus": "CREATE_FAILED",
"resourceStatusReason": "Received FAILURE signal with UniqueId i-04e91cc1f4ea796fe",
"resourceProperties": "{\"LaunchTemplate\":{\"Version\":\"1\",\"LaunchTemplateId\":\"lt-057d2b1e687f05a62\"}}",
"stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387",
"stackName": "mycluster",
"logicalResourceId": "HeadNode",
"resourceType": "AWS::EC2::Instance",
"timestamp": "2021-09-06T11:11:50.127Z"
}
]
```
En el ejemplo anterior, el error se produjo en la configuración del nodo principal.
## Utilice la CLI para ver los flujos de registro
Para solucionar este tipo de problemas, puede enumerar los flujos de registro disponibles en el nodo principal [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md) filtrando `node-type` y analizando el contenido de los flujos de registro.
```
$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \
--filters 'Name=node-type,Values=HeadNode'
{
"logStreams": [
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init",
...
},
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client",
...
},
{
"logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init",
"logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init",
...
},
...
]
}
```
Los dos flujos de registro principales que puede utilizar para buscar errores de inicialización son los siguientes:
+ `cfn-init` es el registro del script `cfn-init`. En primer lugar, compruebe este flujo de registro. Es probable que veas el `Command chef failed` error en 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).
+ `cloud-init` es el registro de [cloud-init](https://cloudinit.readthedocs.io/). Si no ve nada en `cfn-init`, intente revisar este registro a continuación.
Para recuperar el contenido del flujo de registro, utilice las siguientes opciones [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md) (tenga en cuenta la `--limit 5` opción para limitar el número de eventos recuperados):
```
$ pcluster get-cluster-log-events --cluster-name mycluster \
--region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init \
--limit 5
{
"nextToken": "f/36370880979637159565202782352491087067973952362220945409/s",
"prevToken": "b/36370880752972385367337528725601470541902663176996585497/s",
"events": [
{
"message": "2021-09-06 11:11:39,049 [ERROR] Unhandled exception during build: Command runpostinstall failed",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "Traceback (most recent call last):\n File \"/opt/aws/bin/cfn-init\", line 176, in \n worklog.build(metadata, configSets)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 135, in build\n Contractor(metadata).build(configSets, self)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 561, in build\n self.run_config(config, worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 573, in run_config\n CloudFormationCarpenter(config, self._auth_config).build(worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 273, in build\n self._config.commands)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/command_tool.py\", line 127, in apply\n raise ToolError(u\"Command %s failed\" % name)",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "cfnbootstrap.construction_errors.ToolError: Command runpostinstall failed",
"timestamp": "2021-09-06T11:11:39.049Z"
},
{
"message": "2021-09-06 11:11:49,212 [DEBUG] CloudFormation client initialized with endpoint https://cloudformation.eu-west-1.amazonaws.com",
"timestamp": "2021-09-06T11:11:49.212Z"
},
{
"message": "2021-09-06 11:11:49,213 [DEBUG] Signaling resource HeadNode in stack mycluster with unique ID i-04e91cc1f4ea796fe and status FAILURE",
"timestamp": "2021-09-06T11:11:49.213Z"
}
]
}
```
En el ejemplo anterior, el error se debe a un `runpostinstall` error, por lo que está estrictamente relacionado con el contenido del script de arranque personalizado utilizado en el parámetro de `OnNodeConfigured` configuración del[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions).
## Vuelva a crear el clúster fallido con `rollback-on-failure`
AWS ParallelCluster crea flujos de CloudWatch registro de clústeres 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](cloudwatch-logs-v3.md) y [CloudWatch Panel de control de Amazon](cloudwatch-dashboard-v3.md). Si no hay flujos de registro disponibles, el error puede deberse al script de arranque [`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions) personalizado o a un problema relacionado con la AMI. Para diagnosticar el problema de creación en este caso, vuelva a crear el clúster utilizando[`pcluster create-cluster`](pcluster.create-cluster-v3.md), incluido el `--rollback-on-failure` parámetro establecido en. `false` A continuación, utilice SSH para ver el clúster, tal y como se muestra a continuación:
```
$ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \
--cluster-configuration cluster-config.yaml --rollback-on-failure false
{
"cluster": {
"clusterName": "mycluster",
"cloudformationStackStatus": "CREATE_IN_PROGRESS",
"cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387",
"region": "eu-west-1",
"version": "3.15.0",
"clusterStatus": "CREATE_IN_PROGRESS"
}
}
$ pcluster ssh --cluster-name mycluster
```
Una vez que haya iniciado sesión en el nodo principal, encontrará tres archivos de registro principales que podrá usar para encontrar 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` el 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 de implementación del clúster con Terraform
Esta sección es relevante para aquellos clústeres que se implementaron con Terraform.
## ParallelCluster No se encontró la API
La planificación podría fallar porque no se encuentra la ParallelCluster API. En este caso, el error devuelto sería algo como:
```
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: Unable to retrieve ParallelCluster API cloudformation stack.
│
│ with provider["registry.terraform.io/aws-tf/aws-parallelcluster"],
│ on providers.tf line 6, in provider "aws-parallelcluster":
│ 6: provider "aws-parallelcluster" {
│
│ operation error CloudFormation: DescribeStacks, https response error StatusCode: 400, RequestID: REQUEST_ID, api error ValidationError: Stack with id PCAPI_STACK_NAME does not exist
```
Para solucionar este error, implementa la ParallelCluster API en la cuenta en la que se van a crear los clústeres. Consulte [Creación de un clúster con Terraform](tutorial-create-cluster-terraform.md).
## El usuario no está autorizado a llamar a la ParallelCluster API
La planificación podría fallar porque el IAM role/user que creías que iba a implementar tu proyecto de Terraform no tiene permisos para interactuar con la ParallelCluster API. En este caso, el error devuelto sería algo como:
```
Planning failed. Terraform encountered an error while generating this plan.
│ Error: 403 Forbidden
│
│ with module.parallelcluster_clusters.module.clusters[0].pcluster_cluster.managed_configs["DemoCluster01"],
│ on .terraform/modules/parallelcluster_clusters/modules/clusters/main.tf line 35, in resource "pcluster_cluster" "managed_configs":
│ 35: resource "pcluster_cluster" "managed_configs" {
│
│ {{"Message":"User: USER_ARN is not authorized to perform: execute-api:Invoke on resource: PC_API_REST_RESOURCE with an explicit deny"}
│ }
```
Para solucionar este error, configura el ParallelCluster proveedor de modo que utilice la función de ParallelCluster API para interactuar con la API.
```
provider "aws-parallelcluster" {
region = var.region
profile = var.profile
api_stack_name = var.api_stack_name
**use_user_role** **= true**
}
```
# 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 Slurm tareas. Para obtener más información acerca de la configuración de colas de consultas, consulte [Configuración de varias colas](configuration-of-multiple-queues-v3.md).
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`](pcluster.list-cluster-log-streams-v3.md) 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`](pcluster.get-cluster-log-events-v3.md) 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 ParallelCluster crea flujos de CloudWatch registro de clústeres 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](cloudwatch-logs-v3.md) y [CloudWatch Panel de control de Amazon](cloudwatch-dashboard-v3.md).
**Topics**
+ [Registros clave para la depuración](#troubleshooting-v3-key-logs)
+ [Visualización de un error de `InsufficientInstanceCapacity` en `slurm_resume.log` cuando no puedo ejecutar un trabajo o en `clustermgtd.log` cuando no puedo crear un clúster](#compute-node-initialization-ice-failure-v3-c2)
+ [Solución de problemas de inicialización de nodos](#troubleshooting-v3-node-init)
+ [**Solución de problemas de sustituciones y terminaciones inesperadas de nodos**](#troubleshooting-v3-unexpected-node-replacements-and-terminations)
+ [**Reemplazar, terminar o apagar instancias y nodos problemáticos**](#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3)
+ [Estado de la cola (partición) `Inactive`](#troubleshooting-v3-queues)
+ [Solución de otros problemas de nodos y trabajos conocidos](#troubleshooting-v3-other-node-job-issues)
## Registros clave para la depuración
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 CloudFormation inicio. Contiene todos los comandos que se ejecutaron al configurar 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. Se usa 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. Cuando revise este registro, también debe comprobar el registro de `clustermgtd`.
+ Este es el registro de . Se ejecuta como el daemon centralizado que gestiona la mayoría de las acciones operativas del clúster. Se usa para solucionar cualquier problema de inicio, finalización o funcionamiento del clúster.
+ `/var/log/slurmctld.log`- Este es el registro del demonio 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.
+ `/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 él CloudWatch. El `compute_console_output log` contenido que recibe es el mismo cuando utiliza la consola Amazon EC2 o AWS CLI cuando recupera la salida de la consola de instancias.
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. Se usa para solucionar problemas de terminación inesperados.
+ `/var/log/slurmd.log` - Este es el registro del daemon de computación de Slurm. Se usa para solucionar problemas de inicialización y errores de computación.
## Visualización de un error de `InsufficientInstanceCapacity` en `slurm_resume.log` cuando no puedo ejecutar un trabajo o en `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, puede encontrar el error en el registro de `clustermgtd` en `/var/log/parallelcluster/clustermgtd`.
En cuanto a la capacidad dinámica de las instancias, puede encontrar el error en el registro de `ResumeProgram` 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:
+ Deshabilite el grupo de ubicación si está activado. Para obtener más información, consulte [Problemas con los grupos de ubicación y el lanzamiento de instancias](troubleshooting-v3-placemment-groups.md).
+ Reserve capacidad para las instancias y ejecútelas con las ODCR (reservas de capacidad bajo demanda). Para obtener más información, consulte [Inicio de instancias con reservas de capacidad bajo demanda (ODCR)](launch-instances-odcr-v3.md).
+ Configure varios recursos informáticos con distintos tipos de instancias. Si su carga de trabajo no requiere un tipo de instancia específico, puede aprovechar la conmutación por error rápida y con capacidad insuficiente con varios recursos informáticos. Para obtener más información, consulte [Conmutación por error rápida de capacidad insuficiente en el clúster de Slurm](slurm-short-capacity-fail-mode-v3.md).
+ Configura varios tipos de instancias en el mismo recurso informático y aprovecha la asignación de varios tipos de instancias. Para obtener más información sobre la configuración de varias instancias, consulte [Asignación de varios tipos de instancias con Slurm](slurm-multiple-instance-allocation-v3.md) y [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
+ Mueva la cola a una zona de disponibilidad diferente cambiando el ID de subred en la configuración del clúster [`Scheduling`](Scheduling-v3.md)//[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking). [`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds)
+ Si su carga de trabajo no está estrechamente vinculada, distribuya la cola entre distintas zonas de disponibilidad. Para obtener más información acerca de la configuración de las subredes, consulte .
## 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.
**Topics**
+ [Nodo principal](#troubleshooting-v3-node-init.head-node)
+ [Nodos de computación](#troubleshooting-v3-node-init.compute-node)
### 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 de computación que utilice para solucionar problemas de este tipo:
### 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 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 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, consulte el registro. `/var/log/slurmd.log`
**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, 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í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 respaldados por instancias de spot:**
+ Si es la primera vez que utiliza instancias de spot 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 Amazon EC2 Spot Instances.
```
Al utilizar instancias de spot, en la cuenta se debe incluir un rol vinculado a un servicio `AWSServiceRoleForEC2Spot`. Para crear este rol en tu cuenta mediante el AWS CLI, ejecuta 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](spot-v3.md) la Guía del AWS ParallelCluster usuario y la [función vinculada al servicio para las solicitudes de instancias puntuales](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) de la Guía del usuario de *Amazon EC2*.
## **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 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 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.
+ Espere a que se inicie el nodo de computación.
+ Modifique el comportamiento de cierre iniciado por la instancia para que un nodo de computación que falle se detenga en lugar de terminar.
```
$ aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--instance-initiated-shutdown-behavior "{\"Value\": \"stop\"}"
```
+ Habilite la protección de terminación.
```
$ aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--disable-api-termination
```
+ Etiquete el nodo para identificarlo con facilidad.
```
$ aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=Name,Value=QUARANTINED-Compute
```
+ Separe el nodo del clúster cambiando la etiqueta de `parallelcluster:cluster-name`.
```
$ aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=parallelcluster:clustername,Value=QUARANTINED-ClusterName
```
+ 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`](Scheduling-v3.md#Scheduling-v3-SlurmSettings.properties), 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`.
+ Si los nodos de cómputo fallan continuamente debido a errores de arranque, compruebe si se están iniciando con la tecla Enabled. [Slurm modo protegido de clúster](slurm-protected-mode-v3.md) 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 de`inact`, es posible que su clúster [Slurm modo protegido de clúster](slurm-protected-mode-v3.md) 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 de nodos y trabajos conocidos
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 inicia, finaliza o mantiene los recursos de acuerdo con las instrucciones de Slurm. En el caso de estos problemas, consulte el `slurmctld` registro para solucionarlos.
# 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 un error [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) al utilizar grupos con ubicación en clúster, establezca el parámetro [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) en [`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup) y establezca el parámetro [`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup-Enabled) en `false`.
Para tener un control adicional sobre la capacidad de acceso, considere [lanzar instancias con ODCR (reservas de capacidad bajo demanda)](launch-instances-odcr-v3.md).
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 para instancias Linux de Amazon EC2*.
# Sustitución de directorios
Algunos directorios no se pueden reemplazar. Si tiene problemas para reemplazar un directorio, podría deberse a eso. Los siguientes directorios se comparten entre los nodos y no se pueden reemplazar.
+ Esto incluye Intel MPI, Intel Parallel Studio y archivos relacionados.
+ `/opt/slurm` - Incluye el administrador de Slurm Workload Manager y los archivos relacionados. (Condicional, solo si `Scheduler: slurm`).
# Solución de problemas de Amazon DCV
**Topics**
+ [Registros para Amazon DCV](#troubleshooting-v3-nice-dcv-logs)
+ [Problemas con Ubuntu Amazon DCV](#troubleshooting-v3-nice-dcv-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.
El tipo de instancia debe tener al menos 1,7 gibibytes (GiB) de RAM para ejecutar Amazon DCV. Los tipos de instancias nano y micro no tienen suficiente memoria para ejecutar Amazon DCV.
AWS ParallelCluster crea flujos de registro de Amazon DCV 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](cloudwatch-logs-v3.md) y [CloudWatch Panel de control de Amazon](cloudwatch-dashboard-v3.md).
## Problemas con Ubuntu Amazon DCV
Al ejecutar la Terminal de Gnome en una sesión de Amazon DCV en Ubuntu, es posible que no tenga acceso automáticamente al entorno de usuario que ofrece AWS ParallelCluster a través del intérprete de comandos de inicio de sesión. 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 AWS ParallelCluster de usuario no se carga.
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 los clústeres con AWS Batch integración
En esta sección, se proporcionan posibles consejos para la solución de problemas de clústeres con AWS Batch integración de planificadores, específicamente los relacionados con los nodos principales, los problemas de procesamiento, los errores de trabajo y los errores de tiempo de espera.
**Topics**
+ [Problemas con el nodo principal](#troubleshooting-v3-batch-head-node)
+ [Problemas informáticos](#troubleshooting-v3-batch-compute-nodes)
+ [Errores en los trabajos](#troubleshooting-v3-batch-job-fail)
+ [Error de tiempo de espera de conexión en la URL del punto de conexión](#troubleshooting-v3-batch-connect-timeout)
## Problemas con el nodo principal
Puede solucionar los problemas de configuración del nodo principal de la misma manera que con un Slurm clúster (excepto en el caso de registros Slurm específicos). Para obtener más información sobre estos problemas, consulte [Nodo principal](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init.head-node).
## Problemas informáticos
AWS Batch gestiona los aspectos de escalado y procesamiento 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`](awsbatchcli.awsbout-v3.md) para recuperar el resultado del trabajo. También puedes ejecutar el [`awsbstat`](awsbatchcli.awsbstat-v3.md) comando para obtener un enlace a los registros de trabajos almacenados por Amazon CloudWatch.
## Error de tiempo de espera de conexión en la URL del punto de conexión
Si los trabajos paralelos de varios nodos fallan y se produce un error: `Connect timeout on endpoint URL`
+ En el registro `awsbout` de salida, compruebe que el trabajo sea de varios nodos en paralelo a la salida: `Detected 3/3 compute nodes. Waiting for all compute nodes to start.`
+ Compruebe si la subred de los nodos de procesamiento es pública.
Los trabajos paralelos de varios nodos no admiten el uso de subredes públicas cuando se utilizan AWS Batch in. AWS ParallelCluster Use una subred privada para sus tareas y nodos de cómputo. Para obtener más información, consulte [Entornos informáticos](https://docs.aws.amazon.com/batch/latest/userguide/multi-node-parallel-jobs.html#mnp-ce) en la *Guía del usuario de AWS Batch *. Para configurar una subred privada para los nodos de procesamiento, consulte. [AWS ParallelCluster con programador AWS Batch](network-configuration-v3-batch.md)
# Solución de problemas de integración multiusuario con Active Directory
Esta sección es relevante para los clústeres integrados en un Active Directory.
Si la característica de integración de Active Directory no funciona como se esperaba, los registros SSSD pueden proporcionar información de diagnóstico útil. Estos registros se encuentran en el directorio `/var/log/sssd` de los nodos del clúster. De forma predeterminada, también se almacenan en el grupo de CloudWatch registros de Amazon de un clúster.
**Topics**
+ [Solución de problemas específicos de Active Directory](#troubleshooting-v3-multi-ad-specific)
+ [Cómo habilitar el modo de depuración](#troubleshooting-v3-multi-user-debug)
+ [Cómo pasar de LDAPS a LDAP](#troubleshooting-v3-multi-user-ldaps-ldap)
+ [Cómo deshabilitar la verificación del certificado del servidor LDAPS](#troubleshooting-v3-multi-user-ldaps-verify)
+ [¿Cómo iniciar sesión con una clave SSH en lugar de una contraseña?](#troubleshooting-v3-multi-user-ssh-login)
+ [Cómo restablecer una contraseña de usuario y contraseñas caducadas](#troubleshooting-v3-multi-user-reset-passwd)
+ [¿Cómo comprobar el dominio al que se ha unido](#troubleshooting-v3-multi-user-domain-verify)
+ [Cómo solucionar los problemas con .](#troubleshooting-v3-multi-user-certificates)
+ [Cómo comprobar que la integración con Active Directory funciona](#troubleshooting-v3-multi-user-ad-verify)
+ [Cómo solucionar problemas al iniciar sesión en los nodos de cómputo](#troubleshooting-v3-multi-user-ad-compute-node-login)
+ [Problemas conocidos con los trabajos de SimCenter StarCCM\$1 en un entorno multiusuario](#troubleshooting-v3-multi-user-ad-starccm)
+ [Problemas conocidos relacionados con la resolución del nombre de usuario](#troubleshooting-v3-multi-user-name-resolution)
+ [Cómo resolver los problemas de creación del directorio principal](#troubleshooting-v3-multi-home-directory)
## Solución de problemas específicos de Active Directory
Esta sección es relevante para la solución de problemas específicos de un tipo de Active Directory.
### AD sencillo
+ El valor de `DomainReadOnlyUser` debe coincidir con la búsqueda base del directorio Simple AD para los usuarios:
`cn=ReadOnlyUser,cn=Users,dc=corp,dc=example,dc=com`
Nota `cn` para`Users`.
+ El usuario administrador predeterminado es`Administrator`.
+ `Ldapsearch`requiere el nombre de NetBIOS antes del nombre de usuario.
La sintaxis / debe ser la siguiente:
```
$ ldapsearch -x -D "corp\\Administrator" -w "Password" -H ldap://192.0.2.103 \
-b "cn=Users,dc=corp,dc=example,dc=com"
```
### AWS Managed Microsoft AD
+ El `DomainReadOnlyUser` valor debe coincidir con la búsqueda base del AWS Managed Microsoft AD directorio para los usuarios:
`cn=ReadOnlyUser,ou=Users,ou=CORP,dc=corp,dc=example,dc=com`
+ El usuario administrador predeterminado es`Admin`.
+ La sintaxis / debe ser la siguiente:
```
$ ldapsearch -x -D "Admin" -w "Password" -H ldap://192.0.2.103 \
-b "ou=Users,ou=CORP,dc=corp,dc=example,dc=com"
```
## Cómo habilitar el modo de depuración
Los registros de depuración de SSSD pueden ser útiles para solucionar problemas. Para habilitar el modo de depuración, debe actualizar el clúster con los siguientes cambios realizados en la configuración del clúster:
```
DirectoryService:
AdditionalSssdConfigs:
debug_level: "0x1ff"
```
## Cómo pasar de LDAPS a LDAP
No se recomienda pasar del LDAPS (LDAP con TLS/SSL) al LDAP porque el LDAP por sí solo no proporciona ningún tipo de cifrado. Sin embargo, puede resultar útil para realizar pruebas y solucionar problemas.
Puede restaurar el clúster a su configuración anterior actualizándolo con la definición de configuración anterior.
Para pasar de LDAPS a LDAP, debe actualizar el clúster con los siguientes cambios en la configuración del clúster:
```
DirectoryService:
LdapTlsReqCert: never
AdditionalSssdConfigs:
ldap_auth_disable_tls_never_use_in_production: True
```
## Cómo deshabilitar la verificación del certificado del servidor LDAPS
Puede resultar útil deshabilitar temporalmente la verificación del certificado del servidor LDAPS en el nodo principal para realizar pruebas o solucionar problemas.
Puede restaurar el clúster a su configuración anterior actualizándolo con la definición de configuración anterior.
Para deshabilitar la verificación del certificado del servidor LDAPS, debe actualizar el clúster con los siguientes cambios en la configuración del clúster:
```
DirectoryService:
LdapTlsReqCert: never
```
## ¿Cómo iniciar sesión con una clave SSH en lugar de una contraseña?
La clave SSH se crea `/home/$user/.ssh/id_rsa` después de iniciar sesión por primera vez con una contraseña. Para iniciar sesión con la clave SSH, debe iniciar sesión con su contraseña, copiar la clave SSH localmente y, a continuación, utilizarla para realizar SSH sin contraseña, como de costumbre:
```
$ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip
```
## Cómo restablecer una contraseña de usuario y contraseñas caducadas
Si un usuario pierde el acceso a un clúster, es [posible que su AWS Managed Microsoft AD contraseña haya caducado](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_password_policies.html).
Para restablecer la contraseña, ejecute el siguiente comando con un usuario y un rol que tengan permiso de escritura en el directorio:
```
$ aws ds reset-user-password \
--directory-id "d-abcdef01234567890" \
--user-name "USER_NAME" \
--new-password "NEW_PASSWORD" \
--region "region-id"
```
Si restablece la contraseña de [`DirectoryService`](DirectoryService-v3.md)/[`DomainReadOnlyUser`](DirectoryService-v3.md#yaml-DirectoryService-DomainReadOnlyUser):
1. Asegúrese de actualizar el [`PasswordSecretArn`](DirectoryService-v3.md#yaml-DirectoryService-PasswordSecretArn)secreto [`DirectoryService`](DirectoryService-v3.md)/con la nueva contraseña.
1. Actualice el clúster para el nuevo valor secreto:
1. Detenga la flota de computación con el comando `pcluster update-compute-fleet`.
1. A continuación, ejecute el siguiente comando desde el nodo principal del clúster.
```
$ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh
```
Tras restablecer la contraseña y actualizar el clúster, se debe restablecer el acceso del usuario al clúster.
Para obtener más información, consulte [Crear un usuario](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_reset_password.html) en la *Guía de administración de Directory Service *.
## ¿Cómo comprobar el dominio al que se ha unido
El siguiente comando debe ejecutarse desde una instancia que esté unida al dominio, no desde el nodo principal.
```
$ realm list corp.example.com \
type: kerberos \
realm-name: CORP.EXAMPLE.COM \
domain-name: corp.example.com \
configured: kerberos-member \
server-software: active-directory \
client-software: sssd \
required-package: oddjob \
required-package: oddjob-mkhomedir \
required-package: sssd \
required-package: adcli \
required-package: samba-common-tools \
login-formats: %U \
login-policy: allow-realm-logins
```
## Cómo solucionar los problemas con .
Cuando la comunicación LDAPS no funciona, puede deberse a errores en la comunicación TLS, que a su vez pueden deberse a problemas con los certificados.
**Notas acerca de los certificados:**
+ El certificado especificado en la configuración del clúster `LdapTlsCaCert` debe ser un paquete de certificados PEM que contenga los certificados de toda la cadena de certificados de autoridad (CA) que emitió los certificados para los controladores de dominio.
+ Un paquete de certificados PEM es un archivo compuesto por la concatenación de certificados PEM.
+ Un certificado en formato PEM (normalmente utilizado en Linux) equivale a un certificado en formato DER base64 (normalmente exportado por Windows).
+ Si el certificado para los controladores de dominio lo emite una CA subordinada, el paquete de certificados debe contener el certificado de la CA subordinada y raíz.
**Pasos de verificación para solucionar problemas:**
En los siguientes pasos de verificación se supone que los comandos se ejecutan desde el nodo principal del clúster y que se puede acceder al controlador de dominio en `SERVER:PORT` él.
Para solucionar un problema relacionado con los certificados, siga estos pasos de verificación:
**Pasos de verificación:**
1. **Compruebe la conexión a los controladores de dominio de Active Directory:**
Comprobar que puede conectarse a un controlador de dominio. Si este paso se realiza correctamente, la conexión SSL al controlador de dominio se realiza correctamente y se verifica el certificado. El problema no está relacionado con los certificados.
Si este paso no funciona, continúa con la siguiente verificación.
```
$ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE
```
1. **Compruebe la verificación del certificado:**
Compruebe que el paquete de certificados de CA local pueda validar el certificado proporcionado por el controlador de dominio. Si este paso se realiza correctamente, el problema no está relacionado con los certificados, sino con otros problemas de red.
Si este paso no funciona, continúa con la siguiente verificación.
```
$ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE
```
1. **Compruebe el certificado proporcionado por los controladores de dominio de Active Directory:**
Compruebe que el contenido del certificado proporcionado por los controladores de dominio es el esperado. Si este paso se realiza correctamente, es probable que tenga problemas con el certificado de CA utilizado para verificar los controladores. Continúe con el siguiente paso de solución de problemas.
Si este paso no funciona, debe corregir el certificado emitido para los controladores de dominio y volver a ejecutar los pasos de solución de problemas.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **Compruebe el contenido de un certificado:**
Compruebe que el contenido del certificado que proporcionan los controladores de dominio es el esperado. Si este paso se realiza correctamente, es probable que tenga problemas con el certificado de CA utilizado para verificar los controladores. Continúe con el siguiente paso de solución de problemas.
Si este paso no funciona, debe corregir el certificado emitido para los controladores de dominio y volver a ejecutar los pasos de solución de problemas.
```
$ openssl s_client -connect SERVER:PORT -showcerts
```
1. **Compruebe el contenido del paquete de certificados de CA local:**
Compruebe que el contenido del paquete de certificados de CA local utilizado para validar el certificado del controlador de dominio es el esperado. Si este paso se realiza correctamente, es probable que tenga problemas con el certificado proporcionado por los controladores de dominio.
Si este paso no funciona, debe corregir el paquete de certificados de CA emitido para los controladores de dominio y volver a ejecutar los pasos de solución de problemas.
```
$ openssl x509 -in PATH_TO_A_CERTIFICATE -text
```
## Cómo comprobar que la integración con Active Directory funciona
Si las dos comprobaciones siguientes se realizan correctamente, la integración con Active Directory funciona.
verificaciones
1. **Puede detectar los usuarios definidos en el directorio:**
Desde el nodo principal del clúster, como`ec2-user`:
```
$ getent passwd $ANY_AD_USER
```
1. **Puede acceder mediante SSH al nodo principal proporcionando la contraseña de usuario:**
```
$ ssh $ANY_AD_USER@$HEAD_NODE_IP
```
Si la primera comprobación falla, esperamos que la segunda también falle.
Solución de problemas adicionales
+ Compruebe que el usuario existe en el directorio.
+ Habilitación del registro de depuración de
+ Considere la posibilidad de deshabilitar temporalmente el cifrado [pasando de LDAPS a LDAP para descartar problemas con el LDAPS](#troubleshooting-v3-multi-user-ldaps-ldap).
## Cómo solucionar problemas al iniciar sesión en los nodos de cómputo
Esta sección es relevante para iniciar sesión en los nodos de cómputo de los clústeres integrados con Active Directory.
Con AWS ParallelCluster, los inicios de sesión con contraseña en los nodos de cómputo del clúster están deshabilitados por diseño.
Todos los usuarios deben usar su propia clave SSH para iniciar sesión en los nodos de procesamiento.
Los usuarios pueden recuperar su clave SSH en el nodo principal tras la primera autenticación (por ejemplo, al iniciar sesión), si [`GenerateSshKeysForUsers`](DirectoryService-v3.md#yaml-DirectoryService-GenerateSshKeysForUsers)está habilitada en la configuración del clúster.
Cuando los usuarios se autentican en el nodo principal por primera vez, pueden recuperar las claves SSH que se generan automáticamente para ellos como usuarios del directorio. También se crean los directorios principales para el usuario. Esto también puede ocurrir la primera vez que un sudo-usuario cambia a un usuario del nodo principal.
Si un usuario no ha iniciado sesión en el nodo principal, las claves SSH no se generan y el usuario no podrá iniciar sesión en los nodos de cálculo.
## Problemas conocidos con los trabajos de SimCenter StarCCM\$1 en un entorno multiusuario
Esta sección es relevante para los trabajos lanzados en un entorno multiusuario por el software de dinámica de fluidos computacional Simcenter StarCCM\$1 de Siemens.
Si ejecuta tareas de StarCCM\$1 v16 configuradas para utilizar el IntelMPI integrado, los procesos del MPI se iniciarán de forma predeterminada mediante SSH.
Debido a un [error conocido de Slurm](https://bugs.schedmd.com/show_bug.cgi?id=13385) que hace que la resolución del nombre de usuario sea incorrecta, es posible que los trabajos fallen y se produzca un error como `error setting up the bootstrap proxies`. Este error solo afecta a las AWS ParallelCluster versiones 3.1.1 y 3.1.2.
Para evitar que esto ocurra, obligue a IntelMPI a usar Slurm como método de arranque de MPI. Exporte la variable de entorno `I_MPI_HYDRA_BOOTSTRAP=slurm` al script de trabajo que lanza StarCCM\$1, tal y como se describe en la [documentación oficial de IntelMPI](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/hydra-environment-variables.html).
## Problemas conocidos relacionados con la resolución del nombre de usuario
Esta sección es relevante para recuperar los nombres de usuario en los trabajos.
Debido a un [error conocido en Slurm](https://bugs.schedmd.com/show_bug.cgi?id=13385), el nombre de usuario que se recupera en un proceso de trabajo puede ser el de ejecutar un trabajo `nobody` sin él. `srun` Este error solo afecta a AWS ParallelCluster las versiones 3.1.1 y 3.1.2.
Por ejemplo, si ejecuta el comando `sbatch --wrap 'srun id'` como usuario del directorio, se devuelve el nombre de usuario correcto. Sin embargo, si lo ejecuta `sbatch --wrap 'id'` como usuario del directorio, `nobody` es posible que se devuelva como nombre de usuario.
Puede utilizar las siguientes soluciones alternativas.
1. Inicie su trabajo con, `'srun'` en lugar de`'sbatch'`, si es posible.
1. Habilite la enumeración de SSSD configurando la configuración en el clúster de la [AdditionalSssdConfigs](DirectoryService-v3.md#yaml-DirectoryService-AdditionalSssdConfigs)siguiente manera.
```
AdditionalSssdConfigs:
enumerate: true
```
## Cómo resolver los problemas de creación del directorio principal
Esta sección es relevante para los problemas de creación del directorio principal.
Si ve errores como el que se muestra en el siguiente ejemplo, significa que no se creó un directorio principal para usted cuando inició sesión por primera vez en el nodo principal. O bien, no se creó un directorio principal para usted cuando cambió por primera vez de usuario de sudoer a usuario de Active Directory en el nodo principal.
```
$ ssh AD_USER@$HEAD_NODE_IP
/opt/parallelcluster/scripts/generate_ssh_key.sh failed: exit code 1
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
Could not chdir to home directory /home/PclusterUser85: No such file or directory
```
El error al crear el directorio principal puede deberse a los `oddjob-mkhomedir` paquetes `oddjob` y instalados en el nodo principal del clúster.
Sin un directorio principal y una clave SSH, el usuario no puede enviar trabajos o SSH a los nodos del clúster.
Si necesita los `oddjob` paquetes en su sistema, compruebe que el `oddjobd` servicio se esté ejecutando y actualice los archivos de configuración de PAM para asegurarse de que se ha creado el directorio principal. Para ello, ejecute los comandos en el nodo principal como se muestra en el siguiente ejemplo.
```
sudo systemctl start oddjobd
sudo authconfig --enablemkhomedir --updateall
```
Si no necesita los `oddjob` paquetes en su sistema, desinstálelos y actualice los archivos de configuración de PAM para asegurarse de que se ha creado el directorio principal. Para ello, ejecute los comandos en el nodo principal como se muestra en el siguiente ejemplo.
```
sudo yum remove -y oddjob oddjob-mkhomedir
sudo authconfig --enablemkhomedir --updateall
```
# Solución de problemas con las AMI de
En esta sección se proporcionan posibles consejos para la solución de problemas de AMI personalizadas.
Al utilizar una AMI personalizada, puede ver las siguientes advertencias:
```
"validationMessages": [
{
"level": "WARNING",
"type": "CustomAmiTagValidator",
"message": "The custom AMI may not have been created by pcluster. You can ignore this warning if the AMI is shared or copied from another pcluster AMI. If the AMI is indeed not created by pcluster, cluster creation will fail. If the cluster creation fails, please go to https://docs.aws.amazon.com/parallelcluster/latest/ug/troubleshooting.html#troubleshooting-stack-creation-failures for troubleshooting."
},
{
"level": "WARNING",
"type": "AmiOsCompatibleValidator",
"message": "Could not check node AMI ami-0000012345 OS and cluster OS alinux2 compatibility, please make sure they are compatible before cluster creation and update operations."
}
]
```
Si está seguro de que se está utilizando la AMI correcta, puede ignorar estas advertencias.
Si no quiere ver estas advertencias en el futuro, etiquete la AMI personalizada con las siguientes etiquetas, donde `my-os` sea una de`alinux2`,`alinux2023`,`ubuntu2404`, `ubuntu2204``rhel8`, o `rhel9` y *"3.15.0"* sea la `pcluster` versión en uso:
```
$ aws ec2 create-tags \
--resources ami-yourcustomAmi \
--tags Key="parallelcluster:version",Value="3.15.0" Key="parallelcluster:os",Value="my-os"
```
# Solución de problemas cuando se agota el tiempo de espera de una actualización del clúster cuando no se está ejecutando `cfn-hup`
El script auxiliar cfn-hup es un daemon que detecta cambios en los metadatos de recursos y ejecuta acciones especificadas por el usuario cuando se detecta un cambio. Esto le permite llevar a cabo actualizaciones de la configuración en las instancias de Amazon EC2 que se están ejecutando a través de la acción de la API `UpdateStack`.
Actualmente, el `cfn-hup` daemon lo lanza el. `supervisord` Pero después del lanzamiento, el `cfn-hup` proceso se separa del `supervisord` control. Si un actor externo acaba con el daemon de `cfn-hup`, no se reinicia automáticamente. Si `cfn-hup` no se está ejecutando, durante una actualización del clúster, la CloudFormation pila inicia el proceso de actualización según lo previsto, pero el procedimiento de actualización no se activa en el nodo principal y, finalmente, se agota el tiempo de espera de la pila. En los registros del clúster`/var/log/chef-client`, puede ver que la receta de actualización nunca se invoca.
**Compruébelo y reinícielo `cfn-hup` en caso de errores**
1. En el nodo principal, compruebe si `cfn-hup` se está ejecutando:
```
$ ps aux | grep cfn-hup
```
1. Compruebe el `cfn-hup` registro `/var/log/cfn-hup.log` y `/var/log/supervisord.log` el nodo principal.
1. Si `cfn-hup` no se está ejecutando, intenta reiniciarlo ejecutando:
```
$ sudo /opt/parallelcluster/pyenv/versions/cookbook_virtualenv/bin/supervisorctl start cfn-hup
```
# Solución de problemas de redes en bastidor
En esta sección se ofrecen consejos para solucionar problemas de red, especialmente cuando se trata de un problema de clúster en una única subred pública.
## Problemas con los clústeres en una única subred pública
Compruébelo `cloud-init-output.log` desde uno de los nodos de cómputo. Si encuentra algo como lo siguiente que indica que el nodo está atascado en la inicialización de Slurm, lo más probable es que se deba a la falta de un punto de conexión de VPC de DynamoDB. Añada el punto de conexión de DynamoDB. Para obtener más información, consulte [AWS ParallelCluster en una sola subred sin acceso a Internet](aws-parallelcluster-in-a-single-public-subnet-no-internet-v3.md).
```
ruby_block[retrieve compute node info] action run[2022-03-11T17:47:11+00:00] INFO: Processing ruby_block[retrieve compute node info] action run (aws-parallelcluster-slurm::init line 31)
```
# No se pudo actualizar el clúster al realizar una acción `onNodeUpdated` personalizada
Cuando se produce un error en un [`OnNodeUpdated`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeUpdated)script [`HeadNode`[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)](HeadNode-v3.md)//, se produce un error en la actualización y el script no se ejecuta en el momento de la reversión. Es su responsabilidad realizar manualmente las limpiezas necesarias una vez finalizada la reversión. Por ejemplo, si el `OnNodeUpdated` script cambia el estado de un campo en un archivo de configuración (por ejemplo, de `true` a`false`) y, a continuación, se produce un error, tendrá que restaurar manualmente el valor de ese campo al estado anterior a la actualización (por ejemplo, a). `false` `true` Para obtener más información, consulte [Acciones de arranque personalizadas](custom-bootstrap-actions-v3.md).
# Visualización de errores en la configuración personalizada de Slurm
A partir de AWS ParallelCluster la versión 3.6.0, ya no puede centrarse en scripts individuales `prolog` o `epilog` scripts incluyéndolos en una configuración personalizadaSlurm. En AWS ParallelCluster la versión 3.6.0 y versiones posteriores, debe buscar los scripts personalizados `prolog` y los `epilog` scripts en las carpetas `Prolog` y `Epilog` correspondientes. Estas carpetas están configuradas de forma predeterminada para que apunten a:
+ `Prolog` apunta a `/opt/slurm/etc/scripts/prolog.d/`.
+ `Epilog` apunta a `/opt/slurm/etc/scripts/epilog.d/`.
Le recomendamos que mantenga el guion del `90_plcuster_health_check_manager` prólogo y el guion del `90_pcluster_noop` epílogo en su lugar.
Slurm ejecuta los scripts en orden alfabético inverso. Tanto la carpeta `Prolog` como la `Epilog` deben contener un archivo como mínimo. Para obtener más información, consulte [Slurm y `prolog``epilog`](slurm-prolog-epilog-v3.md) y [Slurm personalización de la configuración](slurm-configuration-settings-v3.md).
# Alarmas de clústeres
La supervisión del estado de los clústeres es esencial para garantizar un rendimiento óptimo. AWS ParallelCluster le permite monitorear múltiples alarmas CloudWatch basadas en el nodo principal del clúster.
En esta sección se proporcionan detalles sobre cada tipo de alarma de clúster del nodo principal, incluidas sus convenciones de nomenclatura, las condiciones específicas que activan las alarmas y las medidas sugeridas para la solución de problemas.
La convención de nomenclatura de las alarmas de clúster es `CLUSTER_NAME-COMPONENT-METRIC`, por ejemplo `mycluster-HeadNode-Cpu`.
+ `CLUSTER_NAME-HeadNode`: indica el estado general del nodo principal. Se muestra en rojo si hay al menos una de las siguientes alarmas.
+ `CLUSTER_NAME-HeadNode-Health`: se muestra en rojo si hay al menos un error en la comprobación de estado de Amazon EC2. En caso de alarma, le sugerimos que consulte [Solución de problemas de las instancias de Amazon EC2 para Linux con comprobaciones de estado no superadas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html).
+ `CLUSTER_NAME-HeadNode-Cpu`: se muestra en rojo si el uso de la CPU es superior al 90 %. En caso de alarma, compruebe los procesos que más CPU consumen con `ps -aux --sort=-%cpu | head -n 10`.
+ `CLUSTER_NAME-HeadNode-Mem`: se muestra en rojo si el uso de la memoria es superior al 90 %. En caso de alarma, compruebe los procesos que más memoria consumen con `ps -aux --sort=-%mem | head -n 10`.
+ `CLUSTER_NAME-HeadNode-Disk`: se muestra en rojo si el espacio ocupado en disco es superior al 90 % en la ruta /. En caso de alarma, compruebe las carpetas que ocupan la mayor parte del espacio con `du -h --max-depth=2 / 2> /dev/null | sort -hr`.
# Resolver los cambios en la configuración del sistema operativo que provocan errores o fallas
Al realizar cambios en la configuración del sistema operativo en AWS ParallelCluster los nodos, pueden surgir varios problemas que pueden provocar errores en la creación, la actualización o el funcionamiento del clúster. Esta sección proporciona orientación sobre cómo identificar y resolver problemas comunes relacionados con la configuración del sistema operativo.
## Problemas comunes de configuración del sistema operativo
### Problemas de configuración regional
Uno de los problemas de configuración del sistema operativo más comunes está relacionado con la configuración regional. Si ves errores como los siguientes:
```
cannot change locale (en_US.utf-8) because it has an invalid name
```
Esto suele ocurrir cuando:
+ Un proceso `yum` de instalación no se realizó correctamente y dejó la configuración regional en un estado incoherente
+ Un usuario ha finalizado un proceso de instalación de forma prematura
+ Faltan paquetes de configuración regional o están dañados
#### ¿Cómo diagnosticar
1. Comprueba si puedes cambiar al usuario pcluster-admin:
```
$ su - pcluster-admin
```
Si ves un error como este`cannot change locale...no such file or directory`, esto confirma el problema.
1. Comprueba las ubicaciones disponibles:
```
$ localedef --list
```
Si esto devuelve una lista vacía o no contiene la configuración regional predeterminada, la configuración regional no funciona.
1. Comprueba el último `yum` comando:
```
$ yum history
$ yum history info #ID
```
Si el último identificador no lo tiene `Return-Code: Success`, es posible que los scripts posteriores a la instalación no se hayan ejecutado correctamente.
#### Cómo resolverlo
Reconstruya la configuración regional reinstalando los paquetes de idioma:
```
$ sudo yum reinstall glibc-all-langpacks
```
Tras la reconstrucción, compruebe que el problema se ha solucionado ejecutando lo siguiente:
```
$ su - pcluster-admin
```
Si no aparece ningún error o advertencia, significa que el problema se ha resuelto.
### Conflictos entre paquetes de SO
Al instalar paquetes personalizados o modificar los paquetes del sistema, pueden surgir conflictos que impidan el correcto funcionamiento del clúster.
#### ¿Cómo diagnosticar
1. Consulte el registro de chef-client para ver si hay errores relacionados con el paquete:
```
$ less /var/log/chef-client.log
```
1. Busque conflictos de dependencia de paquetes en el registro cfn-init:
```
$ less /var/log/cfn-init.log
```
#### Cómo resolverlos
1. Si un paquete específico está causando problemas, intenta volver a instalarlo:
```
$ sudo yum reinstall package-name
```
1. En caso de conflictos de dependencia, es posible que tengas que eliminar los paquetes conflictivos:
```
$ sudo yum remove conflicting-package
```
1. Si el problema persiste, considere la posibilidad de crear una AMI personalizada con los paquetes necesarios preinstalados mediante el `pcluster build-image` comando. Para obtener más información, consulte [AWS ParallelCluster Personalización de AMI](custom-ami-v3.md).
### Modificaciones en el archivo de configuración del sistema
La modificación de los archivos de configuración críticos del sistema puede provocar errores en el clúster, especialmente si estos archivos están gestionados por AWS ParallelCluster.
#### ¿Cómo diagnosticar
1. Compruebe si hay errores en el registro del chef-cliente que mencionen archivos de configuración específicos:
```
$ grep -i "config" /var/log/chef-client.log
```
1. Busque errores de permisos o de sintaxis en los archivos de configuración:
```
$ less /var/log/cfn-init.log
```
#### Cómo resolverlos
1. Restaure los archivos de configuración modificados a su estado original:
```
$ sudo cp /etc/file.conf.bak /etc/file.conf
```
1. Si necesita realizar cambios persistentes en los archivos de configuración del sistema, utilice acciones de arranque personalizadas en lugar de modificar los archivos directamente:
```
HeadNode:
CustomActions:
OnNodeConfigured:
Script: s3://bucket-name/config-script.sh
```
Para obtener más información, consulte [Acciones de arranque personalizadas](custom-bootstrap-actions-v3.md).
1. Para los cambios de configuración que deben realizarse directamente en los archivos del sistema, considere la posibilidad de crear una AMI personalizada. Para obtener más información, consulte [AWS ParallelCluster Personalización de AMI](custom-ami-v3.md).
### Problemas de compatibilidad y actualizaciones del núcleo
Las actualizaciones del núcleo pueden provocar problemas de compatibilidad con determinados AWS servicios, especialmente con Amazon FSx for Lustre.
#### ¿Cómo diagnosticar
1. Compruebe si se han aplicado las actualizaciones del núcleo:
```
$ uname -r
```
1. Busca errores de FSx montaje en Amazon en los registros:
```
$ grep -i "fsx" /var/log/chef-client.log
```
#### ¿Cómo resolverlos?
1. Para Ubuntu 22.04, evita actualizar a la última versión del núcleo, ya que no hay ningún FSx cliente de Amazon para ese núcleo. Para obtener más información, consulte [Consideraciones de los sistemas operativos](operating-systems-v3.md#OS-Consideration-v3).
1. Si ya ha actualizado el núcleo y tiene problemas, considere la posibilidad de cambiarlo a una versión de núcleo compatible:
```
$ sudo apt install linux-image-previous-version
```
1. Para las personalizaciones persistentes del núcleo, cree una AMI personalizada con la versión específica del núcleo que necesite. Para obtener más información, consulte [AWS ParallelCluster Personalización de AMI](custom-ami-v3.md).
## Prácticas recomendadas para los cambios en la configuración del sistema operativo
Para minimizar los problemas al realizar cambios en la configuración del sistema operativo:
1. **Utilice acciones de Bootstrap personalizadas**: en lugar de modificar directamente los archivos del sistema, utilice `OnNodeStart` `OnNodeConfigured` nuestros scripts para realizar cambios de forma controlada. Para obtener más información, consulte [Acciones de arranque personalizadas](custom-bootstrap-actions-v3.md).
1. **Crear una AMI personalizada AMIs**: para realizar modificaciones importantes en el sistema operativo, cree una AMI personalizada utilizando, `pcluster build-image` en lugar de realizar cambios en las instancias en ejecución. Para obtener más información, consulte [AWS ParallelCluster Personalización de AMI](custom-ami-v3.md).
1. **Pruebe primero los cambios**: antes de aplicar los cambios a un clúster de producción, pruébelos en un clúster de prueba pequeño para garantizar la compatibilidad.
1. **Documente los cambios**: lleve un registro de todos los cambios en la configuración del sistema operativo realizados para facilitar la solución de problemas.
1. **Archivos de configuración de respaldo**: antes de modificar cualquier archivo de configuración del sistema, cree una copia de seguridad:
```
$ sudo cp /etc/file.conf /etc/file.conf.bak
```
1. **Compruebe los registros después de realizar cambios**: después de realizar cambios en la configuración del sistema operativo, compruebe si hay algún error en los registros:
```
$ less /var/log/cfn-init.log
$ less /var/log/chef-client.log
```
Si sigue estas pautas, puede minimizar el riesgo de que los cambios en la configuración del sistema operativo provoquen errores en el clúster y solucionar de forma más eficaz cualquier problema que pueda surgir.