View a markdown version of this page

Descripción de la estrategia y los escenarios de asignación de nodos de Amazon EMR - Amazon EMR
Estrategia de asignación de nodosConsideraciones sobre la asignación de nodosEscenarios de asignación de nodos

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.

Descripción de la estrategia y los escenarios de asignación de nodos de Amazon EMR

En esta sección se ofrece información general sobre la estrategia de asignación de nodos y los escenarios de escalado comunes que puede utilizar con Escalado administrado de Amazon EMR.

Estrategia de asignación de nodos

Escalado administrado de Amazon EMR asigna los nodos principales y de tarea en función de las siguientes estrategias de escalado y reducción verticales:

Scale-up estrategia

  • Para las versiones 7.2 y posteriores de Amazon EMR, el escalado administrado añade primero los nodos en función de las etiquetas de los nodos y de la propiedad YARN, que restringe el proceso de aplicación.

  • Por ejemplo, si utiliza la versión 7.2 o posteriores de Amazon EMR, si habilita las etiquetas de nodos y restringe el proceso de aplicación a los nodos CORE, el escalado administrado de Amazon EMR escala verticalmente los nodos básicos y los nodos de tarea si aumenta la demanda del proceso de aplicación y aumenta la demanda del ejecutor. Igualmente, si habilitó las etiquetas de nodos y restringió los procesos de aplicación a los nodos ON_DEMAND, el escalado administrado escala verticalmente los nodos bajo demanda si aumenta la demanda del proceso de aplicación y se escalan verticalmente los nodos Spot si aumenta la demanda del ejecutor.

  • Si las etiquetas de nodos no están habilitadas, la ubicación de los procesos de aplicación no está restringida a ningún nodo o tipo de mercado.

  • Al usar etiquetas de nodos, el escalado administrado puede escalar verticalmente y reducir verticalmente diferentes grupos de instancias y flotas de instancias en la misma operación de cambio de tamaño. Por ejemplo, en un escenario en el que instance_group1 tiene un nodo ON_DEMAND y instance_group2 tiene un nodo SPOT, y las etiquetas de nodo están habilitadas y los procesos de aplicación están restringidos a los nodos con la etiqueta ON_DEMAND. El escalado administrado reducirá verticalmente instance_group1 y escalará verticalmente instance_group2 si la demanda del proceso de aplicación disminuye y la demanda del ejecutor aumenta.

  • Cuando Amazon EMR experimenta un retraso en el escalado vertical con el grupo de instancias actual, los clústeres que usan el escalado administrado cambian automáticamente a un grupo de instancias de tareas diferente.

  • Si el parámetro MaximumCoreCapacityUnits está establecido, Amazon EMR escala los nodos principales hasta que las unidades principales alcanzan el límite máximo permitido. Toda la capacidad restante se agrega a los nodos de tarea.

  • Si el MaximumOnDemandCapacityUnits parámetro está establecido, Amazon EMR escala el clúster mediante las On-Demand instancias hasta que las On-Demand unidades alcancen el límite máximo permitido. Toda la capacidad restante se agrega mediante instancias de spot.

  • Si se establecen los parámetros MaximumCoreCapacityUnits y MaximumOnDemandCapacityUnits, Amazon EMR tiene en cuenta ambos límites durante el escalado.

    Por ejemplo, si MaximumCoreCapacityUnits es inferior a MaximumOnDemandCapacityUnits, Amazon EMR primero escala los nodos principales hasta alcanzar el límite de capacidad principal. Para la capacidad restante, Amazon EMR utiliza primero las On-Demand instancias para escalar los nodos de tareas hasta alcanzar el On-Demand límite y, a continuación, utiliza las instancias puntuales para los nodos de tareas.

