View a markdown version of this page

Comprendre la stratégie et les scénarios d'allocation de nœuds Amazon EMR - Amazon EMR
Stratégie d'allocation de nœudConsidérations concernant l'allocation de nœudsScénarios d'allocation de nœuds

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 de nœuds Amazon EMR

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

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, Managed Scaling 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 libellés de nœuds et que vous avez limité les processus d'application aux CORE nœuds, Amazon EMR Managed Scaling fait évoluer les nœuds principaux et les nœuds de tâches si la demande des processus applicatifs augmente et que la demande des exécuteurs augmente. De même, si vous avez activé les étiquettes de nœuds et que vous avez limité les processus d'application aux ON_DEMAND nœuds, la mise à l'échelle gérée augmente les nœuds à la demande si la demande des processus applicatifs augmente et augmente les nœuds ponctuels si la demande de l'exécuteur augmente.

  • Si les étiquettes de nœud 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, la mise à l'échelle gérée peut augmenter et réduire différents groupes d'instances et parcs d'instances au cours d'une même opération de redimensionnement. Par exemple, dans un scénario dans lequel instance_group1 possède un ON_DEMAND nœud et instance_group2 possède un SPOT nœud, les étiquettes de nœud sont activées et les processus d'application sont limités aux nœuds dotés de l'ON_DEMANDétiquette. La mise à l'échelle gérée diminuera instance_group1 et augmentera instance_group2 si la demande des processus applicatifs diminue et si 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 des 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 des nœuds en fonction de leurs étiquettes. Pour plus d'informations sur les libellés des nœuds, voir Comprendre les types de nœuds : nœuds principaux, principaux et nœuds de tâches.

  • Si vous n'avez pas activé les étiquettes de nœuds, la mise à l'échelle gérée supprime les nœuds de tâche, puis les nœuds principaux jusqu'à ce que la capacité cible de réduction souhaitée soit atteinte. 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 et les versions 6.4.0 et supérieures d'Amazon EMR prennent en charge Spark shuffle data awareness, qui empêche une instance de réduire la taille alors que Managed Scaling prend connaissance des données de shuffle existantes. Pour plus d'informations sur les opérations de réorganisation, consultez le Guide de programmation Spark. Managed Scaling met tout en œuvre pour empêcher la réduction de la taille des nœuds en mélangeant les données de l'étape actuelle et de la phase précédente de toute application Spark active, pendant une durée maximale de 30 minutes. Cela permet de minimiser les pertes involontaires de données dues au remaniement, évitant ainsi de devoir recommencer les tâches et de recalculer les données intermédiaires. Cependant, la prévention de la perte de données due au shuffle n'est pas garantie. Pour améliorer la protection contre le shuffle dans Spark, nous recommandons de prendre en compte le shuffle sur les clusters dotés de l'étiquette de version 7.4 ou supérieure. Ajoutez les indicateurs suivants à la configuration du cluster pour améliorer la protection contre Spark shuffle.

    • Si l'yarn.nodemanager.shuffledata-monitor.interval-msindicateur (par défaut 30 000 ms) 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"
		}
	}
]

  • La mise à l'échelle gérée supprime d'abord les nœuds de tâches, puis les nœuds principaux jusqu'à atteindre la capacité cible de réduction souhaitée. Le cluster n'évolue 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 la taille des nœuds ApplicationMaster destinés à Apache Spark, s'il existe des étapes actives dans les applications qui s'y exécutent. 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 avec EMR Managed Scaling minimise les pertes de données liées au shuffle pour Spark, il peut arriver que les données de shuffle transitoire ne soient pas protégées lors d'une réduction d'échelle. Pour améliorer la résilience des données mélangées lors de la réduction d'échelle, nous vous recommandons d'activer la mise hors service gracieuse pour les données mélangées dans YARN. Lorsque la mise hors service gracieuse pour les données aléatoires est activée dans YARN, les nœuds sélectionnés pour la réduction qui contiennent des données de lecture aléatoire passeront en état de mise hors service et continueront à servir des fichiers de lecture aléatoire. Le YARN ResourceManager attend que les nœuds signalent la présence d'aucun fichier aléatoire 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 Yarn-based progressive des données Hive shuffle pour les gestionnaires Tez et Shuffle. MapReduce

      • Activez la mise hors service gracieuse 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 Yarn-based hors service progressive 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 lecture aléatoire externe de Spark, lors de l'exécution de Spark sur Yarn, est que Yarn supprime les fichiers de lecture NodeManager aléatoire de l'application 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, envisagez de configurer spark.shuffle.service.removeShuffle true pour supprimer les fichiers de lecture aléatoire qui ne sont plus utilisés afin de permettre une mise hors service plus rapide des nœuds sans données de lecture aléatoire actives.

    • Pour minimiser la perte de données Spark shuffle dans Amazon EMR version 7.4.0 et versions ultérieures, pensez à définir les indicateurs suivants.

      • Si l'yarn.nodemanager.shuffledata-monitor.interval-msindicateur (par défaut 30 000 ms) 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

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 récupération ponctuelle. 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

