Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Comprendre la stratégie et les scénarios d'allocation des nœuds Amazon EMR
<a name="managed-scaling-allocation-strategy"></a>

Cette section donne un aperçu de la stratégie d'allocation des nœuds et des scénarios de mise à l'échelle courants que vous pouvez utiliser avec la mise à l'échelle gérée par Amazon EMR. 

## Stratégie d'allocation de nœud
<a name="node-allocation-strategy"></a>

La mise à l'échelle gérée par Amazon EMR alloue les nœuds principaux et les nœuds de tâches en fonction des stratégies d'augmentation et de réduction d'échelle suivantes : 

**Scale-up stratégie**
+ Pour les versions 7.2 et supérieures d'Amazon EMR, le dimensionnement géré ajoute d'abord des nœuds en fonction des étiquettes des nœuds et de la propriété YARN de restriction du processus d'application. 
+ Pour les versions 7.2 et supérieures d'Amazon EMR, si vous avez activé les étiquettes de nœuds et restreint les processus d'application aux `CORE` nœuds, le dimensionnement géré par Amazon EMR augmente le dimensionnement des nœuds principaux et des nœuds de tâches si la demande de processus d'application augmente et que la demande d'exécuteurs augmente. De même, si vous avez activé les étiquettes de nœuds et restreint les processus d'application aux `ON_DEMAND` nœuds, le dimensionnement géré augmente les nœuds à la demande si la demande de processus d'application augmente et augmente les nœuds ponctuels si la demande de l'exécuteur augmente.
+ Si les étiquettes de nœuds ne sont pas activées, le placement du processus de candidature n'est limité à aucun nœud ou type de marché.
+ En utilisant des étiquettes de nœuds, le dimensionnement géré peut augmenter ou réduire différents groupes d'instances et flottes d'instances au cours de la même opération de redimensionnement. Par exemple, dans un scénario dans lequel `instance_group1` a un `ON_DEMAND` nœud et `instance_group2` a un `SPOT` nœud, les étiquettes de nœuds sont activées et les processus d'application sont limités aux nœuds portant l'`ON_DEMAND`étiquette. La mise à l'échelle gérée diminuera `instance_group1` et augmentera `instance_group2` si la demande relative au processus de candidature diminue et que la demande des exécuteurs augmente. 
+ Lorsque Amazon EMR subit un retard dans l'augmentation avec le groupe d'instances actuel, les clusters qui utilisent la mise à l'échelle gérée basculent automatiquement vers un autre groupe d'instances de tâches.
+ Si le paramètre `MaximumCoreCapacityUnits` est défini, Amazon EMR adapte les nœuds principaux jusqu'à ce que les unités principales atteignent la limite maximale autorisée. Toute la capacité restante est ajoutée aux nœuds de tâches. 
+ Si le `MaximumOnDemandCapacityUnits` paramètre est défini, Amazon EMR redimensionne le cluster en utilisant les On-Demand instances jusqu'à ce que les On-Demand unités atteignent la limite maximale autorisée. Toute la capacité restante est ajoutée à l'aide d'instances Spot. 
+ Si les paramètres `MaximumCoreCapacityUnits` et `MaximumOnDemandCapacityUnits` sont définis, Amazon EMR prend en compte les deux limites lors de la mise à l'échelle. 

  Par exemple, si `MaximumCoreCapacityUnits` est inférieur à `MaximumOnDemandCapacityUnits`, Amazon EMR augmente d'abord les nœuds principaux jusqu'à ce que la limite de capacité principale soit atteinte. Pour la capacité restante, Amazon EMR utilise d'abord les On-Demand instances pour dimensionner les nœuds de tâches jusqu'à ce que la On-Demand limite soit atteinte, puis utilise des instances ponctuelles pour les nœuds de tâches. 