Scale-down estrategia

  • De forma similar a la estrategia de escalado vertical, Amazon EMR elimina los nodos en función de las etiquetas de los nodos. Para más información sobre las etiquetas de los nodos, consulte Descripción de los tipos de nodos: principales, básicos y de tareas.

  • Si no ha habilitado las etiquetas de nodo, el escalado administrado elimina los nodos de tarea y, a continuación, elimina los nodos básicos hasta que alcanza la capacidad objetivo de reducción vertical deseada. El escalado administrado nunca reduce verticalmente el clúster por debajo de las restricciones mínimas de la política de escalado administrado.

  • Las versiones 5.34.0 y posteriores de Amazon EMR y las versiones 6.4.0 y posteriores de Amazon EMR admiten el reconocimiento de datos aleatorios de Spark, lo que previene que una instancia de reduzca verticalmente mientras el escalado administrado reconoce los datos aleatorios existentes. Para más información sobre las operaciones de mezclas aleatorias, consulte Spark Programming Guide. El escalado administrado hace todo lo posible para evitar la reducción vertical de los nodos con datos aleatorios de la fase actual y anterior de cualquier aplicación de Spark activa, durante un máximo de 30 minutos. Esto ayuda a minimizar la pérdida involuntaria de datos aleatorios, lo que evita la necesidad de volver a intentar el trabajo y volver a calcular los datos intermedios. Sin embargo, no se garantiza la prevención de la pérdida de datos aleatorios. Para mejorar la protección contra la reproducción aleatoria de Spark, recomendamos detectar la reproducción aleatoria en grupos con la etiqueta de lanzamiento 7.4 o superior. Añade los siguientes indicadores a la configuración del clúster para mejorar la protección contra el Spark Shuffle.

    • Si se ha cambiado el yarn.nodemanager.shuffledata-monitor.interval-ms indicador (predeterminado, 30 000 ms) o el spark.dynamicAllocation.executorIdleTimeout (predeterminado, 60 segundos) con respecto a los valores predeterminados, actualice el indicador necesario para asegurarse de que se spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms mantenga true la condición.

      [
	{
		"Classification": "yarn-site",
		"Properties": { 
		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
		}
	},
	{
		"Classification": "spark-defaults",
		"Properties": {
		"spark.dynamicAllocation.enabled": "true",
		"spark.shuffle.service.removeShuffle": "true"
		}
	}
]

  • El escalado administrado elimina primero los nodos de tarea y, a continuación, elimina los nodos básicos hasta que se alcanza la capacidad objetivo de reducción vertical deseada. El clúster nunca se escala por debajo de las restricciones mínimas de la política de escalado administrado.

  • Para los clústeres que se lanzan con Amazon EMR 5.x, versión 5.34.0 y posteriores, y 6.x, versión 6.4.0 y posteriores, Amazon EMR Managed Scaling no reduce la escala de los nodos que tienen ApplicationMaster para Apache Spark, si hay etapas activas en las aplicaciones que se ejecutan en ellos. Esto minimiza los errores y los reintentos en los trabajos, lo que ayuda a mejorar el rendimiento de los trabajos y a reducir los costos. Para confirmar qué nodos del clúster se ejecutan ApplicationMaster, visite el servidor del historial de Spark y filtre el controlador en la pestaña Ejecutores del ID de aplicación de Spark.

  • Si bien el escalado inteligente con el escalado administrado de EMR minimiza la pérdida de datos aleatorios para Spark, puede haber casos en los que los datos aleatorios transitorios no estén protegidos durante una reducción vertical. Para mejorar la resiliencia de los datos aleatorios durante la reducción vertical, recomendamos habilitar Graceful Decommissioning for Shuffle Data en YARN. Cuando la función Graceful Decommissioning for Shuffle Data está habilitada en YARN, los nodos seleccionados para la reducción vertical que contengan datos aleatorios pasarán al estado de retirada y seguirán distribuyendo archivos aleatorios. El YARN ResourceManager espera a que los nodos notifiquen que no hay ningún archivo aleatorio presente antes de eliminar los nodos del clúster.

    • La versión 6.11.0 y las versiones posteriores de Amazon EMR permiten desmantelar sin problemas los datos Yarn-based de Hive Shuffle tanto para los controladores Tez como para los Shuffle. MapReduce

      • Habilite Graceful Decommissioning for Shuffle Data configurando yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data en true.

    • La versión 7.4.0 y las versiones posteriores de Amazon EMR permiten el desmantelamiento Yarn-based sin problemas de los datos de Spark shuffle cuando el servicio de reproducción aleatoria externo está habilitado (habilitado de forma predeterminada en EMR en EC2).

      • El comportamiento predeterminado del servicio aleatorio externo de Spark, cuando se ejecuta Spark en Yarn, es que Yarn elimine los archivos de reproducción aleatoria de las aplicaciones en el momento de la finalización de la NodeManager aplicación. Esto puede afectar a la velocidad de retirada de los nodos y a la utilización del cómputo. En el caso de las aplicaciones de ejecución prolongada, considere la posibilidad de configurar spark.shuffle.service.removeShuffle en true para eliminar los archivos aleatorios que ya no se utilizan y poder retirar más rápidamente los nodos sin datos aleatorios activos.

    • Para minimizar la pérdida de datos de Spark Shuffle en Amazon EMR versión 7.4.0 y versiones posteriores, considere configurar los siguientes indicadores.

      • Si el yarn.nodemanager.shuffledata-monitor.interval-ms indicador (predeterminado, 30 000 ms) o el spark.dynamicAllocation.executorIdleTimeout (predeterminado, 60 segundos) ha cambiado con respecto a los valores predeterminados, actualice el indicador necesario para asegurarse de que se spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms mantenga true la condición.

        [
	{
		"Classification": "yarn-site",
		"Properties": { 
		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
		}
	},
	{
		"Classification": "spark-defaults",
		"Properties": {
		"spark.dynamicAllocation.enabled": "true",
		"spark.shuffle.service.removeShuffle": "true"
		}
	}
]

