View a markdown version of this page

Grundlegendes zur Strategie und zu den Szenarien der Amazon EMR-Knotenzuweisung - Amazon EMR
KnotenzuweisungsstrategieÜberlegungen zur KnotenzuweisungKnotenzuweisungsszenarien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Grundlegendes zur Strategie und zu den Szenarien der Amazon EMR-Knotenzuweisung

Dieser Abschnitt gibt einen Überblick über die Strategie zur Knotenzuweisung und allgemeine Skalierungsszenarien, die Sie mit Amazon EMR Managed Scaling verwenden können.

Knotenzuweisungsstrategie

Amazon EMR Managed Scaling weist Core- und Aufgabenknoten auf der Grundlage der folgenden Strategien zum hochskalieren und herunterskalieren zu:

Scale-up Strategie

  • Bei Amazon EMR-Versionen 7.2 und höher werden bei der verwalteten Skalierung zunächst Knoten hinzugefügt, die auf den Knotenbezeichnungen und der YARN-Eigenschaft der Anwendungsprozesseinschränkung basieren.

  • Für Amazon EMR-Versionen 7.2 und höher gilt Folgendes, wenn Sie Node-Labels aktiviert und Anwendungsprozesse auf Folgendes beschränkt haben CORE Knoten, die von Amazon EMR verwaltete Skalierung skaliert die Core Nodes und Task-Nodes nach oben, wenn die Nachfrage nach Anwendungsprozessen steigt und die Nachfrage nach Ausführern steigt. Ähnlich verhält es sich, wenn Sie Node-Labels aktiviert und Anwendungsprozesse auf Folgendes beschränkt haben ON_DEMAND Knoten, verwaltete Skalierung skaliert On-Demand-Knoten nach oben, wenn die Nachfrage nach Anwendungsprozessen steigt, und Spotknoten hochskaliert, wenn die Nachfrage des Executors steigt.

  • Wenn Node-Labels nicht aktiviert sind, ist die Platzierung von Anwendungsprozessen nicht auf einen Knoten oder Markttyp beschränkt.

  • Mithilfe von Node-Labels kann die verwaltete Skalierung verschiedene Instanzgruppen und Instanzflotten im gleichen Vorgang zur Größenänderung hoch- und herunterskalieren. Zum Beispiel in einem Szenario, in dem instance_group1 hat ON_DEMAND Knoten und instance_group2 hat eine SPOT Knoten, und Knotenbezeichnungen sind aktiviert und Anwendungsprozesse sind auf Knoten beschränkt, die ON_DEMAND Etikett. Die verwaltete Skalierung wird herunterskaliert instance_group1 und skalieren instance_group2 wenn die Nachfrage nach Anwendungsprozessen sinkt und die Nachfrage nach Ausführenden steigt.

  • Wenn Amazon EMR bei der Skalierung mit der aktuellen Instance-Gruppe verzögert wird, wechseln Cluster, die verwaltete Skalierung verwenden, automatisch zu einer anderen Task-Instance-Gruppe.

  • Wenn der MaximumCoreCapacityUnits-Parameter festgelegt ist, skaliert Amazon EMR die Core-Knoten, bis die Kerneinheiten den maximal zulässigen Grenzwert erreichen. Die gesamte verbleibende Kapazität wird den Aufgabenknoten hinzugefügt.

  • Wenn der MaximumOnDemandCapacityUnits ist der Parameter gesetzt, dann skaliert Amazon EMR den Cluster mithilfe von On-Demand Instanzen bis zum On-Demand Einheiten erreichen den maximal zulässigen Grenzwert. Die gesamte verbleibende Kapazität wird mithilfe von Spot Instances hinzugefügt.

  • Wenn sowohl MaximumCoreCapacityUnits als auch der MaximumOnDemandCapacityUnits Parameter festgelegt sind, berücksichtigt Amazon EMR bei der Skalierung beide Grenzwerte.

    Wenn MaximumCoreCapacityUnits beispielsweise kleiner als MaximumOnDemandCapacityUnits ist, skaliert Amazon EMR zunächst die Core-Knoten, bis die Kernkapazitätsgrenze erreicht ist. Für die verbleibende Kapazität verwendet Amazon EMR zunächst On-Demand Instanzen zur Skalierung von Task-Nodes bis zum On-Demand Das Limit ist erreicht und verwendet dann Spot-Instances für Task-Knoten.

