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.

  • Wenn Sie in Amazon EMR-Versionen 7.2 und höher Node-Labels aktiviert und Anwendungsprozesse auf Knoten beschränkt haben, skaliert Amazon EMR Managed Scaling die Core CORE Nodes und Task-Nodes nach oben, wenn die Anforderungen an Anwendungsprozesse und Executoren steigen. Wenn Sie Node-Labels aktiviert und Anwendungsprozesse auf Knoten beschränkt haben, skaliert die verwaltete Skalierung auf Abruf die ON_DEMAND Knoten nach oben, wenn die Anforderungen an den Anwendungsprozess steigen, und die Spot-Nodes, wenn die Nachfrage durch den Executor 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 ON_DEMAND Knoten und Knoten instance_group2 vorhanden sind und SPOT Knotenlabels aktiviert sind und Anwendungsprozesse auf Knoten mit dem ON_DEMAND Label beschränkt sind. Bei der verwalteten Skalierung wird nach unten instance_group1 und nach oben skaliertinstance_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 Parameter festgelegt ist, skaliert Amazon EMR den Cluster mithilfe der On-Demand Instances, bis die On-Demand Einheiten den maximal zulässigen Grenzwert erreichen. 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 Instances, um Task-Knoten zu skalieren, bis das On-Demand Limit erreicht ist, und verwendet dann Spot-Instances für Task-Nodes.

Scale-down Strategie

  • Ähnlich wie bei der Scale-Up-Strategie entfernt Amazon EMR Knoten auf der Grundlage von Knotenbezeichnungen. Weitere Informationen zu Knotenbezeichnungen finden Sie unter Grundlegendes zu den Knotentypen: 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, die Shuffle-Erkennung auf Clustern mit dem Release-Label 7.4 oder höher zu erkennen. Fügen Sie der Cluster-Konfiguration die folgenden Flags hinzu, um den verbesserten Spark-Shuffle-Schutz zu aktivieren.

    • Wenn entweder das yarn.nodemanager.shuffledata-monitor.interval-ms Flag (Standard 30000 ms) oder das spark.dynamicAllocation.executorIdleTimeout (Standard 60 Sekunden) gegenüber den Standardwerten geändert wurde, stellen Sie sicher, dass der Zustand spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms erhalten bleibt, true indem Sie das erforderliche Flag 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 Knoten, die über Apache Spark verfügenApplicationMaster, nicht herunter, wenn die darauf ausgeführten Anwendungen 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 Verlust von Shuffle-Daten für Spark minimiert, kann es vorkommen, dass transiente Shuffle-Daten während eines Scale-Down möglicherweise nicht geschützt werden. Um die Stabilität von Shuffle-Daten beim Herunterskalieren zu erhöhen, empfehlen wir, Graceful Decommissioning for Shuffle Data in YARN zu aktivieren. Wenn Graceful Decommissioning for Shuffle Data in YARN aktiviert ist, wechseln Knoten, die für das Herunterskalieren ausgewählt wurden und Shuffle-Daten enthalten, in den Status Außerbetriebnahme und stellen weiterhin Zufallsdateien bereit. Das YARN ResourceManager wartet, bis die Knoten melden, dass keine Shuffle-Dateien vorhanden sind, bevor die Knoten aus dem Cluster entfernt werden.

    • Amazon EMR Version 6.11.0 und höher unterstützt die ordnungsgemäße Außerbetriebnahme von Yarn-based Hive-Shuffle-Daten sowohl für den Tez- als auch für den Shuffle-Handler. MapReduce

      • Aktivieren Sie die Graceful Decommissioning für Shuffle-Daten, indem Sie auf setzen. yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data true

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

      • Das Standardverhalten des externen Spark-Shuffle-Dienstes bei der Ausführung von Spark auf Yarn besteht darin, dass das Yarn die Shuffle-Dateien der Anwendung zum Zeitpunkt der Beendigung der NodeManager Anwendung entfernt. Dies kann sich auf die Geschwindigkeit der Außerbetriebnahme von Knoten und die Auslastung der Rechenleistung auswirken. Bei Anwendungen mit langer Laufzeit sollten Sie erwägen, diese Einstellung so spark.shuffle.service.removeShuffle einzustellen, true dass nicht mehr verwendete Shuffle-Dateien entfernt 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 das yarn.nodemanager.shuffledata-monitor.interval-ms Flag (Standard 30000 ms) oder der Wert spark.dynamicAllocation.executorIdleTimeout (Standard 60 Sekunden) gegenüber den Standardwerten geändert wurde, stellen Sie sicher, dass der Zustand spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms erhalten bleibt, true indem Sie das erforderliche Flag 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, die On-Demand Kaufoption für Core-Nodes zu verwenden, 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 Core-Node-Parameter Maximum, Minimum, On-Demand Limit und Maximum in unterschiedlichen Kombinationen einrichten.