**Scale-down stratégie**
+ À l'instar de la stratégie de mise à l'échelle, Amazon EMR supprime les nœuds en fonction des étiquettes des nœuds. Pour plus d'informations sur les étiquettes des nœuds, voir [Comprendre les types de nœuds : nœuds principaux, principaux et de tâches](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html).
+ Si vous n'avez pas activé les étiquettes de nœuds, le dimensionnement géré supprime les nœuds de tâches, puis supprime les nœuds principaux jusqu'à ce qu'il atteigne la capacité cible de réduction souhaitée. Le dimensionnement géré ne réduit jamais le cluster en dessous des contraintes minimales spécifiées dans la politique de dimensionnement géré. 
+ Les versions 5.34.0 et supérieures d'Amazon EMR, ainsi que les versions 6.4.0 et supérieures d'Amazon EMR, prennent en charge la reconnaissance des données Spark shuffle, ce qui empêche une instance de se réduire alors que Managed Scaling connaît les données de shuffle existantes. Pour plus d'informations sur les opérations de réorganisation, consultez le [Guide de programmation Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). Managed Scaling met tout en œuvre pour empêcher la réduction de la taille des nœuds contenant des données de l'étape actuelle et précédente de toute application Spark active, dans la limite de 30 minutes. Cela permet de minimiser les pertes de données par transfert involontaire, évitant ainsi de devoir effectuer de nouvelles tentatives de travail et de recalculer des données intermédiaires. Cependant, la prévention de la perte de données par shuffle n'est pas garantie. Pour améliorer la protection contre le shuffle Spark, nous recommandons de prendre en compte le shuffle sur les clusters portant le label de version 7.4 ou supérieur. Ajoutez les indicateurs suivants à la configuration du cluster pour améliorer la protection Spark Shuffle.
  + Si le `yarn.nodemanager.shuffledata-monitor.interval-ms` drapeau (30 000 ms par défaut) ou le drapeau `spark.dynamicAllocation.executorIdleTimeout` (60 secondes par défaut) a été modifié par rapport aux valeurs par défaut, assurez-vous que la condition est `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` maintenue `true` en mettant à jour l'indicateur nécessaire.

    ```
    [
    	{
    		"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"
    		}
    	}
    ]
    ```