Scale-down Strategie

  • Ähnlich wie bei der Scale-Up-Strategie entfernt Amazon EMR Knoten auf der Grundlage von Knotenbezeichnungen. Weitere Informationen zu Node-Labels finden Sie unter Machen Sie sich mit den Knotentypen vertraut: Primär-, Kern- und Taskknoten.

  • Wenn Sie die Knotenbezeichnungen nicht aktiviert haben, entfernt die verwaltete Skalierung Taskknoten und anschließend die Kernknoten, bis die gewünschte Zielkapazität für das Herunterskalieren erreicht ist. Bei verwalteter Skalierung wird der Cluster niemals unter die in der Richtlinie für verwaltete Skalierung angegebenen Mindestbeschränkungen herunterskaliert.

  • Die Amazon EMR-Versionen 5.34.0 und höher sowie die Amazon EMR-Versionen 6.4.0 und höher unterstützen die Spark Shuffle-Datenerkennung, wodurch verhindert wird, dass eine Instance herunterskaliert wird, während Managed Scaling die vorhandenen Shuffle-Daten erkennt. Weitere Informationen zu Shuffle-Vorgängen finden Sie im Spark-Programmierhandbuch. Managed Scaling ist bestrebt, das Herunterskalieren von Knoten mit Shuffle-Daten aus der aktuellen und vorherigen Phase einer aktiven Spark-Anwendung zu verhindern, und zwar bis zu einem Maximum von 30 Minuten. Dies trägt dazu bei, den unbeabsichtigten Verlust von Shuffle-Daten zu minimieren, sodass keine erneuten Auftragsversuche und Neuberechnungen von Zwischendaten erforderlich sind. Der Verlust von Shuffle-Daten kann jedoch nicht garantiert werden. Für einen verbesserten Spark-Shuffle-Schutz empfehlen wir, Shuffle Awareness auf Clustern mit Release-Label 7.4 oder höher zu verwenden. Fügen Sie der Cluster-Konfiguration die folgenden Flags hinzu, um den verbesserten Spark-Shuffle-Schutz zu aktivieren.

    • Wenn entweder yarn.nodemanager.shuffledata-monitor.interval-ms Flagge (Standard 30000 ms) oder die spark.dynamicAllocation.executorIdleTimeout (Standard 60 Sekunden) wurde gegenüber den Standardwerten geändert. Stellen Sie sicher, dass die Bedingung erfüllt ist spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms bleibt true indem Sie die erforderliche Flagge aktualisieren.

      [
	{
		"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"
		}
	}
]

  • Bei der verwalteten Skalierung werden zuerst Taskknoten und dann Kernknoten entfernt, bis die gewünschte Zielkapazität beim Herunterskalieren erreicht ist. Der Cluster wird niemals unter die in der Richtlinie für verwaltete Skalierung angegebenen Mindestbeschränkungen skaliert.

  • Bei Clustern, die mit Amazon EMR 5.x-Versionen 5.34.0 und höher sowie 6.x-Versionen 6.4.0 und höher gestartet wurden, skaliert Amazon EMR Managed Scaling keine Knoten herunter, die ApplicationMaster für Apache Spark, wenn die Anwendungen, die auf ihnen ausgeführt werden, aktive Phasen enthalten. Dadurch werden Fehlschläge und Wiederholungen von Aufträgen minimiert, was zur Verbesserung der Auftragsleistung und zur Senkung der Kosten beiträgt. Um zu überprüfen, welche Knoten in Ihrem Cluster ApplicationMaster ausführen, besuchen Sie den Spark History Server und filtern Sie auf der Registerkarte Executors Ihrer Spark-Anwendungs-ID nach dem Treiber.

  • Während die intelligente Skalierung mit EMR Managed Scaling den Shuffle-Datenverlust für Spark minimiert, kann es vorkommen, dass transiente Shuffle-Daten während eines Scale-Down möglicherweise nicht geschützt sind. Um die Stabilität von Shuffle-Daten beim Herunterskalieren zu erhöhen, empfehlen wir die Aktivierung Ordnungsgemäße Außerbetriebnahme von Shuffle-Daten in GARN. Wann Ordnungsgemäße Außerbetriebnahme von Shuffle Data ist in YARN aktiviert, Knoten, die für das Herunterskalieren ausgewählt wurden und die Shuffle-Daten enthalten, werden in das Außerbetriebnahme Zufallsdateien angeben und weiterhin bereitstellen. Das GARN ResourceManager wartet, bis Knoten melden, dass keine Shuffle-Dateien vorhanden sind, bevor die Knoten aus dem Cluster entfernt werden.

    • Unterstützung für Amazon EMR Version 6.11.0 und höher Yarn-based ordnungsgemäße Außerbetriebnahme für Bienenstock Mischen Sie Daten sowohl für den Tez als auch MapReduce Shuffle-Handler.

      • Aktivieren Sie Graceful Decommissioning für Shuffle Data, indem Sie Folgendes einrichten yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data zu true.

    • Unterstützung für Amazon EMR Version 7.4.0 und höher Yarn-based ordnungsgemäße Außerbetriebnahme von Spark-Shuffle-Daten, wenn der externe Shuffle-Dienst aktiviert ist (in EMR auf EC2 standardmäßig aktiviert).

      • Das Standardverhalten des externen Spark-Shuffle-Dienstes bei der Ausführung von Spark auf Yarn gilt für den Yarn NodeManager um Application-Shuffle-Dateien zum Zeitpunkt der Beendigung der Anwendung zu entfernen. Dies kann sich auf die Geschwindigkeit der Außerbetriebnahme von Knoten und die Auslastung der Rechenleistung auswirken. Bei Anwendungen mit langer Laufzeit sollten Sie folgende Einstellungen in Betracht ziehen spark.shuffle.service.removeShuffle zu true um Shuffle-Dateien zu entfernen, die nicht mehr verwendet werden, um Knoten ohne aktive Shuffle-Daten schneller außer Betrieb zu nehmen.

    • Um den Spark-Shuffle-Datenverlust in Amazon EMR Version 7.4.0 und höher zu minimieren, sollten Sie erwägen, die folgenden Flags zu setzen.

      • Wenn entweder der yarn.nodemanager.shuffledata-monitor.interval-ms Flag (Standard 30000 ms) oder spark.dynamicAllocation.executorIdleTimeout (Standard 60 Sekunden) wurde gegenüber den Standardwerten geändert. Stellen Sie sicher, dass die Bedingung spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms bleibt true indem Sie die erforderliche Flagge aktualisieren.

        [
	{
		"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"
		}
	}
]