Szenario 1: Nur Core-Knoten skalieren

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

  • Das On-Demand Limit entspricht der Maximalgrenze.

  • Der maximale Core-Knoten entspricht der maximalen Grenze.

Wenn der On-Demand Grenzwert und der maximale Kernknotenparameter nicht angegeben sind, wird für beide Parameter standardmäßig die maximale Grenze verwendet.

Dieses Szenario gilt nicht, wenn Sie die verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse so einschränken, dass sie nur auf CORE Knoten ausgeführt werden, 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 mithilfe des On-Demand Typs zwischen 1 und 20 Instances oder Instance-Flotteneinheiten auf Core-Knoten. Keine Skalierung auf Aufgabenknoten.

Wenn Sie die verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse auf ON_DEMAND Knoten beschränken, skaliert der Cluster je nach Bedarf 1 bis 20 Instances On-Demand oder Spot Instance-Flotteneinheiten auf CORE Knoten mithilfe des Typs oder.

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 auf 2 und skaliert nur Taskknoten zwischen 0 und 18 Instances oder Instance-Flotteneinheiten, die den Spot Typ On-demand oder verwenden, je nach 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

Damit es nur On-Demand Instanzen gibt, müssen Ihr Cluster und die verwalteten Skalierungsparameter die folgende Anforderung erfüllen:

  • Das On-Demand Limit entspricht der maximalen Grenze.

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

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 bei der Erstkonfiguration den On-Demand Markttyp verwenden.

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

Die folgenden Beispiele veranschaulichen das Szenario, dass On-Demand Instanzen im gesamten Cluster vorhanden sind.

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 mithilfe des On-Demand Typs zwischen 1 und 12 Instanzen oder Instanzflotteneinheiten auf Core-Knoten. Skalieren Sie die verbleibende Kapazität mithilfe von On-Demand On Task Nodes. Keine Skalierung mit Spot Instances.

Wenn Sie die verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse auf CORE Knoten beschränken, skaliert der Cluster je nach ON_DEMAND Art der Nachfrage zwischen 1 und 20 Instances oder Instance-Flotteneinheiten auf CORE task Knoten oder Knoten, die diesen Typ verwenden. Die Skalierung auf Core-Knoten wird 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 verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse so einschränken, dass sie nur auf ON_DEMAND Knoten ausgeführt werden, da die verwaltete Skalierung ON_DEMAND Knoten skaliert, um den Anforderungen der Anwendungsprozesse 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 Typ.

Wenn Sie die verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse auf CORE Knoten beschränken, skaliert der Cluster je nach Art der Nachfrage zwischen 1 und 20 Instances CORE oder Instance-Flotteneinheiten auf oder TASK Knoten, die Spot verwenden. Amazon EMR skaliert nicht mit diesem Typ. ON_DEMAND

Instance-Flotten

Core: 1 Spot

Aufgabe: 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Szenario 5: Skalieren Sie On-Demand Instances auf Core-Knoten und Spot-Instances auf Task-Knoten

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

  • Das On-Demand Limit muss der maximalen Anzahl an Kernknoten entsprechen.

  • Sowohl der On-Demand Grenzwert als auch der maximale Kernknoten müssen unter der maximalen Grenze liegen.

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

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

Die folgenden Beispiele veranschaulichen das Szenario der Skalierung von 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

