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
<a name="managed-scaling-allocation-strategy"></a>

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

## Knotenzuweisungsstrategie
<a name="node-allocation-strategy"></a>

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

**Scale-up Strategie**
+ 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. 

**Scale-down Strategie**
+ Ä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 Resilienz von Shuffle-Daten beim Herunterskalieren zu erhöhen, empfehlen wir, Graceful Decommissioning für Shuffle-Daten 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ützen Yarn-based die ordnungsgemäße Außerbetriebnahme von **Hive-Shuffle-Daten** sowohl für den Tez- als auch für den Shuffle-Handler. MapReduce 
    + Aktivieren Sie Graceful Decommissioning für Shuffle Data, indem Sie auf einstellen. `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` `true`
  + Amazon EMR Version 7.4.0 und höher unterstützen die ordnungsgemäße Außerbetriebnahme Yarn-based von 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 NodeManager Anwendung entfernt. 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 `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
<a name="node-allocation-considerations"></a>

Wir empfehlen, die On-Demand Kaufoption für Core-Nodes 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
<a name="node-allocation-scenarios"></a>

Sie können je nach Bedarf verschiedene Skalierungsszenarien erstellen, indem Sie die Kernknotenparameter 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 der On-Demand Grenzwert und der maximale Kernknotenparameter 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.


<table>
<thead>
  <tr><th>Ausgangszustand des Clusters</th><th>Skalierungsparameter</th><th>Skalierungs-Verhalten</th></tr>
</thead>
<tbody>
  <tr><td>**Instance-Gruppen**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand und 1 Platz</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 20</td><td rowspan="2">Skalieren Sie mithilfe des On-Demand Typs zwischen 1 und 20 Instances oder Instance-Flotteneinheiten auf Kernknoten. Keine Skalierung auf Aufgabenknoten.<br />Wenn Sie Managed Scaling mit Node-Labels verwenden und Ihre Anwendungsprozesse auf `ON_DEMAND` Knoten beschränken, skaliert der Cluster je nach `Spot` Art der Nachfrage 1 bis 20 Instances oder Instance-Flotteneinheiten auf `CORE` Knoten, die den Typ `On-Demand` oder verwenden.</td></tr>
  <tr><td>**Instance-Flotten**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand und 1 Platz</td><td>UnitType: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 20</td></tr>
</tbody>
</table>


**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.


<table>
<thead>
  <tr><th>Ausgangszustand des Clusters</th><th>Skalierungsparameter</th><th>Skalierungs-Verhalten</th></tr>
</thead>
<tbody>
  <tr><td>**Instance-Gruppen**<br />Kern: 2 On-Demand<br />Aufgabe: 1 Spot</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 2<br />`MaximumCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 2</td><td rowspan="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.<br /> Wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse auf ON\_DEMAND-Knoten beschränken, hält der Cluster die Anzahl der Kernknoten konstant bei 2 und skaliert je nach Art der Nachfrage nur Taskknoten zwischen 0 und 18 Instances oder Instance-Flotteneinheiten, die den `Spot` Typ `On-demand` oder verwenden. </td></tr>
  <tr><td>**Instance-Flotten**<br />Kern: 2 On-Demand<br />Aufgabe: 1 Spot</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 2<br />`MaximumCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 2</td></tr>
</tbody>
</table>


**Szenario 3: Nur On-Demand Instanzen im Cluster**

Um nur On-Demand Instances zu haben, müssen Ihr Cluster und die verwalteten Skalierungsparameter die folgenden Anforderungen erfüllen: 
+ Das On-Demand Limit entspricht der maximalen Grenze. 

  Wenn der On-Demand Grenzwert nicht angegeben ist, ist der Parameterwert standardmäßig auf die maximale Grenze eingestellt. 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 On-Demand Markttyp verwenden. 

Dieses Szenario ist nicht anwendbar, wenn Sie Managed Scaling mit Node Labels verwenden und Ihre Anwendungsprozesse darauf beschränken, nur auf `ON_DEMAND` Knoten ausgeführt zu werden, da Managed Scaling die `Spot` Knoten skaliert, um den Anforderungen der Executoren gerecht zu werden.

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


<table>
<thead>
  <tr><th>Ausgangszustand des Clusters</th><th>Skalierungsparameter</th><th>Skalierungs-Verhalten</th></tr>
</thead>
<tbody>
  <tr><td>**Instance-Gruppen**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand </td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 12</td><td rowspan="2">Skalieren Sie mithilfe des On-Demand Typs zwischen 1 und 12 Instanzen oder Instanzflotteneinheiten auf Kernknoten. Skalieren Sie die verbleibende Kapazität mithilfe von On-Demand On-Task-Knoten. Keine Skalierung mit Spot Instances.<br /> Wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse auf `CORE` Knoten beschränken, skaliert der Cluster je nach `ON_DEMAND` Art des Bedarfs zwischen 1 und 20 Instanzen oder Instanzflotteneinheiten auf `CORE` `task` Knoten oder Knoten, die diesen Typ verwenden. Die Skalierung auf Kernknoten wird 12 Instances oder Instance-Flotteneinheiten nicht überschreiten. </td></tr>
  <tr><td>**Instance-Flotten**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 12</td></tr>
</tbody>
</table>


**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 Managed Scaling mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse darauf beschränken, nur auf `ON_DEMAND` Knoten ausgeführt zu werden, da Managed Scaling `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.