Wenn der Cluster nicht ausgelastet ist, storniert Amazon EMR das Hinzufügen neuer Instances aus einer früheren Evaluierung und führt Herunterskalierungsvorgänge durch. Wenn der Cluster stark ausgelastet ist, bricht Amazon EMR das Entfernen von Instances ab und führt Hochskalierungsvorgänge durch.

Überlegungen zur Knotenzuweisung

Wir empfehlen Ihnen, das zu verwenden On-Demand Kaufoption für Core-Nodes, um HDFS-Datenverlust im Falle einer Spot-Rückgewinnung zu vermeiden. Sie können die Spot-Kaufoption für Aufgabenknoten verwenden, um die Kosten zu senken und die Auftragsausführung zu beschleunigen, wenn mehr Spot Instances zu Aufgabenknoten hinzugefügt werden.

Knotenzuweisungsszenarien

Sie können je nach Bedarf verschiedene Skalierungsszenarien erstellen, indem Sie die Optionen Maximum, Minimum, On-Demand Grenzwert- und Maximalwert der Kernknotenparameter in verschiedenen Kombinationen.

Szenario 1: Nur Core-Knoten skalieren

Um nur Core-Knoten zu skalieren, müssen die verwalteten Skalierungsparameter die folgenden Anforderungen erfüllen:

  • Die On-Demand Die Grenze entspricht der maximalen Grenze.

  • Der maximale Core-Knoten entspricht der maximalen Grenze.

