Verwenden der verwalteten Skalierung in Amazon EMR

Im Folgenden AWS-Regionen ist Amazon EMR Managed Scaling mit Amazon EMR 6.14.0 und höher verfügbar:

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:

Amazon EMR Managed Scaling funktioniert nur mit YARN-Anwendungen wie Spark, Hadoop, Hive und Flink. Es werden keine Anwendungen unterstützt, die nicht auf YARN basieren, wie Presto und HBase.

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.

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.

Die verwaltete Skalierung wird in limitierten Versionen AWS-Regionen und in Amazon EMR-Versionen unterstützt. Weitere Informationen finden Sie unter Verwaltete Skalierungsverfügbarkeit.

Sie müssen die folgenden Parameter für die Amazon EMR Managed Scaling konfigurieren. Weitere Informationen finden Sie unter Verwaltete Skalierungsparameter.

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 richtig. Um sicherzustellen, dass die verwaltete Skalierung funktioniert, empfehlen wir, dass Sie eine der folgenden Aktionen ausführen:

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 integriert wird, zu Fällen, in denen Knoten in Amazon EMR abgelehnt werden können, und zur Konfiguration des Verhaltens bei der Außerbetriebnahme von Spark-Knoten.

Bei Spark-Workloads FALSE kann die Deaktivierung von Spark Dynamic Resource Allocator (DRA) durch Ändern der Spark-Eigenschaft spark.dynamic Allocation.enabled zu Managed Scaling-Problemen führen, bei denen Cluster mehr als für Ihre Workloads erforderlich hochskaliert werden können (bis zur maximalen Rechenleistung). Wenn Sie Managed Scaling für diese Workloads verwenden, empfehlen wir, Spark DRA aktiviert zu lassen, was der Standardstatus dieser Eigenschaft ist.

Over-utilization von EBS-Volumes können Managed Scaling-Probleme verursachen. Wir empfehlen, das EBS-Volumen unter einer Auslastung 90 % zu halten. Weitere Informationen finden Sie unter Speicheroptionen und Verhalten von Instances in Amazon EMR.

CloudWatch Amazon-Metriken sind entscheidend für den Betrieb der von Amazon EMR verwalteten Skalierung. Wir empfehlen Ihnen, die CloudWatch Amazon-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.

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-Node und das On-Demand Limit für die von Amazon EMR verwaltete Skalierung festlegen, sollten Sie die Unterschiede zwischen Instanzgruppen und Instance-Flotten berücksichtigen. Jede Instanzgruppe besteht aus demselben Instance-Typ und derselben Kaufoption für Instances: On-Demand oder Spot. Für jede Instance-Flotte können Sie bis zu fünf Instance-Typen angeben, die als On-Demand Spot-Instances bereitgestellt werden können. Weitere Informationen finden Sie unter Erstellen eines Clusters mit Instance-Flotten oder einheitlichen Instance-Gruppen, Instance Flotten Optionen und Knotenzuweisungsszenarien.

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 zur Konfiguration von Sicherheitsgruppen finden Sie unter EMR-managed Amazon-Sicherheitsgruppe für die primäre Instance (private Subnetze).

Sie können es verwenden AWS CloudFormation , um die von Amazon EMR verwaltete Skalierung zu konfigurieren. Weitere Informationen finden Sie unter AWS::EMR::Cluster im AWS CloudFormation -Benutzerhandbuch.

Wenn Sie Spot-Knoten verwenden, sollten Sie die Verwendung von Node-Labels in Betracht ziehen, um zu verhindern, dass Amazon EMR Anwendungsprozesse entfernt, wenn Amazon EMR Spot-Knoten entfernt. Weitere Informationen zu Node-Labels finden Sie unter Task-Nodes.

Die Knotenbeschriftung wird in den Amazon EMR-Versionen 6.15 oder niedriger standardmäßig nicht unterstützt. Weitere Informationen finden Sie unter Grundlegendes zu den Knotentypen: Primär-, Kern- und Taskknoten.

Wenn Sie Amazon EMR-Versionen 6.15 oder niedriger verwenden, können Sie Node-Labels nur nach Knotentyp zuweisen, z. B. nach Kern- und Taskknoten. 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, weil Sie den Anwendungsprozess auf Kernknoten beschränkt haben, können Sie im gleichen Vorgang zur Größenänderung wieder Kernknoten hinzufügen und Task-Knoten entfernen. Weitere Informationen finden Sie unter Grundlegendes zur Strategie und zu den Szenarien für die Knotenzuweisung.

Amazon EMR kennzeichnet Taskknoten nicht, sodass Sie die YARN-Eigenschaften nicht so einstellen können, dass Anwendungsprozesse nur für Taskknoten eingeschränkt werden. Wenn Sie jedoch Markttypen als Node-Labels verwenden möchten, können Sie die SPOT Or-Labels für die ON_DEMAND Platzierung von Anwendungsprozessen verwenden. Wir empfehlen nicht, Spot-Nodes für primäre Anwendungsprozesse zu verwenden.

Wenn Sie Node-Labels verwenden, kann die Gesamtzahl der ausgeführten Einheiten im Cluster vorübergehend die in Ihrer Richtlinie für verwaltete Skalierung festgelegte maximale Rechenleistung überschreiten, während Amazon EMR einige Ihrer Instances außer Betrieb nimmt. Die Gesamtzahl der angeforderten Einheiten bleibt immer bei oder unter der maximalen Rechenleistung Ihrer Richtlinie.

Die verwaltete Skalierung unterstützt nur die Knotenbezeichnungen ON_DEMAND und SPOT oder CORE undTASK. 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 vom Anwendungsprozess und der Anforderung des Executors skaliert. Um Probleme mit HDFS-Datenverlusten beim Herunterskalieren des Kerns zu vermeiden, folgen Sie der Standardpraxis für Core-Knoten. Weitere Informationen zu bewährten Methoden in Bezug auf Kernknoten und HDFS-Replikation finden Sie unter Überlegungen und bewährte 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 das Maximum im Knoten. ON_DEMAND Entfernen Sie auch die Konfigurationyarn.node-labels.am.default-node-label-expression.

Um sowohl den Anwendungsprozess als auch die Executoren auf den core Knoten hinzuzufügen, entfernen Sie die yarn.node-labels.am.default-node-label-expression Konfiguration.

Wenn Sie die 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 Knoten vollständig nutzen.

Wenn Sie verwaltete Skalierung mit Knotenbezeichnungen verwenden, legen Sie für die Eigenschaft yarn.resourcemanager.decommissioning.timeout einen Wert fest, der länger ist als die am längsten ausgeführte Anwendung in Ihrem Cluster. Dadurch verringert sich die Wahrscheinlichkeit, dass die von Amazon EMR verwaltete Skalierung Ihre Anwendungen für die Wiederinbetriebnahme von Knoten neu CORE planen muss. ON_DEMAND

Um das Risiko von Anwendungsausfällen aufgrund des Verlusts von Shuffle-Daten zu reduzieren, erfasst 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 das rechtzeitige Herunterskalieren von Instances in Ihrem Cluster auswirken. Bei Clustern, die eine große Menge an Shuffle-Daten enthalten, sollten Sie die EMR-Versionen 6.13 und höher in Betracht ziehen.