Vous pouvez créer différents scénarios de dimensionnement en fonction de vos besoins en configurant les paramètres du nœud principal maximum, minimum, On-Demand limite et maximum selon 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 central ne sont pas spécifiés, les deux paramètres sont définis par défaut sur la limite maximale.

Ce scénario ne s'applique pas si vous utilisez une mise à l'échelle gérée avec des étiquettes de nœud et si vous limitez les processus de votre application pour qu'ils ne s'exécutent que sur les CORE nœuds, car la mise à l'échelle gérée dimensionne les nœuds de tâches en fonction de la demande de l'exécuteur.

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

État initial du cluster Paramètres de dimensionnement Comportement de mise à l'échelle.

Groupes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand et 1 place

UnitType : Instances

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 20

MaximumCoreCapacityUnits : 20

Faites évoluer entre 1 et 20 instances ou unités de parc d'instances sur les nœuds principaux en utilisant le On-Demand type. Aucune mise à l'échelle sur les nœuds de tâches.

Lorsque vous utilisez une mise à l'échelle gérée avec des étiquettes de nœuds et que vous limitez vos processus d'application aux ON_DEMAND nœuds, le cluster met à l'échelle de 1 à 20 instances ou unités de parc d'instances sur des CORE nœuds en utilisant le Spot type On-Demand ou, en fonction du type de demande.

Flottes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand et 1 place

UnitType: InstanceFleetUnits

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 20

MaximumCoreCapacityUnits : 20

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.

État initial du cluster Paramètres de dimensionnement Comportement de mise à l'échelle.

Groupes d'instances

Noyau : 2 On-Demand

De tâche : 1 Spot

UnitType : Instances

MinimumCapacityUnits : 2

MaximumCapacityUnits : 20

MaximumCoreCapacityUnits : 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.

Lorsque vous utilisez une mise à l'échelle gérée avec des étiquettes de nœuds et que vous limitez vos processus d'application aux nœuds ON_DEMAND, le cluster maintient la stabilité des nœuds principaux à 2 et ne fait dimensionner que les nœuds de tâches compris entre 0 et 18 instances ou les unités du parc d'instances qui utilisent le Spot type On-demand ou, en fonction du type de demande.

Flottes d'instances

Noyau : 2 On-Demand

De tâche : 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits : 2

MaximumCapacityUnits : 20

MaximumCoreCapacityUnits : 2

Scénario 3 : seules On-Demand les instances du cluster

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 ne s'applique pas si vous utilisez une mise à l'échelle gérée avec des étiquettes de nœud et si vous limitez les processus de votre application pour qu'ils ne s'exécutent que sur ON_DEMAND les nœuds, car la mise à l'échelle gérée dimensionne Spot les nœuds pour répondre à la demande de l'exécuteur.

Les exemples suivants illustrent le scénario selon lequel des On-Demand instances sont présentes dans l'ensemble du cluster.

État initial du cluster Paramètres de dimensionnement Comportement de mise à l'échelle.

Groupes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand

UnitType : Instances

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 20

MaximumCoreCapacityUnits : 12

Faites évoluer entre 1 et 12 instances ou unités de parc d'instances sur les nœuds principaux en utilisant le On-Demand type. Augmentez la capacité restante à l'aide On-Demand de nœuds de tâches. Aucune mise à l'échelle avec les instances Spot.

Lorsque vous utilisez une mise à l'échelle gérée avec des étiquettes de nœuds et que vous limitez vos processus d'application aux CORE nœuds, le cluster fait évoluer entre 1 et 20 instances ou unités de parc d'instances sur des CORE task nœuds ou des nœuds en utilisant le ON_DEMAND type, en fonction du type de demande. La mise à l'échelle sur les nœuds principaux ne dépassera pas 12 instances ou unités de parc d'instances.

Flottes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 20

MaximumCoreCapacityUnits : 12

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 ne s'applique pas si vous utilisez la mise à l'échelle gérée avec des étiquettes de nœud et si vous limitez les processus de votre application pour qu'ils ne s'exécutent que sur ON_DEMAND les nœuds, car la mise à l'échelle gérée dimensionne 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.

État initial du cluster Paramètres de dimensionnement Comportement de mise à l'échelle.

Groupes d'instances

