Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Solución de problemas de clústeres de Amazon EMR
Un clúster EMR se ejecuta en un ecosistema complejo que comprende software de código abierto, código de aplicación personalizado y. Servicios de AWS Si se produce un problema con alguna de estas partes, es posible que el clúster falle o tarde más de lo esperado en completarse. Los temas siguientes le ayudarán a identificar problemas del clúster y a solucionarlos.
**Topics**
+ [¿Qué herramientas hay disponibles para la solución de problemas de un clúster de Amazon EMR?](emr-troubleshoot-tools.md)
+ [Ver y reiniciar Amazon EMR y procesos de aplicaciones (daemons)](emr-process-restart-stop-view.md)
+ [Recopilaciones de errores comunes en Amazon EMR](emr-troubleshoot-errors.md)
+ [Solución de problemas de un clúster de Amazon EMR que ha fallado con un código de error](emr-troubleshoot-failed.md)
+ [Solución de problemas de un clúster de Amazon EMR lento](emr-troubleshoot-slow.md)
+ [Solución de problemas comunes al utilizar Amazon EMR AWS con Lake Formation](emr-troubleshoot-lf.md)
Guía para solucionar problemas de [aplicaciones de Spark en EMR](https://aws.github.io/aws-emr-best-practices/docs/bestpractices/Applications/Spark/troubleshooting/).
Al desarrollar una nueva aplicación de Hadoop, le recomendamos que habilite la depuración y procese un subconjunto pequeño, pero representativo, de sus datos para probar la aplicación. También puede ejecutar la aplicación step-by-step para probar cada paso por separado. Para obtener más información, consulte [Configuración del registro y la depuración de un clúster de Amazon EMR](emr-plan-debugging.md) y [Paso 5: compruebe el clúster de Amazon EMR de forma pormenorizada](emr-troubleshoot-failed-5-test-steps.md).
# ¿Qué herramientas hay disponibles para la solución de problemas de un clúster de Amazon EMR?
Para identificar y corregir los errores del clúster, puede utilizar las herramientas que se describen en esta página. Es posible que tenga que inicializar algunas de las herramientas al lanzar el clúster. De forma predeterminada, hay otras herramientas disponibles para cada clúster.
**Topics**
+ [Ver detalles del clúster de EMR](#emr-troubleshoot-tools-details)
+ [Ver detalles de errores del clúster de EMR](#emr-troubleshoot-errordetail)
+ [Ejecutar scripts y configurar procesos de Amazon EMR](#emr-troubleshoot-tools-commands)
+ [Ver archivos de registro de](#emr-troubleshoot-tools-logs)
+ [Supervisar el rendimiento del clúster de EMR](#emr-troubleshoot-tools-performance)
## Ver detalles del clúster de EMR
Puede usar la API de EMR Consola de administración de AWS AWS CLI, o la API de EMR para recuperar información detallada sobre un clúster de EMR y la ejecución de tareas. Para obtener más información sobre el uso de Consola de administración de AWS y AWS CLI, consulte. [Visualización del estado y los detalles del clúster de Amazon EMR](emr-manage-view-clusters.md)
### Panel de detalles de la consola de Amazon EMR
En la lista **Clústeres** de la consola de Amazon EMR puede ver información de alto nivel sobre el estado de cada clúster de su cuenta y su Región de AWS. En la lista, se muestran todos los clústeres activos y terminados que ha lanzado en los dos últimos meses. En la lista **Clusters (Clústeres)**, puede seleccionar el **Name (Nombre)** de un clúster para ver los detalles del clúster. Esta información está organizada en distintas categorías para poder consultarla más fácilmente.
La opción **Interfaces de usuario de aplicaciones**, disponible en la página de detalles del clúster, puede ser especialmente útil para la resolución de problemas. Proporciona el estado de las aplicaciones de YARN y, en algunos casos, como en las aplicaciones de Spark, puede explorar las diferentes métricas y facetas, como trabajos, etapas y ejecutores. Para obtener más información, consulte [Visualización del historial de aplicaciones de Amazon EMR](emr-cluster-application-history.md). Esta característica solo está disponible para las versiones 5.8.0 y posteriores de Amazon EMR.
### Interfaz de línea de comandos de Amazon EMR
Puede encontrar detalles sobre un clúster a partir del `--describe` argumento AWS CLI with the.
### API de Amazon EMR
Puede encontrar detalles sobre un clúster desde la API utilizando la acción `DescribeJobFlows`.
## Ver detalles de errores del clúster de EMR
Cuando un clúster de EMR termina con un error, `ListClusters` APIs devuelve un código de error `DescribeCluster` y un mensaje de error. En el caso de determinados errores del clúster, la matriz de datos `ErrorDetail` puede ayudarle a solucionar el error.
Para obtener una lista de códigos de error que incluyen datos de `ErrorDetail`, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md).
**nota**
Mejoramos continuamente nuestros mensajes de error para que reciba la información más reciente y pertinente. No recomendamos analizar el texto desde `ErrorMessage` porque está sujeto a cambios.
## Ejecutar scripts y configurar procesos de Amazon EMR
Como parte del proceso de resolución de problemas, puede resultarle útil ejecutar scripts personalizados en el clúster o ver y configurar los procesos del clúster.
### Ver y reiniciar los procesos de la aplicación
Puede resultar útil ver los procesos en ejecución en el clúster para diagnosticar posibles problemas. Para detener y reiniciar los procesos del clúster, puede conectarse al nodo maestro del clúster. Para obtener más información, consulte [Ver y reiniciar Amazon EMR y procesos de aplicaciones (daemons)](emr-process-restart-stop-view.md).
### Ejecutar comandos y scripts sin una conexión SSH
Para ejecutar un comando o un script en el clúster como paso, puede usar las herramientas `command-runner.jar` o `script-runner.jar` sin establecer una conexión SSH con el nodo maestro. Para obtener más información, consulte [Ejecutar comandos y scripts en un clúster de Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-commandrunner.html).
## Ver archivos de registro de
Amazon EMR y Hadoop generan archivos de registro cuando se ejecuta el clúster. Puede acceder a estos archivos de registro desde diversas herramientas, en función de la configuración que haya especificado al lanzar el clúster. Para obtener más información, consulte [Configuración del registro y la depuración de un clúster de Amazon EMR](emr-plan-debugging.md).
### Archivos de registro en el nodo maestro
Cada clúster publica los archivos de registro en el directoriomnt/var/log//del nodo principal. Estos archivos de registro solo están disponibles mientras se ejecuta el clúster.
### Archivos de registro archivados en Amazon S3
Si lanza el clúster y especifica una ruta de registro de Amazon S3, el clúster copia los archivos de registro almacenados en/mnt/var/log/del nodo maestro en Amazon S3 en intervalos de 5 minutos. Esto garantiza que tenga acceso a los archivos de registro incluso después de que el clúster se termine. Dado que los archivos están archivados en intervalos de 5 minutos, los últimos minutos de un clúster terminado de forma repentina podrían no estar disponibles.
## Supervisar el rendimiento del clúster de EMR
Amazon EMR proporciona varias herramientas para supervisar el rendimiento del clúster.
### Interfaces web de Hadoop
Cada clúster publica una serie de interfaces web en el nodo principal que contienen información sobre el clúster. Puede acceder a estas páginas web mediante un túnel SSH para conectarlas en el nodo principal. Para obtener más información, consulte [Ver las interfaces web alojadas en clústeres de Amazon EMR](emr-web-interfaces.md).
### CloudWatch métricas
Cada clúster informa de las métricas a CloudWatch. CloudWatch es un servicio web que realiza un seguimiento de las métricas y que puede utilizar para configurar alarmas en esas métricas. Para obtener más información, consulte [Supervisión de las métricas de Amazon EMR con CloudWatch](UsingEMR_ViewingMetrics.md).
# Ver y reiniciar Amazon EMR y procesos de aplicaciones (daemons)
Cuando realice la solución de problemas en un clúster, conviene que cree una lista de los procesos en ejecución. Es posible que también desee detener o reiniciar procesos. Por ejemplo, puede reiniciar un proceso después de cambiar una configuración o detectar un problema con un proceso determinado tras analizar los archivos de registro y los mensajes de error.
Hay dos tipos de procesos que se ejecutan en un clúster: los procesos de Amazon EMR (por ejemplo, instance-controller y Log Pusher) y los procesos asociados a las aplicaciones instaladas en el clúster (por ejemplo, y). hadoop-hdfs-namenode hadoop-yarn-resourcemanager
Para trabajar con procesos directamente en un clúster, antes debe conectarse al nodo maestro. Para obtener más información, consulte [Conectar a un clúster de Amazon EMR](emr-connect-master-node.md).
## Ver procesos en ejecución
El método que utilice para ver los procesos en ejecución en un clúster varía según la versión de Amazon EMR que utilice.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : enumerar todos los procesos en ejecución**
En el siguiente ejemplo, se utiliza `systemctl` y se especifica `--type` para ver todos los procesos.
```
systemctl --type=service
```
**Example : enumerar procesos específicos**
En el siguiente ejemplo, se muestra una lista de todos los procesos con nombres que contengan `hadoop`.
```
systemctl --type=service | grep -i hadoop
```
Ejemplo de código de salida:
```
hadoop-hdfs-namenode.service loaded active running Hadoop namenode
hadoop-httpfs.service loaded active running Hadoop httpfs
hadoop-kms.service loaded active running Hadoop kms
hadoop-mapreduce-historyserver.service loaded active running Hadoop historyserver
hadoop-state-pusher.service loaded active running Daemon process that processes and serves EMR metrics data.
hadoop-yarn-proxyserver.service loaded active running Hadoop proxyserver
hadoop-yarn-resourcemanager.service loaded active running Hadoop resourcemanager
hadoop-yarn-timelineserver.service loaded active running Hadoop timelineserver
```
**Example : ver un informe de estado detallado de un proceso específico**
En el siguiente ejemplo, se muestra un informe de estado detallado del servicio `hadoop-hdfs-namenode`.
```
sudo systemctl status hadoop-hdfs-namenode
```
Ejemplo de código de salida:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-08-18 21:01:46 UTC; 26min ago
Main PID: 9733 (java)
Tasks: 0
Memory: 1.1M
CGroup: /system.slice/hadoop-hdfs-namenode.service
‣ 9733 /etc/alternatives/jre/bin/java -Dproc_namenode -Xmx1843m -server -XX:OnOutOfMemoryError=kill -9 %p ...
Aug 18 21:01:37 ip-172-31-20-123 systemd[1]: Starting Hadoop namenode...
Aug 18 21:01:37 ip-172-31-20-123 su[9715]: (to hdfs) root on none
Aug 18 21:01:37 ip-172-31-20-123 hadoop-hdfs-namenode[9683]: starting namenode, logging to /var/log/hadoop-hdfs/ha...out
Aug 18 21:01:46 ip-172-31-20-123 hadoop-hdfs-namenode[9683]: Started Hadoop namenode:[ OK ]
Aug 18 21:01:46 ip-172-31-20-123 systemd[1]: Started Hadoop namenode.
Hint: Some lines were ellipsized, use -l to show in full.
```
------
#### [ EMR 4.x - 5.29.0 ]
**Example : enumerar todos los procesos en ejecución**
En el ejemplo siguiente, se muestra una lista de todos los procesos en ejecución.
```
initctl list
```
------
#### [ EMR 2.x - 3.x ]
**Example : enumerar todos los procesos en ejecución**
En el ejemplo siguiente, se muestra una lista de todos los procesos en ejecución.
```
ls /etc/init.d/
```
------
## Detener y reiniciar procesos
Después de determinar qué procesos se están ejecutando, puede detenerlos y, a continuación, reiniciarlos si es necesario.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : detener un proceso**
En el siguiente ejemplo, se detiene el proceso `hadoop-hdfs-namenode`.
```
sudo systemctl stop hadoop-hdfs-namenode
```
Puede consultar el `status` para comprobar que el proceso se ha detenido.
```
sudo systemctl status hadoop-hdfs-namenode
```
Ejemplo de código de salida:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2021-08-18 21:37:50 UTC; 8s ago
Main PID: 9733 (code=exited, status=143)
```
**Example : iniciar un proceso**
En el siguiente ejemplo, se inicia el proceso `hadoop-hdfs-namenode`.
```
sudo systemctl start hadoop-hdfs-namenode
```
Puede consultar el estado para comprobar que el proceso se está ejecutando.
```
sudo systemctl status hadoop-hdfs-namenode
```
Ejemplo de código de salida:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-08-18 21:38:24 UTC; 2s ago
Process: 13748 ExecStart=/etc/init.d/hadoop-hdfs-namenode start (code=exited, status=0/SUCCESS)
Main PID: 13800 (java)
Tasks: 0
Memory: 1.1M
CGroup: /system.slice/hadoop-hdfs-namenode.service
‣ 13800 /etc/alternatives/jre/bin/java -Dproc_namenode -Xmx1843m -server -XX:OnOutOfMemoryError=kill -9 %p...
```
------
#### [ EMR 4.x - 5.29.0 ]
**Example : detener un proceso en ejecución**
En el siguiente ejemplo, se detiene el servicio `hadoop-hdfs-namenode`.
```
sudo stop hadoop-hdfs-namenode
```
**Example : reiniciar un proceso detenido**
En el siguiente ejemplo, se reinicia el servicio `hadoop-hdfs-namenode`. Debe usar el comando `start` y no `restart`.
```
sudo start hadoop-hdfs-namenode
```
**Example : comprobar el estado del proceso**
A continuación, se obtiene el estado de `hadoop-hdfs-namenode`. Puede utilizar el comando `status` para comprobar que el proceso se ha detenido o se ha iniciado.
```
sudo status hadoop-hdfs-namenode
```
------
#### [ EMR 2.x - 3.x ]
**Example : detener el proceso de una aplicación**
En el siguiente ejemplo, se detiene el servicio `hadoop-hdfs-namenode`, que está asociado a la versión de Amazon EMR instalada en el clúster.
```
sudo /etc/init.d/hadoop-hdfs-namenode stop
```
**Example : reiniciar el proceso de una aplicación**
El siguiente comando de ejemplo reinicia el proceso `hadoop-hdfs-namenode`:
```
sudo /etc/init.d/hadoop-hdfs-namenode start
```
**Example : detener un proceso de Amazon EMR**
En el siguiente ejemplo, se detiene un proceso, como instance-controller, que no está asociado a la versión de Amazon EMR del clúster.
```
sudo /sbin/stop instance-controller
```
**Example : reiniciar un proceso de Amazon EMR**
En el siguiente ejemplo, se reinicia un proceso, como instance-controller, que no está asociado a la versión de Amazon EMR del clúster.
```
sudo /sbin/start instance-controller
```
**nota**
Los comandos `/sbin/start, stop` y `restart` son symlinks a `/sbin/intictl`. Para obtener más información acerca de `initctl`, consulte la página del manual de initctl escribiendo `man initctl` en el símbolo del sistema.
------
# Recopilaciones de errores comunes en Amazon EMR
A veces, los clústeres fallan o procesan los datos con lentitud. En las secciones siguientes se enumeran problemas comunes de clústeres. Entre los errores se incluyen los errores de arranque y los errores de validación, con sugerencias sobre cómo resolverlos.
**Topics**
+ [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md)
+ [Errores de recursos durante las operaciones del clústeres de Amazon EMR](emr-troubleshoot-error-resource.md)
+ [Errores de entrada y salida de clúster durante la operaciones de Amazon EMR](emr-troubleshoot-errors-io.md)
+ [Errores de permisos durante las operaciones del clúster de Amazon EMR](emr-troubleshoot-error-permissions.md)
+ [Errores de clúster de Hive](emr-troubleshoot-error-hive.md)
+ [Errores de la VPC durante las operaciones del clúster de Amazon EMR](emr-troubleshoot-error-vpc.md)
+ [Errores del clúster de Amazon EMR de streaming](emr-troubleshoot-error-streaming.md)
+ [Amazon EMR: errores de clúster JAR personalizados](emr-troubleshoot-error-custom-jar.md)
+ [Errores de Amazon EMR AWS GovCloud (EE. UU. - Oeste)](emr-troubleshoot-error-govcloud.md)
+ [Buscar un clúster que falta](#w2aac36c21c47)
# Códigos de error con ErrorDetail información en Amazon EMR
Cuando un clúster de EMR termina con un error, `ListClusters` APIs devuelve un código de error `DescribeCluster` y un mensaje de error. En el caso de algunos errores de clústeres, la matriz de datos `ErrorDetail` puede ayudarle a solucionar el error.
Los errores que incluyen una matriz `ErrorDetail` proporcionan los siguientes detalles:
**`ErrorCode`**
Un código de error único que se puede utilizar para el acceso mediante programación.
**`ErrorData`**
Una lista de identificadores en pares clave-valor que puede utilizar para la programación o la búsqueda manual. Para obtener una descripción de los valores `ErrorData` que incluye un código de error, consulte la página de resolución de problemas del código de error.
**`ErrorMessage`**
Descripción del error con un enlace a más información en la documentación de Amazon EMR.
No recomendamos analizar el texto desde `ErrorMessage` porque está sujeto a cambios.
**Topics**
+ [Errores de arranque](emr-troubleshoot-error-errordetail-bootstrap.md)
+ [Errores internos](emr-troubleshoot-error-errordetail-internal.md)
+ [Errores de validación](emr-troubleshoot-error-errordetail-validation.md)
# Códigos de errores de arranque en Amazon EMR
En las siguientes secciones, se proporciona información sobre la resolución de problemas relacionados con los códigos de errores de arranque.
**Topics**
+ [BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE](BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE.md)
+ [BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY](BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY](BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT ENT\$1DISK\$1SPACE\$1PRIMARY](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER.md)
# BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE
## Descripción general de
Cuando un clúster termina con un error `BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE`, se produce un error en una acción de arranque en la instancia principal. Para obtener más información sobre las acciones de arranque, consulte [Creación de acciones de arranque para instalar software adicional con un clúster de Amazon EMR](emr-plan-bootstrap.md).
## Resolución
Para resolver este error, revise los detalles que se muestran en el error de la API, modifique el script de acción de arranque y cree un clúster nuevo con la acción de arranque actualizada.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`primary-instance-id`**
El ID de la instancia principal en la que se produjo un error en la acción de arranque.
**`bootstrap-action`**
El número ordinal de la acción de arranque que falló. Un script con un valor de `bootstrap-action` de `1` es la primera acción de arranque que se ejecuta en la instancia.
**`return-code`**
El código de retorno de la acción de arranque que falló.
**`amazon-s3-path`**
La ubicación en Amazon S3 de la acción de arranque que falló.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para identificar y corregir la causa raíz del error de la acción de arranque. A continuación, lance un clúster nuevo.
1. Revise los archivos de registro de acciones de arranque en Amazon S3 para identificar la causa raíz del error. Para obtener más información sobre cómo ver los registros de Amazon EMR, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
1. Si activó los registros del clúster al crear la instancia, consulte el registro `stdout` para obtener más información. Puede encontrar el registro `stdout` de la acción de arranque en esta ubicación de Amazon S3:
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
Para obtener más información sobre registros del clúster, consulte [Configuración del registro y la depuración de un clúster de Amazon EMR](emr-plan-debugging.md).
1. Para determinar el error de la acción de arranque, revise las excepciones en los registros `stdout` y el valor `return-code` en `ErrorData`.
1. Utilice los resultados del paso anterior para revisar la acción de arranque de forma que evite las excepciones o pueda gestionarlas correctamente cuando se produzcan.
1. Lance un clúster nuevo con la acción de arranque actualizada.
# BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY
## Descripción general de
Un clúster termina con el error `BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY` cuando la instancia principal no puede descargar un script de acción de arranque desde la ubicación de Amazon S3 que especifique. Las posibles causas son las siguientes:
+ El archivo del script de acción de arranque no se encuentra en la ubicación de Amazon S3.
+ El rol de servicio de las instancias de Amazon EC2 del clúster (también denominado *perfil de instancia de EC2 para Amazon EMR*) no tiene permisos para acceder al bucket de Amazon S3 en el que reside el script de acción de arranque. Para obtener más información acerca de los roles de servicio, consulte [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md).
Para obtener más información sobre las acciones de arranque, consulte [Creación de acciones de arranque para instalar software adicional con un clúster de Amazon EMR](emr-plan-bootstrap.md).
## Resolución
Para resolver este error, asegúrese de que la instancia principal tenga el acceso adecuado al script de acción de arranque.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`primary-instance-id`**
El ID de la instancia principal en la que se produjo un error en la acción de arranque.
**`bootstrap-action`**
El número ordinal de la acción de arranque que falló. Un script con un valor de `bootstrap-action` de `1` es la primera acción de arranque que se ejecuta en la instancia.
**`amazon-s3-path`**
La ubicación en Amazon S3 de la acción de arranque que falló.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para identificar y corregir la causa raíz del error de la acción de arranque. A continuación, lance un clúster nuevo.
**Pasos para la solución de problemas**
1. Utilice el valor `amazon-s3-path` de la matriz `ErrorData` para buscar el script de acción de arranque correspondiente en Amazon S3.
1. Si activó los registros del clúster al crear la instancia, consulte el registro `stdout` para obtener más información. Puede encontrar el registro `stdout` de la acción de arranque en esta ubicación de Amazon S3:
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
Para obtener más información sobre registros del clúster, consulte [Configuración del registro y la depuración de un clúster de Amazon EMR](emr-plan-debugging.md).
1. Para determinar el error de la acción de arranque, revise las excepciones en los registros `stdout` y el valor `return-code` en `ErrorData`.
1. Utilice los resultados del paso anterior para revisar la acción de arranque de forma que evite las excepciones o pueda gestionarlas correctamente cuando se produzcan.
1. Lance un clúster nuevo con la acción de arranque actualizada.
# BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY
## Descripción general de
El error `BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY` indica que la instancia principal no encuentra el script de acción de arranque que la instancia acaba de descargar del bucket de Amazon S3 especificado.
## Resolución
Para resolver este error, confirme que la instancia principal tenga el acceso adecuado al script de acción de arranque.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`primary-instance-id`**
El ID de la instancia principal en la que se produjo un error en la acción de arranque.
**`bootstrap-action`**
El número ordinal de la acción de arranque que falló. Un script con un valor de `bootstrap-action` de `1` es la primera acción de arranque que se ejecuta en la instancia.
**`amazon-s3-path`**
La ubicación en Amazon S3 de la acción de arranque que falló.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para identificar y corregir la causa raíz del error de la acción de arranque. A continuación, lance un clúster nuevo.
1. Para encontrar el script de acción de arranque correspondiente en Amazon S3, utilice el valor `amazon-s3-path` de la matriz `ErrorData`.
1. Revise los archivos de registro de acciones de arranque en Amazon S3 para identificar la causa raíz del error. Para obtener más información sobre cómo ver los registros de Amazon EMR, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
**nota**
Si no activó los registros del clúster, debe crear un clúster nuevo con las mismas configuraciones y acciones de arranque. Para asegurarse de que los registros del clúster estén activados, consulte [Configuración del registro y la depuración de un clúster de Amazon EMR](emr-plan-debugging.md).
1. Revise el registro `stdout` de las acciones de arranque y confirme que no haya procesos personalizados que eliminen los archivos de la carpeta `/emr/instance-controller/lib/bootstrap-actions` de sus instancias principales. Puede encontrar el registro `stdout` de la acción de arranque en esta ubicación de Amazon S3:
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
1. Lance un clúster nuevo con la acción de arranque actualizada.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT ENT\$1DISK\$1SPACE\$1PRIMARY
## Descripción general de
El error `BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY` indica que la instancia primaria no tiene suficiente espacio en disco durante la instalación del software necesario.
## Resolución
Para resolver este error, confirme que su instancia primaria tiene suficiente espacio libre en el volumen raíz.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`primary-instance-id`**
El ID de la instancia primaria con espacio en disco insuficiente.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
1. Revise las prácticas recomendadas para el volumen raíz EBS de su clúster. Consulte [Personalización del volumen de dispositivo raíz de Amazon EBS](emr-custom-ami-root-volume-size.md) en la *Guía de administración de Amazon EMR*.
1. Inicie un clúster nuevo con un volumen raíz EBS de mayor tamaño.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER
## Descripción general de
El error `BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER` indica que una o varias instancias de trabajo no tienen suficiente espacio en disco al instalar el software necesario.
## Resolución
Para resolver este problema, confirme que las instancias de trabajo tengan el espacio adecuado en el volumen raíz.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`worker-instance-ids`**
La IDs de las instancias de trabajo con espacio en disco insuficiente.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
1. Revise las prácticas recomendadas para el volumen raíz EBS de su clúster. Consulte [Personalización del volumen de dispositivo raíz de Amazon EBS](emr-custom-ami-root-volume-size.md) en la *Guía de administración de Amazon EMR*.
1. Inicie un clúster nuevo con un volumen raíz EBS de mayor tamaño.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY
## Descripción general de
El error `BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY` indica que la instancia primaria no logra establecer una conexión con el Hive Metastore externo configurado.
## Resolución
Para resolver este problema, confirme que el Hive Metastore externo esté configurado correctamente y que la instancia primaria tenga permiso para conectarse a él.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`primary-instance-id`**
Revise el ID de la instancia primaria que no puede conectarse al Hive Metastore externo.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
1. Consulte las prácticas recomendadas para configurar un metalmacén externo para Hive. Consulte [Configuring an external metastore for Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html).
1. Lance un clúster nuevo con la configuración del clúster actualizada.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER
## Descripción general de
El error `BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER` indica que una o varias instancias de trabajo no logran conectarse al Hive Metastore externo configurado.
## Resolución
Para resolver este problema, confirme que el Hive Metastore externo esté configurado correctamente y que las instancias de trabajo tengan permiso para conectarse a él.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`worker-instance-ids`**
La IDs de las instancias de trabajo no pudo establecer una conexión con el Hive Metastore externo configurado.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
1. Consulte las prácticas recomendadas para configurar un metalmacén externo para Hive. Consulte [Configuring an external metastore for Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html).
1. Lance un clúster nuevo con la configuración del clúster actualizada.
# Códigos de errores internos de Amazon EMR
En las siguientes secciones, se proporciona información sobre la resolución de problemas relacionados con los códigos de errores internos, incluidos los códigos para capacidad insuficiente o sin capacidad.
**Topics**
+ [INTERNAL\$1ERROR\$1 \$1INSUFFICIENT\$1CAPACITY\$1AZ EC2](INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY](INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY](INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY.md)
# INTERNAL\$1ERROR\$1 \$1INSUFFICIENT\$1CAPACITY\$1AZ EC2
## Descripción general de
Un clúster termina con un error `INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ` cuando la zona de disponibilidad seleccionada no tiene capacidad suficiente para cumplir con la solicitud de tipo de instancia de Amazon EC2. La subred que seleccione para un clúster determina la zona de disponibilidad. Para obtener más información sobre las subredes para Amazon EMR, consulte [Configuración de redes en una VPC para Amazon EMR](emr-plan-vpc-subnet.md).
## Resolución
Para resolver este error, modifique las configuraciones del tipo de instancia y cree un clúster nuevo con la solicitud actualizada.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`instance-type`**
El tipo de instancia que no tiene capacidad.
**`availability-zone`**
La zona de disponibilidad en la que se resuelve la subred.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para identificar y corregir la causa raíz del error de configuración del clúster:
+ Revise las prácticas recomendadas para la configuración del clúster. Consulte [Configuración de tipos de instancias de clúster de Amazon EMR y prácticas recomendadas para instancias de Spot](emr-plan-instances-guidelines.md) en la *Guía de administración de Amazon EMR*.
+ Solucione los problemas de lanzamiento y revise la configuración. Consulte [Solución de problemas de lanzamiento de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) en la *Guía del usuario de Amazon EC2*.
+ Lance un clúster nuevo con la configuración del clúster actualizada.
# INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY
## Descripción general de
Un clúster termina con un error `INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY` cuando Amazon EMR no puede gestionar la solicitud de instancia de spot para el nodo principal porque las instancias no están disponibles por el precio máximo de spot o uno inferior. Para obtener más información, consulte [Instancias de spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) en *Guía del usuario de Amazon EC2*.
## Resolución
Para resolver este error, especifique los tipos de instancia para su clúster que estén dentro de su precio objetivo o aumente el límite de precio para el mismo tipo de instancia.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`primary-instance-id`**
El ID de la instancia principal del clúster que falló.
**`instance-type`**
El tipo de instancia que no tiene capacidad.
**`availability-zone`**
La zona de disponibilidad en la que reside la subred.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para solucionar los problemas de su estrategia de configuración del clúster y, a continuación, lance un clúster nuevo:
1. Revise las prácticas recomendadas para las instancias de spot de Amazon EC2 y la estrategia de configuración del clúster. Para obtener más información, consulte [Prácticas recomendadas para EC2 Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) en la *Guía del usuario de Amazon EC2* y [Configuración de tipos de instancias de clúster de Amazon EMR y prácticas recomendadas para instancias de Spot](emr-plan-instances-guidelines.md).
1. Modifique las configuraciones del tipo de instancia o la zona de disponibilidad y cree un clúster nuevo con la solicitud actualizada.
1. Si el problema persiste, use la capacidad bajo demanda para la instancia principal.
# INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY
## Descripción general de
Un clúster termina con un error `INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY` cuando no hay suficiente capacidad para gestionar una solicitud de instancia de spot para su nodo principal. Para obtener más información, consulte [Instancias de spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) en *Guía del usuario de Amazon EC2*.
## Resolución
Para resolver este error, especifique los tipos de instancia para su clúster que estén dentro de su precio objetivo o aumente el límite de precio para el mismo tipo de instancia.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`primary-instance-id`**
El ID de la instancia principal del clúster que falló.
**`instance-type`**
El tipo de instancia que no tiene capacidad.
**`availability-zone`**
La zona de disponibilidad en la que se resuelve la subred.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para solucionar los problemas de su estrategia de configuración del clúster y, a continuación, lance un clúster nuevo:
1. Revise las prácticas recomendadas para las instancias de spot de Amazon EC2 y la estrategia de configuración del clúster. Para obtener más información, consulte [Prácticas recomendadas para EC2 Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) en la *Guía del usuario de Amazon EC2* y [Configuración de tipos de instancias de clúster de Amazon EMR y prácticas recomendadas para instancias de Spot](emr-plan-instances-guidelines.md).
1. Modifique las configuraciones del tipo de instancia y cree un clúster nuevo con la solicitud actualizada.
1. Si el problema persiste, use la capacidad bajo demanda para la instancia principal.
# Códigos de errores de validación en Amazon EMR
En las siguientes secciones, se proporciona información sobre la resolución de problemas relacionados con los códigos de errores de validación.
**Topics**
+ [VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME](VALIDATION_ERROR_INVALID_SSH_KEY_NAME.md)
+ [VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED](VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED.md)
# VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC
## Descripción general de
Cuando el clúster y las subredes a las que hace referencia pertenecen a nubes privadas virtuales diferentes (VPCs), el clúster finaliza con un error. `VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC` Puede lanzar clústeres con Amazon EMR con la configuración de las flotas de instancias en las subredes de una VPC. Para obtener más información sobre las flotas de instancias, consulte [Planificación y configuración de flotas de instancias para su clúster de Amazon EMR](emr-instance-fleet.md) en la *Guía de administración de Amazon EMR*.
## Resolución
Para resolver este error, utilice subredes que pertenezcan a la misma VPC que el clúster.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`vpc`**
Para cada par subred:VPC, el ID de la VPC a la que pertenece la subred.
**`subnet`**
Para cada par subred:VPC, el ID de la subred.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para identificar y corregir el error:
1. Revise las subredes IDs que aparecen en la `ErrorData` matriz y confirme que pertenecen a la VPC en la que desea lanzar el clúster de EMR.
1. Modifique las configuraciones de la subred. Puede usar uno de los siguientes métodos para buscar todas las subredes públicas y privadas disponibles en una VPC.
+ Vaya a la consola de Amazon VPC. Elija **Subredes** y enumere todas las subredes que residen en ellas para su clúster. Región de AWS Para buscar solo subredes públicas o privadas, aplique el filtro de **asignación automática de direcciones** públicas. IPv4 Para buscar y seleccionar subredes en la VPC que utiliza el clúster, utilice la opción **Filtrar por VPC**. Para obtener más información sobre cómo crear subredes, consulte [Creación de una subred](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) en la *Guía del usuario de Amazon Virtual Private Cloud*.
+ Use el AWS CLI para buscar todas las subredes públicas y privadas disponibles en la VPC que usa su clúster. Para obtener más información, consulte la API [describe-subnets](https://amazonaws.com/ec2/describe-subnets.html). Para crear subredes en una VPC, consulta la API [create-subnet](https://amazonaws.com/ec2/create-subnet.html).
1. Lance un clúster nuevo con subredes desde la misma VPC que el clúster.
# VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC
## Descripción general de
Cuando el clúster y los grupos de seguridad que le asignas pertenecen a nubes privadas virtuales diferentes (VPCs), el clúster finaliza con un error. `VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC` Para obtener más información sobre los grupos de seguridad, consulte [Especificación de los grupos de seguridad adicionales administrados por Amazon EMR](emr-sg-specify.md) y [Control del tráfico de red con grupos de seguridad para su clúster de Amazon EMR](emr-security-groups.md).
## Resolución
Para resolver este error, utilice grupos de seguridad que pertenezcan a la misma VPC que el clúster.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`vpc`**
Para cada par security-group:VPC, el ID de la VPC a la que pertenece el grupo de seguridad.
**`security-group`**
Para cada par security-group:VPC, el ID del grupo de seguridad.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para identificar y corregir el error:
1. Revise los grupos de seguridad IDs que aparecen en la `ErrorData` matriz y confirme que pertenecen a la VPC en la que desea lanzar el clúster de EMR.
1. Vaya a la consola de Amazon VPC. Elija **Grupos de seguridad** para enumerar todos los grupos de seguridad de la región que seleccione. Busque los grupos de seguridad de la misma VPC que el clúster y, a continuación, modifique la configuración del grupo de seguridad.
1. Lance un clúster nuevo con grupos de seguridad desde la misma VPC que el clúster.
# VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME
## Descripción general de
Un clúster termina con un error `VALIDATION_ERROR_INVALID_SSH_KEY_NAME` cuando usa un par de claves de Amazon EC2 que no es válido para SSH en la instancia principal. Es posible que el nombre del par de claves sea incorrecto o que el par de claves no exista en la solicitud Región de AWS. Para obtener más información sobre pares de claves, consulte [Pares de claves de Amazon EC2 e instancias de Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*.
## Resolución
Para resolver este error, cree un clúster nuevo con un nombre de par de claves SSH válido.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`ssh-key`**
El nombre del par de claves SSH que proporcionó al crear el clúster.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para identificar y corregir el error:
1. Compruebe el *keypair* archivo.pem y confirme que coincide con el nombre de la clave SSH que ve en la consola de Amazon EMR.
1. Vaya a la consola de Amazon EC2. Compruebe que el nombre de la clave SSH que utilizó esté disponible en el Región de AWS clúster que utiliza. La encontrarás Región de AWS junto a tu ID de cuenta en la parte superior de Consola de administración de AWS.
1. Lance un clúster nuevo con un nombre de clave SSH válido.
# VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED
## Descripción general de
Un clúster termina con un error `VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED` cuando la Región de AWS y las zonas de disponibilidad del clúster no admiten el tipo de instancia especificado para uno o más grupos de instancias. Amazon EMR puede admitir un tipo de instancia en una zona de disponibilidad de una región, pero no en otra. La subred que seleccione para un clúster determina la zona de disponibilidad dentro de la región. Para ver una lista de tipos de instancia y regiones compatibles con Amazon EMR, consulte [Tipos de instancias admitidas con Amazon EMR](emr-supported-instance-types.md).
## Resolución
Para resolver este error, especifique los tipos de instancia para el clúster que Amazon EMR admite en la región y la zona de disponibilidad en la que solicita el clúster.
Para solucionar los problemas del clúster de EMR que ha fallado, consulte `ErrorDetail` la información devuelta por y. `DescribeCluster` `ListClusters` APIs Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md). La matriz `ErrorData` de `ErrorDetail` devuelve la siguiente información para este código de error:
**`instance-types`**
La lista de tipos de instancia no compatibles.
**`availability-zones`**
La lista de zonas de disponibilidad en las que se resuelve la subred.
**`public-doc`**
La URL pública de la documentación del código de error.
## Pasos que completar
Siga estos pasos para identificar y corregir el error:
1. Úselo AWS CLI para recuperar los tipos de instancias disponibles en una zona de disponibilidad. Para ello, puede usar el `[ec2 describe-instance-type-offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)` comando para filtrar los tipos de instancias disponibles por ubicación (Región de AWS o zona de disponibilidad). Por ejemplo, el siguiente comando devuelve los tipos de instancias que se ofrecen en la zona de disponibilidad especificada, `us-east-2a`.
```
aws ec2 describe-instance-type-offerings --location-type "availability-zone" --filters Name=location,Values=us-east-2a --region us-east-2 --query "InstanceTypeOfferings[*].[InstanceType]" --output text | sort
```
Para obtener más información sobre cómo descubrir los tipos de instancia disponibles, consulte [Buscar un tipo de instancia de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html).
1. Tras determinar los tipos de instancia que están disponibles en la misma región y zona de disponibilidad que el clúster, elija una de las siguientes soluciones para continuar:
1. Cree un clúster nuevo y elija una subred para el clúster que esté en una zona de disponibilidad en la que el tipo de instancia que ha seleccionado esté disponible y sea compatible con Amazon EMR.
1. Cree un clúster nuevo en la misma región y subred de Amazon EC2 que el clúster en el que se produjo el error, pero con un tipo de instancia que Amazon EMR admita en esa ubicación.
Para ver una lista de tipos de instancia y regiones compatibles con Amazon EMR, consulte [Tipos de instancias admitidas con Amazon EMR](emr-supported-instance-types.md). Para comparar las capacidades de los tipos de instancia, consulte [Tipos de instancia de Amazon EC2](https://aws.amazon.com/ec2/instance-types).
# Errores de recursos durante las operaciones del clústeres de Amazon EMR
Los siguientes errores suelen ser causados habitualmente por recursos limitados en el clúster. Las instrucciones describen cada error y proporcionan ayuda para la solución de problemas.
**Topics**
+ [El clúster de Amazon EMR finaliza con NO\$1SLAVE\$1LEFT y los nodos básicos con FAILED\$1BY\$1MASTER](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md)
+ [Error de clúster de Amazon EMR: “No se puede replicar el bloque, solo se pudo replicar a cero nodos”.](enough-hdfs-space.md)
+ [Error de clúster de Amazon EMR: SE HA SUPERADO LA CUOTA DE EC2](emr-EC2.md)
+ [Error de clúster de Amazon EMR: “Demasiados errores de búsqueda”](emr-troubleshoot-error-resource-1.md)
+ [Error de clúster de Amazon EMR: “El archivo solo pudo ser replicado a 0 nodos en lugar de 1”](emr-troubleshoot-error-resource-2.md)
+ [Error de clúster de Amazon EMR: “Nodos en la lista de denegación”](emr-troubleshoot-error-resource-3.md)
+ [Limitación de errores con un clúster de Amazon EMR](emr-throttling-error.md)
+ [Error de clúster de Amazon EMR: “No se admite el tipo de instancia”](emr-INSTANCE_TYPE_NOT_SUPPORTED-error.md)
+ [Error de clúster de Amazon EMR: “EC2 no tiene capacidad”](emr-EC2_INSUFFICIENT_CAPACITY-error.md)
+ [Error de clúster de Amazon EMR: “Error del factor de replicación de HDFS”](emr-hdfs-insufficient-replication.md)
+ [Error de clúster de Amazon EMR: “Error de espacio insuficiente en HDFS”](emr-hdfs-insufficient-space.md)
# El clúster de Amazon EMR finaliza con NO\$1SLAVE\$1LEFT y los nodos básicos con FAILED\$1BY\$1MASTER
Normalmente, esto ocurre porque la protección de terminación está deshabilitada y todos los nodos secundarios superan la capacidad de almacenamiento en disco especificada por el umbral de utilización máximo en la configuración de clasificación `yarn-site`, que corresponde al archivo `yarn-site.xml`. Este valor es el 90 % de forma predeterminada. Cuando la utilización del disco de un nodo principal supera el umbral de utilización, el servicio de NodeManager estado de YARN informa del nodo como`UNHEALTHY`. Mientras esté en este estado, Amazon EMR lo incluye en la lista de denegados y no le asigna contenedores YARN. Si el nodo sigue en mal estado transcurridos 45 minutos, Amazon EMR marca la instancia de Amazon EC2 asociada para su terminación como `FAILED_BY_MASTER`. Cuando todas las instancias de Amazon EC2 asociadas con nodos principales se marcan para su terminación, el clúster termina con el estado `NO_SLAVE_LEFT` porque no hay recursos para ejecutar trabajos.
Sobrepasar la utilización del disco en un nodo secundario podría causar una reacción en cadena. Si un único nodo supera el umbral de utilización del disco debido a HDFS, es posible que otros nodos estén también cerca del umbral. El primer nodo supera el umbral de uso del disco, por lo que Amazon EMR lo agrega a la lista de denegados. Esto aumenta la carga de uso del disco en los nodos restantes, ya que estos comienzan a replicar entre ellos los datos HDFS que perdieron en el nodo incluido en la lista de denegados. Uno por uno, los nodos van adoptando el estado `UNHEALTHY` de la misma manera, y el clúster finalmente termina.
## Prácticas recomendadas y recomendaciones
### Configurar el hardware del clúster con almacenamiento suficiente
Al crear un clúster, asegúrese de que haya suficientes nodos secundarios y de que cada uno tenga un almacén de instancias y volúmenes de almacenamiento de EBS para HDFS apropiados. Para obtener más información, consulte [Cálculo de la capacidad de HDFS requerida de un clúster](emr-plan-instances-guidelines.md#emr-plan-instances-hdfs). También puede añadir instancias secundarias a grupos de instancias existentes de forma manual o mediante el escalado automático. Las instancias nuevas tienen la misma configuración de almacenamiento que el resto de las instancias del grupo. Para obtener más información, consulte [Utilice el escalado de clústeres de Amazon EMR para adaptarse a las cargas de trabajo cambiantes](emr-scale-on-demand.md).
### Cómo habilitar la protección contra la terminación
Habilite la protección de terminación. De esta forma, si un nodo principal se incluye en la lista de denegados, es posible conectarse a la instancia de Amazon EC2 asociada mediante SSH para solucionar el problema y recuperar los datos. Si habilita la protección de terminación, tenga en cuenta que Amazon EMR no sustituye la instancia de Amazon EC2 por una nueva. Para obtener más información, consulte [Uso de la protección de finalización para proteger sus clústeres de Amazon EMR de un cierre accidental](UsingEMR_TerminationProtection.md).
### Cree una alarma para la CloudWatch métrica de MRUnhealthy nodos
Esta métrica indica el número de nodos que tienen el estado `UNHEALTHY`. Es equivalente a la métrica `mapred.resourcemanager.NoOfUnhealthyNodes` de YARN. Puede configurar una notificación para esta alarma que le avise de los nodos en mal estado 45 minutos antes de que se agote el tiempo de espera. Para obtener más información, consulte [Supervisión de las métricas de Amazon EMR con CloudWatch](UsingEMR_ViewingMetrics.md).
### Retocar la configuración mediante yarn-site
Las opciones mostradas a continuación se pueden ajustar de acuerdo con los requisitos de la aplicación. Por ejemplo, es posible que desee aumentar el umbral de utilización del disco si un nodo adopta el estado `UNHEALTHY` aumentando el valor de `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage`.
Puede establecer estos valores al crear un clúster mediante la clasificación de configuración `yarn-site`. Para obtener más información, consulte [Configuración de aplicaciones](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) en la *Guía de publicación de Amazon EMR*. También puede conectarse mediante SSH a las instancias de Amazon EC2 asociadas con los nodos principales y, a continuación, agregar los valores de `/etc/hadoop/conf.empty/yarn-site.xml` con un editor de texto. Tras realizar el cambio, debe reiniciar hadoop-yarn-nodemanager tal y como se muestra a continuación.
**importante**
Al reiniciar el NodeManager servicio, los contenedores YARN activos se eliminan a menos que `yarn.nodemanager.recovery.enabled` estén configurados para `true` usar la clasificación de `yarn-site` configuración al crear el clúster. Asimismo, debe especificar el directorio en el que se va a almacenar el estado del contenedor mediante la propiedad `yarn.nodemanager.recovery.dir`.
```
sudo /sbin/stop hadoop-yarn-nodemanager
sudo /sbin/start hadoop-yarn-nodemanager
```
Para obtener más información sobre las propiedades `yarn-site` actuales y sus valores predeterminados, consulte página relacionada con la [configuración predeterminada de YARN](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml) en la documentación de Apache Hadoop.
| Propiedad | Predeterminado | Description (Descripción) |
| --- | --- | --- |
| yarn.nodemanager. disk-health-checker.interval-ms | 120 000 | La frecuencia (en segundos) con la que se ejecuta el comprobador de estado del disco. |
| yarn.nodemanager. disk-health-checker. min-healthy-disks | 0,25 | La fracción mínima de la cantidad de discos que deben estar en buen estado NodeManager para lanzar nuevos contenedores. Esto se corresponde con yarn.nodemanager.local-dirs (de forma predeterminada, `/mnt/yarn` en Amazon EMR) y yarn.nodemanager.log-dirs (de forma predeterminada, `/var/log/hadoop-yarn/containers`, que está vinculado mediante symlinks a `mnt/var/log/hadoop-yarn/containers` en Amazon EMR). |
| `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` | 90,0 | El porcentaje máximo de utilización del espacio en disco permitido después del cual un disco se marca como dañado. Los valores están comprendidos entre 0,0 y 100,0. Si el valor es mayor o igual a 100, NodeManager comprueba si el disco está lleno. Esto se aplica a `yarn-nodemanager.local-dirs` y `yarn.nodemanager.log-dirs`. |
| `yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb` | 0 | El espacio mínimo que debe estar disponible en un disco para que se pueda utilizar. Esto se aplica a `yarn-nodemanager.local-dirs` y `yarn.nodemanager.log-dirs`. |
# Error de clúster de Amazon EMR: “No se puede replicar el bloque, solo se pudo replicar a cero nodos”.
El error “No se puede replicar el bloque, solo se pudo replicar a cero nodos”. suele ocurrir cuando un clúster no tiene suficiente espacio de almacenamiento de HDFS. Este error se produce cuando se generan más datos en el clúster de los que pueden almacenarse en HDFS. Ve este error solo mientras se está ejecutando el clúster, porque cuando el trabajo termina se libera el espacio de HDFS que se estaba utilizando.
La cantidad de espacio de HDFS disponible para un clúster depende del número y del tipo de instancias de Amazon EC2 que se utilizan como nodos principales. Los nodos de tarea no se utilizan para almacenamiento de HDFS. Todo el espacio en disco en cada instancia de Amazon EC2, incluidos los volúmenes de almacenamiento de EBS adjuntos, está disponible para HDFS. Para obtener más información sobre la cantidad de almacenamiento local para cada tipo de instancia de EC2, consulte [Familias y tipos de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) en la *Guía del usuario de Amazon EC2*.
El otro factor que puede influir en la cantidad de espacio de HDFS disponible es el factor de replicación, que es el número de copias de cada bloque de datos que se almacena en HDFS para redundancia. El factor de replicación aumenta con el número de nodos del clúster: existen tres copias de cada bloque de datos para un clúster con 10 o más nodos, 2 copias de cada bloque por un clúster con 4 a 9 nodos y 1 copia (sin redundancia) para clústeres con 3 o menos nodos. El espacio de HDFS total disponible se divide por el factor de replicación. En algunos casos, como, por ejemplo, aumentando el número de nodos de 9 a 10, el aumento del factor de replicación pueden en realidad hacer que la cantidad de espacio de HDFS disponible se reduzca.
Por ejemplo, un clúster con diez nodos secundarios de tipo m1.large tendría 2 833 GB de espacio disponible para HDFS ((10 nodos X 850 GB por nodo)/factor de replicación de 3).
Si el clúster supera la cantidad de espacio disponible para HDFS, puede añadir más nodos secundarios a su clúster o utilizar la compresión de datos para crear más espacio de HDFS. Si el clúster se puede detener y reiniciar, podría plantearse el uso de nodos principales de un tipo de instancia de Amazon EC2 mayor. También puede plantearse la posibilidad de ajustar el factor de replicación. Tenga en cuenta que la disminución del factor de replicación reduce la redundancia de datos de HDFS y la capacidad de su clúster recuperarse frente a bloques de HDFS perdidos o dañados.
# Error de clúster de Amazon EMR: SE HA SUPERADO LA CUOTA DE EC2
Si recibe un mensaje `EC2 QUOTA EXCEEDED`, se puede deber a varias causas. En función de las diferencias de configuración, los clústeres anteriores pueden tardar entre 5 y 20 minutos en terminar y liberar los recursos asignados. Si aparece un error `EC2 QUOTA EXCEEDED` al intentar lanzar un clúster, puede deberse a que aún no se hayan liberado los recursos de un clúster terminado recientemente. Este mensaje también puede deberse al cambio de tamaño de un grupo o flota de instancias a un tamaño de destino mayor que la cuota de instancias actual para la cuenta. Esto puede ocurrir de forma manual o automática a través de escalado automático.
Tenga en cuenta las opciones siguientes para resolver el problema:
+ Siga las instrucciones de [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) en *Referencia general de Amazon Web Services* para solicitar un aumento del límite de servicio. Para algunos APIs, configurar un CloudWatch evento puede ser una mejor opción que aumentar los límites. Para obtener más información, consulte [Cuándo configurar los eventos de EMR en CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Si uno o varios clústeres en ejecución no se ejecutan según la capacidad, cambie de tamaño los grupos de instancia o reduzca las capacidades de destino en flotas de instancia para clústeres en ejecución.
+ Cree clústeres con menos instancias de EC2 o una capacidad de destino reducida.
# Error de clúster de Amazon EMR: “Demasiados errores de búsqueda”
La presencia de mensajes de error **Too many fetch-failures (Demasiados errores de recuperación)** o **Error reading task output (Error al leer la salida de la tarea)** en los registros de intentos de tareas o de pasos indican que la tarea en ejecución depende de la salida de otra tarea. Esto suele ocurrir cuando una tarea de reducción se pone en cola para ejecutarse y requiere la salida de una o más tareas de asignación y la salida no está disponible aún.
Hay varias razones por las que la salida podría no estar disponible:
+ La tarea requisito previo aún se está procesando. Suele ser una tarea de asignación.
+ Los datos podrían no estar disponibles debido a una mala conectividad de red si los datos se encuentran en otra instancia.
+ Si HDFS se utiliza para recuperar la salida, es posible que exista un problema con HDFS.
La causa más frecuente de este error es que la tarea anterior sigue en procesamiento. Esto es especialmente probable si los errores se producen cuando las tareas de reducción son las primeras que se intentan ejecutar. Puede comprobar si este es el caso revisando el registro syslog para el paso de clúster que devuelve el error. Si el syslog muestra las tareas de asignación y reducción progresando, esto indica que la fase de reducción ha comenzado mientras hay tareas de asignación que no se han completado aún.
Una cosa que hay que buscar en los registros es un porcentaje de progreso de asignación que pasa al 100% y, a continuación, disminuye hasta un valor inferior. Cuando el porcentaje de asignación está al 100%, eso no significa que todas las tareas de asignación se han completado. Simplemente significa que Hadoop está ejecutando todas las tareas de asignación. Si este valor vuelve a disminuir por debajo del 100%, significa que una tarea de asignación ha devuelto un error y, en función de la configuración, Hadoop podría intentar volver a programar la tarea. Si el porcentaje del mapa se mantiene en el 100% de los registros, observe específicamente `RunningMapTasks` las CloudWatch métricas para comprobar si la tarea del mapa aún se está procesando. También puede encontrar esta información a través de la interfaz web de Hadoop en el nodo principal.
Si está viendo este problema, hay varias cosas que puede probar:
+ Indique a la fase de reducción que espere más tiempo antes de empezar. Puede hacerlo modificando el ajuste de configuración de Hadoop mapred.reduce.slowstart.completed.maps a un tiempo superior. Para obtener más información, consulte [Creación de acciones de arranque para instalar software adicional con un clúster de Amazon EMR](emr-plan-bootstrap.md).
+ Asigne el recuento de reductores a la capacidad de reductor total del clúster. Esto se hace ajustando la opción de configuración de Hadoop mapred.reduce.tasks para el trabajo.
+ Utilice un código de clase de combinador para minimizar el número de salidas que se tienen que recuperar.
+ Compruebe que no haya ningún problema con el servicio de Amazon EC2 que esté afectando al rendimiento de red del clúster. Puede hacerlo utilizando el [Panel de estado del servicio](https://status.aws.amazon.com/).
+ Revise los recursos de CPU y de memoria de las instancias en su clúster para asegurarse de que su procesamiento de datos no esté desbordando los recursos de los nodos. Para obtener más información, consulte [Configuración del hardware y las redes de los clústeres de Amazon EMR](emr-plan-instances.md).
+ Compruebe la versión de la imagen de máquina de Amazon (AMI) utilizada en el clúster de Amazon EMR. Si la versión es de la 2.3.0 a la 2.4.4 incluida, actualice a una versión posterior. Las versiones de AMI en el rango especificado utilizan una versión de Jetty que podría fallar a la hora de entregar la salida desde la fase de asignación. El error de recuperación se produce cuando los reductores no pueden obtener la salida desde la fase de asignación.
Jetty es un servidor HTTP de código abierto que se utiliza para comunicaciones de equipo a equipo dentro de un clúster de Hadoop.
# Error de clúster de Amazon EMR: “El archivo solo pudo ser replicado a 0 nodos en lugar de 1”
Cuando un archivo se escribe en HDFS, se replica a varios nodos secundarios. Si aparece este error, significa que el NameNode daemon no tiene ninguna DataNode instancia disponible en la que escribir datos en HDFS. En otras palabras, la replicación de bloques no se está produciendo. Este error puede deberse a una serie de problemas:
+ El sistema de archivos HDFS podría haberse quedado sin espacio. Esta es la causa más probable.
+ DataNode es posible que las instancias no estuvieran disponibles cuando se ejecutó el trabajo.
+ DataNode Es posible que se haya bloqueado la comunicación de las instancias con el nodo maestro.
+ Las instancias del grupo de instancias secundarias podrían no estar disponibles.
+ Es posible que falten permisos. Por ejemplo, es posible que el JobTracker daemon no tenga permisos para crear información sobre el registro de tareas.
+ La configuración de espacio reservado para una DataNode instancia puede ser insuficiente. Compruebe si este es el caso comprobando la opción de configuración dfs.datanode.du.reserved.
Para comprobar si este problema se debe a que el HDFS se está quedando sin espacio en disco, consulte la `HDFSUtilization` métrica que aparece en CloudWatch. Si este valor es demasiado alto, puede añadir nodos secundarios adicionales en el clúster. Si tiene un clúster y cree que podría quedarse sin espacio en el disco HDFS, puede configurar una alarma CloudWatch para que le avise cuando el valor de supere `HDFSUtilization` un nivel determinado. Para obtener más información, consulte [Cambio manual del tamaño de un clúster de Amazon EMR en ejecución](emr-manage-resize.md) y [Supervisión de las métricas de Amazon EMR con CloudWatch](UsingEMR_ViewingMetrics.md).
Si el problema no es que el HDFS se quede sin espacio, compruebe los registros, los DataNode NameNode registros y la conectividad de la red para ver si hay otros problemas que pudieran haber impedido que el HDFS replicara los datos. Para obtener más información, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
# Error de clúster de Amazon EMR: “Nodos en la lista de denegación”
El NodeManager daemon es responsable de lanzar y gestionar los contenedores en los nodos principales y de tareas. El NodeManager daemon que se ejecuta en el nodo maestro asigna los contenedores al ResourceManager daemon. ResourceManager Supervisa el NodeManager nodo en un abrir y cerrar de ojos.
Hay un par de situaciones en las que el ResourceManager daemon deniega la lista a NodeManager y la elimina del grupo de nodos disponibles para procesar tareas:
+ Si no NodeManager ha enviado ni un latido al ResourceManager daemon en los últimos 10 minutos (600.000 milisegundos). Este periodo de tiempo puede configurarse mediante la opción de configuración `yarn.nm.liveness-monitor.expiry-interval-ms`. Para obtener más información sobre cómo cambiar la configuración de Yarn, consulte [Configuración de aplicaciones](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) en la *Guía de publicación de Amazon EMR*.
+ NodeManager comprueba el estado de los discos determinado por `yarn.nodemanager.local-dirs` y. `yarn.nodemanager.log-dirs` Las comprobaciones incluyen permisos y espacio libre en disco (< 90 %). Si un disco no supera la comprobación, NodeManager deja de utilizar ese disco en particular, pero sigue indicando que el estado del nodo es correcto. Si varios discos no pasan la comprobación, el nodo se considera en mal estado ResourceManager y no se asignan nuevos contenedores al nodo.
El maestro de la aplicación también puede denegar la inclusión de un NodeManager nodo en la lista si tiene más de tres tareas fallidas. Puede cambiar esto a un valor superior utilizando el parámetro de configuración `mapreduce.job.maxtaskfailures.per.tracker`. Otras opciones de configuración que podría cambiar controlan cuántas veces se intenta una tarea antes de marcarla como errónea: `mapreduce.map.max.attempts` para tareas de asignación y `mapreduce.reduce.maxattempts` para tareas de reducción. Para obtener más información sobre cómo cambiar la configuración, consulte [Configuración de aplicaciones](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) en la *Guía de publicación de Amazon EMR*.
# Limitación de errores con un clúster de Amazon EMR
Los errores «Limitado desde *Amazon EC2* al lanzar el clúster» y «No se pudieron aprovisionar las instancias debido a la limitación desde» *Amazon EC2* se producen cuando Amazon EMR no puede completar una solicitud porque otro servicio ha limitado la actividad. Amazon EC2 es el origen más habitual de errores de limitación, pero otros servicios pueden ser la causa de estos errores. Los [límites de servicio de AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) se aplican por región para mejorar el rendimiento, y un error de limitación indica que ha superado el límite de servicio de su cuenta en esa región.
## Causas posibles
El origen más habitual de errores de limitación de Amazon EC2 es que se está lanzando un gran número de instancias de clúster, de modo que se supera el límite de servicio de instancias de EC2. Las instancias de clúster pueden lanzarse por las siguientes razones:
+ Se han creado nuevos clústeres.
+ Se ha cambiado manualmente el tamaño de los clústeres. Para obtener más información, consulte [Cambio manual del tamaño de un clúster de Amazon EMR en ejecución](emr-manage-resize.md).
+ Los grupos de instancias en un clúster añaden instancias (escalado) como resultado de una regla de escalado automático. Para obtener más información, consulte [Descripción de las reglas de escalado automático](emr-automatic-scaling.md#emr-scaling-rules).
+ Las flotas de instancia de un clúster añaden instancias para satisfacer una mayor capacidad de destino. Para obtener más información, consulte [Planificación y configuración de flotas de instancias para su clúster de Amazon EMR](emr-instance-fleet.md).
También es posible que la frecuencia o el tipo de solicitud de API hecha a Amazon EC2 provoque errores de limitación. Para obtener más información sobre cómo limita Amazon EC2 las solicitudes de API, consulte [Tasa de solicitudes de la API de consulta](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate) en la *Referencia de la API de Amazon EC2*.
## Soluciones
Tenga en cuenta las soluciones siguientes:
+ Siga las instrucciones de [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) en *Referencia general de Amazon Web Services* para solicitar un aumento del límite de servicio. Para algunos APIs, organizar un CloudWatch evento puede ser una mejor opción que aumentar los límites. Para obtener más información, consulte [Cuándo configurar los eventos de EMR en CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Si tiene clústeres que se lanzan según una misma programación (por ejemplo, al final de una hora), considere la posibilidad de escalonar las horas de inicio.
+ Si tiene clústeres que están dimensionados para picos de demanda y periódicamente tiene problemas de capacidad de la instancia, considere la posibilidad de especificar el escalado automático para añadir y eliminar instancias bajo demanda. De esta forma, las instancias se utilizan de manera más eficiente y, en función del perfil de la demanda, es posible que se soliciten menos instancias en un momento dado en una cuenta. Para obtener más información, consulte [Uso del escalado automático con una política personalizada para grupos de instancias en Amazon EMR](emr-automatic-scaling.md).
# Error de clúster de Amazon EMR: “No se admite el tipo de instancia”
Si creas un clúster y se produce un error con el mensaje de error «El tipo de instancia solicitado no *InstanceType* es compatible con la zona de disponibilidad solicitada», significa que has creado el clúster y especificado un tipo de instancia para uno o más grupos de instancias que no es compatible con Amazon EMR en la región y la zona de disponibilidad en las que se creó el clúster. Amazon EMR puede admitir un tipo de instancia en una zona de disponibilidad de una región y no en otra. La subred que seleccione para un clúster determina la zona de disponibilidad dentro de la región.
## Solución
**Determine los tipos de instancias disponibles en una zona de disponibilidad mediante el AWS CLI**
+ Utilice el comando `ec2 run-instances` con la opción `--dry-run`. En el ejemplo siguiente, *m5.xlarge* sustitúyalo por el tipo de instancia que quieres usar, *ami-035be7bafff33b6b6* por la AMI asociada a ese tipo de instancia y *subnet-12ab3c45* por una subred en la zona de disponibilidad que deseas consultar.
```
aws ec2 run-instances --instance-type m5.xlarge --dry-run --image-id ami-035be7bafff33b6b6 --subnet-id subnet-12ab3c45
```
Para obtener instrucciones sobre cómo encontrar un ID de AMI, consulte [Buscar una AMI de Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html). Para encontrar un ID de subred, puede usar el comando [describe-subnets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-subnets.html).
Para obtener más información sobre cómo descubrir los tipos de instancia disponibles, consulte [Buscar un tipo de instancia de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html).
Después de determinar los tipos de instancia disponibles, puede hacer lo siguiente:
+ Cree el clúster en la misma región y subred EC2 y elija un tipo de instancia diferente con capacidades similares a la elección inicial. Para ver una lista de los tipos de instancia admitidos, consulte [Tipos de instancias admitidas con Amazon EMR](emr-supported-instance-types.md). Para comparar las capacidades de los tipos de instancia de EC2, consulte [Tipos de instancia de Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
+ Elija una subred para el clúster en una zona de disponibilidad en la que el tipo de instancia esté disponible y sea compatible con Amazon EMR.
**Mitigue los errores de lanzamiento del clúster de la flota de instancias debido a tipos de instancias principales no compatibles en Amazon EMR**
Los nodos principales son esenciales en los clústeres de Amazon EMR. Es posible que se produzca un error de `instance type not supported` en el lanzamiento de un clúster en el que Amazon EMR intente lanzar el clúster en una zona de disponibilidad si el tipo de instancia principal no es compatible. La selección mejorada de zonas de disponibilidad, por ejemplo, los clústeres de flota en Amazon EMR, filtra automáticamente los tipos de instancias principales que especificó en la AZs configuración del clúster y descarta automáticamente los tipos de instancias principales que especificó. Esto significa que Amazon EMR no elegirá una zona de disponibilidad en la que no se admitan los tipos de instancias principales configurados, lo que evita que se produzcan errores en el lanzamiento del clúster debido a tipos de instancias no compatibles.
Para permitir esta mejora, añada el permiso necesario a la política o al rol de servicio de su clúster. La versión más reciente de `AmazonEMRServicePolicy_v2` incluye este permiso, por lo que si utiliza esa política, la mejora ya está disponible. Si utiliza una política o un rol de servicio personalizados, agregue el permiso `ec2:DescribeInstanceTypeOfferings` al lanzar su clúster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstanceTypeOfferings"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowEC2Describeinstancetypeofferings"
}
]
}
```
------
# Error de clúster de Amazon EMR: “EC2 no tiene capacidad”
Un *EC2 no tiene capacidad suficiente* o se produce un *InstanceType* error al intentar crear un clúster o añadir instancias a un clúster en una zona de disponibilidad que ya no tiene el tipo de instancia EC2 especificado. La subred que seleccione para un clúster determina la zona de disponibilidad.
Para crear un clúster, realice alguna de las siguientes operaciones:
+ Especificar un tipo de instancia diferente con capacidades similares
+ Crear el clúster en una región diferente
+ Seleccione una subred en una zona de disponibilidad en la que pueda estar disponible el tipo de instancia que desee.
Para agregar instancias en un clúster en ejecución, haga una de estas acciones:
+ Modifique las configuraciones de grupo de instancias o las configuraciones de flota de instancias para agregar tipos de instancia disponibles con capacidades similares. Para ver una lista de los tipos de instancia admitidos, consulte [Tipos de instancias admitidas con Amazon EMR](emr-supported-instance-types.md). Para comparar las capacidades de los tipos de instancia de EC2, consulte [Tipos de instancia de Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
+ Termine el clúster y vuelva a crearlo en una región y zona de disponibilidad en la que el tipo de instancia esté disponible.
# Error de clúster de Amazon EMR: “Error del factor de replicación de HDFS”
Al eliminar un nodo básico de un [grupo de instancias](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-uniform-instance-group.html) principal o de una [flota de instancias](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html), Amazon EMR podría sufrir un error de replicación de HDFS. Este error se produce cuando se eliminan los nodos básicos y el número de nodos básicos es inferior al [factor dfs.replication](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html) configurado para el Sistema de archivos distribuido de Hadoop (HDFS). Por lo tanto, Amazon EMR no puede realizar la operación de forma segura. Para determinar el valor predeterminado de la configuración `dfs.replication`, utilice la [Configuración HDFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html).
## Causas posibles
Consulte lo siguiente para conocer las posibles causas del error del factor de replicación de HDFS:
+ Si [cambia manualmente el tamaño](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-resize.html) de un grupo de instancias principal o una flota de instancias por debajo del factor configurado `dfs.replication`.
+ Sus políticas de [escalado administrado](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) o de [escalado automático](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html) pueden permitir el escalado para reducir la cantidad de nodos básicos por debajo del umbral de `dfs.replication`.
+ Este error también puede producirse si Amazon EMR intenta [reemplazar](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html) un nodo básico en mal estado cuando un clúster tiene el número mínimo de nodos básicos definido por []().
## Soluciones y prácticas recomendadas
Consulte lo siguiente para obtener soluciones y prácticas recomendadas:
+ Cuando cambie manualmente el tamaño de un clúster de Amazon EMR, no lo reduzca verticalmente por debajo de `dfs.replication` ya que Amazon EMR no puede completar el cambio de tamaño de forma segura.
+ Cuando utilice el escalado administrado o el escalado automático, asegúrese de que la capacidad mínima del clúster no sea inferior al factor `dfs.replication`.
+ El número de instancias principales debe ser como mínimo `dfs.replication` más una. Esto garantiza que Amazon EMR pueda reemplazar correctamente un nodo básico en mal estado si habilitó el reemplazo de núcleo en mal estado.
**importante**
El fallo de un solo nodo básico puede provocar la pérdida de datos del HDFS si usted establece `dfs.replication` en 1. Si su clúster tiene almacenamiento HDFS, le recomendamos que lo configure con al menos cuatro nodos básicos para las cargas de trabajo de producción con el objetivo de evitar la pérdida de datos y, también, establecer el factor `dfs.replication` de al menos 2.
# Error de clúster de Amazon EMR: “Error de espacio insuficiente en HDFS”
Si intenta eliminar un nodo básico, puede producirse un error de espacio insuficiente en el Sistema de archivos distribuido de Hadoop (HDFS), pero Amazon EMR no puede completar la operación de forma segura debido a que no queda suficiente espacio en el HDFS. Antes de que Amazon EMR elimine un nodo básico, todos los datos de HDFS del nodo deben transferirse a otros nodos básicos para garantizar la redundancia de los datos. Sin embargo, si no hay suficiente espacio en los otros nodos básicos para la replicación, Amazon EMR no puede realizar una desactivación rápida del nodo.
## Causas posibles
Consulte lo siguiente para ver una lista de las posibles causas del error de espacio insuficiente en HDFS:
+ Si reduce vertical y manualmente un grupo de instancias básico o una flota de instancias cuando no hay suficiente espacio en HDFS en los nodos restantes para replicar los datos antes de la reducción de escala.
+ El escalado administrado o el escalado automático reduce verticalmente un grupo de instancias principal o una flota de instancias cuando no hay suficiente espacio en HDFS para la replicación de datos.
+ Amazon EMR intenta reemplazar un nodo principal en mal estado, pero no puede reemplazar el nodo de forma segura debido a la falta de espacio en HDFS.
## Soluciones y prácticas recomendadas
Consulte lo siguiente para obtener soluciones y prácticas recomendadas:
+ Escale verticalmente la cantidad de nodos básicos de su clúster de Amazon EMR. Si utiliza el escalado administrado o el escalado automático, aumente la capacidad mínima de sus nodos básicos.
+ Utilice volúmenes de EBS más grandes para sus nodos básicos al crear su clúster de EMR.
+ Elimine los datos HDFS innecesarios del clúster de EMR. Le recomendamos que configure CloudWatch alarmas para monitorear la `HDFSUtilization` métrica de su clúster para saber si su clúster de EMR tiene poco espacio.
# Errores de entrada y salida de clúster durante la operaciones de Amazon EMR
Los errores siguientes son habituales en las operaciones de entrada y salida de clúster. Utilice las instrucciones de este tema para solucionar problemas y comprobar su configuración.
**Topics**
+ [¿La ruta hacia Amazon Simple Storage Service (Amazon S3) tiene por lo menos tres barras?](#threeslashes)
+ [¿Está intentando atravesar de forma recursiva directorios de entrada?](#recurseinput)
+ [¿Ya existe el directorio de salida?](#directoryexist)
+ [¿Está intentando especificar un recurso mediante una URL HTTP?](#httpurl)
+ [¿Está haciendo referencia a un bucket de Amazon S3; con un formato de nombre no válido?](#validdnsname)
+ [¿Tiene problemas para cargar datos hacia o desde Amazon S3?](#emr-troubleshoot-errors-io-1)
## ¿La ruta hacia Amazon Simple Storage Service (Amazon S3) tiene por lo menos tres barras?
Cuando especifique un bucket de Amazon S3, deberá incluir una barra de terminación al final de la URL. Por ejemplo, en lugar de hacer referencia a un bucket como “s3n://amzn-s3-demo-bucket1”, debería utilizar “s3n://amzn-s3-demo-bucket1/”; de lo contrario, Hadoop genera un error en el clúster en la mayoría de los casos.
## ¿Está intentando atravesar de forma recursiva directorios de entrada?
Hadoop no busca directorios de entrada de forma recursiva para archivos. Si tiene una estructura de directorios como /corpus/01/01.txt, /corpus/01/02.txt, /corpus/02/01.txt, etc. y especifica /corpus/ como parámetro de entrada para el clúster, Hadoop no encuentra los archivos de entrada, ya que el directorio /corpus/ está vacío y Hadoop no comprueba el contenido de los subdirectorios. Del mismo modo, Hadoop no comprueba recursivamente los subdirectorios de buckets de Amazon S3.
Los archivos de entrada deben estar directamente en el directorio de entrada o bucket de Amazon S3 que especifique, no en subdirectorios.
## ¿Ya existe el directorio de salida?
Si especifica una ruta de salida que ya existe, Hadoop generará un error en el clúster en la mayoría de los casos. Esto significa que si ejecuta un clúster una vez y, a continuación, lo vuelve a ejecutar con los mismos parámetros, probablemente funcionará la primera vez y, a continuación, nunca más; después de la primera ejecución, existe la ruta de salida y, por lo tanto, hace que todas las ejecuciones sucesivas generen un error.
## ¿Está intentando especificar un recurso mediante una URL HTTP?
Hadoop no acepta las ubicaciones de los recursos especificados mediante el prefijo http://. No puede hacer referencia a un recurso con una dirección URL HTTP. Por ejemplo, transferir http://mysite/myjar.jar como parámetro JAR provoca que el clúster devuelva un error.
## ¿Está haciendo referencia a un bucket de Amazon S3; con un formato de nombre no válido?
Si intenta utilizar un nombre de bucket como “amzn-s3-demo-bucket1.1” con Amazon EMR, el clúster devolverá un error porque Amazon EMR requiere que los nombres de bucket sean nombres de host RFC 2396 válidos; el nombre no puede terminar por un número. Además, debido a los requisitos de Hadoop, los nombres de bucket de Amazon S3 que se utilizan con Amazon EMR solo puede contener letras en minúsculas, números, puntos (.) y guiones (-). Para obtener más información acerca de las convenciones de nomenclatura de buckets de Amazon S3, consulte [Restricciones y limitaciones de los buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/index.html?BucketRestrictions.html) en la *Guía del usuario de Amazon Simple Storage Service*.
## ¿Tiene problemas para cargar datos hacia o desde Amazon S3?
Amazon S3 es el origen de entrada y salida más popular para Amazon EMR. Un error común consiste en tratar Amazon S3 como si fuera un sistema de archivos habitual. Existen diferencias entre Amazon S3 y un sistema de archivos que debe tener en cuenta a la hora de ejecutar el clúster.
+ Si se produce un error interno en Amazon S3, la aplicación tiene que gestionarlo correctamente y volver a intentar la operación.
+ Si las llamadas a Amazon S3 tardan demasiado tiempo en devolverse, es posible que la aplicación tenga que reducir la frecuencia con la que llama a Amazon S3.
+ Enumerar todos los objetos en un bucket de Amazon S3 es una llamada costosa. La aplicación debe minimizar el número de veces que lo hace.
Existen varias formas de mejorar la forma en la que el clúster interactúa con Amazon S3.
+ Inicie el clúster con la versión de lanzamiento más reciente de Amazon EMR.
+ Utilice S3 DistCp para mover objetos dentro y fuera de Amazon S3. S3 DistCp implementa la gestión de errores, los reintentos y los retrasos para cumplir con los requisitos de Amazon S3. Para obtener más información, consulte Copia [distribuida](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/UsingEMR_s3distcp.html) mediante S3. DistCp
+ Diseñe la aplicación teniendo en cuenta la consistencia final. Utilice HDFS para el almacenamiento de datos intermedios mientras que el clúster se está ejecutando y Amazon S3 únicamente para entrada de los datos iniciales y salida de los resultados finales.
+ Si los clústeres confirmarán 200 o más transacciones por segundo en Amazon S3, [contacte con la asistencia técnica](https://aws.amazon.com/contact-us/) para preparar el bucket para que haga más transacciones por segundo y plantéese el uso de las estrategias de partición de claves que se describen en [Consejos y trucos de rendimiento de Amazon S3](https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-tricks-seattle-hiring-event/).
+ Defina el ajuste de configuración de Hadoop io.file.buffer.size en 65 536. Esto hace que Hadoop dedique menos tiempo a buscar a través de objetos de Amazon S3.
+ Plantéese deshabilitar la característica de ejecución especulativa de Hadoop si su clúster experimenta problemas de simultaneidad de Amazon S3. Esto también resulta útil cuando se solucionan problemas de un clúster lento. Para ello, establezca las propiedades `mapreduce.reduce.speculative` `mapreduce.map.speculative` y en `false`. Cuando lance un clúster, podrá establecer estos valores mediante la clasificación de configuración `mapred-env`. Para obtener más información, consulte [Configuración de aplicaciones](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) en la *Guía de publicación de Amazon EMR*.
+ Si ejecuta un clúster de Hive, consulte [¿Tiene problemas para cargar datos hacia o desde Amazon S3 en Hive?](emr-troubleshoot-error-hive.md#emr-troubleshoot-error-hive-3).
Para obtener información adicional, consulte [Prácticas recomendadas de errores de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html) en la *Guía del usuario de Amazon Simple Storage Service*.
# Errores de permisos durante las operaciones del clúster de Amazon EMR
Los siguientes errores son comunes cuando se utilizan permisos o credenciales.
**Topics**
+ [¿Está transfiriendo las credenciales correctas en SSH?](#correctcred)
+ [Si está utilizando IAM, ¿tiene definido el conjunto de políticas de Amazon EC2 correcto?](#check-iam-permissions)
## ¿Está transfiriendo las credenciales correctas en SSH?
Si no puede utilizar SSH para conectarse al nodo principal, se trata muy probablemente de un problema con sus credenciales de seguridad.
En primer lugar, compruebe que el archivo .pem que contiene su clave SSH disponga de los permisos adecuados. Puede utilizar chmod para cambiar los permisos de su archivo .pem tal y como se muestra en el siguiente ejemplo, donde debería sustituir mykey.pem por el nombre de su propio archivo .pem.
```
1. chmod og-rwx mykey.pem
```
La segunda posibilidad es que no se esté utilizando el par de claves que especificó al crear el clúster. Esto es fácil de hacer si ha creado varios pares de claves. Consulte los detalles del clúster en la consola de Amazon EMR (o utilice la opción `--describe` de la CLI) para el nombre del par de claves que se especificó cuando se creó el clúster.
Una vez que haya verificado que está utilizando el par de claves correcto y que los permisos se han definido correctamente en el archivo .pem, puede utilizar el siguiente comando para utilizar SSH para conectarse al nodo maestro, donde debería sustituir mykey.pem por el nombre de su archivo .pem y `hadoop@ec2-01-001-001-1.compute-1.amazonaws.com` por el nombre de DNS público del nodo principal (disponible a través de la opción `--describe` en la CLI o a través de la consola de Amazon EMR).
**importante**
Debe utilizar el nombre de inicio de sesión `hadoop` cuando se conecte a un nodo de clúster de Amazon EMR; de lo contrario, es posible que se produzca un error similar a `Server refused our key`.
```
1. ssh -i mykey.pem hadoop@ec2-01-001-001-1.compute-1.amazonaws.com
```
Para obtener más información, consulte [Conexión al nodo principal del clúster de Amazon EMR mediante SSH](emr-connect-master-node-ssh.md).
## Si está utilizando IAM, ¿tiene definido el conjunto de políticas de Amazon EC2 correcto?
Dado que Amazon EMR utiliza instancias de EC2 como nodos, los usuarios de Amazon EMR también deben tener definidas determinadas políticas de Amazon EC2 para que Amazon EMR pueda administrar dichas instancias en nombre del usuario. Si no tiene definidos los permisos necesarios, Amazon EMR devuelve el error: **“La cuenta no tiene autorización para llamar a EC2”.**
Para obtener más información sobre las políticas de Amazon EC2 que la cuenta de IAM tiene que definir para ejecutar Amazon EMR, consulte [Cómo funciona Amazon EMR con IAM](security_iam_service-with-iam.md).
# Errores de clúster de Hive
Normalmente, puede encontrar la causa de un error de Hive en el archivo `syslog`, para el que tiene un enlace en el panel **Steps (Pasos)**. Si no puede determinar el problema allí, consulte el mensaje de error de intento de tareas de Hadoop. Encontrará un enlace al mismo en el panel **Task Attempts (Intentos de tareas)**.
Los siguientes errores son comunes en los clústeres de Hive.
**Topics**
+ [¿Está utilizando la última versión de Hive?](#emr-troubleshoot-error-hive-0)
+ [¿Ha detectado un error de sintaxis en el script de Hive?](#emr-troubleshoot-error-hive-1)
+ [¿Ha devuelto error un trabajo al ejecutarlo de forma interactiva?](#emr-troubleshoot-error-hive-2)
+ [¿Tiene problemas para cargar datos hacia o desde Amazon S3 en Hive?](#emr-troubleshoot-error-hive-3)
## ¿Está utilizando la última versión de Hive?
La última versión de Hive presenta todas las revisiones actuales y correcciones de errores y podría resolver el problema.
## ¿Ha detectado un error de sintaxis en el script de Hive?
Si un paso devuelve un error, examine el archivo `stdout` de los registros para el paso que se ejecutó en el script de Hive. Si el error no se encuentra allí, examine el archivo `syslog` de los registros del intento de tarea que ha devuelto error. Para obtener más información, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
## ¿Ha devuelto error un trabajo al ejecutarlo de forma interactiva?
Si ejecuta Hive de forma interactiva en el nodo principal y el clúster ha fallado, vea las entradas `syslog` en el registro de intento de tarea para el intento de tarea fallido. Para obtener más información, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
## ¿Tiene problemas para cargar datos hacia o desde Amazon S3 en Hive?
Si tiene problemas para tener acceso a los datos en Amazon S3, compruebe antes las causas posibles incluidas en [¿Tiene problemas para cargar datos hacia o desde Amazon S3?](emr-troubleshoot-errors-io.md#emr-troubleshoot-errors-io-1). Si ninguno de estos problemas es la causa, tenga en cuenta las siguientes opciones específicas de Hive.
+ Asegúrese de utilizar la última versión de Hive que presenta todas las revisiones actuales y correcciones de errores que podría resolver el problema. Para obtener más información, consulte [Apache Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive.html).
+ El uso de `INSERT OVERWRITE` requiere mostrar el contenido del bucket o carpeta de Amazon S3. Se trata de una operación costosa. Si es posible, elimine manualmente la ruta en lugar de que Hive enumere y elimine los objetos existentes.
+ Si utiliza versiones de Amazon EMR anteriores a la 5.0, puede utilizar el comando siguiente de HiveQL para guardar previamente en caché los resultados de una operación de listado de Amazon S3 localmente en el clúster:
```
set hive.optimize.s3.query=true;
```
+ Utilice las particiones estáticas donde sea posible.
+ En algunas versiones de Hive y Amazon EMR, es posible que el uso de ALTER TABLES devuelva un error debido a que la tabla se almacena en una ubicación distinta a la esperada por Hive. La solución consiste en añadir o actualizar lo siguiente en `/home/hadoop/conf/core-site.xml`:
```
fs.s3n.endpoint
s3.amazonaws.com
```
# Errores de la VPC durante las operaciones del clúster de Amazon EMR
Los siguientes errores son comunes a la configuración de VPC en Amazon EMR.
**Topics**
+ [Configuración de subredes no válida](#emr-troubleshoot-error-gateway)
+ [Falta el conjunto de opciones de DHCP](#emr-troubleshoot-error-dhcp)
+ [Errores de permisos](#emr-troubleshoot-error-denied)
+ [Errores que dan lugar a `START_FAILED`](#emr-troubleshoot-error-vpc-dns)
+ [Se agrupa y no se puede iniciar `Terminated with errors` NameNode](#emr-troubleshoot-namenode-dns)
## Configuración de subredes no válida
En la página **Cluster Details (Detalles del clúster)**, en el campo **Status (Estado)**, ve un error similar al siguiente:
`The subnet configuration was invalid: Cannot find route to InternetGateway in main RouteTable rtb-id for vpc vpc-id.`
Para solucionar este problema, debe crear una gateway de Internet y asociarla a la VPC. Para obtener más información, consulte [Adding an internet gateway to your VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html) (Cómo añadir una gateway de Internet a la VPC).
De forma alternativa, compruebe que ha configurado la VPC con las opciones **Enable DNS resolution (Habilitar resolución de DNS)** y **Enable DNS hostname support (Habilitar el soporte de nombres de host DNS)** habilitadas. Para obtener más información, consulte [Utilización de DNS con su VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html).
## Falta el conjunto de opciones de DHCP
Puede ver un error de paso en el registro del sistema (syslog) del clúster con un error similar al siguiente:
` ERROR org.apache.hadoop.security.UserGroupInformation (main): PriviledgedActionException as:hadoop (auth:SIMPLE) cause:java.io.IOException: org.apache.hadoop.yarn.exceptions.ApplicationNotFoundException: Application with id 'application_id' doesn't exist in RM. `
o
`ERROR org.apache.hadoop.streaming.StreamJob (main): Error Launching job : org.apache.hadoop.yarn.exceptions.ApplicationNotFoundException: Application with id 'application_id' doesn't exist in RM.`
Para solucionar este problema, debe configurar una VPC que incluya un conjunto de opciones de DHCP cuyos parámetros se hayan definido en los siguientes valores:
**nota**
Si usa la región AWS GovCloud (EE. UU. Oeste), establezca el nombre de dominio **us-gov-west-1.compute.internal** en lugar del valor utilizado en el siguiente ejemplo.
+ **domain-name** = **ec2.internal**
Use **ec2.internal** si su región es Este de EE. UU. (Norte de Virginia). Para otras regiones, utilice. *region-name* **.compute.internal** Por ejemplo en us-west-2, utilice **domain-name**=**us-west-2.compute.internal**.
+ **domain-name-servers** = **AmazonProvidedDNS**
Para obtener más información, consulte [Conjuntos de opciones de DHCP](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
## Errores de permisos
Un error en el registro `stderr` de un paso indica que un recurso de Amazon S3 no tiene los permisos adecuados. Se trata de un error 403 y su aspecto es:
```
Exception in thread "main" com.amazonaws.services.s3.model.AmazonS3Exception: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: REQUEST_ID
```
Si ActionOnFailure se establece en`TERMINATE_JOB_FLOW`, esto provocará que el clúster termine con el estado,`SHUTDOWN_COMPLETED_WITH_ERRORS`.
Algunas formas de solucionar este problema son:
+ Si está utilizando una política de bucket de Amazon S3 dentro de una VPC, asegúrese de proporcionar acceso a todos los buckets. Para ello, cree un punto de conexión de VPC y seleccione **Permitir todo** en la opción Política al crear el punto de conexión.
+ Asegúrese de que las políticas asociadas con recursos de S3 incluyan la VPC en la que lanzar el clúster.
+ Pruebe a ejecutar el siguiente comando desde el clúster para verificar que puede acceder al bucket
```
hadoop fs -copyToLocal s3://path-to-bucket /tmp/
```
+ Puede obtener información más específica sobre la depuración definiendo el parámetro `log4j.logger.org.apache.http.wire` en `DEBUG` en el archivo `/home/hadoop/conf/log4j.properties` en el clúster. Puede comprobar el archivo de registro `stderr` después de intentar acceder al bucket desde el clúster. El archivo de registro proporcionará información más detallada:
```
Access denied for getting the prefix for bucket - us-west-2.elasticmapreduce with path samples/wordcount/input/
15/03/25 23:46:20 DEBUG http.wire: >> "GET /?prefix=samples%2Fwordcount%2Finput%2F&delimiter=%2F&max-keys=1 HTTP/1.1[\r][\n]"
15/03/25 23:46:20 DEBUG http.wire: >> "Host: us-west-2.elasticmapreduce.s3.amazonaws.com[\r][\n]"
```
## Errores que dan lugar a `START_FAILED`
Antes de la AMI 3.7.0, para los VPCs casos en los que se especificaba un nombre de host, Amazon EMR mapeaba los nombres de host internos de la subred con direcciones de dominio personalizadas de la siguiente manera: `ip-X.X.X.X.customdomain.com.tld` Por ejemplo, si el nombre de host fuera `ip-10.0.0.10` y la VPC tuviera la opción de nombre de dominio definida en customdomain.com, el nombre de host resultante asignado por Amazon EMR sería `ip-10.0.1.0.customdomain.com`. Se añade una entrada en `/etc/hosts` para resolver el nombre de host a 10.0.0.10. Este comportamiento se cambia con la AMI 3.7.0 y ahora Amazon EMR respeta completamente la configuración de DHCP de la VPC. Anteriormente, los clientes también podrían utilizar una acción de arranque para especificar un mapeo de nombre de host.
Si desea conservar este comportamiento, debe proporcionar la DNS y reenviar la configuración de resolución que necesita para el dominio personalizado.
## Se agrupa y no se puede iniciar `Terminated with errors` NameNode
Al lanzar un clúster de EMR en una VPC que hace uso de un nombre de dominio de DNS personalizado, el clúster podría devolver el siguiente mensaje de error en la consola:
```
Terminated with errors On the master instance(instance-id), bootstrap action 1 returned a non-zero return code
```
El error se debe a que NameNode no se pudo iniciar. Esto provocará el siguiente error en los NameNode registros, cuyo URI de Amazon S3 tiene el siguiente formato`s3://amzn-s3-demo-bucket/logs/cluster-id/daemons/master instance-id/hadoop-hadoop-namenode-master node hostname.log.gz`:
```
2015-07-23 20:17:06,266 WARN
org.apache.hadoop.hdfs.server.namenode.FSNamesystem (main): Encountered exception
loading fsimage java.io.IOException: NameNode is not formatted.
at
org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:212)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1020)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:739)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:537)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:596)
at org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:765)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:749)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1441)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1507)
```
Esto es debido a un posible problema en una instancia de EC2 que puede tener varios conjuntos de nombres de dominio completos al lanzar clústeres de EMR en una VPC, que hace uso de un servidor de DNS proporcionado por AWS y un servidor de DNS proporcionado por el usuario personalizado. Si el servidor de DNS proporcionado por el usuario no ofrece ningún registro de puntero (PTR) para ningún registro A utilizado para designar nodos en un clúster de EMR, los clústeres devolverán un error al iniciarse cuando se configuran de esta manera. La solución consiste en añadir un registro PTR por cada registro A que se crea cuando se lanza una instancia de EC2 en cualquiera de las subredes de la VPC.
# Errores del clúster de Amazon EMR de streaming
Normalmente, puede encontrar la causa de un error de streaming en un archivo `syslog`. Encontrará un enlace al mismo en el panel **Steps (Pasos)**.
Los siguientes errores son comunes a los clústeres de streaming.
**Topics**
+ [¿Los datos que se envían al mapeador están en formato equivocado?](#emr-troubleshoot-error-streaming-1)
+ [¿Se agota el tiempo de espera del script?](#emr-troubleshoot-error-streaming-2)
+ [¿Está transfiriendo un argumento de streaming no válido?](#invalidarg)
+ [¿El script se cierra con un error?](#emr-troubleshoot-error-streaming-3)
## ¿Los datos que se envían al mapeador están en formato equivocado?
Para comprobar si este es el caso, busque un mensaje de error en el archivo `syslog` un intento de tarea con error en los registros de intento de tareas. Para obtener más información, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
## ¿Se agota el tiempo de espera del script?
El tiempo de espera predeterminado para un script de mapeador o reductor es 600 segundos. Si el script tarda más tiempo, el intento de tarea devolverá un error. Puede comprobar si es así comprobando el archivo `syslog` de un intento de tarea con error en los registros de intento de tareas. Para obtener más información, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
Puede cambiar el límite de tiempo estableciendo un nuevo valor para el ajuste de configuración de `mapred.task.timeout`. Esta configuración especifica el número de milisegundos tras el que Amazon EMR terminará una tarea que no tiene entrada de lectura, salida de escritura o ha actualizado su cadena de estado. Puede actualizar este valor transfiriendo un argumento de streaming adicional `-jobconf mapred.task.timeout=800000`.
## ¿Está transfiriendo un argumento de streaming no válido?
Hadoop Streaming admite únicamente los siguientes argumentos. Si transfiere argumentos distintos de los que se indican a continuación, el clúster devolverá un error.
```
1. -blockAutoGenerateCacheFiles
2. -cacheArchive
3. -cacheFile
4. -cmdenv
5. -combiner
6. -debug
7. -input
8. -inputformat
9. -inputreader
10. -jobconf
11. -mapper
12. -numReduceTasks
13. -output
14. -outputformat
15. -partitioner
16. -reducer
17. -verbose
```
Además, Hadoop Streaming solo reconoce argumentos transferidos mediante sintaxis de Java; es decir, precedidos de un único guion. Si transfiere argumentos precedidos de un guion doble, el clúster fallará.
## ¿El script se cierra con un error?
Si su script de mapeador o reductor termina con un error, puede localizar el error en el archivo `stderr` de los registros de intento de tarea del intento de tarea que ha devuelto error. Para obtener más información, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
# Amazon EMR: errores de clúster JAR personalizados
Los siguientes errores son comunes en los clústeres JAR personalizados.
**Topics**
+ [¿Su JAR lanza una excepción antes de crear un trabajo?](#emr-troubleshoot-error-custom-jar-1)
+ [¿Su JAR lanza un error dentro de una tarea de asignación?](#emr-troubleshoot-error-custom-jar-2)
## ¿Su JAR lanza una excepción antes de crear un trabajo?
Si el programa principal de su JAR personalizado arroja una excepción al crear el trabajo de Hadoop, el mejor lugar consiste donde buscar es el archivo `syslog` de los registros de pasos. Para obtener más información, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
## ¿Su JAR lanza un error dentro de una tarea de asignación?
Si su JAR personalizado y mapeador lanzan una excepción al procesar los datos de entrada, el mejor lugar donde buscar es el archivo `syslog` de los registros de intento de tarea. Para obtener más información, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
# Errores de Amazon EMR AWS GovCloud (EE. UU. - Oeste)
La región AWS GovCloud (EE. UU. oeste) se diferencia de otras regiones en cuanto a la seguridad, la configuración y los ajustes predeterminados. Como resultado, utilice la siguiente lista de comprobación para solucionar los errores de Amazon EMR específicos de la región AWS GovCloud (EE. UU. Oeste) antes de utilizar recomendaciones de solución de problemas más generales.
+ Compruebe que sus roles de IAM estén correctamente configurados. Para obtener más información, consulte [Configure las funciones de servicio de IAM para los permisos de Amazon EMR AWS a los servicios y recursos](emr-iam-roles.md).
+ Asegúrese de que la configuración de la VPC haya configurado correctamente los parámetros de resolution/hostname compatibilidad con DNS, Internet Gateway y conjunto de opciones de DHCP. Para obtener más información, consulte [Errores de la VPC durante las operaciones del clúster de Amazon EMR](emr-troubleshoot-error-vpc.md).
Si estos pasos no resuelven el problema, continúe con los pasos para la resolución de los errores de Amazon EMR comunes. Para obtener más información, consulte [Recopilaciones de errores comunes en Amazon EMR](emr-troubleshoot-errors.md).
## Buscar un clúster que falta
Si el clúster no aparece en la lista de consolas o en la API `ListClusters`, compruebe lo siguiente:
+ Confirme que la antigüedad del clúster desde el momento de su finalización es inferior a dos meses. Amazon EMR conserva la información de metadatos sobre clústeres completados, gratuitamente, durante dos meses. No puede eliminar los clústeres completados de la consola; en su lugar, Amazon EMR purga los clústeres completados automáticamente después de dos meses.
+ Confirme que tiene los permisos de rol para ver el clúster.
+ Confirme que está viendo el mismo Región de AWS lugar donde reside el clúster.
# Solución de problemas de un clúster de Amazon EMR que ha fallado con un código de error
Esta sección le muestra el proceso de resolución de problemas de un clúster que ha generado un error. Esto significa que el clúster terminó con un código de error.
**nota**
Cuando un clúster de EMR termina con un error, `ListClusters` APIs devuelve un código de error `DescribeCluster` y un mensaje de error. En el caso de algunos errores del clúster, la matriz de datos `ErrorDetail` también puede ayudarle a solucionar el error. Para obtener más información, consulte [Códigos de error con ErrorDetail información en Amazon EMR](emr-troubleshoot-error-errordetail.md).
Si el clúster se ejecuta, pero tarda mucho en devolver resultados, consulte [Solución de problemas de un clúster de Amazon EMR lento](emr-troubleshoot-slow.md).
**Topics**
+ [Paso 1: recopile datos sobre el problema con el clúster de Amazon EMR](emr-troubleshoot-failed-1.md)
+ [Paso 2: comprobar el entorno](emr-troubleshoot-failed-2.md)
+ [Paso 3: comprobar el último cambio de estado](emr-troubleshoot-failed-3.md)
+ [Paso 4: examine los archivos de registro de Amazon EMR](emr-troubleshoot-failed-4.md)
+ [Paso 5: compruebe el clúster de Amazon EMR de forma pormenorizada](emr-troubleshoot-failed-5-test-steps.md)
# Paso 1: recopile datos sobre el problema con el clúster de Amazon EMR
El primer paso para solucionar problemas de un clúster es recopilar información sobre lo que ha fallado y el estado y la configuración actuales del clúster. Esta información se utilizará en los siguientes pasos para confirmar o descartar las posibles causas del problema.
## Definir el problema
Una definición clara del problema es el primer punto de partida. Algunas preguntas que debe hacerse:
+ ¿Qué esperaba que sucediera? ¿Qué pasó en su lugar?
+ ¿Cuándo se produjo este problema por primera vez? ¿Con qué frecuencia ha ocurrido desde entonces?
+ ¿Ha cambiado algo en la forma en que configuro o ejecuto mi clúster?
## Detalles de clúster
Los siguientes detalles del clúster son útiles para ayudar a detectar problemas. Para obtener más información sobre cómo recopilar esta información, consulte [Visualización del estado y los detalles del clúster de Amazon EMR](emr-manage-view-clusters.md).
+ El identificador del clúster. (También se denomina identificador de flujo de tareas).
+ Región de AWS y la zona de disponibilidad en la que se lanzó el clúster.
+ El estado del clúster, incluidos los detalles del último cambio de estado.
+ Tipo y número de instancias de EC2 especificados para los nodos maestro, principal y de tarea.
# Paso 2: comprobar el entorno
Amazon EMR opera como parte de un ecosistema de servicios web y software de código abierto. Lo que afecta a dichas dependencias pueden influir en el rendimiento de Amazon EMR.
**Topics**
+ [Comprobar las interrupciones de servicio](#emr-troubleshoot-failed-2-outages)
+ [Comprobar los límites de uso](#emr-troubleshoot-failed-2-limits)
+ [Comprobar la versión](#emr-troubleshoot-failed-2-ami)
+ [Comprobar la configuración de subredes de Amazon VPC](#emr-troubleshoot-failed-2-vpc)
## Comprobar las interrupciones de servicio
Amazon EMR utiliza varios servicios de Amazon Web Services internamente. Ejecuta servidores virtuales en Amazon EC2, almacena datos y scripts en Amazon S3 e informa de las métricas a. CloudWatch Los eventos que interrumpen estos servicios son poco frecuentes, pero, cuando se producen, pueden provocar problemas en Amazon EMR.
Antes de continuar, compruebe el [Panel de estado del servicio](https://status.aws.amazon.com/). Compruebe la región en la que lanzó el clúster para ver si hay interrupciones en alguno de estos servicios.
## Comprobar los límites de uso
Si va a lanzar un clúster grande, ha lanzado varios clústeres simultáneamente o es un usuario que comparte uno Cuenta de AWS con otros usuarios, es posible que el clúster haya fallado porque ha superado un límite de AWS servicio.
Amazon EC2 limita el número de instancias de servidores virtuales que se ejecutan en una sola AWS región a 20 instancias reservadas o bajo demanda. Si lanza un clúster con más de 20 nodos o lanza un clúster que hace que el número total de instancias de EC2 activas en la suya Cuenta de AWS supere las 20, el clúster no podrá lanzar todas las instancias de EC2 que necesita y podría fallar. Cuando esto ocurre, Amazon EMR devuelve un error `EC2 QUOTA EXCEEDED`. Puede solicitar que se AWS aumente el número de instancias EC2 que puede ejecutar en su cuenta enviando una [solicitud para aumentar el límite de instancias de Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/).
Otro factor que puede provocar que supere los límites de uso es el retraso que transcurre entre la finalización de un clúster y el momento en que libera todos sus recursos. En función de las diferencias de configuración, un clúster puede tardar entre 5 y 20 minutos terminar por completo y liberar los recursos asignados. Si aparece un error `EC2 QUOTA EXCEEDED` al intentar lanzar un clúster, puede deberse a que aún no se hayan liberado los recursos de un clúster terminado recientemente. En este caso, puede [solicitar un aumento de la cuota de Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/) o puede esperar 20 minutos y volver a lanzar el clúster.
Amazon S3 limita el número de buckets creados en una cuenta a 100. Si el clúster crea un bucket nuevo que supera este límite, se producirá un error en la creación del bucket y es posible que el clúster falle.
## Comprobar la versión
Compare la etiqueta de versión que ha usado para lanzar el clúster con la última versión de Amazon EMR. Cada versión de Amazon EMR incorpora mejoras, como nuevas aplicaciones, características, parches y errores corregidos. Puede que el problema que afecta a su clúster ya se haya solucionado en la última versión. Si es posible, vuelva a ejecutar el clúster con la versión más reciente.
## Comprobar la configuración de subredes de Amazon VPC
Si el clúster se lanzó en una subred de Amazon VPC, la subred debe configurarse como se describe en [Configuración de redes en una VPC para Amazon EMR](emr-plan-vpc-subnet.md). Además, compruebe que la subred en la que lanza el clúster tenga suficientes direcciones IP elásticas libres para asignar una a cada nodo del clúster.
# Paso 3: comprobar el último cambio de estado
El último cambio de estado ofrece información sobre qué ocurrió la última vez que el clúster cambió de estado. Esto a menudo contiene información capaz de indicar lo que ha funcionado mal cuando el clúster cambia su estado a `FAILED`. Por ejemplo, si lanza un clúster de streaming y especifica una ubicación de salida que ya existe en Amazon S3, se producirá el error con un último cambio de estado “El directorio de salida de streaming ya existe” en el clúster.
Puede localizar el valor del último cambio de estado desde la consola consultando el panel de detalles del clúster, desde la CLI utilizando los argumentos `list-steps` o `describe-cluster` o desde el API utilizando las acciones `DescribeCluster` y `ListSteps`. Para obtener más información, consulte [Visualización del estado y los detalles del clúster de Amazon EMR](emr-manage-view-clusters.md).
# Paso 4: examine los archivos de registro de Amazon EMR
El siguiente paso consiste en examinar los archivos de registro para encontrar un código de error u otro indicio del problema que ha sufrido el clúster. Para obtener información sobre los archivos de registro disponibles, dónde encontrarlos y cómo verlos, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
Es posible que sea necesario un poco de trabajo de investigación para determinar qué pasó. Hadoop ejecuta los trabajos en los intentos de tareas en varios nodos del clúster. Amazon EMR puede iniciar intentos de tareas especulativos y terminar los demás intentos de tareas que no se completen primero. Esto genera una actividad importante que se registra en los archivos de registro del controlador, stderr y syslog a medida que se produce. Además, se ejecutan varios intentos de tareas simultáneamente, pero un archivo de registro solo puede mostrar los resultados de forma lineal.
Para comenzar, compruebe los registros de acciones de arranque para ver si hay errores o cambios de configuración inesperados durante el lanzamiento del clúster. A partir de ahí, consulte los registros de pasos para identificar los trabajos de Hadoop lanzados como parte de un paso con errores. Examine los registros de trabajos de Hadoop para identificar los intentos fallidos de tareas. El registro de intentos de tarea contendrá detalles sobre la causa del error de un intento de tarea.
En las siguientes secciones, se describe cómo utilizar los distintos archivos de registro para identificar errores en el clúster.
## Comprobar los registros de acción de arranque
Las acciones de arranque ejecutan scripts en el clúster a medida que se lanza. Por lo general, se utilizan para instalar software adicional en el clúster o para modificar los valores predeterminados de los valores de configuración. La comprobación de estos registros puede proporcionar información sobre los errores que se produjeron durante la configuración del clúster, así como sobre los cambios en los ajustes de configuración que podrían afectar al rendimiento.
## Comprobar los registros de pasos
Hay cuatro tipos de registros de pasos.
+ **controlador:** contiene archivos generados por Amazon EMR (Amazon EMR) que se deben a errores encontrados al intentar ejecutar el paso. Si se produce un error en el paso durante la carga, puede encontrar el registro de seguimiento de la pila en este registro. Aquí se describen con frecuencia los errores al cargar la aplicación o al acceder a ella, así como los errores que faltan en el archivo de asignación.
+ **stderr:** contiene los mensajes de error que se produjeron al procesar el paso. Los errores de carga de la aplicación se describen a menudo aquí. En ocasiones, este registro contiene un seguimiento de pila.
+ **stdout:** contiene el estado generado por los ejecutables de asignación y reducción. Los errores de carga de la aplicación se describen a menudo aquí. En ocasiones, este registro contiene mensajes de error de la aplicación.
+ **syslog:** contiene registros de software ajeno a Amazon, como Apache y Hadoop. Los errores de streaming suelen describirse aquí.
Compruebe si hay errores obvios en stderr. Si stderr muestra una lista corta de errores, el paso se detuvo rápidamente y se produjo un error. En la mayoría de los casos, esto se debe a un error en las aplicaciones de asignación y reducción que se ejecutan en el clúster.
Examine las últimas líneas del controlador y de syslog en busca de avisos de errores. Siga cualquier aviso sobre tareas con errores, especialmente si dice “Trabajo con errores”.
## Comprobar los registros de intento de tarea
Si el análisis anterior de los registros de pasos reveló una o más tareas fallidas, investigue los registros de los intentos de tareas correspondientes para obtener información de error más detallada.
# Paso 5: compruebe el clúster de Amazon EMR de forma pormenorizada
Una técnica útil cuando se intenta localizar el origen de un error consiste en reiniciar el clúster y enviar los pasos al mismo uno a uno. Esto le permite comprobar los resultados de cada paso antes de procesar el siguiente y le ofrece la oportunidad de corregir y volver a ejecutar un paso que ha fallado. Esto también tiene la ventaja de cargar los datos de entrada solo una vez.
**Para probar un clúster paso a paso**
1. Lance un clúster nuevo, con keep alive y la protección de terminación habilitados. Keep alive mantiene el clúster en ejecución después de que haya procesado todos los pasos pendientes. La protección de terminación evita que un clúster se cierre en caso de que se produzca un error. Para obtener más información, consulte [Configuración de un clúster de Amazon EMR para que continúe o finalice después de la ejecución de pasos](emr-plan-longrunning-transient.md) y [Uso de la protección de finalización para proteger sus clústeres de Amazon EMR de un cierre accidental](UsingEMR_TerminationProtection.md).
1. Envíe un paso al clúster. Para obtener más información, consulte [Envío del trabajo a un clúster de Amazon EMR](emr-work-with-steps.md).
1. Cuando el paso completa el procesamiento, compruebe los errores en los archivos de registro del paso. Para obtener más información, consulte [Paso 4: examine los archivos de registro de Amazon EMR](emr-troubleshoot-failed-4.md). La manera más rápida de localizar estos archivos de registro consiste en conectar al nodo maestro y visualizar los archivos de registro allí. Los archivos de registro del paso no aparecen hasta que el paso se ejecuta durante algún tiempo, finaliza o genera un error.
1. Si el paso se realiza correctamente sin error, ejecutar el siguiente paso. Si se produjeron errores, investigar el error en los archivos de registro. Si se trató de un error en el código, corríjalo y vuelva a ejecutar el paso. Continúe hasta que todos los pasos se ejecuten sin errores.
1. Cuando haya terminado la depuración del clúster y desea terminarlo, tendrá que terminarlo manualmente. Esto es necesario porque el clúster se lanzó con la protección de terminación habilitada. Para obtener más información, consulte [Uso de la protección de finalización para proteger sus clústeres de Amazon EMR de un cierre accidental](UsingEMR_TerminationProtection.md).
# Solución de problemas de un clúster de Amazon EMR lento
Esta sección describe el proceso de solución de problemas de un clúster que sigue en ejecución, pero que tarda mucho en devolver los resultados. Para obtener más información sobre qué hacer si el clúster ha terminado con un código de error, consulte [Solución de problemas de un clúster de Amazon EMR que ha fallado con un código de error](emr-troubleshoot-failed.md)
Amazon EMR le permite especificar el número y el tipo de instancias en el clúster. Estas especificaciones son los medios principales que afectan a la velocidad con que la que se completa el procesamiento de datos. Una cosa que debería tener en cuenta es volver a ejecutar el clúster, esta vez especificando instancias de EC2 con más recursos o especificar un número mayor de instancias en el clúster. Para obtener más información, consulte [Configuración del hardware y las redes de los clústeres de Amazon EMR](emr-plan-instances.md).
Los siguientes temas le guiarán a través del proceso de identificación de causas alternativas de un clúster lento.
**Topics**
+ [Paso 1: recopile datos sobre el problema con el clúster de Amazon EMR](emr-troubleshoot-slow-1.md)
+ [Paso 2: compruebe el entorno del clúster de Amazon EMR](emr-troubleshoot-slow-2.md)
+ [Paso 3: examine los archivos de registro del clúster de Amazon EMR](emr-troubleshoot-slow-3.md)
+ [Paso 4: compruebe el estado de la instancia y el clúster de Amazon EMR](emr-troubleshoot-slow-4.md)
+ [Paso 5: comprobar si hay grupos suspendidos](emr-troubleshoot-slow-5.md)
+ [Paso 6: revise los ajustes de configuración del clúster de Amazon EMR](emr-troubleshoot-slow-6.md)
+ [Paso 7: examine los datos de entrada del clúster de Amazon EMR](emr-troubleshoot-slow-7.md)
# Paso 1: recopile datos sobre el problema con el clúster de Amazon EMR
El primer paso para solucionar problemas de un clúster es recopilar información sobre lo que ha fallado y el estado y la configuración actuales del clúster. Esta información se utilizará en los siguientes pasos para confirmar o descartar las posibles causas del problema.
## Definir el problema
Una definición clara del problema es el primer punto de partida. Algunas preguntas que debe hacerse:
+ ¿Qué esperaba que sucediera? ¿Qué pasó en su lugar?
+ ¿Cuándo se produjo este problema por primera vez? ¿Con qué frecuencia ha ocurrido desde entonces?
+ ¿Ha cambiado algo en la forma en que configuro o ejecuto mi clúster?
## Detalles de clúster
Los siguientes detalles del clúster son útiles para ayudar a detectar problemas. Para obtener más información sobre cómo recopilar esta información, consulte [Visualización del estado y los detalles del clúster de Amazon EMR](emr-manage-view-clusters.md).
+ El identificador del clúster. (También se denomina identificador de flujo de tareas).
+ Región de AWS y la zona de disponibilidad en la que se lanzó el clúster.
+ El estado del clúster, incluidos los detalles del último cambio de estado.
+ Tipo y número de instancias de EC2 especificados para los nodos maestro, principal y de tarea.
# Paso 2: compruebe el entorno del clúster de Amazon EMR
Compruebe su entorno para ver si hay interrupciones en el servicio o si ha superado un límite de AWS servicio.
**Topics**
+ [Comprobar las interrupciones de servicio](#emr-troubleshoot-slow-2-outages)
+ [Comprobar los límites de uso](#emr-troubleshoot-slow-2-limits)
+ [Comprobar la configuración de subredes de Amazon VPC](#emr-troubleshoot-slow-2-vpc)
+ [Reiniciar el clúster](#emr-troubleshoot-slow-2-restart)
## Comprobar las interrupciones de servicio
Amazon EMR utiliza varios servicios de Amazon Web Services internamente. Ejecuta servidores virtuales en Amazon EC2, almacena datos y scripts en Amazon S3 e informa de las métricas a. CloudWatch Los eventos que interrumpen estos servicios son poco frecuentes, pero, cuando se producen, pueden provocar problemas en Amazon EMR.
Antes de continuar, compruebe el [Panel de estado del servicio](https://status.aws.amazon.com/). Compruebe la región en la que lanzó el clúster para ver si hay interrupciones en alguno de estos servicios.
## Comprobar los límites de uso
Si va a lanzar un clúster grande, ha lanzado varios clústeres simultáneamente o es un usuario que comparte uno Cuenta de AWS con otros usuarios, es posible que el clúster haya fallado porque ha superado un límite de AWS servicio.
Amazon EC2 limita el número de instancias de servidores virtuales que se ejecutan en una sola AWS región a 20 instancias reservadas o bajo demanda. Si lanza un clúster con más de 20 nodos o lanza un clúster que hace que el número total de instancias de EC2 activas en la suya Cuenta de AWS supere las 20, el clúster no podrá lanzar todas las instancias de EC2 que necesita y podría fallar. Cuando esto ocurre, Amazon EMR devuelve un error `EC2 QUOTA EXCEEDED`. Puede solicitar que se AWS aumente el número de instancias EC2 que puede ejecutar en su cuenta enviando una [solicitud para aumentar el límite de instancias de Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/).
Otro factor que puede provocar que supere los límites de uso es el retraso que transcurre entre la finalización de un clúster y el momento en que libera todos sus recursos. En función de las diferencias de configuración, un clúster puede tardar entre 5 y 20 minutos terminar por completo y liberar los recursos asignados. Si aparece un error `EC2 QUOTA EXCEEDED` al intentar lanzar un clúster, puede deberse a que aún no se hayan liberado los recursos de un clúster terminado recientemente. En este caso, puede [solicitar un aumento de la cuota de Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/) o puede esperar 20 minutos y volver a lanzar el clúster.
Amazon S3 limita el número de buckets creados en una cuenta a 100. Si el clúster crea un bucket nuevo que supera este límite, se producirá un error en la creación del bucket y es posible que el clúster falle.
## Comprobar la configuración de subredes de Amazon VPC
Si el clúster se lanzó en una subred de Amazon VPC, la subred debe configurarse como se describe en [Configuración de redes en una VPC para Amazon EMR](emr-plan-vpc-subnet.md). Además, compruebe que la subred en la que lanza el clúster tenga suficientes direcciones IP elásticas libres para asignar una a cada nodo del clúster.
## Reiniciar el clúster
La ralentización de procesamiento puede deberse a una condición transitoria. Plantéese terminar y reiniciar el clúster para ver si el rendimiento mejora.
# Paso 3: examine los archivos de registro del clúster de Amazon EMR
El siguiente paso consiste en examinar los archivos de registro para encontrar un código de error u otro indicio del problema que ha sufrido el clúster. Para obtener información sobre los archivos de registro disponibles, dónde encontrarlos y cómo verlos, consulte [Visualización de los archivos de registro de Amazon EMR](emr-manage-view-web-log-files.md).
Es posible que sea necesario un poco de trabajo de investigación para determinar qué pasó. Hadoop ejecuta los trabajos en los intentos de tareas en varios nodos del clúster. Amazon EMR puede iniciar intentos de tareas especulativos y terminar los demás intentos de tareas que no se completen primero. Esto genera una actividad importante que se registra en los archivos de registro del controlador, stderr y syslog a medida que se produce. Además, se ejecutan varios intentos de tareas simultáneamente, pero un archivo de registro solo puede mostrar los resultados de forma lineal.
Para comenzar, compruebe los registros de acciones de arranque para ver si hay errores o cambios de configuración inesperados durante el lanzamiento del clúster. A partir de ahí, consulte los registros de pasos para identificar los trabajos de Hadoop lanzados como parte de un paso con errores. Examine los registros de trabajos de Hadoop para identificar los intentos fallidos de tareas. El registro de intentos de tarea contendrá detalles sobre la causa del error de un intento de tarea.
En las siguientes secciones, se describe cómo utilizar los distintos archivos de registro para identificar errores en el clúster.
## Comprobar los registros de acción de arranque
Las acciones de arranque ejecutan scripts en el clúster a medida que se lanza. Por lo general, se utilizan para instalar software adicional en el clúster o para modificar los valores predeterminados de los valores de configuración. La comprobación de estos registros puede proporcionar información sobre los errores que se produjeron durante la configuración del clúster, así como sobre los cambios en los ajustes de configuración que podrían afectar al rendimiento.
## Comprobar los registros de pasos
Hay cuatro tipos de registros de pasos.
+ **controlador:** contiene archivos generados por Amazon EMR (Amazon EMR) que se deben a errores encontrados al intentar ejecutar el paso. Si se produce un error en el paso durante la carga, puede encontrar el registro de seguimiento de la pila en este registro. Aquí se describen con frecuencia los errores al cargar la aplicación o al acceder a ella, así como los errores que faltan en el archivo de asignación.
+ **stderr:** contiene los mensajes de error que se produjeron al procesar el paso. Los errores de carga de la aplicación se describen a menudo aquí. En ocasiones, este registro contiene un seguimiento de pila.
+ **stdout:** contiene el estado generado por los ejecutables de asignación y reducción. Los errores de carga de la aplicación se describen a menudo aquí. En ocasiones, este registro contiene mensajes de error de la aplicación.
+ **syslog:** contiene registros de software ajeno a Amazon, como Apache y Hadoop. Los errores de streaming suelen describirse aquí.
Compruebe si hay errores obvios en stderr. Si stderr muestra una lista corta de errores, el paso se detuvo rápidamente y se produjo un error. En la mayoría de los casos, esto se debe a un error en las aplicaciones de asignación y reducción que se ejecutan en el clúster.
Examine las últimas líneas del controlador y de syslog en busca de avisos de errores. Siga cualquier aviso sobre tareas con errores, especialmente si dice “Trabajo con errores”.
## Comprobar los registros de intento de tarea
Si el análisis anterior de los registros de pasos reveló una o más tareas fallidas, investigue los registros de los intentos de tareas correspondientes para obtener información de error más detallada.
## Comprobar los registros de daemon de Hadoop
En raras ocasiones, Hadoop podría fallar. Para comprobar si ese es el caso, consulte los registros de Hadoop. Están ubicados en `/var/log/hadoop/` en cada nodo.
Puede utilizar los JobTracker registros para asignar un intento de tarea fallido al nodo en el que se ejecutó. Una vez que conozca el nodo asociado al intento de tarea, puede comprobar el estado de la instancia de EC2 que aloja ese nodo para comprobar si se ha producido algún problema, por ejemplo, si se ha quedado sin CPU o memoria.
# Paso 4: compruebe el estado de la instancia y el clúster de Amazon EMR
Un clúster de Amazon EMR se compone de nodos que se ejecutan en instancias de Amazon EC2. Si dichas instancias se ven limitadas por los recursos (como, por ejemplo, quedarse sin CPU o memoria), tienen problemas de conectividad de red o se terminan, la velocidad de procesamiento del clúster se resiente.
Existen hasta tres tipos de nodos en un clúster:
+ **nodo maestro**: administra el clúster. Si experimenta problemas de rendimiento, se ve afectado todo el clúster.
+ **nodos principales**: procesan tareas de map-reduce y mantienen Hadoop Distributed FileSystem (HDFS). Si uno de estos nodos experimenta un problema de rendimiento, puede ralentizar las operaciones de HDFS, así como el procesamiento de MapReduce. Puede añadir más nodos secundarios a un clúster para mejorar el rendimiento, pero no puede eliminar nodos secundarios. Para obtener más información, consulte [Cambio manual del tamaño de un clúster de Amazon EMR en ejecución](emr-manage-resize.md).
+ **nodos de tareas**: procesan tareas map-reduce. Se trata exclusivamente de recursos informáticos y no almacenan datos. Puede añadir nodos de tareas a un clúster para acelerar el rendimiento o eliminar los nodos de tareas que no sean necesarios. Para obtener más información, consulte [Cambio manual del tamaño de un clúster de Amazon EMR en ejecución](emr-manage-resize.md).
Al examinar el estado de un clúster, debe examinar tanto el rendimiento global del clúster, así como el rendimiento de instancias concretas. Existen varias herramientas que puede utilizar:
## Compruebe el estado del clúster con CloudWatch
Cada clúster de Amazon EMR informa de las métricas a. CloudWatch Estas métricas proporcionan información sobre el rendimiento de resumen acerca del clúster, como la carga total, utilización de HDFS, ejecución de tareas, tareas restante, bloques corruptos, etc. Al analizar las CloudWatch métricas, tendrá una idea general de lo que está sucediendo con su clúster y puede proporcionar información sobre las causas de la ralentización del procesamiento. Además de usarlo CloudWatch para analizar un problema de rendimiento existente, puede configurar alarmas que emitan alertas si se produce un problema de rendimiento en el futuro. CloudWatch Para obtener más información, consulte [Supervisión de las métricas de Amazon EMR con CloudWatch](UsingEMR_ViewingMetrics.md).
## Comprobar el estado del trabajo y de HDFS
Utilice la pestaña **Interfaces de usuario de aplicaciones** de la página de detalles del clúster para ver los detalles de las aplicaciones de YARN. Para determinadas aplicaciones, puede consultar información adicional y tener acceso a los logs directamente. Esto resulta especialmente útil para las aplicaciones Spark. Para obtener más información, consulte [Visualización del historial de aplicaciones de Amazon EMR](emr-cluster-application-history.md).
Hadoop proporciona una serie de interfaces web que puede utilizar para ver información. Para obtener más información sobre cómo acceder a estas interfaces web, consulte [Ver las interfaces web alojadas en clústeres de Amazon EMR](emr-web-interfaces.md).
+ JobTracker — proporciona información sobre el progreso del trabajo que está procesando el clúster. Puede utilizar esta interfaz para identificar si se ha bloqueado un trabajo.
+ HDFS NameNode : proporciona información sobre el porcentaje de uso de HDFS y el espacio disponible en cada nodo. Puede utilizar esta interfaz para identificar cuando HDFS se ve limitado por los recursos y requiere capacidad adicional.
+ TaskTracker — proporciona información sobre las tareas del trabajo que está procesando el clúster. Puede utilizar esta interfaz para identificar cuando se ha bloqueado una tarea.
## Comprobar el estado de la instancia con Amazon EC2
Otra forma de buscar información sobre el estado de las instancias en el clúster consiste en utilizar la consola de Amazon EC2. Dado que cada nodo del clúster se ejecuta en una instancia de EC2, puede utilizar las herramientas proporcionadas por Amazon EC2 para comprobar su estado. Para obtener más información, consulte [Ver instancias del clúster en Amazon EC2](UsingEMR_Tagging.md).
# Paso 5: comprobar si hay grupos suspendidos
Un grupo de instancias queda suspendido cuando encuentra demasiados errores al intentar lanzar nodos. Por ejemplo, si nodos nuevos devuelven error repetidamente al llevar a cabo acciones de arranque, el grupo de instancias, después de un tiempo, pasará al estado `SUSPENDED` en lugar intentar de forma continua aprovisionar nuevos nodos.
Un nodo podría no cargarse si:
+ Hadoop o el clúster están estropeados por algún motivo y no aceptan un nuevo nodo en el clúster
+ Una acción de arranque falla en el nuevo nodo
+ El nodo no funciona correctamente y no puede iniciar sesión con Hadoop
Si un grupo de instancias está en estado `SUSPENDED` y el clúster está en estado `WAITING`, puede añadir un paso de clúster para restablecer el número deseado de nodos secundarios y de tareas. Al añadir el paso se reanuda el procesamiento del clúster y coloca el grupo de instancias de nuevo en estado `RUNNING`.
Para obtener más información sobre cómo restablecer un clúster en estado suspendido, consulte [Estado de suspensión](emr-manage-resize.md#emr-manage-resizeSuspended).
# Paso 6: revise los ajustes de configuración del clúster de Amazon EMR
Los ajustes de configuración especifican detalles acerca de cómo se ejecuta un clúster, como cuántas veces se vuelve a intentar una tarea y la cantidad de memoria que hay disponible para clasificación. Al lanzar un clúster con Amazon EMR, existen ajustes específicos de Amazon EMR además de los ajustes de configuración estándar de Hadoop. Los ajustes de configuración se almacenan en el nodo principal del clúster. Puede comprobar los ajustes de configuración para asegurarse de que su clúster tenga los recursos que necesita para ejecutarse de forma eficaz.
Amazon EMR define los ajustes de configuración de Hadoop predeterminados que utiliza para lanzar un clúster. Los valores se basan en la AMI y el tipo de instancia que especifique para el clúster. Puede modificar los ajustes de configuración a partir de los valores predeterminados mediante una acción de arranque o especificando nuevos valores en parámetros de ejecución de trabajo. Para obtener más información, consulte [Creación de acciones de arranque para instalar software adicional con un clúster de Amazon EMR](emr-plan-bootstrap.md). Para determinar si una acción de arranque ha cambiado los ajustes de configuración, compruebe los registros de la acción de arranque.
Amazon EMR registra los ajustes de Hadoop utilizados para ejecutar cada trabajo. Los datos de registro se almacenan en un archivo `job_job-id_conf.xml` denominado en el `/mnt/var/log/hadoop/history/` directorio del nodo principal, donde *job-id* se sustituyen por el identificador del trabajo. Si ha activado el archivado de registros, estos datos se copian en Amazon S3 en la `logs/date/jobflow-id/jobs` carpeta, donde aparece la fecha en que *date* se ejecutó el trabajo y *jobflow-id* es el identificador del clúster.
Los siguientes ajustes de configuración de trabajo de Hadoop son especialmente útiles para investigar los problemas de rendimiento. Para obtener más información acerca de los ajustes de configuración de Hadoop y cómo afectan al comportamiento de Hadoop, visite [http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/).
**aviso**
Establecer `dfs.replication` en 1 en clústeres con menos de cuatro nodos puede conllevar la pérdida de datos del HDFS si un solo nodo deja de funcionar. Se recomienda que utilice un clúster con al menos cuatro nodos principales para las cargas de trabajo de producción.
Amazon EMR no permitirá que los clústeres escalen los nodos principales por debajo de `dfs.replication`. Por ejemplo, si `dfs.replication = 2`, el número mínimo de nodos principales es 2.
Cuando utiliza el escalado administrado, el escalado automático o decide cambiar el tamaño del clúster manualmente, se recomienda que establezca `dfs.replication` en 2 o más.
| Opción de configuración | Description (Descripción) |
| --- | --- |
| dfs.replication | El número de nodos de HDFS en los que un bloque único (como el bloque de disco duro) se copian para producir un entorno similar a RAID. Determina el número de nodos de HDFS que contienen una copia del bloque. |
| io.sort.mb | Memoria total disponible para clasificación. Este valor debería ser 10x io.sort.factor. Este ajuste también puede utilizarse para calcular la memoria total utilizada por el nodo de tareas calculando io.sort.mb multiplicado por mapred.tasktracker.ap.tasks.maximum. |
| io.sort.spill.percent | Utilizado durante la clasificación, momento en que el disco empezará a utilizarse porque la memoria de clasificación asignada se está llenando. |
| mapred.child.java.opts | Obsoleto. Utilice mapred.map.child.java.opts y mapred.reduce.child.java.opts en su lugar. Las opciones de Java que se TaskTracker utilizan al lanzar una JVM para ejecutar una tarea en ella. Un parámetro común es “-Xmx” para configurar el tamaño de memoria máximo. |
| mapred.map.child.java.opts | Las opciones de Java se TaskTracker utilizan al lanzar una JVM para ejecutar una tarea de mapa en ella. Un parámetro común es “-Xmx” para configurar el tamaño de montón de memoria máximo. |
| mapred.map.tasks.speculative.execution | Determina si los intentos de tarea Map de la misma tarea se pueden lanzar en paralelo. |
| mapred.reduce.tasks.speculative.execution | Determina si los intentos de tarea Reduce de la misma tarea se pueden lanzar en paralelo. |
| mapred.map.max.attempts | El número máximo de veces que se puede intentar una tarea Map. Si todos fallan, entonces la tarea Map se marca como error. |
| mapred.reduce.child.java.opts | Las opciones de Java que se TaskTracker utilizan al lanzar una JVM reducen la cantidad de tareas que se pueden ejecutar en ella. Un parámetro común es “-Xmx” para configurar el tamaño de montón de memoria máximo. |
| mapred.reduce.max.attempts | El número máximo de veces que se puede intentar una tarea Reduce. Si todos fallan, entonces la tarea Map se marca como error. |
| mapred.reduce.slowstart.completed.maps | La cantidad de tareas Map que deben completar antes de intentar las tareas Reduce. Si no se espera lo suficiente, se podrían devolver errores “Demasiados errores de recuperación” en los intentos. |
| mapred.reuse.jvm.num.tasks | Una tarea se ejecuta dentro de una única JVM. Especifica cuántas tareas podría reutilizar la misma JVM. |
| mapred.tasktracker.map.tasks.maximum | La cantidad máxima de tareas que se pueden ejecutar en paralelo por nodo de tareas durante el mapeo. |
| mapred.tasktracker.reduce.tasks.maximum | La cantidad máxima de tareas que se pueden ejecutar en paralelo por nodo de tareas durante la reducción. |
Si las tareas de clúster utilizan mucha memoria, puede mejorar el rendimiento utilizando menos tareas por nodo secundario y reduciendo el tamaño de montón de rastreador de trabajos.
# Paso 7: examine los datos de entrada del clúster de Amazon EMR
Compruebe los datos de entrada. ¿Están distribuidos de manera uniforme entre los valores clave? Si los datos están muy sesgados hacia uno o varios valores clave, la carga de procesamiento podría estar asignada a un pequeño número de nodos, mientras que los demás nodos están inactivos. Esta distribución desequilibrada de trabajo puede dar lugar a tiempos de procesamiento más lentos.
Un ejemplo de conjunto de datos desequilibrado sería la ejecución de un clúster para alfabetizar palabras, pero disponer de un conjunto de datos que contenga solo palabras que comienzan con la letra "a". Cuando el trabajo se ha planificado, los valores de procesamiento del nodo que comienzan por "a" serían abrumadores, mientras que los nodos que procesan palabras que comienzan por otras letras estarían inactivos.
# Solución de problemas comunes al utilizar Amazon EMR AWS con Lake Formation
Esta sección le guía por el proceso de resolución de problemas comunes al utilizar Amazon EMR con AWS Lake Formation.
## No se permite el acceso al lago de datos
Debe optar explícitamente por el filtrado de datos en los clústeres de Amazon EMR antes de poder analizar y procesar los datos de su lago de datos. Cuando se produzca un error en el acceso a los datos, verá un mensaje `Access is not allowed` genérico en el resultado de las entradas de su bloc de notas.
Para activar y permitir el filtrado de datos en Amazon EMR, consulte [Permitir el filtrado de datos en Amazon EMR](https://docs.aws.amazon.com/lake-formation/latest/dg/getting-started-setup.html#emr-switch) en la *Guía para desarrolladores de AWS Lake Formation * para obtener instrucciones.
## Vencimiento de la sesión
El tiempo de espera para EMR Notebooks y Zeppelin se controla mediante el rol de IAM para la configuración `Maximum CLI/API session duration` de Lake Formation. El valor predeterminado para esta configuración es de una hora. Cuando se agote el tiempo de espera de una sesión, verá el siguiente mensaje en el resultado de las entradas de su bloc de notas al intentar ejecutar los comandos de Spark SQL.
```
Error 401 HTTP ERROR: 401 Problem accessing /sessions/2/statements.
Reason: JWT token included in request failed validation.
Powered by Jetty:// 9.3.24.v20180605 org.springframework.web.client.HttpClientErrorException: 401 JWT token included in request failed validation…
```
Para validar su sesión actualice la página. Se le pedirá que vuelva a autenticarse con su IdP y se le redirigirá de vuelta al bloc de notas. Puede continuar ejecutando consultas después de la segunda autenticación.
## No hay permisos para el usuario en la tabla solicitada
Al intentar acceder a una tabla a la que no tiene acceso, verá la siguiente excepción en el resultado de las entradas de su bloc de notas al intentar ejecutar comandos de Spark SQL.
```
org.apache.spark.sql.AnalysisException: org.apache.hadoop.hive.ql.metadata.HiveException: Unable to fetch table table.
Resource does not exist or requester is not authorized to access requested permissions.
(Service: AWSGlue; Status Code: 400; Error Code: AccessDeniedException; Request ID: …
```
Para obtener acceso a la tabla, debe conceder acceso al usuario. Para ello, actualice los permisos asociados a esta tabla en Lake Formation.
## Consulta de datos entre cuentas compartidos con Lake Formation
Al usar Amazon EMR para acceder a los datos compartidos desde otra cuenta, algunas bibliotecas de Spark intentarán llamar a la operación de la API `Glue:GetUserDefinedFunctions`. Como las versiones 1 y 2 de los permisos AWS RAM administrados no admiten esta acción, recibirá el siguiente mensaje de error:
`"ERROR: User: arn:aws:sts::012345678901:assumed-role/my-spark-role/i-06ab8c2b59299508a is not authorized to perform: glue:GetUserDefinedFunctions on resource: arn:exampleCatalogResource because no resource-based policy allows the glue:GetUserDefinedFunctions action"`
Para resolver este error, el administrador del lago de datos que creó el recurso compartido debe actualizar los permisos AWS RAM administrados asociados al recurso compartido. La versión 3 de los permisos administrados de AWS RAM permite a las entidades principales llevar a cabo la acción `glue:GetUserDefinedFunctions`.
Si crea un nuevo recurso compartido, Lake Formation aplica la última versión del permiso AWS RAM gestionado de forma predeterminada y no es necesario que realice ninguna acción. Para habilitar el acceso a los datos entre cuentas para los recursos compartidos existentes, debe actualizar los permisos AWS RAM administrados a la versión 3.
Puede ver los AWS RAM permisos asignados a los recursos compartidos con usted en AWS RAM. Los siguientes permisos se incluyen en la versión 3:
```
Databases
AWSRAMPermissionGlueDatabaseReadWriteForCatalog
AWSRAMPermissionGlueDatabaseReadWrite
Tables
AWSRAMPermissionGlueTableReadWriteForCatalog
AWSRAMPermissionGlueTableReadWriteForDatabase
AllTables
AWSRAMPermissionGlueAllTablesReadWriteForCatalog
AWSRAMPermissionGlueAllTablesReadWriteForDatabase
```
**Para actualizar la versión de los permisos AWS RAM administrados de los recursos compartidos existentes**
Usted (administrador del lago de datos) puede [actualizar los permisos AWS RAM administrados a una versión más reciente](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-update-permissions.html) siguiendo las instrucciones de la *Guía del AWS RAM usuario* o puede revocar todos los permisos existentes para el tipo de recurso y volver a concederlos. Si revoca los permisos, AWS RAM elimina el AWS RAM recurso compartido asociado al tipo de recurso. Al volver a conceder los permisos, AWS RAM crea nuevos recursos compartidos adjuntando la última versión de los permisos gestionados. AWS RAM
## Inserción, creación y alteración de tablas
No se admite la inserción, creación ni alteración de tablas en las bases de datos protegidas por políticas de Lake Formation. Al realizar estas operaciones, verá la siguiente excepción en el resultado de las entradas de su bloc de notas al intentar ejecutar los comandos de Spark SQL:
```
java.io.IOException: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.AmazonS3Exception:
Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: …
```
Para obtener más información, consulte [Limitaciones de la integración de Amazon EMR con. AWS Lake Formation](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lf-scope.html#emr-lf-limitations)