<table>
<thead>
  <tr><th>Ausgangszustand des Clusters</th><th>Skalierungsparameter</th><th>Skalierungs-Verhalten</th></tr>
</thead>
<tbody>
  <tr><td>**Instance-Gruppen**<br />Core: 1 Spot<br />Aufgabe: 1 Spot</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 0</td><td rowspan="2">Skalieren Sie mithilfe von Spot zwischen 1 und 20 Instances oder Instance-Flotteneinheiten auf Core-Knoten. Keine Skalierung anhand On-Demand des Typs.<br />Wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden und Ihre Anwendungsprozesse auf `CORE` Knoten beschränken, skaliert der Cluster je nach Art des Bedarfs zwischen 1 und 20 Instances `CORE` oder Instance-Flotteneinheiten auf oder `TASK` Knoten, die Spot verwenden. Amazon EMR skaliert nicht mit dem `ON_DEMAND` Typ.</td></tr>
  <tr><td>**Instance-Flotten**<br />Core: 1 Spot<br />Aufgabe: 1 Spot</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 0</td></tr>
</tbody>
</table>


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

Um On-Demand Instances auf Kernknoten und Spot-Instances auf Task-Knoten 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 Kernknoten müssen unter der maximalen Grenze liegen.

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

Dieses Szenario ist nicht anwendbar, wenn Sie Managed Scaling 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 Kernknoten und Spot-Instances auf Task-Knoten.


<table>
<thead>
  <tr><th>Ausgangszustand des Clusters</th><th>Skalierungsparameter</th><th>Skalierungs-Verhalten</th></tr>
</thead>
<tbody>
  <tr><td>**Instance-Gruppen**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand und 1 Platz</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 7 <br />`MaximumCoreCapacityUnits`: 7</td><td rowspan="2">Skalieren Sie auf bis zu 6 On-Demand Einheiten auf dem Kernknoten, da sich bereits 1 On-Demand Einheit auf dem Task-Knoten befindet und die Höchstgrenze für 7 On-Demand ist. Hochskalieren Sie anschließend auf bis zu 13 Spot-Einheiten auf Aufgabenknoten.</td></tr>
  <tr><td>**Instance-Flotten**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand und 1 Platz</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 7<br />`MaximumCoreCapacityUnits`: 7</td></tr>
</tbody>
</table>


**Szenario 6: Skalieren Sie `CORE` Instances für den Bedarf an Anwendungsprozessen und `TASK` Instanzen 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 `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 des Anwendungsprozesses und von TASK-Instanzen auf der Grundlage der Nachfrage von Executoren.


<table>
<thead>
  <tr><th>Ausgangszustand des Clusters</th><th>Skalierungsparameter</th><th>Skalierungs-Verhalten</th></tr>
</thead>
<tbody>
  <tr><td>**Instance-Gruppen**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 10<br />`MaximumCoreCapacityUnits`: 20</td><td rowspan="2">Skaliert `CORE` Knoten zwischen 1 und 20 Knoten auf der Grundlage der Nachfrage nach dem Anwendungsprozess des Clusters und verwendet dabei den Markttyp On-Demand oder den Spot-Markttyp. Skaliert `TASK` Knoten auf der Grundlage der Nachfrage der Executoren und der verbleibenden verfügbaren Kapazität, nachdem Amazon EMR Knoten zugewiesen hat. `CORE`<br />Die Summe der angeforderten `TASK` Knoten `CORE` und der Knoten wird den Wert von 20 nicht überschreiten. `maximumCapacity` Die Summe der angeforderten On-Demand-Core-Knoten und der On-Demand-Aufgabenknoten wird den Wert `maximumOnDemandCapacity` von 10 nicht überschreiten. Zusätzliche Kern- oder Taskknoten verwenden den Spotmarkttyp. </td></tr>
  <tr><td>**Instance-Flotten**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 10<br />`MaximumCoreCapacityUnits`: 20</td></tr>
</tbody>
</table>


**Szenario 7: Skalieren Sie `ON_DEMAND` Instances für den Bedarf von Anwendungsprozessen und `SPOT` Instanzen 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.


<table>
<thead>
  <tr><th>Ausgangszustand des Clusters</th><th>Skalierungsparameter</th><th>Skalierungs-Verhalten</th></tr>
</thead>
<tbody>
  <tr><td>**Instance-Gruppen**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand</td><td>`UnitType`: Instances<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 10</td><td rowspan="2">Skaliert `ON_DEMAND` Knoten zwischen 1 und 20 Knoten auf der Grundlage der Anforderungen des Clusters für den Anwendungsprozess unter Verwendung des `TASK` Knotentyps `CORE` oder. Skaliert `SPOT` Knoten auf der Grundlage der Nachfrage der Executoren und der verbleibenden verfügbaren Kapazität, nachdem Amazon EMR Knoten zugewiesen hat. `ON_DEMAND`<br />Die Summe der angeforderten `SPOT` Knoten `ON_DEMAND` und der Knoten wird den Wert von 20 nicht überschreiten. `maximumCapacity` Die Summe der angeforderten On-Demand-Core-Knoten und Spot-Core-Knoten wird den Wert `maximumCoreCapacity` von 10 nicht überschreiten. Zusätzliche On-Demand-Nodes oder Spot-Nodes verwenden den `TASK` Knotentyp. </td></tr>
  <tr><td>**Instance-Flotten**<br />Kern: 1 On-Demand<br />Aufgabe: 1 On-Demand</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 10</td></tr>
</tbody>
</table>