Principal : 1 Spot

De tâche : 1 Spot

UnitType : Instances

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 0

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 à l'aide On-Demand du type.

Lorsque vous utilisez une mise à l'échelle gérée avec des étiquettes de nœuds et que vous limitez vos processus d'application aux CORE nœuds, le cluster évolue entre 1 et 20 instances ou unités de parc d'instances sur CORE ou TASK nœuds utilisant Spot, selon le type de demande. Amazon EMR n'effectue pas de mise à l'échelle en fonction du ON_DEMAND type.

Flottes d'instances

Principal : 1 Spot

De tâche : 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 0

Scénario 5 : mise à l'échelle On-Demand des instances sur les nœuds principaux et 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 maximum du nœud central.

  • La On-Demand limite et le nœud central 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 ne s'applique pas si vous utilisez une mise à l'échelle gérée avec des étiquettes de nœud et si vous limitez les processus de votre application à ne s'exécuter que sur ON_DEMAND des nœuds ou CORE des nœuds.

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

État initial du cluster Paramètres de dimensionnement Comportement de mise à l'échelle.

Groupes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand et 1 place

UnitType : Instances

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 7

MaximumCoreCapacityUnits : 7

Passez à 6 On-Demand unités sur le nœud principal, car il y en a déjà On-Demand une sur le nœud de tâche et la limite maximale On-Demand est de 7. Augmentez ensuite à 13 unités Spot sur les nœuds de tâches.

Flottes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand et 1 place

UnitType: InstanceFleetUnits

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 7

MaximumCoreCapacityUnits : 7

Scénario 6 : dimensionnez CORE les instances en fonction de la demande des processus applicatifs et des TASK instances en fonction de la demande de l'exécuteur.

Ce scénario n'est applicable que si vous utilisez une mise à l'échelle gérée avec des étiquettes de nœud et si 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 applicatif et TASK les 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 nombre maximum de ON_DEMAND nœuds est inférieur à la limite maximale, la mise à l'échelle gérée utilise le paramètre de ON_DEMAND nœud maximum 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 maximum 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.

État initial du cluster Paramètres de dimensionnement Comportement de mise à l'échelle.

Groupes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand

UnitType : Instances

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 10

MaximumCoreCapacityUnits : 20

Fait évoluer les CORE nœuds entre 1 et 20 nœuds en fonction de la demande du processus d'application du cluster en utilisant le type de marché On-Demand ou Spot market. Dimensionne TASK les nœuds en fonction de la demande de l'exécuteur et de la capacité disponible restante une fois qu'Amazon EMR a alloué CORE les nœuds.

La somme des nœuds demandés CORE et TASK des nœuds ne dépassera pas 20. maximumCapacity La somme des nœuds principaux à la demande et des nœuds de tâches à la maximumOnDemandCapacity demande ne dépassera pas 10. Les nœuds principaux ou de tâches supplémentaires utilisent le type de marché au comptant.

Flottes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 10

MaximumCoreCapacityUnits : 20

Scénario 7 : dimensionnez ON_DEMAND les instances en fonction de la demande des processus applicatifs et des SPOT instances en fonction de la demande de l'exécuteur.

Ce scénario n'est applicable que si vous utilisez une mise à l'échelle gérée avec des étiquettes de nœud et si 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 applicatif et SPOT les 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 nombre maximum de CORE nœuds est inférieur à la limite maximale, la mise à l'échelle gérée utilise le paramètre de CORE nœud maximum 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 maximum 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 applicatif et des instances Spot en fonction de la demande de l'exécuteur.

État initial du cluster Paramètres de dimensionnement Comportement de mise à l'échelle.

Groupes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand

UnitType : Instances

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 20

MaximumCoreCapacityUnits : 10

Fait évoluer les ON_DEMAND nœuds entre 1 et 20 nœuds en fonction de la demande du processus d'application du cluster en utilisant le type de TASK nœud CORE ou. Dimensionne SPOT les nœuds en fonction de la demande de l'exécuteur et de la capacité disponible restante une fois qu'Amazon EMR a alloué ON_DEMAND les nœuds.

La somme des nœuds demandés ON_DEMAND et SPOT des nœuds ne dépassera pas 20. maximumCapacity La somme des nœuds principaux à la demande et des nœuds principaux ponctuels demandés ne dépassera pas 10. maximumCoreCapacity Les nœuds ponctuels ou à la demande supplémentaires utilisent le type de TASK nœud.

Flottes d'instances

Noyau : 1 On-Demand

Tâche : 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits : 1

MaximumCapacityUnits : 20

MaximumOnDemandCapacityUnits : 20

MaximumCoreCapacityUnits : 10