Si el clúster no tiene ninguna carga, Amazon EMR cancela la adición de nuevas instancias de una evaluación anterior y realiza operaciones de reducción vertical. Si el clúster tiene una carga elevada, Amazon EMR cancela la eliminación de instancias y realiza operaciones de escalado vertical.

Consideraciones sobre la asignación de nodos

Le recomendamos que utilice la opción de On-Demand compra para los nodos principales a fin de evitar la pérdida de datos del HDFS en caso de recuperación puntual. Puede utilizar la opción de compra puntual para los nodos de tarea a fin de reducir los costos y agilizar la ejecución de los trabajos cuando se agreguen más instancias de spot a los nodos de tarea.

Escenarios de asignación de nodos

Puede crear varios escenarios de escalado en función de sus necesidades configurando los parámetros máximo, mínimo, On-Demand límite y máximo del nodo central en diferentes combinaciones.

Escenario 1: escalar únicamente los nodos principales

Para escalar únicamente los nodos principales, los parámetros de escalado administrado deben cumplir los siguientes requisitos:

  • El On-Demand límite es igual al límite máximo.

  • El máximo de nodos principales es igual al límite máximo.

Cuando no se especifican los parámetros On-Demand límite y máximo del nodo principal, ambos parámetros se establecen de forma predeterminada en el límite máximo.

Este escenario no es aplicable si utiliza el escalado administrado con etiquetas de nodos y restringe los procesos de su aplicación para que solo se ejecuten en los nodos CORE, ya que el escalado administrado escala los nodos de tareas para adaptarlos a la demanda de los ejecutores.

En los siguientes ejemplos, se muestra el escenario de escalado de nodos principales únicamente.

Estado inicial del clúster Parámetros de escalado Comportamiento del escalado

Grupos de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand y 1 punto

UnitType: instancias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Escale entre 1 y 20 instancias o unidades de flota de instancias en los nodos principales según el On-Demand tipo. No se puede escalar en los nodos de tarea.

Si utiliza el escalado administrado con etiquetas de nodos y restringe los procesos de las aplicaciones a nodos ON_DEMAND, el clúster escalará de 1 a 20 instancias o unidades de flota de instancias en los nodos CORE utilizando el tipo Spot o On-Demand, en función del tipo de demanda.

Flotas de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand y 1 punto

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Escenario 2: escalar únicamente los nodos de tarea

Para escalar únicamente los nodos de tarea, los parámetros de escalado administrado deben cumplir el siguiente requisito:

  • El máximo de nodos principales debe ser igual al límite mínimo.

En los siguientes ejemplos, se muestra el escenario de escalado de nodos de tarea únicamente.

Estado inicial del clúster Parámetros de escalado Comportamiento del escalado

Grupos de instancias

Núcleo: 2 On-Demand

Tarea: 1 de spot

UnitType: instancias

MinimumCapacityUnits: 2

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits: 2

Mantenga los nodos principales estables en 2 y escale únicamente los nodos de tarea entre 0 y 18 instancias o unidades de flota de instancias. La capacidad entre los límites mínimo y máximo se agrega únicamente a los nodos de tarea.

Cuando utiliza el escalado administrado con etiquetas de nodo y restringe los procesos de sus aplicaciones a nodos ON_DEMAND, el clúster mantendrá los nodos básicos estables en 2 y solo escalará los nodos de tareas entre 0 y 18 instancias o unidades de flota de instancias que usen el tipo On-demand o Spot, según el tipo de demanda.

Flotas de instancias

Núcleo: 2 On-Demand

Tarea: 1 de spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 2

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits: 2

Escenario 3: solo On-Demand instancias del clúster

Para tener solo On-Demand instancias, el clúster y los parámetros de escalado gestionado deben cumplir los siguientes requisitos:

  • El On-Demand límite es igual al límite máximo.

    Si no se especifica el On-Demand límite, el valor del parámetro se establece por defecto en el límite máximo. El valor predeterminado indica que Amazon EMR solo escala las On-Demand instancias.