Skalieren Sie auf bis zu 6 On-Demand Einheiten auf dem Kernknoten, da sich bereits 1 On-Demand Einheit auf dem Task-Knoten On-Demand befindet und die Höchstgrenze für 7 Einheiten beträgt. 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: Skalieren Sie CORE Instances für die Anforderungen von Anwendungsprozessen und TASK Instances für Executor-Anforderungen.

Dieses Szenario gilt nur, wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden und Anwendungsprozesse so einschränken, dass sie nur auf CORE Knoten ausgeführt werden.

Um CORE Knoten auf der Grundlage der Anforderungen des Anwendungsprozesses und TASK Knoten auf der Grundlage der Anforderungen des Executors zu skalieren, 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 den ON_DEMAND Grenzwert und die maximale Anzahl der CORE Knotenparameter nicht angeben, wird für beide Parameter standardmäßig die maximale Grenze verwendet.

Wenn der maximale ON_DEMAND Knoten kleiner als die maximale Grenze ist, verwendet die verwaltete Skalierung den maximalen ON_DEMAND Knotenparameter, um die Kapazitätszuweisung zwischen SPOT Knoten ON_DEMAND und aufzuteilen. Wenn Sie den Parameter für den maximalen CORE Knoten auf einen Wert setzen, der kleiner als oder gleich dem Parameter für die Mindestkapazität ist, bleiben die CORE Knoten bei der maximalen 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

Skaliert CORE Knoten auf der Grundlage der Anforderungen des Clusters im Anwendungsprozess zwischen 1 und 20 Knoten. Dabei wird der Markttyp On-Demand oder Spot verwendet. Skaliert TASK Knoten basierend auf der Nachfrage des Executors und der verbleibenden verfügbaren Kapazität, nachdem Amazon EMR Knoten zugewiesen hat. CORE

Die Summe der angeforderten TASK Knoten CORE und Knoten darf den Wert von 20 nicht überschreiten. maximumCapacity Die Summe der angeforderten On-Demand-Kernknoten und On-Demand-Taskknoten darf den Wert maximumOnDemandCapacity von 10 nicht überschreiten. 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: Skalieren Sie ON_DEMAND Instanzen für die Anforderungen von Anwendungsprozessen und SPOT Instanzen für die Anforderungen von Executoren.

Dieses Szenario gilt nur, wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden und Anwendungsprozesse so einschränken, dass sie nur auf ON_DEMAND Knoten ausgeführt werden.

Um ON_DEMAND Knoten auf der Grundlage der Anforderungen des Anwendungsprozesses und SPOT Knoten auf der Grundlage der Anforderungen des Executors zu skalieren, 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 den ON_DEMAND Grenzwert und die maximale Anzahl der CORE Knotenparameter nicht angeben, wird für beide Parameter standardmäßig die maximale Grenze verwendet.

Wenn der maximale CORE Knoten kleiner als die maximale Grenze ist, verwendet die verwaltete Skalierung den Parameter für den maximalen CORE Knoten, um die Kapazitätszuweisung zwischen den TASK Knoten CORE und den Knoten aufzuteilen. Wenn Sie den Parameter für den maximalen CORE Knoten auf einen Wert setzen, der kleiner als oder gleich dem Parameter für die Mindestkapazität ist, bleiben die CORE Knoten bei der maximalen Kernkapazität statisch.

Die folgenden Beispiele veranschaulichen das Szenario der Skalierung von On-Demand Instances auf der Grundlage der Nachfrage nach Anwendungsprozessen und Spot-Instances 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: 20

MaximumCoreCapacityUnits: 10

Skaliert ON_DEMAND Knoten auf der Grundlage der Anforderungen des Clusters an den Anwendungsprozess zwischen 1 und 20 TASK Knoten unter Verwendung des Knotentyps CORE oder. Skaliert SPOT Knoten basierend auf der Nachfrage des Executors und der verbleibenden verfügbaren Kapazität, nachdem Amazon EMR Knoten zugewiesen hat. ON_DEMAND

Die Summe der angeforderten SPOT Knoten ON_DEMAND und Knoten darf den Wert von 20 nicht überschreiten. maximumCapacity Die Summe der angeforderten On-Demand-Core-Knoten und Spot-Core-Knoten darf den Wert maximumCoreCapacity von 10 nicht überschreiten. 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