Wenn der On-Demand Grenzwert und maximale Kernknotenparameter sind nicht angegeben, beide Parameter verwenden standardmäßig die maximale Grenze.

Dieses Szenario ist nicht anwendbar, wenn Sie die verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse so einschränken, dass sie nur auf CORE Knoten, da die verwaltete Skalierung die Taskknoten skaliert, um den Anforderungen des Executors gerecht zu werden.

Das folgende Beispiele zeigt das Szenario der ausschließlichen Skalierung von Core-Knoten.

Ausgangszustand des Clusters Skalierungsparameter Skalierungs-Verhalten

Instance-Gruppen

Kern: 1 On-Demand

Aufgabe: 1 On-Demand und 1 Spot

UnitType: Instances

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Skalieren Sie zwischen 1 und 20 Instances oder Instance-Flotteneinheiten auf Core-Knoten mit On-Demand geben Sie ein. Keine Skalierung auf Aufgabenknoten.

Wenn Sie verwaltete Skalierung mit Node-Labels verwenden und Ihre Anwendungsprozesse einschränken auf ON_DEMAND Knoten, auf denen der Cluster 1 bis 20 Instanzen oder Instanzflotteneinheiten skaliert CORE Knoten, die On-Demand oder Spot Typ, abhängig von der Art der Nachfrage.

Instance-Flotten

Kern: 1 On-Demand

Aufgabe: 1 On-Demand und 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Szenario 2: Nur Aufgabenknoten skalieren

Um nur Aufgabenknoten zu skalieren, müssen die verwalteten Skalierungsparameter die folgenden Anforderungen erfüllen:

  • Der maximale Core-Knoten muss der Mindestgrenze entsprechen.

Das folgende Beispiele zeigt das Szenario der ausschließlichen Skalierung von Aufgabenknoten.

Ausgangszustand des Clusters Skalierungsparameter Skalierungs-Verhalten

Instance-Gruppen

Kern: 2 On-Demand

Aufgabe: 1 Spot

UnitType: Instances

MinimumCapacityUnits: 2

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits: 2

Halten Sie die Anzahl der Core-Knoten konstant bei 2 und skalieren Sie nur Aufgabenknoten zwischen 0 und 18 Instances oder Instance-Flotteneinheiten. Die Kapazität zwischen Mindest- und Höchstgrenzen wird nur den Aufgabenknoten hinzugefügt.

Wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse auf ON_DEMAND-Knoten beschränken, hält der Cluster die Core-Nodes konstant bei 2 und skaliert nur Taskknoten zwischen 0 und 18 Instances oder Instance-Flotteneinheiten, die On-demand oder Spot Typ, abhängig von der Art der Nachfrage.

Instance-Flotten

Kern: 2 On-Demand

Aufgabe: 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 2

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits: 2

Szenario 3: Nur On-Demand Instanzen im Cluster