+ Le dimensionnement géré supprime d'abord les nœuds de tâches, puis les nœuds principaux jusqu'à ce qu'il atteigne la capacité cible de réduction souhaitée. Le cluster ne s'adapte jamais en dessous des contraintes minimales spécifiées dans la politique de dimensionnement gérée.
+ Pour les clusters lancés avec Amazon EMR 5.x versions 5.34.0 et supérieures, et 6.x versions 6.4.0 et supérieures, Amazon EMR Managed Scaling ne réduit pas le nombre de nœuds dotés d'Apache Spark, s'il existe des stages `ApplicationMaster` actifs dans les applications qui y sont exécutées. Cela permet de minimiser les échecs et les nouvelles tentatives, ce qui contribue à améliorer les performances de tâche et à réduire les coûts. Pour vérifier quels nœuds de votre cluster exécutent `ApplicationMaster`, rendez-vous sur le serveur d'historique Spark et filtrez le pilote sous l'onglet **Exécuteurs** de l'ID de votre application Spark.
+ Bien que la mise à l'échelle intelligente associée à EMR Managed Scaling minimise la perte de données de shuffle pour Spark, il peut arriver que les données de shuffle transitoires ne soient pas protégées lors d'une réduction d'échelle. Pour améliorer la résilience des données de shuffle lors de la réduction, nous recommandons d'activer la mise **hors service gracieuse** des données de shuffle dans YARN. **Lorsque la **mise hors service progressive pour les données de shuffle** est activée dans YARN, les nœuds sélectionnés pour la réduction et contenant des données de shuffle passent à l'état de mise hors service et continuent à servir les fichiers de shuffle.** Le YARN ResourceManager attend que les nœuds ne signalent aucun fichier de shuffle présent avant de supprimer les nœuds du cluster.
  + Les versions 6.11.0 et supérieures d'Amazon EMR prennent en charge la mise hors service progressive des Yarn-based données **Hive** Shuffle pour les gestionnaires Tez et Shuffle. MapReduce 
    + Activez la mise hors service progressive pour Shuffle Data en réglant sur. `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` `true`
  + Les versions 7.4.0 et supérieures d'Amazon EMR prennent en charge la mise hors service progressive Yarn-based des données Spark Shuffle lorsque le service de shuffle externe est activé (activé par défaut dans EMR sur EC2).
    + Le comportement par défaut du service de shuffle externe Spark, lors de l'exécution de Spark on Yarn, est que le Yarn NodeManager supprime les fichiers de shuffle d'applications au moment de la fermeture de l'application. Cela peut avoir un impact sur la vitesse de mise hors service des nœuds et sur l'utilisation du calcul. Pour les applications de longue durée, pensez `spark.shuffle.service.removeShuffle` `true` à configurer pour supprimer les fichiers de shuffle qui ne sont plus utilisés afin de permettre une mise hors service plus rapide des nœuds sans données de shuffle actives.
  + Pour minimiser la perte de données Spark Shuffle dans Amazon EMR version 7.4.0 et supérieure, pensez à définir les indicateurs suivants.
    + Si le `yarn.nodemanager.shuffledata-monitor.interval-ms` drapeau (30 000 ms par défaut) ou le drapeau `spark.dynamicAllocation.executorIdleTimeout` (60 secondes par défaut) a été modifié par rapport aux valeurs par défaut, assurez-vous que la condition est `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` maintenue `true` en mettant à jour l'indicateur nécessaire.

      ```
      [
      	{
      		"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 le cluster n'est pas chargé, Amazon EMR annule l'ajout de nouvelles instances issues d'une évaluation précédente et effectue des opérations de réduction. Si le cluster est soumis à une charge importante, Amazon EMR annule la suppression des instances et effectue des opérations d'augmentation.

## Considérations concernant l'allocation de nœuds
<a name="node-allocation-considerations"></a>

Nous vous recommandons d'utiliser l'option On-Demand d'achat pour les nœuds principaux afin d'éviter toute perte de données HDFS en cas de restauration de Spot. Vous pouvez utiliser l'option d'achat Spot pour les nœuds de tâches afin de réduire les coûts et d'accélérer l'exécution des tâches lorsque davantage d'instances Spot sont ajoutées aux nœuds de tâches.

## Scénarios d'allocation de nœuds
<a name="node-allocation-scenarios"></a>

Vous pouvez créer différents scénarios de dimensionnement en fonction de vos besoins en configurant les paramètres maximum, minimum, On-Demand limite et maximum du nœud principal dans différentes combinaisons. 

**Scénario 1 : mise à l'échelle des nœuds principaux uniquement**

Pour mettre à l'échelle les nœuds principaux uniquement, les paramètres de mise à l'échelle gérée doivent répondre aux exigences suivantes : 
+ La On-Demand limite est égale à la limite maximale.
+ Le nœud principal maximal est égal à la limite maximale. 

Lorsque les paramètres de On-Demand limite et de maximum du nœud principal ne sont pas spécifiés, les deux paramètres utilisent par défaut la limite maximale. 

Ce scénario n'est pas applicable si vous utilisez le dimensionnement géré avec des étiquettes de nœuds et que vous limitez les processus de votre application à ne s'exécuter que sur des `CORE` nœuds, car le dimensionnement géré redimensionne les nœuds de tâches pour répondre à la demande des exécuteurs.

Les exemples suivants montrent le scénario de mise à l'échelle des nœuds principaux uniquement.


<table>
<thead>
  <tr><th>État initial du cluster</th><th>Paramètres de dimensionnement</th><th>Comportement de mise à l'échelle.</th></tr>
</thead>
<tbody>
  <tr><td><b>Groupes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand et 1 place</td><td><code>UnitType</code> : Instances<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 20 <br /><code>MaximumCoreCapacityUnits</code> : 20</td><td rowspan="2">Faites évoluer entre 1 et 20 instances ou unités de flotte d'instances sur les nœuds principaux en utilisant le On-Demand type. Aucune mise à l'échelle sur les nœuds de tâches.<br />Lorsque vous utilisez le dimensionnement géré avec des étiquettes de nœuds et que vous limitez vos processus d'application aux <code>ON_DEMAND</code> nœuds, le cluster met à l'échelle de 1 à 20 instances ou unités de parc d'instances sur des <code>CORE</code> nœuds utilisant le <code>Spot</code> type <code>On-Demand</code> ou, en fonction du type de demande.</td></tr>
  <tr><td><b>Flottes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand et 1 place</td><td>UnitType: InstanceFleetUnits<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 20 <br /><code>MaximumCoreCapacityUnits</code> : 20</td></tr>
</tbody>
</table>


**Scénario 2 : mettre à l'échelle les nœuds de tâches uniquement**

Pour mettre à l'échelle les nœuds de tâches uniquement, les paramètres de mise à l'échelle gérée doivent répondre aux exigences suivantes : 
+ Le nœud principal maximal doit être égal à la limite minimale.

Les exemples suivants montrent le scénario de mise à l'échelle des nœuds de tâches uniquement.


<table>
<thead>
  <tr><th>État initial du cluster</th><th>Paramètres de dimensionnement</th><th>Comportement de mise à l'échelle.</th></tr>
</thead>
<tbody>
  <tr><td><b>Groupes d'instances</b><br />Noyau : 2 On-Demand<br />De tâche : 1 Spot</td><td><code>UnitType</code> : Instances<br /><code>MinimumCapacityUnits</code> : 2<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumCoreCapacityUnits</code> : 2</td><td rowspan="2">Maintenez la stabilité des nœuds principaux à 2 et mettez à l'échelle uniquement les nœuds de tâches entre 0 et 18 instances ou unités de flotte d'instances. La capacité entre les limites minimale et maximale est ajoutée aux nœuds de tâches uniquement.<br /> Lorsque vous utilisez un dimensionnement géré avec des étiquettes de nœuds et que vous limitez vos processus d'application aux nœuds ON_DEMAND, le cluster maintient les nœuds principaux stables à 2 et ne redimensionne les nœuds de tâches qu'entre 0 et 18 instances ou unités de parc d'instances utilisant le <code>Spot</code> type <code>On-demand</code> ou, en fonction du type de demande. </td></tr>
  <tr><td><b>Flottes d'instances</b><br />Noyau : 2 On-Demand<br />De tâche : 1 Spot</td><td><code>UnitType</code>: InstanceFleetUnits<br /><code>MinimumCapacityUnits</code> : 2<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumCoreCapacityUnits</code> : 2</td></tr>
</tbody>
</table>


**Scénario 3 : On-Demand instances du cluster uniquement**

Pour disposer d' On-Demand instances uniquement, votre cluster et les paramètres de dimensionnement gérés doivent répondre aux exigences suivantes : 
+ La On-Demand limite est égale à la limite maximale. 

  Lorsque la On-Demand limite n'est pas spécifiée, la valeur du paramètre est par défaut la limite maximale. La valeur par défaut indique qu'Amazon EMR redimensionne uniquement On-Demand les instances. 

Si le nœud principal maximal est inférieur à la limite maximale, le paramètre du nœud principal maximal peut être utilisé pour répartir l'allocation de capacité entre le nœud principal et le nœud de tâche. 

Pour activer ce scénario dans un cluster composé de groupes d'instances, tous les groupes de nœuds du cluster doivent utiliser le type de On-Demand marché lors de la configuration initiale. 

Ce scénario n'est pas applicable si vous utilisez le dimensionnement géré avec des étiquettes de nœuds et que vous limitez les processus de votre application à ne s'exécuter que sur les `ON_DEMAND` nœuds, car le dimensionnement géré redimensionne les `Spot` nœuds pour répondre à la demande des exécuteurs.

Les exemples suivants illustrent le scénario consistant à avoir des On-Demand instances dans l'ensemble du cluster.


<table>
<thead>
  <tr><th>État initial du cluster</th><th>Paramètres de dimensionnement</th><th>Comportement de mise à l'échelle.</th></tr>
</thead>
<tbody>
  <tr><td><b>Groupes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand </td><td><code>UnitType</code> : Instances<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 20 <br /><code>MaximumCoreCapacityUnits</code> : 12</td><td rowspan="2">Faites évoluer entre 1 et 12 instances ou unités de flotte d'instances sur les nœuds principaux en utilisant le On-Demand type. Augmentez la capacité restante à l'aide On-Demand des nœuds de tâches. Aucune mise à l'échelle avec les instances Spot.<br /> Lorsque vous utilisez un dimensionnement géré avec des étiquettes de nœuds et que vous limitez vos processus d'application aux <code>CORE</code> nœuds, le cluster évolue entre 1 et 20 instances ou unités de parc d'instances sur des <code>CORE</code> <code>task</code> nœuds ou des nœuds utilisant le <code>ON_DEMAND</code> type, en fonction du type de demande. Le dimensionnement sur les nœuds principaux ne dépassera pas 12 instances ou unités de parc d'instances. </td></tr>
  <tr><td><b>Flottes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand</td><td><code>UnitType</code>: InstanceFleetUnits<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 20 <br /><code>MaximumCoreCapacityUnits</code> : 12</td></tr>
</tbody>
</table>


**Scénario 4 : uniquement les instances Spot du cluster**

Pour disposer uniquement d'instances Spot, les paramètres de mise à l'échelle gérée doivent répondre aux exigences suivantes : 
+ On-Demand la limite est fixée à 0.

Si le nœud principal maximal est inférieur à la limite maximale, le paramètre du nœud principal maximal peut être utilisé pour répartir l'allocation de capacité entre le nœud principal et le nœud de tâche.

Pour activer ce scénario dans un cluster composé de groupes d'instances, le groupe d'instances principal doit utiliser l'option d'achat Spot lors de la configuration initiale. S'il n'y a aucune instance Spot dans le groupe d'instances de tâches, la mise à l'échelle gérée par Amazon EMR crée un groupe de tâches utilisant des instances Spot en cas de besoin. 

Ce scénario n'est pas applicable si vous utilisez le dimensionnement géré avec des étiquettes de nœuds et que vous limitez les processus de votre application pour qu'ils s'exécutent uniquement sur les `ON_DEMAND` nœuds, car le dimensionnement géré redimensionne `ON_DEMAND` les nœuds pour répondre à la demande des processus d'application.

Les exemples suivants illustrent le scénario consistant à disposer d'instances Spot dans l'ensemble du cluster.


<table>
<thead>
  <tr><th>État initial du cluster</th><th>Paramètres de dimensionnement</th><th>Comportement de mise à l'échelle.</th></tr>
</thead>
<tbody>
  <tr><td><b>Groupes d'instances</b><br />Principal : 1 Spot<br />De tâche : 1 Spot</td><td><code>UnitType</code> : Instances<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 0</td><td rowspan="2">Mettre à l'échelle entre 1 et 20 instances ou unités de flotte d'instances sur les nœuds principaux en utilisant Spot. Aucune mise à l'échelle en utilisant On-Demand le type.<br />Lorsque vous utilisez un dimensionnement géré avec des étiquettes de nœuds et que vous limitez vos processus d'application aux <code>CORE</code> nœuds, le cluster évolue entre 1 et 20 instances ou unités de parc d'instances sur <code>CORE</code> ou <code>TASK</code> nœuds utilisant Spot, en fonction du type de demande. Amazon EMR ne s'adapte pas à l'échelle en fonction du <code>ON_DEMAND</code> type.</td></tr>
  <tr><td><b>Flottes d'instances</b><br />Principal : 1 Spot<br />De tâche : 1 Spot</td><td><code>UnitType</code>: InstanceFleetUnits<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 0</td></tr>
</tbody>
</table>


**Scénario 5 : dimensionner On-Demand les instances sur les nœuds principaux et les instances ponctuelles sur les nœuds de tâches**

Pour dimensionner On-Demand les instances sur les nœuds principaux et les instances ponctuelles sur les nœuds de tâches, les paramètres de dimensionnement gérés doivent répondre aux exigences suivantes : 
+ La On-Demand limite doit être égale au nœud principal maximal.
+ La On-Demand limite et le nœud principal maximum doivent être inférieurs à la limite maximale.

Pour activer ce scénario dans un cluster composé de groupes d'instances, le groupe de nœuds principal doit utiliser l'option On-Demand d'achat.

Ce scénario n'est pas applicable si vous utilisez un dimensionnement géré avec des étiquettes de nœuds et que vous limitez les processus de votre application pour qu'ils s'exécutent uniquement sur `ON_DEMAND` des nœuds ou `CORE` des nœuds. 

Les exemples suivants illustrent le scénario de dimensionnement des On-Demand instances sur les nœuds principaux et des instances ponctuelles sur les nœuds de tâches.


<table>
<thead>
  <tr><th>État initial du cluster</th><th>Paramètres de dimensionnement</th><th>Comportement de mise à l'échelle.</th></tr>
</thead>
<tbody>
  <tr><td><b>Groupes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand et 1 place</td><td><code>UnitType</code> : Instances<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 7 <br /><code>MaximumCoreCapacityUnits</code> : 7</td><td rowspan="2">Passez à 6 On-Demand unités sur le nœud principal puisqu'il y a déjà une On-Demand unité sur le nœud de tâche et que la limite maximale On-Demand est de 7. Augmentez ensuite à 13 unités Spot sur les nœuds de tâches.</td></tr>
  <tr><td><b>Flottes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand et 1 place</td><td><code>UnitType</code>: InstanceFleetUnits<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 7<br /><code>MaximumCoreCapacityUnits</code> : 7</td></tr>
</tbody>
</table>


**Scénario 6 : dimensionner `CORE` les instances en fonction de la demande du processus d'application et les `TASK` instances en fonction de la demande de l'exécuteur.**

Ce scénario n'est applicable que si vous utilisez un dimensionnement géré avec des étiquettes de nœuds et que vous limitez les processus d'application à ne s'exécuter que sur `CORE` les nœuds.

Pour dimensionner `CORE` les nœuds en fonction de la demande du processus d'application et `TASK` des nœuds en fonction de la demande de l'exécuteur, vous devez définir les configurations suivantes lors du lancement du cluster :
+  `yarn.node-labels.enabled:true` 
+  `yarn.node-labels.am.default-node-label-expression: 'CORE'` 

Si vous ne spécifiez pas les paramètres de `ON_DEMAND` limite et de `CORE` nœud maximum, les deux paramètres utilisent par défaut la limite maximale.

Si le `ON_DEMAND` nœud maximal est inférieur à la limite maximale, le dimensionnement géré utilise le paramètre de `ON_DEMAND` nœud maximal pour répartir l'allocation de capacité entre les `SPOT` nœuds `ON_DEMAND` et. Si vous définissez le paramètre de `CORE` nœud maximal sur une valeur inférieure ou égale au paramètre de capacité minimale, `CORE` les nœuds restent statiques à la capacité maximale du cœur.

Les exemples suivants illustrent le scénario de dimensionnement des instances CORE en fonction de la demande du processus d'application et des instances TASK en fonction de la demande de l'exécuteur.


<table>
<thead>
  <tr><th>État initial du cluster</th><th>Paramètres de dimensionnement</th><th>Comportement de mise à l'échelle.</th></tr>
</thead>
<tbody>
  <tr><td><b>Groupes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand</td><td><code>UnitType</code> : Instances<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 10<br /><code>MaximumCoreCapacityUnits</code> : 20</td><td rowspan="2"><code>CORE</code>Redimensionne les nœuds entre 1 et 20 nœuds en fonction de la demande du cluster en matière de processus applicatif en utilisant le type de marché On-Demand ou Spot. Évalue <code>TASK</code> les nœuds en fonction de la demande de l'exécuteur et de la capacité disponible restante une fois qu'Amazon EMR <code>CORE</code> a alloué des nœuds.<br />La somme des nœuds demandés <code>CORE</code> et <code>TASK</code> des nœuds ne dépassera pas 20. <code>maximumCapacity</code> La somme des nœuds principaux à la demande et des nœuds de tâches à la <code>maximumOnDemandCapacity</code> demande ne dépassera pas 10. Les nœuds principaux ou de tâches supplémentaires utilisent le type de marché au comptant. </td></tr>
  <tr><td><b>Flottes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand</td><td><code>UnitType</code>: InstanceFleetUnits<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 10<br /><code>MaximumCoreCapacityUnits</code> : 20</td></tr>
</tbody>
</table>


**Scénario 7 : dimensionner `ON_DEMAND` les instances en fonction de la demande du processus d'application et les `SPOT` instances en fonction de la demande de l'exécuteur.**

Ce scénario n'est applicable que si vous utilisez un dimensionnement géré avec des étiquettes de nœuds et que vous limitez les processus d'application à ne s'exécuter que sur `ON_DEMAND` les nœuds.

Pour dimensionner `ON_DEMAND` les nœuds en fonction de la demande du processus d'application et `SPOT` des nœuds en fonction de la demande de l'exécuteur, vous devez définir les configurations suivantes lors du lancement du cluster :
+  `yarn.node-labels.enabled:true` 
+  `yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'` 

