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
<a name="managed-scaling-allocation-strategy"></a>

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
<a name="node-allocation-strategy"></a>

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: 

**Estrategia de escalado vertical**
+ 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 parámetro `MaximumOnDemandCapacityUnits` está establecido, Amazon EMR escala el clúster mediante las instancias bajo demanda hasta que las unidades bajo demanda alcanzan 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 instancias bajo demanda para escalar los nodos de tarea hasta alcanzar el límite bajo demanda y, a continuación, utiliza las instancias de spot para los nodos de tarea. 

**Estrategia de reducción vertical**
+ 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](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html).
+ 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](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). 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 los grupos con la etiqueta de publicación 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 admiten el desmantelamiento gradual basado en Yarn para los datos 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 admiten la retirada gradual basada en YARN para los datos aleatorios de Spark cuando el servicio de aleatorización externo está habilitado (habilitado de forma predeterminada en EMR en EC2).
    + El comportamiento predeterminado del servicio de reproducción aleatoria 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 aplicación. NodeManager 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
<a name="node-allocation-considerations"></a>

Le recomendamos que utilice la opción de compra bajo demanda para los nodos principales a fin de evitar la pérdida de datos de HDFS en caso de recuperación de spot. 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
<a name="node-allocation-scenarios"></a>

Puede crear varios escenarios de escalado en función de sus necesidades configurando los parámetros máximo, mínimo, límite bajo demanda y máximo de nodos principales 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 límite bajo demanda 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 del límite bajo demanda y el máximo de nodos principales, 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.


<table>
<thead>
  <tr><th>Estado inicial del clúster</th><th>Parámetros de escalado</th><th>Comportamiento del escalado</th></tr>
</thead>
<tbody>
  <tr><td>**Grupos de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 bajo demanda y 1 de spot</td><td>`UnitType`: instancias<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 20</td><td rowspan="2">Escale entre 1 y 20 instancias o unidades de flota de instancias en los nodos principales mediante el tipo bajo demanda. No se puede escalar en los nodos de tarea.<br />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.</td></tr>
  <tr><td>**Flotas de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 bajo demanda y 1 de spot</td><td>UnitType: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 20</td></tr>
</tbody>
</table>


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


<table>
<thead>
  <tr><th>Estado inicial del clúster</th><th>Parámetros de escalado</th><th>Comportamiento del escalado</th></tr>
</thead>
<tbody>
  <tr><td>**Grupos de instancias**<br />Principal: 2 bajo demanda<br />Tarea: 1 de spot</td><td>`UnitType`: instancias<br />`MinimumCapacityUnits`: 2<br />`MaximumCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 2</td><td rowspan="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.<br /> 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. </td></tr>
  <tr><td>**Flotas de instancias**<br />Principal: 2 bajo demanda<br />Tarea: 1 de spot</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 2<br />`MaximumCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 2</td></tr>
</tbody>
</table>


**Escenario 3: solo las instancias bajo demanda del clúster**

Para tener únicamente instancias bajo demanda, el clúster y los parámetros de escalado administrado deben cumplir el siguiente requisito: 
+ El límite bajo demanda es igual al límite máximo. 

  Si no se especifica el límite bajo demanda, el valor del parámetro se establece de forma predeterminada en el límite máximo. El valor predeterminado indica que Amazon EMR escala únicamente las instancias bajo demanda. 

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 compra bajo demanda 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.

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


<table>
<thead>
  <tr><th>Estado inicial del clúster</th><th>Parámetros de escalado</th><th>Comportamiento del escalado</th></tr>
</thead>
<tbody>
  <tr><td>**Grupos de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 baja demanda </td><td>`UnitType`: instancias<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 12</td><td rowspan="2">Escale entre 1 y 12 instancias o unidades de flota de instancias en los nodos principales mediante el tipo bajo demanda. Escale la capacidad restante mediante el tipo bajo demanda en los nodos de tarea. No se puede escalar con instancias de spot.<br /> 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. </td></tr>
  <tr><td>**Flotas de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 baja demanda</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 12</td></tr>
</tbody>
</table>


**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: 
+ El límite bajo demanda 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.


<table>
<thead>
  <tr><th>Estado inicial del clúster</th><th>Parámetros de escalado</th><th>Comportamiento del escalado</th></tr>
</thead>
<tbody>
  <tr><td>**Grupos de instancias**<br />Principal: 1 de spot<br />Tarea: 1 de spot</td><td>`UnitType`: instancias<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 0</td><td rowspan="2">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 con el tipo bajo demanda.<br />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`.</td></tr>
  <tr><td>**Flotas de instancias**<br />Principal: 1 de spot<br />Tarea: 1 de spot</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 0</td></tr>
</tbody>
</table>


**Escenario 5: escalar las instancias bajo demanda en los nodos principales y las instancias de spot en los nodos de tarea**

Para escalar las instancias bajo demanda en los nodos principales y las instancias de spot en los nodos de tarea, los parámetros de escalado administrado deben cumplir los siguientes requisitos: 
+ El límite bajo demanda debe ser igual al máximo de nodos principales.
+ Tanto el límite bajo demanda como el máximo de nodos principales 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 principales debe usar la opción de compra bajo demanda.

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

En los siguientes ejemplos, se muestra el escenario en el que se escalan las instancias bajo demanda en los nodos principales y las instancias de spot en los nodos de tarea.


<table>
<thead>
  <tr><th>Estado inicial del clúster</th><th>Parámetros de escalado</th><th>Comportamiento del escalado</th></tr>
</thead>
<tbody>
  <tr><td>**Grupos de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 bajo demanda y 1 de spot</td><td>`UnitType`: instancias<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 7 <br />`MaximumCoreCapacityUnits`: 7</td><td rowspan="2">Escale hasta 6 unidades bajo demanda en el nodo principal, ya que ya hay una unidad bajo demanda en el nodo de tarea y el límite máximo de unidades bajo demanda es de 7. A continuación, escale hasta 13 unidades de spot en los nodos de tarea.</td></tr>
  <tr><td>**Flotas de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 bajo demanda y 1 de spot</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 7<br />`MaximumCoreCapacityUnits`: 7</td></tr>
</tbody>
</table>


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


<table>
<thead>
  <tr><th>Estado inicial del clúster</th><th>Parámetros de escalado</th><th>Comportamiento del escalado</th></tr>
</thead>
<tbody>
  <tr><td>**Grupos de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 baja demanda</td><td>`UnitType`: instancias<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 10<br />`MaximumCoreCapacityUnits`: 20</td><td rowspan="2">Escala los nodos `CORE` entre 1 y 20 nodos en función de la demanda de procesos de aplicación del clúster, utilizando el tipo de mercado bajo demanda 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`.<br />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. </td></tr>
  <tr><td>**Flotas de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 baja demanda</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 10<br />`MaximumCoreCapacityUnits`: 20</td></tr>
</tbody>
</table>


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

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


<table>
<thead>
  <tr><th>Estado inicial del clúster</th><th>Parámetros de escalado</th><th>Comportamiento del escalado</th></tr>
</thead>
<tbody>
  <tr><td>**Grupos de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 baja demanda</td><td>`UnitType`: instancias<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 10</td><td rowspan="2">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`.<br />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`. </td></tr>
  <tr><td>**Flotas de instancias**<br />Principal: 1 bajo demanda<br />Tarea: 1 baja demanda</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 10</td></tr>
</tbody>
</table>