Si el máximo de nodos principales es inferior al límite máximo, el parámetro del máximo de nodos principales se puede utilizar para dividir la asignación de capacidad entre los nodos principales y de tarea.

Para habilitar este escenario en un clúster compuesto por grupos de instancias, todos los grupos de nodos del clúster deben usar el tipo de On-Demand mercado durante la configuración inicial.

Este escenario no es aplicable si utiliza el escalado administrado con etiquetas de nodo y restringe los procesos de las aplicaciones para que solo se ejecuten en los nodos ON_DEMAND, ya que el escalado gestionado escala los nodos Spot para adaptarse a la demanda de los ejecutores.

Los siguientes ejemplos muestran el escenario en el que On-Demand hay instancias en todo el clúster.

Estado inicial del clúster Parámetros de escalado Comportamiento del escalado

Grupos de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand

UnitType: instancias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Escale entre 1 y 12 instancias o unidades de flota de instancias en los nodos principales mediante el On-Demand tipo. Escale la capacidad restante utilizando On-Demand los nodos de tareas. No se puede escalar con instancias de spot.

Si utiliza el escalado administrado con etiquetas de nodos y restringe los procesos de las aplicaciones a los nodos CORE, el clúster escala entre 1 y 20 instancias o unidades de flota de instancias en los nodos CORE o los nodos task que utilizan ese tipo ON_DEMAND, según el tipo de demanda. El escalado en los nodos básicos no superará las 12 instancias o unidades de flota de instancias.

Flotas de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Escenario 4: solo las instancias de spot del clúster

Para tener únicamente instancias de spot, los parámetros de escalado administrado deben cumplir el siguiente requisito:

  • On-Demand el límite está establecido en 0.

Si el máximo de nodos principales es inferior al límite máximo, el parámetro del máximo de nodos principales se puede utilizar para dividir la asignación de capacidad entre los nodos principales y de tarea.

Para habilitar este escenario en un clúster compuesto por grupos de instancias, el grupo de instancias principales debe usar la opción de compra de spot durante la configuración inicial. Si no hay ninguna instancia de spot en el grupo de instancias de las tareas, Escalado administrado de Amazon EMR crea un grupo de tareas que utiliza instancias de spot cuando es necesario.

Este escenario no es aplicable si utiliza el escalado administrado con etiquetas de nodo y restringe los procesos de sus aplicaciones para que solo se ejecuten en los nodos ON_DEMAND, ya que el escalado administrado escala los nodos ON_DEMAND para adaptarse a la demanda de los procesos de aplicación.

En los siguientes ejemplos, se muestra el escenario en el que hay instancias de spot en todo el clúster.

Estado inicial del clúster Parámetros de escalado Comportamiento del escalado

Grupos de instancias

Principal: 1 de spot

Tarea: 1 de spot

UnitType: instancias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Escale entre 1 y 20 instancias o unidades de flota de instancias en los nodos principales mediante el tipo de spot. No se puede escalar mediante el On-Demand tipo.

Cuando utiliza el escalado administrado con etiquetas de nodos y restringe los procesos de sus aplicaciones a nodos CORE, el clúster escala entre 1 y 20 instancias o unidades de flota de instancias en nodos CORE o TASK que utilizan Spot, según el tipo de demanda. Amazon EMR no escala mediante el tipo ON_DEMAND.

Flotas de instancias

Principal: 1 de spot

Tarea: 1 de spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Escenario 5: escale On-Demand las instancias en los nodos principales e instancias puntuales en los nodos de tareas

Para escalar On-Demand las instancias en los nodos principales y las instancias puntuales en los nodos de tareas, los parámetros de escalado gestionado deben cumplir los siguientes requisitos:

  • El On-Demand límite debe ser igual al nodo central máximo.

  • Tanto el On-Demand límite como el nodo de núcleo máximo deben ser inferiores al límite máximo.

Para habilitar este escenario en un clúster compuesto por grupos de instancias, el grupo de nodos principal debe usar la opción de On-Demand compra.

Este escenario no es aplicable si utiliza el escalado administrado con etiquetas de nodo y restringe los procesos de su aplicación para que solo se ejecuten en nodos ON_DEMAND o en nodos CORE.

Los siguientes ejemplos muestran el escenario en el que las On-Demand instancias se escalan en los nodos principales y las instancias puntuales en los nodos de tareas.

Estado inicial del clúster Parámetros de escalado Comportamiento del escalado

Grupos de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand y 1 punto