Si vous ne spécifiez pas les paramètres de `ON_DEMAND` limite et de `CORE` nœud maximum, les deux paramètres utilisent par défaut la limite maximale.

Si le `CORE` nœud maximal est inférieur à la limite maximale, le dimensionnement géré utilise le paramètre de `CORE` nœud maximal pour répartir l'allocation de capacité entre les `TASK` nœuds `CORE` et. Si vous définissez le paramètre de `CORE` nœud maximal sur une valeur inférieure ou égale au paramètre de capacité minimale, `CORE` les nœuds restent statiques à la capacité maximale du cœur.

Les exemples suivants illustrent le scénario de dimensionnement des On-Demand instances en fonction de la demande du processus d'application et des instances ponctuelles en fonction de la demande de l'exécuteur.


<table>
<thead>
  <tr><th>État initial du cluster</th><th>Paramètres de dimensionnement</th><th>Comportement de mise à l'échelle.</th></tr>
</thead>
<tbody>
  <tr><td><b>Groupes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand</td><td><code>UnitType</code> : Instances<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 20<br /><code>MaximumCoreCapacityUnits</code> : 10</td><td rowspan="2"><code>ON_DEMAND</code>Redimensionne les nœuds entre 1 et 20 nœuds en fonction de la demande du processus d'application du cluster en utilisant le type de <code>TASK</code> nœud <code>CORE</code> or. Évalue <code>SPOT</code> les nœuds en fonction de la demande de l'exécuteur et de la capacité disponible restante une fois qu'Amazon EMR <code>ON_DEMAND</code> a alloué des nœuds.<br />La somme des nœuds demandés <code>ON_DEMAND</code> et <code>SPOT</code> des nœuds ne dépassera pas 20. <code>maximumCapacity</code> La somme des nœuds principaux à la demande et des nœuds principaux ponctuels demandés ne dépassera pas 10. <code>maximumCoreCapacity</code> Les nœuds ponctuels ou à la demande supplémentaires utilisent le type de <code>TASK</code> nœud. </td></tr>
  <tr><td><b>Flottes d'instances</b><br />Noyau : 1 On-Demand<br />Tâche : 1 On-Demand</td><td><code>UnitType</code>: InstanceFleetUnits<br /><code>MinimumCapacityUnits</code> : 1<br /><code>MaximumCapacityUnits</code> : 20<br /><code>MaximumOnDemandCapacityUnits</code> : 20<br /><code>MaximumCoreCapacityUnits</code> : 10</td></tr>
</tbody>
</table>