Zu haben On-Demand Nur Instances, Ihr Cluster und die verwalteten Skalierungsparameter müssen die folgenden Anforderungen erfüllen:

  • Die On-Demand Die Grenze entspricht der maximalen Grenze.

    Wenn der On-Demand Der Grenzwert ist nicht angegeben, der Parameterwert entspricht standardmäßig der maximalen Grenze. Der Standardwert gibt an, dass Amazon EMR skaliert On-Demand Nur Instanzen.

Wenn die maximale Anzahl an Core-Knoten kleiner als die maximale Grenze ist, kann der Parameter „Maximaler Core-Knoten“ verwendet werden, um die Kapazitätszuweisung zwischen Core- und Aufgabenknoten aufzuteilen.

Um dieses Szenario in einem Cluster zu ermöglichen, der aus Instanzgruppen besteht, müssen alle Knotengruppen im Cluster die On-Demand Markttyp bei der Erstkonfiguration.

Dieses Szenario ist nicht anwendbar, wenn Sie die verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse darauf beschränken, nur auf ON_DEMAND Knoten, da die verwaltete Skalierung skaliert Spot Knoten, um den Anforderungen des Executors gerecht zu werden.

Die folgenden Beispiele veranschaulichen das Szenario On-Demand Instanzen im gesamten Cluster.

Ausgangszustand des Clusters Skalierungsparameter Skalierungs-Verhalten

Instance-Gruppen

Kern: 1 On-Demand

Aufgabe: 1 On-Demand

UnitType: Instances

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Skalieren Sie zwischen 1 und 12 Instanzen oder Instanzflotteneinheiten auf Core-Knoten mit On-Demand geben Sie ein. Skalieren Sie die verbleibende Kapazität mit On-Demand auf Taskknoten. Keine Skalierung mit Spot Instances.

Wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse einschränken auf CORE Knoten, der Cluster skaliert zwischen 1 und 20 Instances oder Instance-Flotteneinheiten auf CORE Knoten oder task Knoten mit dem ON_DEMANDTyp, abhängig von der Art der Nachfrage. Die Skalierung auf Kernknoten darf 12 Instances oder Instance-Flotteneinheiten nicht überschreiten.

Instance-Flotten

Kern: 1 On-Demand

Aufgabe: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Szenario 4: Nur Spot Instances im Cluster

Um nur Spot Instances zu verwenden, müssen die verwalteten Skalierungsparameter die folgenden Anforderungen erfüllen:

  • On-Demand Das Limit ist auf 0 gesetzt.

Wenn die maximale Anzahl an Core-Knoten kleiner als die maximale Grenze ist, kann der Parameter „Maximaler Core-Knoten“ verwendet werden, um die Kapazitätszuweisung zwischen Core- und Aufgabenknoten aufzuteilen.

Um dieses Szenario in einem Cluster zu aktivieren, der aus Instance-Gruppen besteht, muss die Kern-Instance-Gruppe bei der Erstkonfiguration die Spot-Kaufoption verwenden. Wenn in der Aufgaben-Instance-Gruppe keine Spot Instance vorhanden ist, erstellt Amazon EMR Managed Scaling bei Bedarf eine Auftragsgruppe, die Spot Instances verwendet.

Dieses Szenario ist nicht anwendbar, wenn Sie die verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse so einschränken, dass sie nur auf ausgeführt werden ON_DEMAND Knoten, da die verwaltete Skalierung skaliert ON_DEMAND Knoten, um den Anforderungen von Anwendungsprozessen gerecht zu werden.

Die folgenden Beispiele veranschaulichen das Szenario, in dem Spot Instances im gesamten Cluster vorhanden sind.

Ausgangszustand des Clusters Skalierungsparameter Skalierungs-Verhalten

Instance-Gruppen

Core: 1 Spot

Aufgabe: 1 Spot

UnitType: Instances

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Skalieren Sie mithilfe von Spot zwischen 1 und 20 Instances oder Instance-Flotteneinheiten auf Core-Knoten. Keine Skalierung mit On-Demand geben Sie ein.