UnitType: instancias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Escale hasta 6 On-Demand unidades en el nodo principal, ya que ya hay 1 On-Demand unidad en el nodo de tarea y el límite máximo On-Demand es de 7. A continuación, escale hasta 13 unidades de spot en los nodos de tarea.

Flotas de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand y 1 punto

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Escenario 6: escale las instancias CORE según la demanda del proceso de la aplicación y las instancias TASK según la demanda de los ejecutores.

Este escenario no es aplicable si utiliza el escalado administrado con etiquetas de nodo y restringe los procesos de su aplicación para que solo se ejecuten en nodos CORE.

Para escalar los nodos CORE en función de la demanda del proceso de la aplicación y los nodos TASK en función de la demanda del ejecutor, debe establecer las siguientes configuraciones al lanzar el clúster:

  • yarn.node-labels.enabled:true

  • yarn.node-labels.am.default-node-label-expression: 'CORE'

Si no especifica el límite ON_DEMAND y los parámetros máximos de nodos CORE, ambos parámetros se establecen de forma predeterminada en el límite máximo.

Si el máximo de nodos ON_DEMAND es inferior al límite máximo, el escalado administrado usa el parámetro máximo de nodos ON_DEMAND para dividir la asignación de capacidad entre los nodos ON_DEMAND y SPOT. Si establece el parámetro máximo de nodo CORE en un valor inferior o igual al parámetro de capacidad mínima, los nodos CORE permanecen estáticos con la capacidad máxima básica.

En los siguientes ejemplos, se muestra el escenario en el que se escalan las instancias CORE en función de la demanda de procesos de aplicación y las instancias TASK en función de la demanda del ejecutor.

Estado inicial del clúster Parámetros de escalado Comportamiento del escalado

Grupos de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand

UnitType: instancias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Escala CORE los nodos entre 1 y 20 nodos en función de la demanda del proceso de solicitud del clúster, utilizando el tipo de mercado On-Demand o spot. Escala los nodos TASK en función de la demanda del ejecutor y de la capacidad restante disponible después de que Amazon EMR asigne los nodos CORE.

La suma de los nodos TASK y CORE solicitados no superará la maximumCapacity de 20. La suma de los nodos básicos bajo demanda y de los nodos de tareas bajo demanda solicitados no superará la maximumOnDemandCapacity de 10. Los nodos básicos o de tareas adicionales utilizan el tipo de mercado o de Spot.

Flotas de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Escenario 7: escale las instancias ON_DEMAND según la demanda del proceso de aplicación y las instancias SPOT según la demanda de los ejecutores.

Este escenario no es aplicable si utiliza el escalado administrado con etiquetas de nodo y restringe los procesos de su aplicación para que solo se ejecuten en nodos ON_DEMAND.

Para escalar los nodos ON_DEMAND en función de la demanda del proceso de la aplicación y los nodos SPOT en función de la demanda del ejecutor, debe establecer las siguientes configuraciones al lanzar el clúster:

  • yarn.node-labels.enabled:true

  • yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'

Si no especifica el límite ON_DEMAND y los parámetros máximos de nodos CORE, ambos parámetros se establecen de forma predeterminada en el límite máximo.

Si el máximo de nodos CORE es inferior al límite máximo, el escalado administrado usa el parámetro máximo de nodos CORE para dividir la asignación de capacidad entre los nodos CORE y TASK. Si establece el parámetro máximo de nodo CORE en un valor inferior o igual al parámetro de capacidad mínima, los nodos CORE permanecen estáticos con la capacidad máxima básica.

Los siguientes ejemplos muestran el escenario en el que se escalan las On-Demand instancias en función de la demanda del proceso de aplicación y las instancias puntuales en función de la demanda de los ejecutores.

Estado inicial del clúster Parámetros de escalado Comportamiento del escalado

Grupos de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand

UnitType: instancias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10

Escala los nodos ON_DEMAND entre 1 y 20 nodos en función de la demanda de procesos de aplicación del clúster mediante el tipo de nodo CORE o TASK. Escala los nodos SPOT en función de la demanda del ejecutor y de la capacidad restante disponible después de que Amazon EMR asigne los nodos ON_DEMAND.

La suma de los nodos SPOT y ON_DEMAND solicitados no superará la maximumCapacity de 20. La suma de los nodos básicos bajo demanda y los nodos básicos de Spot solicitados no superará la maximumCoreCapacity de 10. Los nodos de Spot o bajo demanda adicionales utilizan el tipo de nodo TASK.

Flotas de instancias

Núcleo: 1 On-Demand

Tarea: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10