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. # 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.