Wenn Sie verwaltete Skalierung mit Node-Labels verwenden und Ihre Anwendungsprozesse einschränken auf CORE Knoten, der Cluster skaliert zwischen 1 und 20 Instances oder Instance-Flotteneinheiten auf CORE oder TASK Knoten, die Spot verwenden, abhängig von der Art der Nachfrage. Amazon EMR skaliert nicht mithilfe von ON_DEMAND geben Sie ein.

Instance-Flotten

Core: 1 Spot

Aufgabe: 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Szenario 5: Skala On-Demand Instanzen auf Kernknoten und Spot-Instances auf Task-Knoten

Um zu skalieren On-Demand Bei Instances auf Core-Knoten und Spot-Instances auf Task-Knoten müssen die verwalteten Skalierungsparameter die folgenden Anforderungen erfüllen:

  • Die On-Demand Das Limit muss dem maximalen Kernknoten entsprechen.

  • Sowohl On-Demand Grenzwert und maximaler Kernknoten müssen kleiner als die maximale Grenze sein.

Um dieses Szenario in einem Cluster, der aus Instanzgruppen besteht, zu ermöglichen, muss die Kernknotengruppe die On-Demand Kaufoption.

Dieses Szenario gilt nicht, wenn Sie die verwaltete Skalierung mit Node-Labels verwenden und Ihre Anwendungsprozesse so einschränken, dass sie nur auf ausgeführt werden ON_DEMAND Knoten oder CORE Knoten.

Die folgenden Beispiele veranschaulichen das Szenario der Skalierung On-Demand Instances auf Core-Knoten und Spot-Instances auf Task-Knoten.

Ausgangszustand des Clusters Skalierungsparameter Skalierungs-Verhalten

Instance-Gruppen

Kern: 1 On-Demand

Aufgabe: 1 On-Demand und 1 Spot

UnitType: Instances

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Auf bis zu 6 skalieren On-Demand Einheiten auf dem Kernknoten, da es bereits 1 gibt On-Demand Einheit auf dem Taskknoten und die Höchstgrenze für On-Demand ist 7. Hochskalieren Sie anschließend auf bis zu 13 Spot-Einheiten auf Aufgabenknoten.

Instance-Flotten

Kern: 1 On-Demand

Aufgabe: 1 On-Demand und 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Szenario 6: Skala CORE Instanzen für die Nachfrage nach Anwendungsprozessen und TASK Instanzen für die Nachfrage des Executors.

Dieses Szenario gilt nur, wenn Sie die verwaltete Skalierung mit Knotenbezeichnungen verwenden und die Ausführung von Anwendungsprozessen nur auf folgenden Geräten einschränken CORE Knoten.

Maßstabsgetreu CORE Knoten auf der Grundlage der Anforderungen des Anwendungsprozesses und TASK Bei Knoten, die auf der Executor-Nachfrage basieren, müssen Sie beim Clusterstart die folgenden Konfigurationen festlegen:

  • yarn.node-labels.enabled:true

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

Wenn Sie das nicht angeben ON_DEMAND Limit und das Maximum CORE Knotenparameter, beide Parameter haben standardmäßig die maximale Grenze.

Wenn das Maximum ON_DEMAND Der Knoten liegt unter der maximalen Grenze, bei der verwalteten Skalierung wird das Maximum verwendet ON_DEMAND Knotenparameter zur Aufteilung der Kapazitätszuweisung zwischen ON_DEMAND und SPOT Knoten. Wenn Sie das Maximum festlegen CORE auf einen Knotenparameter, der kleiner als oder gleich dem Parameter für die Mindestkapazität ist, CORE Knoten bleiben bei maximaler Kernkapazität statisch.

Die folgenden Beispiele veranschaulichen das Szenario der Skalierung von CORE-Instanzen auf der Grundlage der Anforderungen des Anwendungsprozesses und von TASK-Instanzen basierend auf der Nachfrage des Executors.

