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 Amazon EMR-Knotenzuweisungsstrategie und -Szenarien
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:
**Strategie zum hochskalieren**
+ Für Amazon EMR-Versionen 7.2 und höher fügt die verwaltete Skalierung zunächst Knoten hinzu, die auf Knotenbezeichnungen und der YARN-Eigenschaft für Anwendungsprozesseinschränkungen basieren.
+ Für Amazon EMR-Versionen 7.2 und höher gilt: Wenn Sie Node Labels aktiviert und Anwendungsprozesse auf `CORE` Knoten beschränkt haben, skaliert Amazon EMR Managed Scaling die Kernknoten und Aufgabenknoten hoch, wenn die Nachfrage nach Anwendungsprozessen steigt und die Nachfrage nach Ausführern steigt. Wenn Sie Node-Labels aktiviert und Anwendungsprozesse auf Knoten beschränkt haben, skaliert Managed Scaling entsprechend `ON_DEMAND` On-Demand-Knoten, wenn die Nachfrage nach Anwendungsprozessen steigt, und skaliert Spot-Knoten, wenn die Nachfrage nach Executoren steigt.
+ Wenn Node Labels nicht aktiviert sind, ist die Platzierung von Anwendungsprozessen nicht auf einen Knoten oder Markttyp beschränkt.
+ Durch die Verwendung von Node Labels kann Managed Scaling verschiedene Instanzgruppen und Instanzflotten bei derselben Größenänderung hoch- und herunterskalieren. Zum Beispiel in einem Szenario, in dem `instance_group1` ein `ON_DEMAND` Knoten und ein `SPOT` Knoten `instance_group2` vorhanden sind und die Knotenbezeichnungen aktiviert sind und Anwendungsprozesse auf Knoten mit der `ON_DEMAND` Bezeichnung beschränkt sind. Die verwaltete Skalierung wird herunterskaliert `instance_group1` und hochskaliert, `instance_group2` wenn die Nachfrage nach Anwendungsprozessen sinkt und die Nachfrage nach Ausführern 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 Aufgabenknoten zu skalieren, bis das On-Demand-Limit erreicht ist, und verwendet dann Spot Instances für Aufgabenknoten.
**Strategie zum herunterskalieren**
+ Ähnlich wie bei der Scale-up-Strategie entfernt Amazon EMR Knoten, die auf Knotenbezeichnungen basieren. Weitere Informationen zu Knotenbezeichnungen finden Sie unter Grundlegendes [zu Knotentypen: Primär-, Kern- und Aufgabenknoten](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html).
+ Wenn Sie Node Labels nicht aktiviert haben, entfernt Managed Scaling Task-Knoten und anschließend Core-Knoten, bis die gewünschte Scale-Down-Zielkapazität erreicht ist. Bei der verwalteten Skalierung wird der Cluster niemals unter die in der Richtlinie für verwaltete Skalierung angegebenen Mindestbeschränkungen herunterskaliert.
+ Amazon EMR-Versionen 5.34.0 und höher sowie Amazon EMR-Versionen 6.4.0 und höher unterstützen Spark Shuffle Data Awareness, wodurch verhindert wird, dass eine Instance herunterskaliert wird, während Managed Scaling vorhandene Shuffle-Daten erkennt. [Weitere Informationen zu Shuffle-Vorgängen finden Sie im Spark-Programmierhandbuch.](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations) Managed Scaling bemüht sich nach besten Kräften, 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 Versuche und die Neuberechnung von Zwischendaten erforderlich sind. Die Verhinderung des Verlusts von Shuffle-Daten kann jedoch nicht garantiert werden. Für einen verbesserten Spark-Shuffle-Schutz empfehlen wir die Erkennung von Shuffle Awareness auf Clustern mit Release-Label 7.4 oder höher. 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 30.000 ms) oder das Flag `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 Aufgabenknoten und dann Kernknoten entfernt, bis die gewünschte Zielkapazität für das Herunterskalieren erreicht ist. Der Cluster wird niemals unter die in der Richtlinie für verwaltete Skalierung angegebenen Mindestbeschränkungen skaliert.
+ Bei Clustern, die mit den Amazon EMR 5.x-Versionen 5.34.0 und höher und 6.x-Versionen 6.4.0 und höher gestartet wurden, skaliert Amazon EMR Managed Scaling keine Knoten, die `ApplicationMaster` für Apache Spark verwendet wurden, herunter, wenn es aktive Phasen in den darauf laufenden Anwendungen gibt. 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.
+ Die intelligente Skalierung mit EMR Managed Scaling minimiert zwar den Verlust von Shuffle-Daten für Spark, es kann jedoch vorkommen, dass vorübergehende Shuffle-Daten während eines Scale-Down möglicherweise nicht geschützt sind. **Um die Ausfallsicherheit 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, gehen Knoten, die für das Herunterskalieren ausgewählt wurden und über Shuffle-Daten verfügen, in den Status Außerbetriebnahme über und stellen weiterhin Shuffle-Dateien bereit.** Das YARN ResourceManager wartet, bis die Knoten melden, dass keine Shuffle-Dateien vorhanden sind, bevor es die Knoten aus dem Cluster entfernt.
+ Amazon EMR Version 6.11.0 und höher unterstützt Yarn-basierte Graceful Decommissioning für **Hive-Shuffle-Daten** sowohl für den Tez- als auch für den Shuffle-Handler. MapReduce
+ Aktivieren Sie die automatische `true` Außerbetriebnahme für Shuffle Data, indem Sie auf `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` einstellen.
+ Amazon EMR, Version 7.4.0 und höher, unterstützt Yarn-basierte Graceful Decommissioning für 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 Yarn die Shuffle-Dateien der Anwendung beim Beenden der Anwendung entfernt. NodeManager Dies kann sich auf die Geschwindigkeit der Außerbetriebnahme von Knoten und die Rechenauslastung auswirken. Bei Anwendungen mit langer Laufzeit sollten Sie erwägen, `spark.shuffle.service.removeShuffle` die Einstellung `true` auf so einzustellen, 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 die folgenden Flags setzen.
+ Wenn entweder das `yarn.nodemanager.shuffledata-monitor.interval-ms` Flag (Standard 30.000 ms) oder das Flag `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, die On-Demand-Kaufoption für Core-Knoten zu verwenden, um HDFS-Datenverlust im Falle einer Spot-Rückforderung 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-Knotenparameter 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 maximalen Grenze.
+ Der maximale Core-Knoten entspricht der maximalen Grenze.
Wenn das On-Demand-Limit und die maximale Anzahl an Core-Knoten nicht angegeben sind, verwenden beide Parameter standardmäßig die maximale Grenze.
Dieses Szenario ist nicht anwendbar, wenn Sie Managed Scaling mit Node Labels verwenden und Ihre Anwendungsprozesse darauf beschränken, nur auf `CORE` Knoten ausgeführt zu werden, da Managed Scaling Task-Knoten skaliert, um den Anforderungen der Executoren gerecht zu werden.
Das folgende Beispiele zeigt das Szenario der ausschließlichen Skalierung von Core-Knoten.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**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.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Szenario 4: Nur On-Demand-Instance im Cluster**
Um nur über On-Demand-Instances zu verfügen, müssen Ihr Cluster und die verwalteten Skalierungsparameter die folgende Anforderung erfüllen:
+ Das On-Demand-Limit entspricht der maximalen Grenze.
Wenn das On-Demand-Limit nicht angegeben ist, entspricht der Parameterwert standardmäßig der Höchstgrenze. 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 aktivieren, der aus Instance-Gruppen besteht, müssen alle Knotengruppen im Cluster bei der Erstkonfiguration den Markttyp On-Demand verwenden.
Dieses Szenario ist nicht anwendbar, wenn Sie Managed Scaling mit Node-Labels verwenden und Ihre Anwendungsprozesse so beschränken, dass sie nur auf Knoten ausgeführt werden, da die verwaltete Skalierung die `ON_DEMAND` Knoten skaliert, um den Anforderungen der Executoren gerecht zu `Spot` werden.
Die folgenden Beispiele veranschaulichen das Szenario, in dem On-Demand-Instances im gesamten Cluster vorhanden sind.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Szenario 4: Nur Spot Instances im Cluster**
Um nur Spot Instances zu verwenden, müssen die verwalteten Skalierungsparameter die folgenden Anforderungen erfüllen:
+ Das On-Demand-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 darauf beschränken, nur auf `ON_DEMAND` Knoten ausgeführt zu werden, da die verwaltete Skalierung die `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.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Szenario 5: On-Demand-Instances auf Core-Knoten und Spot Instances auf Aufgabenknoten skalieren**
Um On-Demand-Instances auf Core-Knoten und Spot Instances auf Aufgabenknoten zu skalieren, müssen die verwalteten Skalierungsparameter die folgenden Anforderungen erfüllen:
+ Das On-Demand-Limit muss dem maximalen Core-Knoten entsprechen.
+ Sowohl das On-Demand-Limit als auch die maximale Anzahl an Core-Knoten müssen unter der maximalen Grenze liegen.
Um dieses Szenario in einem Cluster zu aktivieren, der aus Instance-Gruppen besteht, muss die Core-Knotengruppe die On-Demand-Kaufoption verwenden.
Dieses Szenario ist nicht anwendbar, wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse darauf beschränken, nur auf `ON_DEMAND` Knoten oder `CORE` Knoten ausgeführt zu werden.
Die folgenden Beispiele veranschaulichen das Szenario der Skalierung von On-Demand-Instances auf Core-Knoten und Spot Instances auf Aufgabenknoten.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Szenario 6: Skalieren Sie `CORE` Instances für den Bedarf von Anwendungsprozessen und `TASK` Instanzen für den Bedarf von Executoren.**
Dieses Szenario ist nur anwendbar, 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 der Executoren 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 den maximalen `CORE` Knotenparameter nicht angeben, verwenden beide Parameter standardmäßig die maximale Grenze.
Wenn die maximale Anzahl an `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 Knoten aufzuteilen. Wenn Sie den Parameter für den maximalen `CORE` Knoten auf weniger als oder gleich dem Parameter für die minimale Kapazität festlegen, 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 von Anwendungsprozessen und von TASK-Instanzen auf der Grundlage der Anforderungen von Executoren.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Szenario 7: Skalieren Sie `ON_DEMAND` Instances für den Bedarf an Anwendungsprozessen und `SPOT` Instances für den Bedarf an Executoren.**
Dieses Szenario ist nur anwendbar, 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 der Executoren 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 den maximalen `CORE` Knotenparameter nicht angeben, verwenden beide Parameter standardmäßig die maximale Grenze.
Wenn die maximale Anzahl an `CORE` Knoten kleiner als die maximale Grenze ist, verwendet die verwaltete Skalierung den maximalen `CORE` Knotenparameter, um die Kapazitätszuweisung zwischen `TASK` Knoten `CORE` und Knoten aufzuteilen. Wenn Sie den Parameter für den maximalen `CORE` Knoten auf weniger als oder gleich dem Parameter für die minimale Kapazität festlegen, 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 Anforderungen des Anwendungsprozesses und Spot-Instances auf der Grundlage der Nachfrage von Executoren.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)