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.
# Verwenden Sie die Amazon EMR-Cluster-Skalierung, um sich an wechselnde Workloads anzupassen
Als Reaktion auf Workloads mit unterschiedlichen Anforderungen können Sie die Anzahl der für einen Amazon-EMR-Cluster verfügbaren Amazon-EC2-Instances automatisch oder manuell festlegen. Um die automatische Skalierung zu verwenden, haben Sie zwei Optionen. Sie können Amazon EMR Managed Scaling aktivieren oder eine benutzerdefinierte Richtlinie für Auto Scaling erstellen. Die folgende Tabelle beschreibt die Unterschiede zwischen den Optionen.
| | Amazon EMR Managed Scaling | Benutzerdefinierte automatische Skalierung |
| --- | --- | --- |
| Skalieren von Richtlinien und Regeln | Keine Richtlinie erforderlich. Amazon EMR verwaltet die Aktivität von Auto Scaling durch kontinuierliche Auswertung von Cluster-Metriken und optimierte Skalierungsentscheidungen. | Sie müssen die Richtlinien und Regeln für das Auto Scaling definieren und verwalten, z. B. die spezifischen Bedingungen, die Skalierungsaktivitäten, Evaluierungszeiträume, Ruhephasen usw. auslösen. |
| Unterstützte Versionen für Amazon EMR | Amazon-EMR-Version 5.30.0 und höher (außer Amazon-EMR-Version 6.0.0) | Amazon-EMR-Version 4.0.0 und höher |
| Unterstützte Clusterzusammenstellung | Instance-Gruppen oder Instance-Flotten | Nur Instance-Gruppen |
| Konfiguration von Skalierungsgrenzen | Skalierungsgrenzwerte werden für den gesamten Cluster konfiguriert. | Skalierungslimits können nur für jede Instance-Gruppe konfiguriert werden. |
| Häufigkeit der Auswertung von Metriken | Alle 5 bis 10 Sekunden Eine häufigere Auswertung von Metriken ermöglicht es Amazon EMR, präzisere Skalierungsentscheidungen zu treffen. | Sie können die Auswertungszeiträume nur in Fünf-Minuten-Schritten definieren. |
| Unterstützte Anwendungen | Es werden nur YARN-Anwendungen wie Spark, Hadoop, Hive, Flink unterstützt. Amazon EMR Managed Scaling unterstützt keine Anwendungen, die nicht auf YARN basieren, wie Presto oder. HBase | Sie können auswählen, welche Anwendungen unterstützt werden, wenn Sie die Regeln für eine automatische Skalierung definieren. |
## Überlegungen
+ Ein Amazon-EMR-Cluster besteht immer aus einem oder drei Primärknoten. Sobald Sie den Cluster zum ersten Mal konfiguriert haben, können Sie nur Core- und Aufgabenknoten skalieren. Sie können die Anzahl der Primärknoten für den Cluster nicht skalieren.
+ Bei Instance-Gruppen werden Rekonfigurations- und Größenänderungsvorgänge nacheinander und nicht gleichzeitig ausgeführt. Wenn Sie eine Neukonfiguration initiieren, während die Größe einer Instance-Gruppe geändert wird, beginnt die Neukonfiguration, sobald die Instance-Gruppe die laufende Größenänderung abgeschlossen hat. Umgekehrt gilt: Wenn Sie einen Vorgang zur Größenänderung einleiten, während eine Instance-Gruppe mit der Neukonfiguration beschäftigt ist, beginnt die Größenänderung, sobald die Neukonfiguration abgeschlossen ist.
# Verwenden der verwalteten Skalierung in Amazon EMR
**Wichtig**
Wir empfehlen dringend, die neueste Amazon EMR-Version (Amazon EMR 7.12.0) für verwaltete Skalierung zu verwenden. In einigen frühen Versionen kann es zu zeitweiligen Anwendungsausfällen oder Verzögerungen bei der Skalierung kommen. Amazon EMR hat dieses Problem mit den 5.x-Versionen 5.30.2, 5.31.1, 5.32.1, 5.33.1 und höher sowie mit den 6.x-Versionen 6.1.1, 6.2.1, 6.3.1 und höher behoben. Weitere Informationen zur Region und Release-Verfügbarkeit finden Sie unter [Verwaltete Skalierungsverfügbarkeit](#emr-managed-scaling-availability)
## -Übersicht
Mit den Amazon-EMR-Versionen 5.30.0 und höher (außer Amazon EMR 6.0.0) können Sie die von Amazon EMR Managed Scaling aktivieren. Managed Scaling hilft Ihnen, die Anzahl der Instances oder Einheiten in Ihrem Cluster basierend auf der Workload automatisch zu erhöhen oder zu verringern. Amazon EMR wertet Cluster-Metriken kontinuierlich aus, um Skalierungsentscheidungen zu treffen, die Ihre Cluster für Kosten und Geschwindigkeit optimieren. Verwaltete Skalierung ist für Cluster verfügbar, die entweder aus Instance-Gruppen oder Instance-Flotten bestehen.
## Verwaltete Skalierungsverfügbarkeit
+ Im Folgenden AWS-Regionen ist die von Amazon EMR verwaltete Skalierung mit Amazon EMR 6.14.0 und höher verfügbar:
+ Asien-Pazifik (Taipei) (ap-east-2)
+ Asien-Pazifik (Melbourne) (ap-southeast-4)
+ Asien-Pazifik (Malaysia) (ap-southeast-5)
+ Asien-Pazifik (Neuseeland) (ap-southeast-6)
+ Asien-Pazifik (Thailand) (ap-southeast-7)
+ Kanada West (Calgary) (ca-west-1)
+ Europa (Spanien) (eu-south-2)
+ Mexiko (Zentral) (mx-central-1)
+ Im Folgenden AWS-Regionen ist die von Amazon EMR verwaltete Skalierung mit Amazon EMR 5.30.0 und 6.1.0 und höher verfügbar:
+ USA Ost (Nord-Virginia): (us-east-1)
+ USA Ost (Ohio): (us-east-2)
+ USA West (Oregon): (us-west-2)
+ USA West (Nordkalifornien) (us-west-1)
+ Afrika (Kapstadt) (af-south-1)
+ Asien-Pazifik (Hongkong) (ap-east-1)
+ Asien-Pazifik (Mumbai): (ap-south-1)
+ Asien-Pazifik (Hyderabad) (ap-south-2)
+ Asien-Pazifik (Seoul): (ap-northeast-2)
+ Asien-Pazifik (Singapur): (ap-southeast-1)
+ Asien-Pazifik (Sydney): (ap-southeast-2)
+ Asien-Pazifik (Jakarta) (ap-southeast-3)
+ Asien-Pazifik (Tokyo) (ap-northeast-1)
+ Asien-Pazifik (Osaka) (ap-northeast-3)
+ Kanada (Zentral): (ca-central-1)
+ Südamerika (São Paulo) (sa-east-1)
+ Europa (Frankfurt) (eu-central-1)
+ Europa (Zürich) (eu-central-2)
+ Europa (Irland) (eu-west-1)
+ Europa (London) (eu-west-2)
+ Europa (Mailand) (eu-south-1)
+ Europa (Paris) (eu-west-3)
+ Europa (Stockholm) (eu-north-1)
+ Israel (Tel Aviv) (il-central-1)
+ Naher Osten (VAE) (me-central-1)
+ China (Peking) (cn-north-1)
+ China (Ningxia) (cn-northwest-1)
+ AWS GovCloud (US-Ost) (-1) us-gov-east
+ AWS GovCloud (US-West) (us-gov-west-1)
+ Amazon EMR Managed Scaling funktioniert nur mit YARN-Anwendungen wie Spark, Hadoop, Hive und Flink. Es unterstützt keine Anwendungen, die nicht auf YARN basieren, wie Presto und. HBase
## Verwaltete Skalierungsparameter
Sie müssen die folgenden Parameter für die verwaltete Skalierung konfigurieren. Das Limit gilt nur für die Kern- und Aufgabenknoten. Der Primärknoten kann nach der Erstkonfiguration nicht skaliert werden.
+ **Minimum** (`MinimumCapacityUnits`) – Die untere Grenze der zulässigen EC2-Kapazität in einem Cluster. Sie wird durch vCPU-Kerne oder Instances für Instance-Gruppen gemessen. Sie wird in Einheiten für Instance-Flotten gemessen.
+ **Maximum** (`MaximumCapacityUnits`) – Die Obergrenze der zulässigen EC2-Kapazität in einem Cluster. Sie wird durch vCPU-Kerne oder Instances für Instance-Gruppen gemessen. Sie wird in Einheiten für Instance-Flotten gemessen.
+ **On-Demand-Limit** (`MaximumOnDemandCapacityUnits`) (optional) – Die Obergrenze der zulässigen EC2-Kapazität für den On-Demand-Markttyp in einem Cluster. Wenn dieser Parameter nicht angegeben wird, wird der Standardwert `MaximumCapacityUnits` verwendet.
+ Dieser Parameter wird verwendet, um die Kapazitätszuweisung zwischen On-Demand- und Spot Instances aufzuteilen. Wenn Sie beispielsweise den Minimalparameter auf 2 Instances, den Maximalparameter auf 100 Instances und das On-Demand-Limit auf 10 Instances festlegen, skaliert Amazon EMR Managed Scaling auf bis zu 10 On-Demand-Instances und weist die verbleibende Kapazität Spot Instances zu. Weitere Informationen finden Sie unter [Knotenzuweisungsszenarien](managed-scaling-allocation-strategy.md#node-allocation-scenarios).
+ **Maximale Core-Knoten** (`MaximumCoreCapacityUnits`) (optional) – Die Obergrenze der zulässigen EC2-Kapazität für den Core-Knotentyp in einem Cluster. Wenn dieser Parameter nicht angegeben wird, wird der Standardwert `MaximumCapacityUnits` verwendet.
+ Dieser Parameter wird verwendet, um die Kapazitätszuweisung zwischen Core- und Aufgabenknoten aufzuteilen. Wenn Sie beispielsweise den Minimalparameter auf 2 Instances, das Maximum auf 100 Instances und den maximalen Core-Knoten auf 17 Instances festlegen, skaliert Amazon EMR Managed Scaling auf bis zu 17 Core-Knoten und weist die verbleibenden 83 Instances Aufgabenknoten zu. Weitere Informationen finden Sie unter [Knotenzuweisungsszenarien](managed-scaling-allocation-strategy.md#node-allocation-scenarios).
Weitere Informationen zu verwalteten Skalierungsparametern finden Sie unter [https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html).
## Hinweise zu Amazon EMR Managed Scaling
+ Managed Scaling wird in limitierten Versionen AWS-Regionen und Amazon EMR-Versionen unterstützt. Weitere Informationen finden Sie unter [Verwaltete Skalierungsverfügbarkeit](#emr-managed-scaling-availability).
+ Sie müssen die folgenden Parameter für die Amazon EMR Managed Scaling konfigurieren. Weitere Informationen finden Sie unter [Verwaltete Skalierungsparameter](#emr-managed-scaling-parameters).
+ Um verwaltete Skalierung verwenden zu können, muss der Metrics-Collector-Prozess in der Lage sein, eine Verbindung zum öffentlichen API-Endpunkt für die verwaltete Skalierung in API Gateway herzustellen. Wenn Sie einen privaten DNS-Namen mit verwenden Amazon Virtual Private Cloud, funktioniert die verwaltete Skalierung nicht ordnungsgemäß. Um sicherzustellen, dass die verwaltete Skalierung funktioniert, empfehlen wir, dass Sie eine der folgenden Aktionen ausführen:
+ Entfernen Sie den VPC-Endpunkt der API-Gateway-Schnittstelle aus Ihrer Amazon VPC.
+ Folgen Sie den Anweisungen unter [Warum erhalte ich den Fehler HTTP 403 Forbidden, wenn ich von einer VPC APIs aus eine Verbindung zu meinem API Gateway](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-vpc-connections/) herstelle? um die Einstellung für den privaten DNS-Namen zu deaktivieren.
+ Starten Sie Ihren Cluster stattdessen in einem privaten Subnetz. Weitere Informationen finden Sie im Thema [Private Subnetze](emr-clusters-in-a-vpc.md#emr-vpc-private-subnet).
+ Wenn Ihre YARN-Jobs während des Herunterskalierens zeitweise langsam sind und die YARN Ressource Manager-Protokolle zeigen, dass die meisten Ihrer Knoten während dieser Zeit auf der Negativliste standen, können Sie den Schwellenwert für die Außerbetriebnahme anpassen.
Reduzieren Sie den `spark.blacklist.decommissioning.timeout` von einer Stunde auf eine Minute, um den Knoten für andere ausstehende Container verfügbar zu machen, um die Aufgabenverarbeitung fortzusetzen.
Sie sollten auch einen höheren Wert `YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs` festlegen, um sicherzustellen, dass Amazon EMR das Beenden des Knotens nicht erzwingt, solange die längste „Spark-Task“ noch auf dem Knoten läuft. Die aktuelle Standardeinstellung ist 60 Minuten, was bedeutet, dass YARN den Container nach 60 Minuten auf jeden Fall beendet, sobald der Knoten in den Stilllegungszustand übergeht.
Die folgende Protokollzeile von YARN Resource Manager zeigt Knoten, die dem Status „Außerbetriebnahme“ hinzugefügt wurden:
```
2021-10-20 15:55:26,994 INFO org.apache.hadoop.YARN.server.resourcemanager.DefaultAMSProcessor (IPC Server handler 37 on default port 8030): blacklist are updated in Scheduler.blacklistAdditions: [ip-10-10-27-207.us-west-2.compute.internal, ip-10-10-29-216.us-west-2.compute.internal, ip-10-10-31-13.us-west-2.compute.internal, ... , ip-10-10-30-77.us-west-2.compute.internal], blacklistRemovals: []
```
Erfahren Sie mehr darüber wie[ Amazon EMR bei der Außerbetriebnahme von Knoten mit YARN Ablehnungsliste](https://aws.amazon.com/blogs/big-data/spark-enhancements-for-elasticity-and-resiliency-on-amazon-emr/) integriert wird, zu [Fällen, in denen Knoten in Amazon EMR abgelehnt werden können](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-troubleshoot-error-resource-3.html), und zur [Konfiguration des Verhaltens bei der Außerbetriebnahme von Spark-Knoten](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-configure.html#spark-decommissioning).
+ Bei Spark-Workloads `FALSE` kann die Deaktivierung von Spark Dynamic Resource Allocator (DRA) durch Ändern der Spark-Eigenschaft **spark.dynamicalLocation.ENABLED** in zu Managed Scaling-Problemen führen, bei denen Cluster stärker skaliert werden können, als es für Ihre Workloads erforderlich ist (bis zur maximalen Rechenleistung). Wenn Sie Managed Scaling für diese Workloads verwenden, empfehlen wir, Spark DRA aktiviert zu lassen. Dies ist der Standardstatus dieser Eigenschaft.
+ Eine übermäßige Auslastung von EBS-Volumes kann zu Problemen bei der verwalteten Skalierung führen. Wir empfehlen, das EBS-Volumen unter einer Auslastung 90 % zu halten. Weitere Informationen finden Sie unter [Speicheroptionen und Verhalten von Instances in Amazon EMR](emr-plan-storage.md).
+ CloudWatch Amazon-Metriken sind entscheidend für den Betrieb der von Amazon EMR verwalteten Skalierung. Wir empfehlen Ihnen, die CloudWatch Amazon-Metriken genau zu beobachten, um sicherzustellen, dass keine Daten fehlen. Weitere Informationen darüber, wie Sie CloudWatch Alarme konfigurieren können, um fehlende Messwerte zu erkennen, finden Sie unter [ CloudWatch Amazon-Alarme verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
+ Verwaltete Skalierungsvorgänge auf Clustern der Versionen 5.30.0 und 5.30.1, ohne dass Presto installiert ist, können zu Anwendungsausfällen führen oder dazu führen, dass eine einheitliche Instance-Gruppe oder Instance-Flotte unverändert im Status `ARRESTED` bleibt, insbesondere wenn auf einen Herunterskalierungsvorgang schnell ein Skalierungsvorgang folgt.
Um dieses Problem zu umgehen, wählen Sie Presto als zu installierende Anwendung, wenn Sie einen Cluster mit den Amazon-EMR-Versionen 5.30.0 und 5.30.1 erstellen, auch wenn Ihr Auftrag Presto nicht benötigt.
+ Wenn Sie den maximalen Core-Knoten und das On-Demand-Limit für Amazon EMR Managed Scaling festlegen, sollten Sie die Unterschiede zwischen Instance-Gruppen und Instance-Flotten berücksichtigen. Jede Instance-Gruppenkonfiguration besteht jeder Knotentyp aus demselben Instance-Typ und derselben Kaufoption für Instances: On-Demand oder Spot. Für jede Instance-Flotte geben Sie bis zu fünf Instance-Typen an, die als On-Demand- und Spot Instances bereitgestellt werden können. Weitere Informationen finden Sie unter [Erstellen eines Clusters mit Instance-Flotten oder einheitlichen Instance-Gruppen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-group-configuration.html), [Instance Flotten Optionen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html#emr-instance-fleet-options) und [Knotenzuweisungsszenarien](managed-scaling-allocation-strategy.md#node-allocation-scenarios).
+ Wenn Sie bei Amazon EMR 5.30.0 und höher die standardmäßige ausgehende Regel **Alle zulassen** auf 0.0.0.0/ für die Master-Sicherheitsgruppe entfernen, müssen Sie eine Regel hinzufügen, die ausgehende TCP-Konnektivität zu Ihrer Sicherheitsgruppe für den Servicezugriff am Port 9443 zulässt. Ihre Sicherheitsgruppe für den Servicezugang muss auch eingehenden TCP-Verkehr auf Port 9443 von der Master-Sicherheitsgruppe zulassen. Weitere Informationen über die Konfiguration von Sicherheitsgruppen finden Sie unter Von [Amazon EMR verwaltete Sicherheitsgruppe für die primäre Instance (private Subnetze)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-man-sec-groups.html#emr-sg-elasticmapreduce-master-private).
+ Sie können es verwenden AWS CloudFormation , um Amazon EMR Managed Scaling zu konfigurieren. Weitere Informationen finden Sie unter [AWS::EMR::Cluster](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticmapreduce-cluster.html) im *AWS CloudFormation -Benutzerhandbuch*.
+ Wenn Sie Spot-Knoten verwenden, sollten Sie die Verwendung von Knotenbezeichnungen in Betracht ziehen, um zu verhindern, dass Amazon EMR Anwendungsprozesse entfernt, wenn Amazon EMR Spot-Knoten entfernt. Weitere Informationen zu Knotenbezeichnungen finden Sie unter [Task-Knoten](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html#emr-plan-task).
+ Die Knotenkennzeichnung wird in Amazon EMR-Versionen 6.15 oder niedriger standardmäßig nicht unterstützt. Weitere Informationen 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 Amazon EMR-Versionen 6.15 oder niedriger verwenden, können Sie Knotenbezeichnungen nur nach Knotentyp zuweisen, z. B. Kern- und Aufgabenknoten. Wenn Sie jedoch Amazon EMR Version 7.0 oder höher verwenden, können Sie Node-Labels nach Knotentyp und Markttyp konfigurieren, z. B. On-Demand und Spot.
+ Wenn die Nachfrage nach Anwendungsprozessen steigt und die Nachfrage nach Ausführern sinkt, wenn Sie den Anwendungsprozess auf Kernknoten beschränkt haben, können Sie bei derselben Größenänderung wieder Kernknoten hinzufügen und Aufgabenknoten entfernen. Weitere Informationen finden Sie unter [Grundlegendes zu Strategien und Szenarien für die Knotenzuweisung](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html).
+ Amazon EMR kennzeichnet Aufgabenknoten nicht, sodass Sie die YARN-Eigenschaften nicht so einstellen können, dass Anwendungsprozesse nur für Aufgabenknoten eingeschränkt werden. Wenn Sie jedoch Markttypen als Knotenbezeichnungen verwenden möchten, können Sie die `SPOT` Bezeichnungen `ON_DEMAND` oder für die Platzierung von Antragsprozessen verwenden. Wir empfehlen nicht, Spot-Nodes für primäre Anwendungsprozesse zu verwenden.
+ Wenn Sie Node Labels verwenden, kann die Gesamtzahl der laufenden Einheiten im Cluster vorübergehend die in Ihrer verwalteten Skalierungsrichtlinie festgelegte maximale Rechenleistung überschreiten, während Amazon EMR einige Ihrer Instances außer Betrieb nimmt. Die Gesamtzahl der angeforderten Einheiten bleibt immer auf oder unter der maximalen Rechenleistung Ihrer Richtlinie.
+ Managed Scaling unterstützt nur die Knotenbezeichnungen `ON_DEMAND` und `SPOT` oder `CORE` und`TASK`. Benutzerdefinierte Knotenbezeichnungen werden nicht unterstützt.
+ Amazon EMR erstellt Knotenbezeichnungen, wenn der Cluster erstellt und Ressourcen bereitgestellt werden. Amazon EMR unterstützt das Hinzufügen von Knotenbezeichnungen bei der Neukonfiguration des Clusters nicht. Sie können die Knotenbezeichnungen auch nicht ändern, wenn Sie die verwaltete Skalierung nach dem Start des Clusters konfigurieren.
+ Bei der verwalteten Skalierung werden Kern- und Taskknoten unabhängig voneinander auf der Grundlage des Anwendungsprozesses und der Nachfrage der Executoren skaliert. Um Probleme mit dem Verlust von HDFS-Daten beim Herunterfahren der Kerne zu vermeiden, sollten Sie sich an die Standardpraxis für Kernknoten halten. Weitere Informationen zu bewährten Methoden für Kernknoten und HDFS-Replikation finden Sie unter [Überlegungen und bewährte](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-considerations.html) Methoden.
+ Sie können nicht sowohl den Anwendungsprozess als auch die Executoren nur auf dem Knoten `core` oder dem Knoten platzieren. `ON_DEMAND` Wenn Sie sowohl den Anwendungsprozess als auch die Executoren auf einem der Knoten hinzufügen möchten, verwenden Sie die Konfiguration nicht. `yarn.node-labels.am.default-node-label-expression`
Um beispielsweise sowohl den Anwendungsprozess als auch die Executoren in `ON_DEMAND` Knoten zu platzieren, setzen Sie max compute auf den Wert Maximum im Knoten. `ON_DEMAND` Entfernen Sie außerdem die Konfiguration`yarn.node-labels.am.default-node-label-expression`.
Um sowohl den Anwendungsprozess als auch Executoren auf den `core` Knoten hinzuzufügen, entfernen Sie die `yarn.node-labels.am.default-node-label-expression` Konfiguration.
+ Wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden, legen Sie die Eigenschaft fest, `yarn.scheduler.capacity.maximum-am-resource-percent: 1` wenn Sie mehrere Anwendungen parallel ausführen möchten. Dadurch wird sichergestellt, dass Ihre Anwendungsprozesse die verfügbaren `CORE` `ON_DEMAND` OR-Knoten vollständig nutzen.
+ Wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden, legen Sie für `yarn.resourcemanager.decommissioning.timeout` die Eigenschaft einen Wert fest, der länger ist als die am längsten laufende Anwendung in Ihrem Cluster. Dadurch wird die Wahrscheinlichkeit verringert, dass Amazon EMR Managed Scaling Ihre Anwendungen für die Wiederinbetriebnahme oder Knoten neu `CORE` planen muss. `ON_DEMAND`
+ Um das Risiko von Anwendungsausfällen aufgrund von Shuffle-Datenverlusten zu verringern, sammelt Amazon EMR Metriken aus dem Cluster, um Knoten zu ermitteln, auf denen transiente Shuffle-Daten aus der aktuellen und vorherigen Phase vorhanden sind. In seltenen Fällen können Metriken weiterhin veraltete Daten für Anwendungen melden, die bereits abgeschlossen oder beendet wurden. Dies kann sich auf die rechtzeitige Reduzierung der Instanzen in Ihrem Cluster auswirken. Für Cluster mit einer großen Menge an Shuffle-Daten sollten Sie die Verwendung von EMR-Versionen 6.13 und höher in Betracht ziehen.
## Feature-Verlauf
In dieser Tabelle sind Aktualisierungen zur Funktion Amazon EMR Managed Scaling aufgeführt.
| Datum der Veröffentlichung | Funktion | Versionen für Amazon EMR |
| --- | --- | --- |
| 20. November 2024 | Managed Scaling ist in den Regionen il-central-1 Israel (Tel Aviv), me-central-1 Naher Osten (VAE) und ap-northeast-3 Asien-Pazifik (Osaka) verfügbar. | 5.30.0 und 6.1.0 und höher |
| 15. November 2024 | Managed Scaling ist in der Region eu-central-2 Europa (Zürich) verfügbar. | 5.30.0 und 6.1.0 und höher |
| 20. August 2024 | Node-Labels sind jetzt in Managed Scaling verfügbar, sodass Sie Ihre Instances nach Markt- oder Knotentyp kennzeichnen können, um die automatische Skalierung zu verbessern. | 7.2.0 und höher |
| 31. März 2024 | Managed Scaling ist in der Region ap-south-2 Asien-Pazifik (Hyderabad) verfügbar. | 6.14.0 und höher |
| 13. Februar 2024 | Managed Scaling ist in der Region eu-south-2 Europa (Spanien) verfügbar. | 6.14.0 und höher |
| 10. Oktober 2023 | Managed Scaling ist in der ap-southeast-3-Region Asien-Pazifik (Jakarta) verfügbar. | 6.14.0 und höher |
| 28. Juli 2023 | Verbesserte verwaltete Skalierung, um beim hochskalieren zu einer anderen Aufgaben-Instance-Gruppe zu wechseln, wenn es bei Amazon EMR beim hochskalieren mit der aktuellen Instance-Gruppe zu Verzögerungen kommt. | 5.34.0 und höher, 6.4.0 und höher |
| 16. Juni 2023 | Verbesserte verwaltete Skalierung, sodass erkannt wird, auf welchen Knoten der Application Master ausgeführt wird, sodass diese Knoten nicht herunterskaliert werden. Weitere Informationen finden Sie unter [Grundlegendes zur Amazon EMR-Knotenzuweisungsstrategie und -Szenarien](managed-scaling-allocation-strategy.md). | 5.34.0 und höher, 6.4.0 und höher |
| 21. März 2022 | Spark Shuffle Data Awareness wurde hinzugefügt, das beim Herunterskalieren von Clustern verwendet wird. Für Amazon-EMR-Cluster mit Apache Spark und aktiviertem verwaltetem Skalierungsfeature überwacht Amazon EMR kontinuierlich Spark-Executoren und Zwischenspeicherorte für Shuffle-Daten. Anhand dieser Informationen skaliert Amazon EMR nur ungenutzte Instances herunter, die keine aktiv genutzten Shuffle-Daten enthalten. Dadurch wird eine Neuberechnung verloren gegangener Shuffle-Daten verhindert, was zur Senkung der Kosten und zur Verbesserung der Arbeitsleistung beiträgt. Weitere Informationen finden Sie unter im [Spark-Programmierhandbuch](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). | 5.34.0 und höher, 6.4.0 und höher |
# Verwaltete Skalierung für Amazon EMR konfigurieren
In den folgenden Abschnitten wird erklärt, wie Sie einen EMR-Cluster starten, der verwaltete Skalierung mit dem AWS-Managementkonsole AWS SDK für Java, dem oder dem AWS Command Line Interface verwendet.
**Topics**
+ [Verwenden Sie den AWS-Managementkonsole , um die verwaltete Skalierung zu konfigurieren](#managed-scaling-console)
+ [Verwenden Sie den, um die verwaltete AWS CLI Skalierung zu konfigurieren](#managed-scaling-cli)
+ [Wird verwendet AWS SDK für Java , um verwaltete Skalierung zu konfigurieren](#managed-scaling-sdk)
## Verwenden Sie den AWS-Managementkonsole , um die verwaltete Skalierung zu konfigurieren
Sie können die Amazon-EMR-Konsole verwenden, um die verwaltete Skalierung zu konfigurieren, wenn Sie einen Cluster erstellen, oder um eine verwaltete Skalierungsrichtlinie für einen laufenden Cluster zu ändern.
------
#### [ Console ]
**Um die verwaltete Skalierung zu konfigurieren, wenn Sie einen Cluster mit der Konsole erstellen**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon EMR-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr).
1. Wählen Sie im linken Navigationsbereich unter **EMR in EC2** die Option **Cluster** und dann **Cluster erstellen** aus.
1. **Wählen Sie eine Amazon-EMR-Version **emr-5.30.0** oder höher, außer Version emr-6.0.0.**
1. Wählen Sie unter Option **Clusterskalierung und -Bereitstellungsoption** **EMR-verwaltete Skalierung verwenden** aus. Geben Sie das **Minimum** – und **Maximum** von Instances, die **maximale Anzahl an Core-Knoten**-Instances und die **maximale Anzahl von On-Demand-Instances** an.
1. Wählen Sie alle anderen Optionen aus, die für Ihren Cluster gelten.
1. Um Ihren Cluster jetzt zu starten, wählen Sie **Cluster erstellen** aus.
**Um verwaltete Skalierung auf einem vorhandenen Cluster mit der Konsole zu konfigurieren**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon EMR-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr).
1. Wählen Sie im linken Navigationsbereich unter **EMR in EC2** die Option **Cluster** und dann den Cluster aus, den Sie aktualisieren möchten.
1. Suchen Sie auf der Registerkarte **Instances** der Cluster-Detailseite den Abschnitt **Instance-Gruppen-Einstellungen**. Geben Sie im Abschnitt **Clusterskalierung bearbeiten** neue Werte für die **Minimum**- und **Maximum**-Anzahl von Instances und das **On-Demand-Limit** an.
------
## Verwenden Sie den, um die verwaltete AWS CLI Skalierung zu konfigurieren
Sie können AWS CLI Befehle für Amazon EMR verwenden, um die verwaltete Skalierung zu konfigurieren, wenn Sie einen Cluster erstellen. Sie können eine Kurzschreibweise mit der passenden JSON-Konfiguration in den entsprechenden Befehlen oder eine Referenzdatei mit der JSON-Konfiguration verwenden. Sie können auch eine Richtlinie für verwaltete Skalierung auf einen vorhandenen Cluster anwenden und eine zuvor angewendete Richtlinie für verwaltete Skalierung entfernen. Darüber hinaus können Sie Details einer Skalierungsrichtlinien-Konfiguration aus einem aktuell ausgeführten Cluster abrufen.
**Aktivieren der verwalteten Skalierung während des Clusterstarts**
Sie können die verwaltete Skalierung während des Clusterstarts aktivieren, wie im folgenden Beispiel veranschaulicht wird.
```
aws emr create-cluster \
--service-role EMR_DefaultRole \
--release-label emr-7.12.0 \
--name EMR_Managed_Scaling_Enabled_Cluster \
--applications Name=Spark Name=Hbase \
--ec2-attributes KeyName=keyName,InstanceProfile=EMR_EC2_DefaultRole \
--instance-groups InstanceType=m4.xlarge,InstanceGroupType=MASTER,InstanceCount=1 InstanceType=m4.xlarge,InstanceGroupType=CORE,InstanceCount=2 \
--region us-east-1 \
--managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=2,MaximumCapacityUnits=4,UnitType=Instances}'
```
Sie können bei Verwendung der managed-scaling-policy Option -- auch eine verwaltete Richtlinienkonfiguration angeben. `create-cluster`
**Anwenden einer Richtlinie für verwaltete Skalierung auf einen vorhandenen Cluster**
Sie können eine Richtlinie für verwaltete Skalierung auf einen vorhandenen Cluster anwenden, wie im folgenden Beispiel veranschaulicht wird.
```
aws emr put-managed-scaling-policy
--cluster-id j-123456
--managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=1,
MaximumCapacityUnits=10, MaximumOnDemandCapacityUnits=10, UnitType=Instances}'
```
Sie können eine Richtlinie für verwaltete Skalierung auch auf einen vorhandenen Cluster anwenden, indem Sie den Befehl `aws emr put-managed-scaling-policy` verwenden. Im folgenden Beispiel wird ein Verweis auf eine JSON-Datei verwendet, `managedscaleconfig.json`, die die Konfiguration der Richtlinie für verwaltete Skalierung angibt.
```
aws emr put-managed-scaling-policy --cluster-id j-123456 --managed-scaling-policy file://./managedscaleconfig.json
```
Das folgende Beispiel zeigt den Inhalt der Datei `managedscaleconfig.json`, in der die Richtlinie für verwaltete Skalierung definiert wird.
```
{
"ComputeLimits": {
"UnitType": "Instances",
"MinimumCapacityUnits": 1,
"MaximumCapacityUnits": 10,
"MaximumOnDemandCapacityUnits": 10
}
}
```
**Abrufen einer Richtlinienkonfiguration für verwaltete Skalierung**
Der Befehl `GetManagedScalingPolicy` ruft die Richtlinienkonfiguration ab. Mit dem folgenden Befehl wird beispielsweise die Konfiguration für den Cluster mit der Cluster-ID `j-123456` abgerufen.
```
aws emr get-managed-scaling-policy --cluster-id j-123456
```
Der Befehl generiert die folgende Beispielausgabe:
```
1. {
2. "ManagedScalingPolicy": {
3. "ComputeLimits": {
4. "MinimumCapacityUnits": 1,
5. "MaximumOnDemandCapacityUnits": 10,
6. "MaximumCapacityUnits": 10,
7. "UnitType": "Instances"
8. }
9. }
10. }
```
Weitere Informationen zur Verwendung von Amazon EMR-Befehlen finden Sie AWS CLI unter[https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr).
**Entfernen der Richtlinie für verwaltete Skalierung**
Mit dem Befehl `RemoveManagedScalingPolicy` wird die Richtlinienkonfiguration entfernt. Mit dem folgenden Befehl wird beispielsweise die Konfiguration für den Cluster mit der Cluster-ID `j-123456` entfernt.
```
aws emr remove-managed-scaling-policy --cluster-id j-123456
```
## Wird verwendet AWS SDK für Java , um verwaltete Skalierung zu konfigurieren
Der folgende Programmausschnitt zeigt, wie die verwaltete Skalierung mit dem AWS SDK für Java konfiguriert wird:
```
package com.amazonaws.emr.sample;
import java.util.ArrayList;
import java.util.List;
import com.amazonaws.AmazonClientException;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.profile.ProfileCredentialsProvider;
import com.amazonaws.regions.Regions;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduce;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduceClientBuilder;
import com.amazonaws.services.elasticmapreduce.model.Application;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimits;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimitsUnitType;
import com.amazonaws.services.elasticmapreduce.model.InstanceGroupConfig;
import com.amazonaws.services.elasticmapreduce.model.JobFlowInstancesConfig;
import com.amazonaws.services.elasticmapreduce.model.ManagedScalingPolicy;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowRequest;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowResult;
public class CreateClusterWithManagedScalingWithIG {
public static void main(String[] args) {
AWSCredentials credentialsFromProfile = getCreadentials("AWS-Profile-Name-Here");
/**
* Create an Amazon EMR client with the credentials and region specified in order to create the cluster
*/
AmazonElasticMapReduce emr = AmazonElasticMapReduceClientBuilder.standard()
.withCredentials(new AWSStaticCredentialsProvider(credentialsFromProfile))
.withRegion(Regions.US_EAST_1)
.build();
/**
* Create Instance Groups - Primary, Core, Task
*/
InstanceGroupConfig instanceGroupConfigMaster = new InstanceGroupConfig()
.withInstanceCount(1)
.withInstanceRole("MASTER")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
InstanceGroupConfig instanceGroupConfigCore = new InstanceGroupConfig()
.withInstanceCount(4)
.withInstanceRole("CORE")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
InstanceGroupConfig instanceGroupConfigTask = new InstanceGroupConfig()
.withInstanceCount(5)
.withInstanceRole("TASK")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
List igConfigs = new ArrayList<>();
igConfigs.add(instanceGroupConfigMaster);
igConfigs.add(instanceGroupConfigCore);
igConfigs.add(instanceGroupConfigTask);
/**
* specify applications to be installed and configured when Amazon EMR creates the cluster
*/
Application hive = new Application().withName("Hive");
Application spark = new Application().withName("Spark");
Application ganglia = new Application().withName("Ganglia");
Application zeppelin = new Application().withName("Zeppelin");
/**
* Managed Scaling Configuration -
* Using UnitType=Instances for clusters composed of instance groups
*
* Other options are:
* UnitType = VCPU ( for clusters composed of instance groups)
* UnitType = InstanceFleetUnits ( for clusters composed of instance fleets)
**/
ComputeLimits computeLimits = new ComputeLimits()
.withMinimumCapacityUnits(1)
.withMaximumCapacityUnits(20)
.withUnitType(ComputeLimitsUnitType.Instances);
ManagedScalingPolicy managedScalingPolicy = new ManagedScalingPolicy();
managedScalingPolicy.setComputeLimits(computeLimits);
// create the cluster with a managed scaling policy
RunJobFlowRequest request = new RunJobFlowRequest()
.withName("EMR_Managed_Scaling_TestCluster")
.withReleaseLabel("emr-7.12.0") // Specifies the version label for the Amazon EMR release; we recommend the latest release
.withApplications(hive,spark,ganglia,zeppelin)
.withLogUri("s3://path/to/my/emr/logs") // A URI in S3 for log files is required when debugging is enabled.
.withServiceRole("EMR_DefaultRole") // If you use a custom IAM service role, replace the default role with the custom role.
.withJobFlowRole("EMR_EC2_DefaultRole") // If you use a custom Amazon EMR role for EC2 instance profile, replace the default role with the custom Amazon EMR role.
.withInstances(new JobFlowInstancesConfig().withInstanceGroups(igConfigs)
.withEc2SubnetId("subnet-123456789012345")
.withEc2KeyName("my-ec2-key-name")
.withKeepJobFlowAliveWhenNoSteps(true))
.withManagedScalingPolicy(managedScalingPolicy);
RunJobFlowResult result = emr.runJobFlow(request);
System.out.println("The cluster ID is " + result.toString());
}
public static AWSCredentials getCredentials(String profileName) {
// specifies any named profile in .aws/credentials as the credentials provider
try {
return new ProfileCredentialsProvider("AWS-Profile-Name-Here")
.getCredentials();
} catch (Exception e) {
throw new AmazonClientException(
"Cannot load credentials from .aws/credentials file. " +
"Make sure that the credentials file exists and that the profile name is defined within it.",
e);
}
}
public CreateClusterWithManagedScalingWithIG() { }
}
```
# Erweiterte Skalierung für Amazon EMR
Ab Amazon EMR auf EC2 Version 7.0 können Sie Advanced Scaling nutzen, um die Ressourcennutzung Ihres Clusters zu kontrollieren. Advanced Scaling führt eine Nutzungs- und Leistungsskala ein, mit der Sie Ihre Ressourcennutzung und Ihr Leistungsniveau an Ihre Geschäftsanforderungen anpassen können. Der von Ihnen festgelegte Wert bestimmt, ob Ihr Cluster stärker auf Ressourcenschonung oder auf Skalierung zur Bewältigung service-level-agreement (SLA) sensibler Workloads ausgerichtet ist, bei denen eine schnelle Fertigstellung entscheidend ist. Wenn der Skalierungswert angepasst wird, interpretiert die verwaltete Skalierung Ihre Absicht und skaliert intelligent, um die Ressourcen zu optimieren. Weitere Informationen zur verwalteten Skalierung finden [Sie unter Managed Scaling für Amazon EMR konfigurieren](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-configure.html).
## Erweiterte Skalierungseinstellungen
Der Wert, den Sie für Advanced Scaling festgelegt haben, optimiert Ihren Cluster an Ihre Anforderungen. Die Werte liegen im Bereich von **1** bis **100**. Mögliche Werte sind **1**, **25**, **50**, **75** und **100**. Wenn Sie den Index auf andere Werte als diese festlegen, führt dies zu einem Validierungsfehler.
Skalierungswerte entsprechen Strategien zur Ressourcennutzung. In der folgenden Liste werden mehrere davon definiert:
+ **Optimierte Nutzung [1]** — Diese Einstellung verhindert eine übermäßige Bereitstellung von Ressourcen. Verwenden Sie einen niedrigen Wert, wenn Sie die Kosten niedrig halten und einer effizienten Ressourcennutzung Priorität einräumen möchten. Dies führt dazu, dass der Cluster weniger aggressiv skaliert wird. Dies eignet sich gut für den Anwendungsfall, in dem regelmäßig Arbeitslastspitzen auftreten und Sie nicht möchten, dass die Ressourcen zu schnell ansteigen.
+ **Ausgewogen [50]** — Dadurch wird ein ausgewogenes Verhältnis zwischen Ressourcennutzung und Arbeitsleistung erreicht. Diese Einstellung eignet sich für konstante Workloads, bei denen die meisten Phasen über eine stabile Laufzeit verfügen. Sie eignet sich auch für Workloads mit einer Mischung aus Phasen mit kurzer und langer Laufzeit. Wir empfehlen, mit dieser Einstellung zu beginnen, wenn Sie sich nicht sicher sind, welche Sie wählen sollen.
+ **Leistungsoptimiert [100]** — Bei dieser Strategie wird Leistung priorisiert. Der Cluster wird aggressiv skaliert, um sicherzustellen, dass Jobs schnell abgeschlossen werden und die Leistungsziele erreicht werden. Performance Optimized eignet sich für service-level-agreement (SLA-) sensible Workloads, bei denen eine schnelle Laufzeit entscheidend ist.
**Anmerkung**
Die verfügbaren Zwischenwerte bieten einen Mittelweg zwischen den Strategien zur Feinabstimmung des Advanced Scaling-Verhaltens Ihres Clusters.
## Vorteile von Advanced Scaling
Da Ihre Umgebung und Ihre Anforderungen unterschiedlich sind, z. B. sich ändernde Datenmengen, Anpassungen der Kostenziele und SLA-Implementierungen, kann Ihnen die Clusterskalierung dabei helfen, Ihre Clusterkonfiguration so anzupassen, dass Sie Ihre Ziele erreichen. Zu den wichtigsten Vorteilen gehören:
+ **Verbesserte detaillierte Steuerung** — Mit der Einführung der Einstellung „Auslastungsleistung“ können Sie das Skalierungsverhalten Ihres Clusters ganz einfach an Ihre Anforderungen anpassen. Sie können je nach Ihren Nutzungsmustern nach oben skalieren, um den Bedarf an Rechenressourcen zu decken, oder nach unten skalieren, um Ressourcen zu sparen.
+ **Verbesserte Kostenoptimierung** — Sie können je nach Bedarf einen niedrigen Nutzungswert wählen, um Ihre Kostenziele leichter zu erreichen.
## Erste Schritte mit der Optimierung
**Einrichtung und Konfiguration**
Gehen Sie wie folgt vor, um den Leistungsindex festzulegen und Ihre Skalierungsstrategie zu optimieren.
1. Mit dem folgenden Befehl wird ein vorhandener Cluster mit der nutzungsoptimierten `[1]` Skalierungsstrategie aktualisiert:
```
aws emr put-managed-scaling-policy --cluster-id 'cluster-id' \
--managed-scaling-policy '{
"ComputeLimits": {
"UnitType": "Instances",
"MinimumCapacityUnits": 1,
"MaximumCapacityUnits": 2,
"MaximumOnDemandCapacityUnits": 2,
"MaximumCoreCapacityUnits": 2
},
"ScalingStrategy": "ADVANCED",
"UtilizationPerformanceIndex": "1"
}' \
--region "region-name"
```
Die Attribute `ScalingStrategy` und `UtilizationPerformanceIndex` sind neu und für die Skalierungsoptimierung relevant. Sie können verschiedene Skalierungsstrategien auswählen, indem Sie die entsprechenden Werte (1, 25, 50, 75 und 100) für das `UtilizationPerformanceIndex` Attribut in der Richtlinie für verwaltete Skalierung festlegen.
1. Um zur Standardstrategie für verwaltete Skalierung zurückzukehren, führen Sie den `put-managed-scaling-policy` Befehl aus, ohne die Attribute und einzubeziehen. `ScalingStrategy` `UtilizationPerformanceIndex` (Dies ist optional.) Dieses Beispiel zeigt, wie das geht:
```
aws emr put-managed-scaling-policy \
--cluster-id 'cluster-id' \
--managed-scaling-policy '{"ComputeLimits":{"UnitType":"Instances","MinimumCapacityUnits":1,"MaximumCapacityUnits":2,"MaximumOnDemandCapacityUnits":2,"MaximumCoreCapacityUnits":2}}' \
--region "region-name"
```
**Verwendung von Überwachungsmetriken zur Nachverfolgung der Cluster-Auslastung**
Ab EMR-Version 7.3.0 veröffentlicht Amazon EMR vier neue Metriken zu Arbeitsspeicher und virtueller CPU. Sie können diese verwenden, um die Cluster-Auslastung über verschiedene Skalierungsstrategien hinweg zu messen. Diese Metriken sind für jeden Anwendungsfall verfügbar, aber Sie können die hier bereitgestellten Details zur Überwachung von Advanced Scaling verwenden.
Zu den verfügbaren hilfreichen Metriken gehören die folgenden:
+ **YarnContainersUsedMemoryGBSeconds**— Speichermenge, die von Anwendungen verbraucht wird, die von YARN verwaltet werden.
+ **YarnContainersTotalMemoryGBSeconds**— Gesamtspeicherkapazität, die YARN innerhalb des Clusters zugewiesen wurde.
+ **YarnNodesUsedVCPUSeconds**— VCPU-Sekunden insgesamt für jede von YARN verwaltete Anwendung.
+ **YarnNodesTotalVCPUSeconds**— Aggregierte Gesamt-VCPU-Sekunden für den verbrauchten Speicher, einschließlich des Zeitfensters, in dem Yarn nicht bereit ist.
Sie können Ressourcenmetriken mit Amazon CloudWatch Logs Insights analysieren. Zu den Funktionen gehört eine speziell entwickelte Abfragesprache, mit der Sie Kennzahlen extrahieren können, die für die Ressourcennutzung und Skalierung spezifisch sind.
Die folgende Abfrage, die Sie in der Amazon CloudWatch Konsole ausführen können, verwendet metrische Mathematik, um die durchschnittliche Speicherauslastung (e1) zu berechnen, indem die laufende Summe des verbrauchten Speichers (e2) durch die laufende Summe des Gesamtspeichers (e3) dividiert wird:
```
{
"metrics": [
[ { "expression": "e2/e3", "label": "Average Mem Utilization", "id": "e1", "yAxis": "right" } ],
[ { "expression": "RUNNING_SUM(m1)", "label": "RunningTotal-YarnContainersUsedMemoryGBSeconds", "id": "e2", "visible": false } ],
[ { "expression": "RUNNING_SUM(m2)", "label": "RunningTotal-YarnContainersTotalMemoryGBSeconds", "id": "e3", "visible": false } ],
[ "AWS_EMR_ManagedResize", "YarnContainersUsedMemoryGBSeconds", "ACCOUNT_ID", "793684541905", "COMPONENT", "ManagerService", "JOB_FLOW_ID", "cluster-id", { "id": "m1", "label": "YarnContainersUsedMemoryGBSeconds" } ],
[ ".", "YarnContainersTotalMemoryGBSeconds", ".", ".", ".", ".", ".", ".", { "id": "m2", "label": "YarnContainersTotalMemoryGBSeconds" } ]
],
"view": "timeSeries",
"stacked": false,
"region": "region",
"period": 60,
"stat": "Sum",
"title": "Memory Utilization"
}
```
Um Protokolle abzufragen, können Sie CloudWatch in der AWS Konsole auswählen. Weitere Informationen zum Schreiben von Abfragen für CloudWatch finden Sie unter [Analysieren von Protokolldaten mit CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) im Amazon CloudWatch Logs-Benutzerhandbuch.
Die folgende Abbildung zeigt diese Metriken für einen Beispielcluster:
![\[Diagramm, das Nutzungsstatistiken zeigt.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/scaling_graph_EMR.png)
## Überlegungen und Einschränkungen
+ Die Effektivität von Skalierungsstrategien kann je nach Ihren individuellen Workload-Merkmalen und der Cluster-Konfiguration variieren. Wir empfehlen Ihnen, mit der Skalierungseinstellung zu experimentieren, um einen optimalen Indexwert für Ihren Anwendungsfall zu ermitteln.
+ Amazon EMR Advanced Scaling eignet sich besonders gut für Batch-Workloads. Für SQL/Data-Warehousing- und Streaming-Workloads empfehlen wir die Verwendung der Standardstrategie für verwaltete Skalierung, um eine optimale Leistung zu erzielen.
+ Amazon EMR Advanced Scaling wird nicht unterstützt, wenn Node Label Configurations im Cluster aktiviert sind. Wenn sowohl Advanced Scaling als auch Node Label Configurations zusammen in einem Cluster aktiviert sind, entspricht das Skalierungsverhalten so, als ob die Standardeinstellung für verwaltete Skalierung aktiviert wäre.
+ Die leistungsoptimierte Skalierungsstrategie ermöglicht eine schnellere Auftragsausführung, indem hohe Rechenressourcen über einen längeren Zeitraum aufrechterhalten werden als die standardmäßige Strategie für verwaltete Skalierung. Dieser Modus priorisiert die schnelle Skalierung, um den Ressourcenanforderungen gerecht zu werden, was zu einer schnelleren Auftragsabwicklung führt. Dies kann im Vergleich zur Standardstrategie zu höheren Kosten führen.
+ In Fällen, in denen der Cluster bereits optimiert und voll ausgelastet ist, bietet die Aktivierung von Advanced Scaling möglicherweise keine zusätzlichen Vorteile. In einigen Situationen kann die Aktivierung von Advanced Scaling zu erhöhten Kosten führen, da die Workloads länger laufen können. In diesen Fällen empfehlen wir, die Standardstrategie für verwaltete Skalierung zu verwenden, um eine optimale Ressourcenzuweisung und Kosteneffizienz zu gewährleisten.
+ **Im Zusammenhang mit verwalteter Skalierung verlagert sich der Schwerpunkt auf die Ressourcennutzung im Laufe der Ausführungszeit, da die Einstellung von leistungsoptimiert [**100] auf auslastungsoptimiert [1**] geändert wird.** Es ist jedoch wichtig zu beachten, dass die Ergebnisse je nach Art der Arbeitslast und der Topologie des Clusters variieren können. Um optimale Ergebnisse für Ihren Anwendungsfall sicherzustellen, empfehlen wir dringend, die Skalierungsstrategien mit Ihren Workloads zu testen, um die am besten geeignete Einstellung zu ermitteln.
+ Der **PerformanceUtilizationIndex**akzeptiert nur die folgenden Werte:
+ **1**
+ **25**
+ **50**
+ **75**
+ **100**
Alle anderen übermittelten Werte führen zu einem Validierungsfehler.
# 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)
# Grundlegendes zu verwalteten Skalierungsmetriken in Amazon EMR
Amazon EMR veröffentlicht hochaufgelöste Metriken mit Daten mit einer Granularität von einer Minute, wenn die verwaltete Skalierung für einen Cluster aktiviert ist. Sie können Ereignisse bei jeder Initiierung und Beendigung der Größenänderung anzeigen, die durch verwaltete Skalierung mit der Amazon EMR-Konsole oder der CloudWatch Amazon-Konsole gesteuert werden. CloudWatch Metriken sind entscheidend für den Betrieb der von Amazon EMR verwalteten Skalierung. Wir empfehlen Ihnen, die CloudWatch Metriken genau zu überwachen, um sicherzustellen, dass keine Daten fehlen. Weitere Informationen darüber, wie Sie CloudWatch Alarme konfigurieren können, um fehlende Messwerte zu erkennen, finden Sie unter [ CloudWatch Amazon-Alarme verwenden](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Weitere Informationen zur Verwendung von CloudWatch Ereignissen mit Amazon EMR finden Sie unter [ CloudWatchEreignisse überwachen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html).
Die folgenden Metriken geben die aktuelle oder Zielkapazitäten eines Clusters an. Diese Metriken sind nur verfügbar, wenn die verwaltete Skalierung aktiviert ist. Bei Clustern, die aus Instance-Flotten bestehen, werden die Cluster-Kapazitätsmetriken in `Units` gemessen. Bei Clustern, die aus Instance-Gruppen bestehen, werden die Clusterkapazitätsmetriken in `Nodes` oder `vCPU` basierend auf dem Einheitentyp gemessen, der in der Richtlinie für verwaltete Skalierung verwendet wird.
| Metrik | Description |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Die Zielgesamtanzahl von units/nodes/vCPUs in einem Cluster, wie sie durch verwaltete Skalierung bestimmt wird. Einheiten: *Anzahl* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Die aktuelle Gesamtzahl der in einem laufenden Cluster units/nodes/vCPUs verfügbaren. Wenn eine Clustergrößenänderung angefordert wird, wird diese Metrik aktualisiert, nachdem die neuen Instances hinzugefügt oder aus dem Cluster entfernt wurden. Einheiten: *Anzahl* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Die Zielanzahl von CORE units/nodes/vCPUs in einem Cluster, wie sie durch verwaltete Skalierung bestimmt wird. Einheiten: *Anzahl* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Die aktuelle Anzahl von CORE, die in einem Cluster units/nodes/vCPUs ausgeführt werden. Einheiten: *Anzahl* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Die Zielanzahl von TASKs units/nodes/vCPUs in einem Cluster, wie sie durch verwaltete Skalierung bestimmt wird. Einheiten: *Anzahl* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Die aktuelle Anzahl von TASK, die in einem Cluster units/nodes/vCPUs ausgeführt werden. Einheiten: *Anzahl* |
Die folgenden Metriken geben den Verwendungsstatus von Clustern und Anwendungen an. Diese Metriken sind für alle Amazon-EMR-Features verfügbar, werden jedoch mit einer höheren Auflösung mit Daten in einer einminütigen Granularität veröffentlicht, wenn die verwaltete Skalierung für einen Cluster aktiviert ist. Sie können die folgenden Metriken mit den Clusterkapazitätsmetriken in der vorherigen Tabelle korrelieren, um die Entscheidungen bezüglich der verwalteten Skalierung zu verständlich zu machen.
| Metrik | Description |
| --- | --- |
| `AppsCompleted` | Anzahl der an YARN übermittelten abgeschlossenen Anwendungen. Anwendungsfall: Cluster-Fortschritt überwachen Einheiten: *Anzahl* |
| `AppsPending` | Anzahl der an YARN übermittelten Anwendungen, die sich im ausstehenden Zustand befinden. Anwendungsfall: Cluster-Fortschritt überwachen Einheiten: *Anzahl* |
| `AppsRunning` | Anzahl der an YARN übermittelten Anwendungen, die ausgeführt werden. Anwendungsfall: Cluster-Fortschritt überwachen Einheiten: *Anzahl* |
| ContainerAllocated | Die Anzahl der Ressourcencontainer, die von der zugewiesen wurdenResourceManager. Anwendungsfall: Cluster-Fortschritt überwachen Einheiten: *Anzahl* |
| `ContainerPending` | Anzahl der Container in der Warteschlange, die noch nicht zugeordnet worden sind. Anwendungsfall: Cluster-Fortschritt überwachen Einheiten: *Anzahl* |
| ContainerPendingRatio | Das Verhältnis von ausstehenden Containern zu zugewiesenen Containern (ContainerPendingRatio = ContainerPending / ContainerAllocated). Wenn ContainerAllocated = 0, dann ContainerPendingRatio =ContainerPending. Der Wert von ContainerPendingRatio steht für eine Zahl, nicht für einen Prozentsatz. Dieser Wert ist zum Skalieren von Cluster-Ressourcen anhand des Zuordnungsverhaltens des Containers hilfreich. Einheiten: *Anzahl* |
| `HDFSUtilization` | Prozentsatz des gegenwärtig benutzten HDFS-Speichers. Anwendungsfall: Cluster-Leistung analysieren Einheiten: *Prozent* |
| `IsIdle` | Gibt an, dass ein Cluster keine Arbeiten mehr ausführt, aber unverändert aktiv ist und Kosten verursacht. Der Wert beträgt 1, wenn weder Tasks noch Aufträge ausgeführt werden, andernfalls beträgt der Wert 0. Dieser Wert wird in 5-Minuten-Intervallen geprüft. Wenn der Wert 1 beträgt, bedeutet dies, dass der Cluster zum Zeitpunkt der Prüfung ungenutzt war, aber nicht die gesamten fünf Minuten. Um Fehlalarme zu vermeiden, sollten Sie einen Alarm auslösen, wenn dieser Wert mehrere aufeinander folgende fünfminütige Prüfungen lang 1 beträgt. Sie können zum Beispiel einen Alarm auslösen, wenn dieser Wert 30 Minuten oder länger 1 beträgt. Anwendungsfall: Cluster-Leistung überwachen Einheiten: *boolescher Wert* |
| `MemoryAvailableMB` | Verfügbarer zuzuordnender Speicher. Anwendungsfall: Cluster-Fortschritt überwachen Einheiten: *Anzahl* |
| `MRActiveNodes` | Die Anzahl der Knoten, auf denen derzeit MapReduce Aufgaben oder Jobs ausgeführt werden. Entspricht der YARN-Metrik `mapred.resourcemanager.NoOfActiveNodes`. Anwendungsfall: Cluster-Fortschritt überwachen Einheiten: *Anzahl* |
| `YARNMemoryAvailablePercentage` | Der Prozentsatz des verbleibenden Speichers, der YARN zur Verfügung steht (YARNMemoryAvailablePercentage = MemoryAvailable MB/MemoryTotalMB). Dieser Wert ist zum Skalieren von Cluster-Ressourcen anhand der YARN-Speichernutzung hilfreich. Einheiten: *Prozent* |
Die folgenden Metriken enthalten Informationen zu den Ressourcen, die von YARN-Containern und -Knoten verwendet werden. Diese Metriken aus dem YARN-Ressourcenmanager bieten Einblicke in die Ressourcen, die von Containern und Knoten verwendet werden, die im Cluster ausgeführt werden. Der Vergleich dieser Metriken mit den Clusterkapazitätsmetriken der vorherigen Tabelle bietet ein klareres Bild der Auswirkungen der verwalteten Skalierung:
| Metrik | Dazugehörige Veröffentlichungen | Description |
| --- | --- | --- |
| `YarnContainersUsedMemoryGBSeconds` | Verfügbar für Release-Label 7.3.0 und höher | Der verbrauchte Container-Speicher in \$1 Sekunden für den Veröffentlichungszeitraum. **Einheiten:** GB \$1 Sekunden |
| `YarnContainersTotalMemoryGBSeconds` | Verfügbar für Release-Label 7.3.0 und höher | Der gesamte Garnbehälter (\$1 Sekunden) für den Veröffentlichungszeitraum. **Einheiten:** GB \$1 Sekunden |
| `YarnContainersUsedVCPUSeconds` | Verfügbar für Release-Label 7.5.0 und höher | Die verbrauchte Container-VCPU (\$1 Sekunden) für den Veröffentlichungszeitraum. **Einheiten:** VCPU \$1 Sekunden |
| `YarnContainersTotalVCPUSeconds` | Verfügbar für Release-Label 7.5.0 und höher | Die Gesamtanzahl der Container-VCPU\$1 Sekunden für den Veröffentlichungszeitraum. **Einheiten:** VCPU \$1 Sekunden |
| `YarnNodesUsedMemoryGBSeconds` | Verfügbar für Release-Label 7.5.0 und höher | Der verbrauchte Knotenspeicher (\$1 Sekunden) für den Veröffentlichungszeitraum. **Einheiten:** GB \$1 Sekunden |
| `YarnNodesTotalMemoryGBSeconds` | Verfügbar für Release-Label 7.5.0 und höher | Der gesamte Knotenspeicher (\$1 Sekunden) für den Veröffentlichungszeitraum. **Einheiten:** GB \$1 Sekunden |
| `YarnNodesUsedVCPUSeconds` | Verfügbar für Release-Label 7.3.0 und höher | Die verbrauchte Knoten-VCPU in \$1 Sekunden für den Veröffentlichungszeitraum. **Einheiten:** VCPU \$1 Sekunden |
| `YarnNodesTotalVCPUSeconds` | Verfügbar für Release-Label 7.3.0 und höher | Die Gesamtzahl der Knoten-VCPU\$1 Sekunden für den Veröffentlichungszeitraum. **Einheiten:** VCPU \$1 Sekunden |
## Grafieren der Metriken für verwaltete Skalierung
Sie können Metriken als Grafiken darstellen, um die Workload-Muster Ihres Clusters und entsprechenden Skalierungsentscheidungen zu visualisieren, die durch Amazon EMR Managed Scaling getroffen werden, wie die folgenden Schritte veranschaulichen.
**Um die Metriken der verwalteten Skalierung in der CloudWatch Konsole grafisch darzustellen**
1. Öffnen Sie die [CloudWatch-Konsole](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Amazon EMR** aus. Sie können die Cluster-Kennung auch nach dem zu überwachenden Cluster durchsuchen.
1. Scrollen Sie zur Metrik, die grafisch dargestellt werden soll. Öffnen Sie eine Metrik, um das Diagramm anzuzeigen.
1. Um eine oder mehrere Metriken grafisch darzustellen, aktivieren Sie das Kontrollkästchen neben jeder Metrik.
Das folgende Beispiel veranschaulicht die Aktivität von Amazon EMR Managed Scaling eines Clusters. Das Diagramm zeigt drei automatische Scale-Down-Perioden, die Kosten sparen, wenn eine weniger aktive Workload vorliegt.
![\[Grafieren der Metriken für verwaltete Skalierung\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/Managed_Scaling_Decision.png)
Alle Cluster-Kapazitäts- und Nutzungsmetriken werden in Intervallen von einer Minute veröffentlicht. Zusätzliche statistische Informationen sind auch jeweils mit allen einminütigen Daten verknüpft, sodass Sie verschiedene Funktionen wie `Percentiles`, `Min`, `Max`, `Sum`, `Average`, `SampleCount` darstellen können.
Im folgenden Diagramm wird beispielsweise dieselbe `YARNMemoryAvailablePercentage`-Metrik an verschiedenen Perzentilen (P10, P50, P90, P99) zusammen mit `Sum`, `Average`, `Min`, `SampleCount` dargestellt.
![\[Grafieren von Metriken für verwaltete Skalierung mit unterschiedlichen Perzentilen\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/Managed_Scaling_Metrics.png)
# Verwenden der automatischen Skalierung mit einer benutzerdefinierten Richtlinie für Instanzgruppen in Amazon EMR
*Die automatische Skalierung mit einer benutzerdefinierten Richtlinie in Amazon EMR-Versionen 4.0 und höher ermöglicht Ihnen die programmatische Skalierung und Skalierung in Kern- und Aufgabenknoten auf der Grundlage einer CloudWatch Metrik und anderer Parameter, die Sie in einer Skalierungsrichtlinie angeben.* Automatische Skalierung mit einer benutzerdefinierten Richtlinie ist bei der Instance-Gruppenkonfiguration verfügbar, aber nicht bei der Verwendung von Instance-Flotten. Weitere Informationen zu Instance-Gruppen und Instance-Flotten finden Sie unter [Erstellen Sie einen Amazon EMR-Cluster mit Instance-Flotten oder einheitlichen Instance-Gruppen](emr-instance-group-configuration.md).
**Anmerkung**
Um das Auto Scaling mit einem benutzerdefinierten Richtlinienfeature in Amazon EMR zu verwenden, müssen Sie beim Erstellen eines Clusters `true` für den Parameter `VisibleToAllUsers` festlegen. Weitere Informationen finden Sie unter [SetVisibleToAllUsers](https://docs.aws.amazon.com/emr/latest/APIReference/API_SetVisibleToAllUsers.html).
Die Skalierungsrichtlinie ist Teil einer Instance-Gruppen-Konfiguration. Sie können eine Richtlinie während der anfänglichen Konfiguration einer Instance-Gruppe oder durch Ändern einer Instance-Gruppe in einer vorhandenen Cluster-Gruppe festlegen (auch wenn die Instance aktiv ist). Jede Instance-Gruppe in einem Cluster,mit Ausnahme der Primär-Instance-Gruppe, kann ihre eigene Skalierungsrichtlinie haben. Diese besteht aus Regeln zur Hoch- und Herunter-Skalierung. Scale-Out- und Scale-In-Regeln können unabhängig konfiguriert werden. Jede Regel kann andere Parameter haben.
Sie können Skalierungsrichtlinien mit der AWS-Managementkonsole AWS CLI, der oder der Amazon EMR-API konfigurieren. Wenn Sie die AWS CLI oder Amazon EMR-API verwenden, geben Sie die Skalierungsrichtlinie im JSON-Format an. Wenn Sie die AWS CLI oder die Amazon EMR-API verwenden, können Sie außerdem benutzerdefinierte CloudWatch Metriken angeben. Benutzerdefinierte Metriken können nicht über die AWS-Managementkonsole ausgewählt werden. Wenn Sie eine Skalierungsrichtlinie zum ersten Mal über die Konsole erstellen, wird eine für viele Anwendungen geeignete Standardrichtlinie erstellt. Diese können Sie als Basis für Ihre eigene Richtlinie nutzen. Sie können die Standardregeln löschen oder ändern.
Auch wenn die automatische Skalierung es Ihnen ermöglicht, die EMR-Clusterkapazität anzupassen on-the-fly, sollten Sie dennoch die grundlegenden Workload-Anforderungen berücksichtigen und Ihre Knoten- und Instanzgruppenkonfigurationen planen. Weitere Informationen finden Sie unter [Richtlinien zur Cluster-Konfiguration](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html).
**Anmerkung**
Bei den meisten Workloads ist die Einrichtung von Scale-In- und Scale-Out-Regeln zur Optimierung der Ressourcenauslastung erstrebenswert. Wenn Sie eine Regel ohne Gegenstück erstellen, müssen Sie die Größe der Instanz nach einer Skalierung möglicherweise manuell anpassen. In diesem Fall richten Sie sozusagen ein "unidirektionales" Auto Scaling in eine Richtung (Scale-Out oder Scale-In) mit einem manuellen Reset ein.
## Erstellen einer IAM-Rolle zur automatischen Skalierung
Auto Scaling in Amazon EMR erfordert eine IAM-Rolle mit Berechtigungen zum Hinzufügen und Beenden von Instances für den Fall, dass die Skalierung ausgelöst wird. Eine Standardrolle, `EMR_AutoScaling_DefaultRole`, mit der entsprechenden Rollen- und Vertrauensrichtlinie, ist für diesen Zweck verfügbar. Wenn Sie mit dem zum ersten Mal einen Cluster mit einer Skalierungsrichtlinie erstellen AWS-Managementkonsole, erstellt Amazon EMR die Standardrolle und fügt die verwaltete Standardrichtlinie für Berechtigungen an. `AmazonElasticMapReduceforAutoScalingRole`
Wenn Sie einen Cluster mit einer automatischen Skalierungsrichtlinie mit dem erstellen AWS CLI, müssen Sie zunächst sicherstellen, dass entweder die Standard-IAM-Rolle vorhanden ist oder dass Sie über eine benutzerdefinierte IAM-Rolle mit einer angehängten Richtlinie verfügen, die die entsprechenden Berechtigungen bereitstellt. Um die Standardrolle zu erstellen, können Sie den Befehl `create-default-roles` ausführen, bevor Sie einen Cluster erstellen. Sie können dann die Option `--auto-scaling-role EMR_AutoScaling_DefaultRole` angeben, wenn Sie einen Cluster erstellen. Alternativ können Sie eine benutzerdefinierte Rolle mit Auto Scaling erstellen und diese angeben, wenn Sie einen Cluster erstellen, zum Beispiel `--auto-scaling-role MyEMRAutoScalingRole`. Wenn Sie eine benutzerdefinierte Auto-Scaling-Rolle für Amazon EMR erstellen, empfehlen wir Ihnen, die Berechtigungsrichtlinien für Ihre benutzerdefinierte Rolle auf der Grundlage der verwalteten Richtlinie zu erstellen. Weitere Informationen finden Sie unter [Konfiguration von IAM-Servicerollen für Amazon EMR-Berechtigungen für AWS Dienste und Ressourcen](emr-iam-roles.md).
## Grundlegendes zu Auto-Scaling-Regeln
Wenn eine Aufskalierungs-Regel eine Skalierung für eine Instance-Gruppe auslöst, werden entsprechend den Regeln Amazon-EC2-Instances zur Instance-Gruppe hinzugefügt. Neue Knoten können von Anwendungen wie Apache Spark, Apache Hive und Presto genutzt werden, sobald die Amazon-EC2-Instance in den Zustand `InService` übergeht. Sie können auch eine Scale-In-Regel einrichten, die Instanzen beendet und Knoten entfernt. Weitere Informationen über den Lebenszyklus von automatisch skalierten Amazon-EC2-Instances finden Sie unter [Auto-Scaling-Lebenszyklus](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroupLifecycle.html) im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.
Sie können konfigurieren, wie ein Cluster Amazon-EC2-Instances beendet. Sie können die Instance entweder zur Amazon-EC2-Instance-Stundengrenze für die Fakturierung oder nach Abschluss der Aufgabe beenden. Diese Einstellung gilt sowohl für die Auto Scaling- als auch für manuelle Größenanpassungen. Weitere Informationen zu dieser Konfiguration finden Sie unter [Cluster-Scale-Down-Optionen für Amazon EMR-Cluster](emr-scaledown-behavior.md).
Die folgenden Parameter für eine Regel in einer Richtlinie bestimmen das Auto Scaling-Verhalten.
**Anmerkung**
Die hier aufgeführten Parameter basieren auf dem AWS-Managementkonsole für Amazon EMR. Wenn Sie die AWS CLI oder Amazon EMR-API verwenden, sind zusätzliche erweiterte Konfigurationsoptionen verfügbar. Weitere Informationen zu erweiterten Optionen finden Sie [SimpleScalingPolicyConfiguration](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_PutAutoScalingPolicy.html)in der *Amazon EMR API-Referenz.*
+ Maximale und minimale Instances-Anzahl. Die **Maximale-Instances**-Beschränkung gibt die maximale Anzahl von Amazon-EC2-Instances an, die sich in der Instance-Gruppe befinden können. Sie gilt für alle Aufskalierungs-Regeln. Die **Minimale-Instances**-Beschränkung gibt die minimale Anzahl von Amazon-EC2-Instances an. Sie gilt für alle Abskalierungs-Regeln.
+ Der **Rule name (Regelname)** muss innerhalb der Richtlinie eindeutig sein.
+ **Scaling adjustment (Skalierungsanpassung)** legt die Anzahl der EC2-Instances fest, die während der durch die Regel ausgelösten Skalierung hinzugefügt (für Scale-Out-Regel) oder beendet (für Scale-In-Regeln) werden.
+ Die **CloudWatch Metrik**, die im Hinblick auf einen Alarm überwacht wird.
+ Ein **Vergleichsoperator**, der verwendet wird, um die CloudWatch Metrik mit dem **Schwellenwert** zu vergleichen und eine Auslösebedingung zu bestimmen.
+ Ein **Bewertungszeitraum** in Schritten von fünf Minuten, für den sich die CloudWatch Metrik in einem Triggerzustand befinden muss, bevor die Skalierungsaktivität ausgelöst wird.
+ Eine **Ruhephase** in Sekunden legt fest, wie viel Zeit zwischen einer durch eine Regel ausgelösten Skalierung und dem Start der nächsten Skalierung vergehen muss (unabhängig von der auslösenden Regel). Wenn eine Instanzgruppe eine Skalierungsaktivität abgeschlossen hat und ihren Status nach der Skalierung erreicht hat, bietet die Abklingzeit die Möglichkeit, dass sich die CloudWatch Metriken, die nachfolgende Skalierungsaktivitäten auslösen könnten, stabilisieren. Weitere Informationen finden Sie unter [Ruhephasen für das Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/Cooldown.html) im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.
![\[AWS-Managementkonsole automatische Skalierungsregelparameter für Amazon EMR.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/auto-scaling-rule-params.png)
## Überlegungen und Einschränkungen
+ CloudWatch Amazon-Metriken sind entscheidend für den Betrieb der automatischen Skalierung von Amazon EMR. Wir empfehlen Ihnen, die CloudWatch Amazon-Metriken genau zu beobachten, um sicherzustellen, dass keine Daten fehlen. Weitere Informationen darüber, wie Sie CloudWatch Amazon-Alarme konfigurieren können, um fehlende Messwerte zu erkennen, finden Sie unter [ CloudWatch Amazon-Alarme verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
+ Eine übermäßige Auslastung von EBS-Volumes kann zu Problemen bei der verwalteten Skalierung führen. Wir empfehlen, die Nutzung des EBS-Volumes genau zu überwachen, um sicherzustellen, dass das EBS-Volume unter 90 % ausgelastet ist. Informationen zur Angabe zusätzlicher EBS-Volumes finden Sie unter [Instance-Speicher](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-storage.html).
+ Bei der automatischen Skalierung mit einer benutzerdefinierten Richtlinie in den Amazon EMR-Versionen 5.18 bis 5.28 kann es zu Skalierungsfehlern kommen, die durch zeitweise fehlende Daten in den Amazon-Metriken verursacht werden. CloudWatch Wir empfehlen, dass Sie die neuesten Amazon-EMR-Versionen verwenden, um das Auto Scaling zu verbessern. Sie können sich auch an den [AWS -Support](https://aws.amazon.com/premiumsupport/) wenden, um einen Patch zu erhalten, wenn Sie eine Amazon-EMR-Version zwischen 5.18 und 5.28 verwenden müssen.
## Verwenden von, um die automatische Skalierung zu konfigurieren AWS-Managementkonsole
Wenn Sie einen Cluster erstellen, konfigurieren Sie mithilfe der erweiterten Optionen für die Cluster-Konfiguration eine Skalierungsrichtlinie für Instance-Gruppen. Sie können außerdem eine Skalierungsrichtlinie für eine laufende Instance-Gruppe erstellen, indem Sie die **Hardware**-Einstellungen eines vorhandenen Clusters bearbeiten.
1. Navigieren Sie zur neuen Amazon-EMR-Konsole und wählen Sie in der Seitennavigation die Option **Zur alten Konsole wechseln** aus. Weitere Informationen darüber, was Sie erwartet, wenn Sie zur alten Konsole wechseln, finden Sie unter [Verwenden der alten Konsole](https://docs.aws.amazon.com/emr/latest/ManagementGuide/whats-new-in-console.html#console-opt-in).
1. Wenn Sie einen Cluster in der Amazon-EMR-Konsole erstellen, wählen Sie **Cluster erstellen** und **Zu erweiterten Optionen gehen** aus, wählen dann Optionen für **Schritt 1: Software und Schritte** aus und wechseln dann zu **Schritt 2: Hardware-Konfiguration**.
** – oder – **
Wenn Sie eine Instance-Gruppe in einem ausgeführten Cluster ändern, wählen Sie den Cluster aus der Cluster-Liste aus und erweitern Sie dann den **Hardware**-Abschnitt.
1. Wählen Sie im Abschnitt **Clusterskalierung und Bereitstellungoption** die Option **Clusterskalierung aktivieren** aus. Wählen Sie dann **Benutzerdefinierte Richtlinie für automatische Skalierung erstellen** aus.
Klicken Sie in der Tabelle **Benutzerdefinierte Richtlinien für automatische Skalierung** auf das Stiftsymbol in der Zeile der Instance-Gruppe, die Sie konfigurieren möchten. Die Seite Auto-Scaling-Regeln wird geöffnet.
1. Geben Sie die **Maximum instances (maximale Instances)**-Anzahl ein, die die Instance-Gruppe nach dem Scale-Out enthalten soll. Geben Sie die **Minimum instances (minimale Instances)**-Anzahl ein, die die Instance-Gruppe nach dem Scale-In enthalten soll.
1. Klicken Sie auf den Stift, um Regelparameter zu bearbeiten. Klicken Sie auf das **X**, um eine Regel aus der Richtlinie zu entfernen, und klicken Sie auf **Add rule (Regel hinzufügen)**, um weitere Regeln hinzuzufügen.
1. Wählen Sie die weiter oben in diesem Thema beschriebenen Regelparameter aus. Eine Beschreibung der verfügbaren CloudWatch Metriken für Amazon EMR finden Sie unter [Amazon EMR-Metriken und -Dimensionen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/emr-metricscollected.html) im * CloudWatch Amazon-Benutzerhandbuch*.
## Verwenden von, AWS CLI um die automatische Skalierung zu konfigurieren
Sie können AWS CLI Befehle für Amazon EMR verwenden, um die automatische Skalierung zu konfigurieren, wenn Sie einen Cluster und eine Instanzgruppe erstellen. Sie können eine Kurzschreibweise mit der passenden JSON-Konfiguration in den entsprechenden Befehlen oder eine Referenzdatei mit der JSON-Konfiguration verwenden. Sie können außerdem eine Auto Scaling-Richtlinie auf eine vorhandene Instance-Gruppe anwenden und eine angewendete Auto Scaling-Richtlinie entfernen. Darüber hinaus können Sie Details einer Skalierungsrichtlinien-Konfiguration aus einem aktuell ausgeführten Cluster abrufen.
**Wichtig**
Wenn Sie einen Cluster erstellen, der eine Richtlinie für automatische Skalierung nutzt, müssen Sie mit dem Befehl `--auto-scaling-role MyAutoScalingRole` die IAM-Rolle für das Auto Scaling anzugeben. Die Standard-Rolle ist `EMR_AutoScaling_DefaultRole` und kann mit dem Befehl `create-default-roles` erstellt werden. Die Rolle kann nur hinzugefügt werden, wenn der Cluster erstellt wird. Sie kann nicht zu einem vorhandenen Cluster hinzugefügt werden.
Eine ausführliche Beschreibung der Parameter, die bei der Konfiguration einer automatischen Skalierungsrichtlinie verfügbar sind, finden Sie [PutAutoScalingPolicy](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_PutAutoScalingPolicy.html)in *Amazon EMR API Reference.*
### Erstellen eines Clusters mit einer angewendeten Auto-Scaling-Richtlinie in einer Instance-Gruppe
Sie können eine Auto Scaling-Konfiguration innerhalb der Option `--instance-groups` des Befehls `aws emr create-cluster` festlegen. Das folgende Beispiel demonstriert einen create-Cluster-Befehl, in dem eine Auto Scaling-Richtlinie für die Core-Instance-Gruppe enthalten ist. Der Befehl erstellt eine Skalierungskonfiguration, die der Standard-Scale-Out-Richtlinie entspricht, die angezeigt wird, wenn Sie eine automatische Skalierungsrichtlinie mit dem AWS-Managementkonsole für Amazon EMR erstellen. Aus Gründen der Übersichtlichkeit verzichten wir auf die Abbildung einer Scale-In-Richtlinie. Das Erstellen einer Scale-Out-Regel ohne Verringern der Scale-In-Regel wird nicht empfohlen.
```
aws emr create-cluster --release-label emr-5.2.0 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --auto-scaling-role EMR_AutoScaling_DefaultRole --instance-groups Name=MyMasterIG,InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 'Name=MyCoreIG,InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=2,AutoScalingPolicy={Constraints={MinCapacity=2,MaxCapacity=10},Rules=[{Name=Default-scale-out,Description=Replicates the default scale-out rule in the console.,Action={SimpleScalingPolicyConfiguration={AdjustmentType=CHANGE_IN_CAPACITY,ScalingAdjustment=1,CoolDown=300}},Trigger={CloudWatchAlarmDefinition={ComparisonOperator=LESS_THAN,EvaluationPeriods=1,MetricName=YARNMemoryAvailablePercentage,Namespace=AWS/ElasticMapReduce,Period=300,Statistic=AVERAGE,Threshold=15,Unit=PERCENT,Dimensions=[{Key=JobFlowId,Value="${emr.clusterId}"}]}}}]}'
```
Der folgende Befehl veranschaulicht die Verwendung der Befehlszeile zur Angabe einer Auto-Scaling-Richtliniendefinition im Rahmen einer Instance-Gruppe-Konfigurationsdatei mit dem Namen `instancegroupconfig.json`.
```
aws emr create-cluster --release-label emr-5.2.0 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --instance-groups file://your/path/to/instancegroupconfig.json --auto-scaling-role EMR_AutoScaling_DefaultRole
```
Der Inhalt der Konfigurationsdatei sieht wie folgt aus:
```
[
{
"InstanceCount": 1,
"Name": "MyMasterIG",
"InstanceGroupType": "MASTER",
"InstanceType": "m5.xlarge"
},
{
"InstanceCount": 2,
"Name": "MyCoreIG",
"InstanceGroupType": "CORE",
"InstanceType": "m5.xlarge",
"AutoScalingPolicy":
{
"Constraints":
{
"MinCapacity": 2,
"MaxCapacity": 10
},
"Rules":
[
{
"Name": "Default-scale-out",
"Description": "Replicates the default scale-out rule in the console for YARN memory.",
"Action":{
"SimpleScalingPolicyConfiguration":{
"AdjustmentType": "CHANGE_IN_CAPACITY",
"ScalingAdjustment": 1,
"CoolDown": 300
}
},
"Trigger":{
"CloudWatchAlarmDefinition":{
"ComparisonOperator": "LESS_THAN",
"EvaluationPeriods": 1,
"MetricName": "YARNMemoryAvailablePercentage",
"Namespace": "AWS/ElasticMapReduce",
"Period": 300,
"Threshold": 15,
"Statistic": "AVERAGE",
"Unit": "PERCENT",
"Dimensions":[
{
"Key" : "JobFlowId",
"Value" : "${emr.clusterId}"
}
]
}
}
}
]
}
}
]
```
### Hinzufügen einer Instance-Gruppe mit einer Auto-Scaling-Richtlinie zu einem Cluster
Sie können genauso wie bei `--instance-groups` mithilfe der `add-instance-groups`-Option des `create-cluster`-Befehls eine Skalierungsrichtlinien-Konfiguration festlegen. Im folgenden Beispiel wird ein Verweis auf eine JSON-Datei (`instancegroupconfig.json`) mit der Konfiguration der Instance-Gruppe verwendet.
```
aws emr add-instance-groups --cluster-id j-1EKZ3TYEVF1S2 --instance-groups file://your/path/to/instancegroupconfig.json
```
### Anwenden einer Auto-Scaling-Richtlinie auf eine vorhandene Instance-Gruppe oder Ändern einer angewandten Richtlinie
Verwenden Sie den `aws emr put-auto-scaling-policy`-Befehl, um eine Auto Scaling-Richtlinie auf eine vorhandene Instance-Gruppe anzuwenden. Die Instance-Gruppe muss Teil eines Clusters sein, der die Auto-Scaling-IAM-Rolle verwendet. Im folgenden Beispiel wird ein Verweis auf eine JSON-Datei (`autoscaleconfig.json`) verwendet, in der eine Auto Scaling-Richtlinienkonfiguration definiert ist.
```
aws emr put-auto-scaling-policy --cluster-id j-1EKZ3TYEVF1S2 --instance-group-id ig-3PLUZBA6WLS07 --auto-scaling-policy file://your/path/to/autoscaleconfig.json
```
Der Inhalt der `autoscaleconfig.json`-Datei, die die gleiche Scale-Out-Regel wie im vorherigen Beispiel definiert, ist unten dargestellt.
```
{
"Constraints": {
"MaxCapacity": 10,
"MinCapacity": 2
},
"Rules": [{
"Action": {
"SimpleScalingPolicyConfiguration": {
"AdjustmentType": "CHANGE_IN_CAPACITY",
"CoolDown": 300,
"ScalingAdjustment": 1
}
},
"Description": "Replicates the default scale-out rule in the console for YARN memory",
"Name": "Default-scale-out",
"Trigger": {
"CloudWatchAlarmDefinition": {
"ComparisonOperator": "LESS_THAN",
"Dimensions": [{
"Key": "JobFlowId",
"Value": "${emr.clusterID}"
}],
"EvaluationPeriods": 1,
"MetricName": "YARNMemoryAvailablePercentage",
"Namespace": "AWS/ElasticMapReduce",
"Period": 300,
"Statistic": "AVERAGE",
"Threshold": 15,
"Unit": "PERCENT"
}
}
}]
}
```
### Entfernen einer Auto-Scaling-Richtlinie aus einer Instance-Gruppe
```
aws emr remove-auto-scaling-policy --cluster-id j-1EKZ3TYEVF1S2 --instance-group-id ig-3PLUZBA6WLS07
```
### Abrufen einer Auto-Scaling-Richtlinienkonfiguration
Der `describe-cluster` Befehl ruft die Richtlinienkonfiguration im Block ab. InstanceGroup Mit dem folgenden Befehl wird beispielsweise die Konfiguration für den Cluster mit der Cluster-ID `j-1CWOHP4PI30VJ` abgerufen.
```
aws emr describe-cluster --cluster-id j-1CWOHP4PI30VJ
```
Der Befehl generiert die folgende Beispielausgabe:
```
{
"Cluster": {
"Configurations": [],
"Id": "j-1CWOHP4PI30VJ",
"NormalizedInstanceHours": 48,
"Name": "Auto Scaling Cluster",
"ReleaseLabel": "emr-5.2.0",
"ServiceRole": "EMR_DefaultRole",
"AutoTerminate": false,
"TerminationProtected": true,
"MasterPublicDnsName": "ec2-54-167-31-38.compute-1.amazonaws.com",
"LogUri": "s3n://aws-logs-232939870606-us-east-1/elasticmapreduce/",
"Ec2InstanceAttributes": {
"Ec2KeyName": "performance",
"AdditionalMasterSecurityGroups": [],
"AdditionalSlaveSecurityGroups": [],
"EmrManagedSlaveSecurityGroup": "sg-09fc9362",
"Ec2AvailabilityZone": "us-east-1d",
"EmrManagedMasterSecurityGroup": "sg-0bfc9360",
"IamInstanceProfile": "EMR_EC2_DefaultRole"
},
"Applications": [
{
"Name": "Hadoop",
"Version": "2.7.3"
}
],
"InstanceGroups": [
{
"AutoScalingPolicy": {
"Status": {
"State": "ATTACHED",
"StateChangeReason": {
"Message": ""
}
},
"Constraints": {
"MaxCapacity": 10,
"MinCapacity": 2
},
"Rules": [
{
"Name": "Default-scale-out",
"Trigger": {
"CloudWatchAlarmDefinition": {
"MetricName": "YARNMemoryAvailablePercentage",
"Unit": "PERCENT",
"Namespace": "AWS/ElasticMapReduce",
"Threshold": 15,
"Dimensions": [
{
"Key": "JobFlowId",
"Value": "j-1CWOHP4PI30VJ"
}
],
"EvaluationPeriods": 1,
"Period": 300,
"ComparisonOperator": "LESS_THAN",
"Statistic": "AVERAGE"
}
},
"Description": "",
"Action": {
"SimpleScalingPolicyConfiguration": {
"CoolDown": 300,
"AdjustmentType": "CHANGE_IN_CAPACITY",
"ScalingAdjustment": 1
}
}
},
{
"Name": "Default-scale-in",
"Trigger": {
"CloudWatchAlarmDefinition": {
"MetricName": "YARNMemoryAvailablePercentage",
"Unit": "PERCENT",
"Namespace": "AWS/ElasticMapReduce",
"Threshold": 75,
"Dimensions": [
{
"Key": "JobFlowId",
"Value": "j-1CWOHP4PI30VJ"
}
],
"EvaluationPeriods": 1,
"Period": 300,
"ComparisonOperator": "GREATER_THAN",
"Statistic": "AVERAGE"
}
},
"Description": "",
"Action": {
"SimpleScalingPolicyConfiguration": {
"CoolDown": 300,
"AdjustmentType": "CHANGE_IN_CAPACITY",
"ScalingAdjustment": -1
}
}
}
]
},
"Configurations": [],
"InstanceType": "m5.xlarge",
"Market": "ON_DEMAND",
"Name": "Core - 2",
"ShrinkPolicy": {},
"Status": {
"Timeline": {
"CreationDateTime": 1479413437.342,
"ReadyDateTime": 1479413864.615
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"RunningInstanceCount": 2,
"Id": "ig-3M16XBE8C3PH1",
"InstanceGroupType": "CORE",
"RequestedInstanceCount": 2,
"EbsBlockDevices": []
},
{
"Configurations": [],
"Id": "ig-OP62I28NSE8M",
"InstanceGroupType": "MASTER",
"InstanceType": "m5.xlarge",
"Market": "ON_DEMAND",
"Name": "Master - 1",
"ShrinkPolicy": {},
"EbsBlockDevices": [],
"RequestedInstanceCount": 1,
"Status": {
"Timeline": {
"CreationDateTime": 1479413437.342,
"ReadyDateTime": 1479413752.088
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"RunningInstanceCount": 1
}
],
"AutoScalingRole": "EMR_AutoScaling_DefaultRole",
"Tags": [],
"BootstrapActions": [],
"Status": {
"Timeline": {
"CreationDateTime": 1479413437.339,
"ReadyDateTime": 1479413863.666
},
"State": "WAITING",
"StateChangeReason": {
"Message": "Cluster ready after last step completed."
}
}
}
}
```
# Manuelles Ändern der Größe eines laufenden Amazon EMR-Clusters
Sie können Instances zu Kern- und Task-Instance-Gruppen und Instance-Flotten in einem laufenden Cluster mit der AWS-Managementkonsole AWS CLI, oder der Amazon EMR-API hinzufügen und daraus entfernen. Wenn ein Cluster Instance-Gruppen verwendet, müssen Sie die Anzahl der Instances explizit ändern. Wenn Ihr Cluster Instance-Flotten verwendet, können Sie die Zieleinheiten für On-Demand-Instances und Spot-Instances ändern. Die Instance-Flotte fügt anschließend Instances hinzu bzw. entfernt diese, um dem neuen Ziel zu entsprechen. Weitere Informationen finden Sie unter [Instance-Flotten-Optionen](emr-instance-fleet.md#emr-instance-fleet-options). Sobald die Instances verfügbar sind, können Anwendungen die neu bereitgestellten Amazon-EC2-Instances zum Hosten von Knoten nutzen. Wenn Instances entfernt werden, fährt Amazon EMR Aufgaben so herunter, dass es weder zu einer Unterbrechung der Aufträge noch zu einem Datenverlust kommt. Weitere Informationen finden Sie unter [Beendigung bei Aufgaben-Abschluss](emr-scaledown-behavior.md#emr-scaledown-terminate-task).
## Die Größe eines Clusters mit der Konsole anpassen
Sie können die Größe eines Clusters über die Amazon-EMR-Konsole ändern.
------
#### [ Console ]
**So ändern Sie die Anzahl der Instances für einen vorhandenen Cluster mithilfe der neuen Konsole**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon EMR-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr).
1. Wählen Sie im linken Navigationsbereich unter **EMR in EC2** die Option **Cluster** und dann den Cluster aus, den Sie aktualisieren möchten. Der Cluster muss ausgeführt werden. Sie können die Größe eines bereitgestellten oder beendeten Clusters nicht ändern.
1. Sehen Sie sich auf der Cluster-Detailseite auf der Registerkarte **Instances** den Bereich **Instance-Gruppen** an.
1. Um die Größe einer vorhandenen Instance-Gruppe zu ändern, wählen Sie das Optionsfeld neben der Core- oder Aufgaben-Instance-Gruppe aus, deren Größe Sie ändern möchten, und wählen Sie dann **Größe der Instance-Gruppe ändern**. Geben Sie die neue Anzahl der Instances für die Instance-Gruppe an und wählen Sie anschließend **Größe ändern** aus.
**Anmerkung**
Wenn Sie sich dafür entscheiden, die Größe einer laufenden Instance-Gruppe zu reduzieren, wählt Amazon EMR intelligent die Instances aus, die aus der Gruppe entfernt werden sollen, um den Datenverlust zu minimieren. Für eine genauere Steuerung Ihrer Größenänderungsaktion können Sie die **ID** für die Instance-Gruppe auswählen, die Instances auswählen, die Sie entfernen möchten, und dann die Option **Terminate** verwenden. Weitere Informationen zum intelligenten Herunterskalierungs-Verhalten finden Sie unter [Cluster-Scale-Down-Optionen für Amazon EMR-Cluster](emr-scaledown-behavior.md).
1. Wenn Sie die Größenänderung abbrechen möchten, können Sie das Optionsfeld für eine Instance-Gruppe mit dem Status **Größenänderung** beenden auswählen und dann in der Liste der Aktionen die Option **Größenänderung beenden** auswählen.
1. Um Ihrem Cluster als Reaktion auf den steigenden Workload eine oder mehrere Aufgaben-Instance-Gruppen hinzuzufügen, wählen Sie **Aufgaben-Instance-Gruppe hinzufügen** aus der Liste der Aktionen aus. Wählen Sie den Amazon EC2-Instance-Typ, geben Sie die Anzahl der Instances für die Aufgabengruppe ein und wählen Sie dann **Aufgaben-Instance-Gruppe hinzufügen**, um zum Bereich **Instance-Gruppen** für Ihren Cluster zurückzukehren.
------
Wenn Sie die Anzahl der Knoten ändern, wird der **Status** der Instance-Gruppe aktualisiert. Wenn die gewünschte Änderung abgeschlossen ist, ändert sich der **Status** zu **Running (Wird ausgeführt)**.
## Ändern Sie die Größe eines Clusters mit dem AWS CLI
Sie können den verwenden AWS CLI , um die Größe eines laufenden Clusters zu ändern. Sie können die Anzahl der Aufgabenknoten erhöhen oder verringern. Sie können außerdem die Anzahl der Core-Knoten in einem ausgeführten Cluster erhöhen oder verringern. Es ist auch möglich, eine Instanz in der Core-Instanzgruppe mit der AWS CLI oder der API herunterzufahren. Dies sollte mit Vorsicht erfolgen. Beim Beenden einer Instance in der Core-Instance-Gruppe besteht das Risiko eines Datenverlustes. Die Instance wird zudem nicht automatisch ersetzt.
Zusätzlich zur Größenanpassung der Core- und Aufgaben-Gruppen können Sie mithilfe der AWS CLI auch eine oder mehrere Aufgaben-Instance-Gruppen zu einem ausgeführten Cluster hinzufügen.
**Um die Größe eines Clusters zu ändern, indem Sie die Anzahl der Instanzen mit dem AWS CLI**
Sie können der Kerngruppe oder Aufgabengruppe Instanzen hinzufügen und mit dem AWS CLI `modify-instance-groups` Unterbefehl mit dem Parameter Instanzen aus der Aufgabengruppe entfernen. `InstanceCount` Erhöhen Sie `InstanceCount`, um Instances zu Core- oder Task-Gruppen hinzuzufügen. Reduzieren Sie `InstanceCount`, um die Anzahl der Instances in der Gruppe zu verringern. Die Reduzierung der Anzahl der Instances einer Task-Gruppe auf null entfernt zwar alle Instances, nicht jedoch die Instance-Gruppe.
+ Um die Anzahl der Instanzen in der Aufgaben-Instanzgruppe von 3 auf 4 zu erhöhen, geben Sie den folgenden Befehl ein und *ig-31JXXXXXXBTO* ersetzen Sie ihn durch die Instanzgruppen-ID.
```
aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-31JXXXXXXBTO,InstanceCount=4
```
Verwenden Sie den Unterbefehl `InstanceGroupId`, um die `describe-cluster` abzurufen. Die Ausgabe ist ein JSON-Objekt mit dem Namen `Cluster`, das die ID jeder Instance-Gruppe enthält. Um diesen Befehl verwenden zu können, benötigen Sie die Cluster-ID (diese können Sie über den `aws emr list-clusters`-Befehl oder die Konsole abrufen). Um die Instanzgruppen-ID abzurufen, geben Sie den folgenden Befehl ein und *j-2AXXXXXXGAPLF* ersetzen Sie ihn durch die Cluster-ID.
```
aws emr describe-cluster --cluster-id j-2AXXXXXXGAPLF
```
Mit dem AWS CLI können Sie auch eine Instance in der Core-Instanzgruppe mit dem `--modify-instance-groups` Unterbefehl beenden.
**Warnung**
Die Angabe von `EC2InstanceIdsToTerminate` muss mit Vorsicht erfolgen. Instances werden sofort beendet, unabhängig vom Status der Anwendungen, die auf ihnen ausgeführt werden, und die Instance wird nicht automatisch ersetzt. Dies gilt unabhängig von der Konfiguration vom **Scale down behavior (Abwärtsskalierungsverhalten)** für den Cluster. Wenn eine Instance auf diese Weise beendet wird, besteht das Risiko von Datenverlusten und unvorhersehbarem Clusterverhalten.
Um eine bestimmte Instanz zu beenden, benötigen Sie die Instanzgruppen-ID (vom `aws emr describe-cluster --cluster-id` Unterbefehl zurückgegeben) und die Instanz-ID (vom `aws emr list-instances --cluster-id` Unterbefehl zurückgegeben). Geben Sie den folgenden Befehl ein, ersetzen Sie ihn durch die Instanzgruppen-ID und *ig-6RXXXXXX07SA* *i-f9XXXXf2* ersetzen Sie ihn durch die Instanz-ID.
```
1. aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-6RXXXXXX07SA,EC2InstanceIdsToTerminate=i-f9XXXXf2
```
Weitere Informationen zur Verwendung von Amazon EMR-Befehlen finden Sie AWS CLI unter[https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr).
**Um die Größe eines Clusters zu ändern, indem Sie Task-Instance-Gruppen hinzufügen, verwenden Sie AWS CLI**
Mit dem AWS CLI können Sie einem Cluster 1—48 Task-Instance-Gruppen mit dem `--add-instance-groups` Unterbefehl hinzufügen. Aufgaben-Instances-Gruppen können nur zu einem Cluster mit einer Primär-Instance-Gruppe und einer Core-Instance-Gruppe hinzugefügt werden. Wenn Sie den verwenden AWS CLI, können Sie bei jeder Verwendung des Unterbefehls bis zu fünf Task-Instanzgruppen hinzufügen. `--add-instance-groups`
1. Um einem Cluster eine einzelne Task-Instanzgruppe hinzuzufügen, geben Sie den folgenden Befehl ein und *j-JXBXXXXXX37R* ersetzen Sie ihn durch die Cluster-ID.
```
1. aws emr add-instance-groups --cluster-id j-JXBXXXXXX37R --instance-groups InstanceCount=6,InstanceGroupType=task,InstanceType=m5.xlarge
```
1. Um einem Cluster mehrere Task-Instance-Gruppen hinzuzufügen, geben Sie den folgenden Befehl ein und *j-JXBXXXXXX37R* ersetzen Sie ihn durch die Cluster-ID. Sie können bis zu fünf Task-Instance-Gruppen pro Befehl hinzufügen.
```
aws emr add-instance-groups --cluster-id j-JXBXXXXXX37R --instance-groups InstanceCount=6,InstanceGroupType=task,InstanceType=m5.xlarge InstanceCount=10,InstanceGroupType=task,InstanceType=m5.xlarge
```
Weitere Informationen zur Verwendung von Amazon EMR-Befehlen finden Sie AWS CLI unter[https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr).
## Unterbrechen einer Größenänderung
Wenn Sie Amazon-EMR-Version 4.1.0 oder höher verwenden, können Sie eine Größenänderung auch während einer laufenden Größenänderung durchführen. Sie können außerdem eine zuvor gesendete Anfrage zur Größenanpassung stoppen oder eine neue Anfrage senden, um eine frühere Anfrage zu überschreiben, ohne auf deren Abschluss zu warten. Sie können eine vorhandene Größenänderung über die Konsole oder über einen `ModifyInstanceGroups`-API-Aufruf mit der aktuellen Anzahl als Zielanzahl für den Cluster beenden.
Die folgende Abbildung zeigt eine Task-Instance-Gruppe, deren Größe gerade geändert wird und bei der die Größenänderung über **Stop (Stopp)** beendet werden kann.
![\[Task instance group showing resizing status with options to resize or stop.\]](http://docs.aws.amazon.com/de_de/emr/latest/ManagementGuide/images/resize-stop.png)
**Um eine Größenänderung zu unterbrechen, verwenden Sie den AWS CLI**
Sie können den verwenden AWS CLI , um eine Größenänderung mit dem Unterbefehl zu beenden. `modify-instance-groups` Nehmen wir an, Sie haben sechs Instances in der Instance-Gruppe und Sie möchten diese auf 10 erhöhen. Später entscheiden Sie, dass Sie diese Anforderung stornieren möchten:
+ Die ursprüngliche Anforderung:
```
aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-myInstanceGroupId,InstanceCount=10
```
Die zweite Anforderung zum Beenden der ersten Anforderung:
```
aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-myInstanceGroupId,InstanceCount=6
```
**Anmerkung**
Da es sich um einen asynchronen Prozess handelt, ändert sich die Instance-Anzahl möglicherweise entsprechend der vorherigen API-Anforderung, bevor nachfolgende Anforderungen berücksichtigt werden. Bei einer Verkleinerung kann es sein, dass auf den Knoten noch Aufgaben ausgeführt werden. In diesem Fall wird die Instance-Gruppe nicht verkleinert, bis die Knoten ihre Arbeit abgeschlossen haben.
## Suspendierter Zustand
Eine Instance-Gruppe geht in einen suspendierten Zustand über, wenn sie beim Versuch, die neuen Clusterknoten zu starten, auf zu viele Fehler stößt. Wenn z. B. neue Knoten während der Durchführung von Bootstrap-Aktionen wiederholt fehlschlagen, wechselt die Instance-Gruppe in den Status *SUSPENDED*, statt weiterhin zu versuchen, neue Knoten bereitzustellen. Nachdem Sie das entsprechende Problem behoben haben, setzen Sie die Anzahl der gewünschten Knoten in der Instance-Gruppe des Clusters zurück. Anschließend fährt die Instance-Gruppe mit der Reservierung von Knoten fort. Das Ändern einer Instance-Gruppe weist Amazon EMR an, die Knotenbereitstellung erneut zu versuchen. Nicht ausgeführte Knoten werden neu gestartet oder beendet.
In dem AWS CLI gibt der `list-instances` Unterbefehl alle Instanzen und deren Status zurück, ebenso wie der Unterbefehl. `describe-cluster` Wenn Amazon EMR einen Fehler bei einer Instance-Gruppe erkennt, wird der Status der Gruppe auf `SUSPENDED` geändert.
**Um einen Cluster im SUSPENDED-Zustand zurückzusetzen, verwenden Sie den AWS CLI**
Geben Sie den `describe-cluster`-Unterbefehl mit dem Parameter `--cluster-id` ein, um den Status der Instances in Ihrem Cluster anzuzeigen.
+ Um Informationen zu allen Instances und Instanzgruppen in einem Cluster anzuzeigen, geben Sie den folgenden Befehl ein und *j-3KVXXXXXXY7UG* ersetzen Sie ihn durch die Cluster-ID.
```
1. aws emr describe-cluster --cluster-id j-3KVXXXXXXY7UG
```
Die Ausgabe zeigt Informationen über Ihre Instance-Gruppen und den Status der Instances an:
```
1. {
2. "Cluster": {
3. "Status": {
4. "Timeline": {
5. "ReadyDateTime": 1413187781.245,
6. "CreationDateTime": 1413187405.356
7. },
8. "State": "WAITING",
9. "StateChangeReason": {
10. "Message": "Waiting after step completed"
11. }
12. },
13. "Ec2InstanceAttributes": {
14. "Ec2AvailabilityZone": "us-west-2b"
15. },
16. "Name": "Development Cluster",
17. "Tags": [],
18. "TerminationProtected": false,
19. "RunningAmiVersion": "3.2.1",
20. "NormalizedInstanceHours": 16,
21. "InstanceGroups": [
22. {
23. "RequestedInstanceCount": 1,
24. "Status": {
25. "Timeline": {
26. "ReadyDateTime": 1413187775.749,
27. "CreationDateTime": 1413187405.357
28. },
29. "State": "RUNNING",
30. "StateChangeReason": {
31. "Message": ""
32. }
33. },
34. "Name": "MASTER",
35. "InstanceGroupType": "MASTER",
36. "InstanceType": "m5.xlarge",
37. "Id": "ig-3ETXXXXXXFYV8",
38. "Market": "ON_DEMAND",
39. "RunningInstanceCount": 1
40. },
41. {
42. "RequestedInstanceCount": 1,
43. "Status": {
44. "Timeline": {
45. "ReadyDateTime": 1413187781.301,
46. "CreationDateTime": 1413187405.357
47. },
48. "State": "RUNNING",
49. "StateChangeReason": {
50. "Message": ""
51. }
52. },
53. "Name": "CORE",
54. "InstanceGroupType": "CORE",
55. "InstanceType": "m5.xlarge",
56. "Id": "ig-3SUXXXXXXQ9ZM",
57. "Market": "ON_DEMAND",
58. "RunningInstanceCount": 1
59. }
60. ...
61. }
```
Um Informationen zu einer bestimmten Instance-Gruppe anzuzeigen, geben Sie den Unterbefehl `list-instances` mit den Parametern `--cluster-id` und `--instance-group-types` ein. Sie können Informationen für Primär-, Core- oder Aufgaben-Gruppen anzeigen.
```
1. aws emr list-instances --cluster-id j-3KVXXXXXXY7UG --instance-group-types "CORE"
```
Verwenden Sie den Unterbefehl `modify-instance-groups` mit dem Parameter `--instance-groups`, um einen Cluster mit dem `SUSPENDED`-Status zurückzusetzen. Die Instance-Gruppen-ID wird vom Unterbefehl `describe-cluster` zurückgegeben.
```
1. aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-3SUXXXXXXQ9ZM,InstanceCount=3
```
## Überlegungen zur Reduzierung der Clustergröße
Wenn Sie sich dafür entscheiden, die Größe eines laufenden Clusters zu reduzieren, sollten Sie das folgende Verhalten und die folgenden Best Practices von Amazon EMR berücksichtigen:
+ Um die Auswirkungen auf laufende Jobs zu reduzieren, wählt Amazon EMR intelligent die zu entfernenden Instances aus. Weitere Informationen zum Verhalten beim Herunterskalieren von Clustern finden Sie unter [Beendigung bei Aufgaben-Abschluss](emr-scaledown-behavior.md#emr-scaledown-terminate-task) im Verwaltungshandbuch für Amazon EMR.
+ Wenn Sie die Größe eines Clusters herunterskalieren, kopiert Amazon EMR die Daten aus den Instances, die es entfernt hat, in die verbleibenden Instances. Stellen Sie sicher, dass in den Instances, die in der Gruppe verbleiben, ausreichend Speicherkapazität für diese Daten vorhanden ist.
+ Amazon EMR versucht, HDFS auf Instances in der Gruppe außer Betrieb zu nehmen. Bevor Sie die Größe eines Clusters reduzieren, empfehlen wir, die HDFS-Schreib-I/O zu minimieren.
+ Wenn Sie die Größe eines Clusters am genauesten steuern möchten, können Sie den Cluster in der Konsole anzeigen und zur Registerkarte **Instances** wechseln. Wählen Sie die **ID** für die Instance-Gruppe aus, deren Größe Sie ändern möchten. Verwenden Sie dann die Option **Terminate** für die spezifischen Instanceen, die Sie entfernen möchten.
# Konfiguration von Bereitstellungs-Timeouts zur Steuerung der Kapazität in Amazon EMR
Wenn Sie Instanceflotten verwenden, können Sie *Timeouts für die Bereitstellung* konfigurieren. Ein Bereitstellungs-Timeout weist Amazon EMR an, die Bereitstellung von Instance-Kapazität zu beenden, wenn der Cluster während des Cluster-Starts oder der Cluster-Skalierung einen bestimmten Zeitschwellenwert überschreitet. In den folgenden Themen wird beschrieben, wie ein Bereitstellungs-Timeout für den Clusterstart und für Cluster-Hochskalierungsvorgänge konfiguriert wird.
**Topics**
+ [Konfigurieren Sie Bereitstellungs-Timeouts für den Cluster-Start in Amazon EMR](emr-provisioning-timeout-launch.md)
+ [Ein Bereitstellungs-Timeout für den Cluster-Start in Amazon EMR anpassen](emr-provisioning-timeout-resize.md)
# Konfigurieren Sie Bereitstellungs-Timeouts für den Cluster-Start in Amazon EMR
Sie können einen Timeout-Zeitraum für die Bereitstellung von Spot Instances für jede Flotte in Ihrem Cluster definieren. Wenn Amazon EMR keine Spot-Kapazität bereitstellen kann, können Sie entweder den Cluster beenden oder stattdessen On-Demand-Kapazität bereitstellen. Wenn der Timeout-Zeitraum während der Cluster-Größenänderung endet, storniert Amazon EMR nicht bereitgestellte Spot-Anfragen. Nicht bereitgestellte Spot Instances werden nicht in On-Demand-Kapazität übertragen.
Führen Sie die folgenden Schritte aus, um ein Bereitstellungs-Timeout für den Clusterstart mit der Amazon-EMR-Konsole anzupassen.
------
#### [ Console ]
**Um das Bereitstellungs-Timeout zu konfigurieren, wenn Sie einen Cluster mit der Konsole erstellen**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon EMR-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr).
1. Wählen Sie im linken Navigationsbereich unter **EMR in EC2** die Option **Cluster** und dann **Cluster erstellen** aus.
1. Navigieren Sie auf der Seite **Cluster erstellen** zur **Cluster-Konfiguration** und wählen Sie **Instanceflotten**.
1. Geben Sie unter **Option Clusterskalierung und -Bereitstellung** die Spotgröße für Ihre Core- und Taskflotten an.
1. Wählen Sie unter **Spot-Timeout-Konfiguration** entweder **Cluster nach Spot-Timeout beenden** oder **Nach Spot-Timeout zu On-Demand wechseln**. Geben Sie dann den Timeout-Zeitraum für die Bereitstellung von Spot Instances an. Der Standardwert lautet 1 Stunde.
1. Wählen Sie alle anderen Optionen aus, die für Ihren Cluster gelten.
1. Um Ihren Cluster mit dem konfigurierten Timeout zu starten, wählen Sie **Cluster erstellen** aus.
------
#### [ AWS CLI ]
**Um ein Bereitstellungs-Timeout mit dem Befehl `create-cluster` anzugeben**
```
aws emr create-cluster \
--release-label emr-5.35.0 \
--service-role EMR_DefaultRole \
--ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \
--instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"LaunchSpecifications":{"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]'
```
------
# Ein Bereitstellungs-Timeout für den Cluster-Start in Amazon EMR anpassen
Definieren Sie einen Timeout-Zeitraum für die Bereitstellung von Spot Instances für jede Flotte in Ihrem Cluster. Wenn Amazon EMR die Spot-Kapazität nicht bereitstellen kann, storniert es die Größenänderungsanforderung und beendet seine Versuche, zusätzliche Spot-Kapazität bereitzustellen. Wenn Sie einen Cluster erstellen, können Sie das Timeout konfigurieren. Für einen laufenden Cluster können Sie ein Timeout hinzufügen oder aktualisieren.
Wenn der Timeout-Zeitraum abläuft, sendet Amazon EMR Ereignisse automatisch an einen Amazon CloudWatch Events-Stream. Mit können Sie Regeln erstellen CloudWatch, die Ereignisse nach einem bestimmten Muster zuordnen, und die Ereignisse dann an Ziele weiterleiten, um Maßnahmen zu ergreifen. Sie können beispielsweise eine Regel zum Senden einer E-Mail-Benachrichtigung konfigurieren. Weitere Informationen zum Erstellen von Regeln finden Sie unter [Regeln für Amazon EMR-Ereignisse erstellen mit CloudWatch](emr-events-cloudwatch-console.md). Weitere Informationen zu verschiedenen Ereignisdetails finden Sie unter [Ereignisse zur Änderung des Status der Instance-Flotte](emr-manage-cloudwatch-events.md#emr-cloudwatch-instance-fleet-events).
## Beispiele für Bereitstellungs-Timeouts bei der Clustergrößenänderung
**Geben Sie ein Bereitstellungs-Timeout für die Größenänderung mit dem AWS CLI an**
Im folgenden Beispiel wird der `create-cluster`-Befehl verwendet, um ein Bereitstellungs-Timeout für die Größenänderung hinzuzufügen.
```
aws emr create-cluster \
--release-label emr-5.35.0 \
--service-role EMR_DefaultRole \
--ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \
--instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":20},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":25}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]'
```
Im folgenden Beispiel wird der `modify-instance-fleet`-Befehl verwendet, um ein Bereitstellungs-Timeout für die Größenänderung hinzuzufügen.
```
aws emr modify-instance-fleet \
--cluster-id j-XXXXXXXXXXXXX \
--instance-fleet '{"InstanceFleetId":"if-XXXXXXXXXXXX","ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":30},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":60}}}' \
--region us-east-1
```
Im folgenden Beispiel wird der `add-instance-fleet-command` verwendet, um ein Bereitstellungs-Timeout für die Größenänderung hinzuzufügen.
```
aws emr add-instance-fleet \
--cluster-id j-XXXXXXXXXXXXX \
--instance-fleet '{"InstanceFleetType":"TASK","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"TaskFleet","ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":30},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":35}}}' \
--region us-east-1
```
**Geben Sie ein Bereitstellungs-Timeout für die Größenänderung und den Start mit dem AWS CLI**
Im folgenden Beispiel wird der `create-cluster`-Befehl verwendet, um ein Bereitstellungs-Timeout für die Größenänderung hinzuzufügen.
```
aws emr create-cluster \
--release-label emr-5.35.0 \
--service-role EMR_DefaultRole \
--ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \
--instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"LaunchSpecifications":{"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":20},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":25}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]'
```
## Überlegungen zur Größenänderung von Bereitstellungs-Timeouts
Wenn Sie Timeouts für die Cluster-Bereitstellung für Ihre Instanceflotten konfigurieren, sollten Sie die folgenden Verhaltensweisen berücksichtigen.
+ Sie können Bereitstellungs-Timeouts sowohl für Spot Instances als auch für On-Demand-Instances konfigurieren. Das Mindestzeitlimit für die Bereitstellung beträgt 5 Minuten. Das maximale Bereitstellungszeitlimit beträgt 7 Tage.
+ Sie können Bereitstellungs-Zeitlimit nur für einen EMR-Cluster konfigurieren, der Instance-Flotten verwendet. Sie müssen jeden Core und jede Aufgaben-Flotte separat konfigurieren.
+ Wenn Sie einen Cluster erstellen, können Sie Bereitstellungs-Zeitlimits konfigurieren. Sie können ein Zeitlimit für einen laufenden Cluster hinzufügen oder ein vorhandenes Zeitlimit aktualisieren.
+ Wenn Sie mehrere Größenänderungsvorgänge einreichen, verfolgt Amazon EMR die Bereitstellungs-Timeouts für jeden Größenänderungsvorgang. Legen Sie beispielsweise das Bereitstellungs-Timeout für einen Cluster auf Minuten fest. *60* Senden Sie dann nach und nach einen Vorgang *R1* zur Größenänderung. *T1* Reichen Sie jeweils einen zweiten Vorgang *R2* zur Größenänderung ein. *T2* Das Bereitstellungs-Timeout für R1 läuft am ab. *T1 \$1 60 minutes* Das Bereitstellungstimeout für R2 läuft am ab. *T2 \$1 60 minutes*
+ Wenn Sie vor Ablauf des Timeouts einen neuen Vorgang zur Skalierung der Größe einreichen, versucht Amazon EMR weiterhin, Kapazität für Ihren EMR-Cluster bereitzustellen.
# Cluster-Scale-Down-Optionen für Amazon EMR-Cluster
**Anmerkung**
Optionen für das Herunterskalierungs-Verhalten werden seit der Amazon-EMR-Version 5.10.0 nicht mehr unterstützt. Aufgrund der Einführung der sekundengenauen Abrechnung in Amazon EC2 lautet das standardmäßige Herunterskalierungsverhalten für Amazon-EMR-Cluster nun „Beenden bei Abschluss der Aufgabe“.
Mit Amazon EMR Version 5.1.0 bis 5.9.1. gibt es zwei Optionen für das Herunterskalierungs-Verhalten: „Beenden zur Instance-Stundengrenze für die Amazon EC2-Fakturierung“ oder „Beenden bei Abschluss der Aufgabe“. Beginnend mit Amazon-EMR-Version 5.10.0 ist aufgrund der sekundenweisen Abrechnung die Einstellung für ein Beenden an einer Instance-Stundengrenze veraltet, da die Amazon-EC2-Abrechnung pro Sekunde eingeführt wurde. Wir raten davon ab, die Beendigung zur Instance-Stundengrenze zu verwenden, wenn diese Option angeboten wird.
**Warnung**
Wenn Sie die Option verwenden, AWS CLI um ein `modify-instance-groups` mit auszustellen`EC2InstanceIdsToTerminate`, werden diese Instances sofort beendet, ohne Berücksichtigung dieser Einstellungen und unabhängig vom Status der Anwendungen, die auf ihnen ausgeführt werden. Wenn eine Instance auf diese Weise beendet wird, besteht das Risiko von Datenverlusten und unvorhersehbarem Clusterverhalten.
Wenn „Beim Abschluss der Aufgabe beenden“ angegeben ist, führt Amazon EMR eine Ablehnungsliste auf und entlädt Aufgaben von den Knoten, bevor die Amazon-EC2-Instances beendet werden. Bei beiden Varianten werden durch Amazon EMR keine Amazon-EC2-Instances in den Core-Instance-Gruppen beendet, sofern dies zu HDFS-Beschädigungen führen könnte.
## Beendigung bei Aufgaben-Abschluss
Mit Amazon EMR können Sie eine Herunterskalierung für den Cluster durchführen, ohne dass es zu Auswirkungen auf den Workload kommt. Amazon EMR versucht, YARN, HDFS und andere Daemons auf Kern- und Taskknoten während einer Größenänderung ordnungsgemäß außer Betrieb zu nehmen, ohne Daten zu verlieren oder Jobs zu unterbrechen. Amazon EMR verkleinert Instance-Gruppen nur, wenn die zu den Gruppen zugewiesenen Aufgaben abgeschlossen sind und sie unausgelastet sind. Bei YARN NodeManager Graceful Decommission können Sie die Zeit, die ein Knoten auf die Außerbetriebnahme wartet, manuell anpassen.
**Anmerkung**
Bei einer ordnungsgemäßen Außerbetriebnahme kann es zu Datenverlust kommen. Stellen Sie sicher, dass Sie Ihre Daten sichern.
**Wichtig**
Es ist möglich, dass HDFS-Daten beim ordnungsgemäßen Austausch einer fehlerhaften Core-Instance dauerhaft verloren gehen. Wir empfehlen, dass Sie Ihre Daten immer sichern.
Die Dauer wird mit einer Eigenschaft in der `YARN-site`-Konfigurationsklassifizierung eingerichtet. Wenn Sie Amazon-EMR-Version 5.12.0 und höher verwenden, geben Sie die Eigenschaft `YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs` an. Bei Verwendung von früheren Amazon-EMR-Versionen geben Sie die Eigenschaft `YARN.resourcemanager.decommissioning.timeout` an.
Wenn nach diesem Stilllegungszeitraum noch Container oder YARN-Anwendungen ausgeführt werden, wird die Stilllegung des Knotens erzwungen. YARN plant betroffene Container in anderen Knoten neu. Die Standardwert ist 3600 Sekunden (eine Stunde). Sie können den Timeout auf einen extrem hohen Wert festlegen, um die ordnungsgemäße Verkleinerung zu verzögern. Weitere Informationen finden Sie unter [Ordnungsgemäßes Stilllegen von YARN Knoten](http://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/GracefulDecommission.html) in der Apache-Hadoop-Dokumentation.
### Aufgabenknoten-Gruppen
Amazon EMR wählt in intelligenter Weise Instances aus, die keine Aufgaben im Zusammenhang mit einem Schritt oder einer Anwendung ausführen und entfernt diese Instance zuerst aus einem Cluster. Wenn alle Instances im Cluster genutzt werden, wartet Amazon EMR auf den Abschluss von Tasks in einer Instance, bevor diese aus dem Cluster entfernt wird. Die standardmäßige Leerlaufzeit beträgt eine Stunde. Dieser Wert kann mit der Einstellung `YARN.resourcemanager.decommissioning.timeout` geändert werden. Amazon EMR nutzt die neue Einstellung dynamisch. Sie können diesen Wert auf eine beliebig große Zahl festlegen, um sicherzustellen, dass Amazon EMR keine Aufgaben beendet und gleichzeitig die Clustergröße reduziert.
### Core-Knoten-Gruppen
Auf Kernknoten müssen sowohl YARN NodeManager - als auch DataNode HDFS-Daemons außer Betrieb genommen werden, damit die Instanzgruppe reduziert werden kann. Bei YARN stellt das ordnungsgemäße Verkleinern sicher, dass ein für die Außerbetriebnahme vorgesehener Knoten nur dann in den Status `DECOMMISSIONED` wechselt, wenn es keine ausstehenden oder unvollständigen Container oder Anwendungen gibt. Die Außerbetriebnahme wird direkt beendet, falls es zu Beginn der Außerbetriebnahme keine laufenden Container auf dem Knoten gibt.
Bei HDFS stellt die ordnungsgemäße Verkleinerung sicher, dass die Zielkapazität von HDFS für alle vorhandenen Blöcke ausreichend ist. Wenn die Zielkapazität nicht groß genug ist, wird nur ein Teil der Core-Instances außer Betrieb gestellt. So können die verbleibenden Knoten die aktuell in HDFS vorhandenen Daten verarbeiten. Stellen Sie für eine weitere Außerbetriebnahme zusätzliche HDFS-Kapazität sicher. Sie sollten auch versuchen, den Schreibaufwand zu minimieren, I/O bevor Sie versuchen, Instanzgruppen zu reduzieren. Übermäßiger Schreibvorgang I/O kann den Abschluss des Größenänderungsvorgangs verzögern.
Ein weiterer Faktor ist der Standard-Replikationsfaktor (`dfs.replication`) in `/etc/hadoop/conf/hdfs-site`. Amazon EMR konfiguriert den Wert basierend auf der Anzahl der Instances im Cluster: `1` bei 1–3 Instances, `2` für Cluster mit 4–9 Instances und `3` für Cluster mit mehr als zehn Instances.
**Warnung**
Das Festlegen von `dfs.replication` auf 1 auf Clustern mit weniger als vier Knoten kann zu einem HDFS-Datenverlust führen, wenn ein einzelner Knoten ausfällt. Wir empfehlen, für Produktionsworkloads einen Cluster mit mindestens vier Core-Knoten zu verwenden.
Amazon EMR erlaubt Clustern nicht, Core-Knoten unter `dfs.replication` zu skalieren. Bei `dfs.replication = 2` z. B. beträgt die Mindestanzahl von Core-Knoten 2.
Wenn Sie verwaltete Skalierung oder Auto-Scaling verwenden oder die Größe Ihres Clusters manuell ändern möchten, empfehlen wir Ihnen, `dfs.replication` auf 2 oder höher einzustellen.
Durch die schrittweise Reduzierung können Sie die Anzahl der Core-Knoten nicht unter den HDFS-Replikationsfaktor reduzieren. Auf diese Weise kann HDFS Dateien aufgrund unzureichender Replikate schließen. Um dieses Limit zu umgehen, verringern Sie den Replikationsfaktor und starten Sie den NameNode Daemon neu.
# Das Herunterskalierungs-Verhalten für Amazon-EMR-Cluster konfigurieren
**Anmerkung**
Die Option zum Herunterskalieren zur Instance-Stunde wird für Amazon EMR Version 5.10.0 und höher nicht mehr unterstützt. Die folgenden Optionen für das Scale-Down-Verhalten werden nur in der Amazon-EMR-Konsole für die Versionen 5.1.0 bis 5.9.1 angezeigt.
Sie können die AWS-Managementkonsole, oder die Amazon EMR-API verwenden AWS CLI, um das Scale-Down-Verhalten bei der Erstellung eines Clusters zu konfigurieren.
------
#### [ Console ]
**Um das Scale-Down-Verhalten mit der Konsole zu konfigurieren**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon EMR-Konsole unter [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr).
1. Wählen Sie im linken Navigationsbereich unter **EMR in EC2** die Option **Cluster** und dann **Cluster erstellen** aus.
1. Wählen Sie im Abschnitt **Optionen für Clusterskalierung und -bereitstellung die Option** Benutzerdefinierte automatische Skalierung **verwenden** aus. Wählen Sie unter **Benutzerdefinierte automatische Skalierungsrichtlinien** die **Plus-Aktionsschaltfläche** aus, um **Skalierungsrichtlinien** hinzuzufügen. Wir empfehlen, dass Sie sowohl Richtlinien für die **Skalierung** als auch für die **horizontale Skalierung** hinzufügen. Wenn Sie nur einen Richtliniensatz hinzufügen, führt Amazon EMR nur eine unidirektionale Skalierung durch und Sie müssen die anderen Aktionen manuell ausführen.
1. Wählen Sie alle anderen Optionen aus, die für Ihren Cluster gelten.
1. Um Ihren Cluster jetzt zu starten, wählen Sie **Cluster erstellen** aus.
------
#### [ AWS CLI ]
**Um das Scale-Down-Verhalten zu konfigurieren, verwenden Sie AWS CLI**
+ Verwenden Sie für die `--scale-down-behavior`-Option entweder `TERMINATE_AT_INSTANCE_HOUR` oder `TERMINATE_AT_TASK_COMPLETION`.
------