Ausgangszustand des Clusters Skalierungsparameter Skalierungs-Verhalten

Instance-Gruppen

Kern: 1 On-Demand

Aufgabe: 1 On-Demand

UnitType: Instances

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Waagen CORE Knoten zwischen 1 und 20 Knoten auf der Grundlage der Anforderungen des Clusters an den Anwendungsprozessen mithilfe von On-Demand oder Spot-Markt-Typ. Waagen TASK Knoten basierend auf der Nachfrage des Testdienstleisters und der verbleibenden verfügbaren Kapazität nach der Zuweisung durch Amazon EMR CORE Knoten.

Die Summe der angeforderten CORE und TASK Knoten werden den Wert nicht überschreiten maximumCapacity von 20. Die Summe der angeforderten On-Demand-Core-Knoten und On-Demand-Taskknoten wird den Wert von nicht überschreiten maximumOnDemandCapacity von 10. Zusätzliche Kern- oder Task-Nodes verwenden den Spot-Market-Typ.

Instance-Flotten

Kern: 1 On-Demand

Aufgabe: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Szenario 7: Skala ON_DEMAND Instanzen für die Nachfrage nach Anwendungsprozessen und SPOT Instanzen für die Nachfrage des Executors.

Dieses Szenario gilt nur, wenn Sie die verwaltete Skalierung mit Knotenbezeichnungen verwenden und die Ausführung von Anwendungsprozessen nur auf folgenden Geräten einschränken ON_DEMAND Knoten.

Maßstabsgetreu ON_DEMAND Knoten auf der Grundlage der Anforderungen des Anwendungsprozesses und SPOT Bei Knoten, die auf der Executor-Nachfrage basieren, müssen Sie beim Clusterstart die folgenden Konfigurationen festlegen:

  • yarn.node-labels.enabled:true

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

Wenn Sie das nicht angeben ON_DEMAND Limit und das Maximum CORE Knotenparameter, beide Parameter haben standardmäßig die maximale Grenze.

Wenn das Maximum CORE Der Knoten liegt unter der maximalen Grenze, bei der verwalteten Skalierung wird das Maximum verwendet CORE Knotenparameter zur Aufteilung der Kapazitätszuweisung zwischen CORE und TASK Knoten. Wenn Sie das Maximum festlegen CORE auf einen Knotenparameter, der kleiner als oder gleich dem Parameter für die Mindestkapazität ist, CORE Knoten bleiben bei maximaler Kernkapazität statisch.

Die folgenden Beispiele veranschaulichen das Skalierungsszenario On-Demand Instanzen, die auf der Anforderung des Anwendungsprozesses basieren, und Spot-Instances, die auf der Nachfrage des Executors basieren.

Ausgangszustand des Clusters Skalierungsparameter Skalierungs-Verhalten

Instance-Gruppen

Kern: 1 On-Demand

Aufgabe: 1 On-Demand

UnitType: Instances

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10

Waagen ON_DEMAND Knoten zwischen 1 und 20 Knoten auf der Grundlage der Anforderungen des Clusters an den Anwendungsprozessen mithilfe von CORE oder TASK Knotentyp. Waagen SPOT Knoten basierend auf der Nachfrage des Testdienstleisters und der verbleibenden verfügbaren Kapazität nach der Zuweisung durch Amazon EMR ON_DEMAND Knoten.

Die Summe der angeforderten ON_DEMAND und SPOT Knoten werden den Wert nicht überschreiten maximumCapacity von 20. Die Summe der angeforderten On-Demand-Core-Knoten und Spot-Core-Nodes wird den Wert von nicht überschreiten maximumCoreCapacity von 10. Zusätzliche On-Demand- oder Spot-Nodes verwenden den TASK Knotentyp.

Instance-Flotten

Kern: 1 On-Demand

Aufgabe: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10