Cluster automatisch skalieren

Ziel: Sie erfahren, wie Sie das Autoscaling von Managed Service for Apache Spark konfigurieren und verwenden, um die Anzahl der Worker-VMs in Managed Service for Apache Spark-Clustern automatisch und dynamisch an die Anforderungen der Arbeitslast anzupassen.

Was ist Autoscaling?

Das Schätzen der "richtigen" Anzahl von Cluster-Workern (Knoten) für eine Arbeitslast ist schwierig und eine einzelne Clustergröße für eine gesamte Pipeline ist oft nicht ideal. Vom Nutzer initiierte Cluster-Skalierung wird diese Herausforderung teilweise gelöst, erfordert jedoch die Überwachung der Clusternutzung und ein manuelles Eingreifen.

Die Dataproc AutoscalingPolicies API bietet einen Mechanismus zur Automatisierung der Clusterressourcenverwaltung und ermöglicht das Autoscaling von Cluster-Worker-VMs. Eine Autoscaling Policy ist eine wiederverwendbare Konfiguration, die beschreibt, wie Cluster-Worker mit der Autoscaling-Richtlinie skalieren sollen. Sie definiert Skalierungsgrenzen, Häufigkeit und Aggressivität, um eine detaillierte Kontrolle über Clusterressourcen während der gesamten Clusterlebensdauer zu ermöglichen.

• Beim Autoscaling von Managed Service for Apache Spark werden die Worker-Knoten des Clusters skaliert, nicht die Clustermaster.
• Das Autoscaling von Managed Service for Apache Spark unterstützt die horizontale Skalierung (Skalierung der Anzahl der Knoten), nicht die vertikale Skalierung (Skalierung der Maschinentypen).

Einsatzmöglichkeiten für Autoscaling

Verwenden Sie Autoscaling:

bei Clustern, die Daten in externen Diensten speichern, wie z. B. Cloud Storage oder BigQuery

bei Clustern, die viele Jobs verarbeiten

, um Einzeljobcluster hochzuskalieren

mit dem Enhanced Flexibility Mode für Spark-Batch-Jobs

Autoscaling wird nicht empfohlen bei/für:

• HDFS: Autoscaling ist nicht für die Skalierung von HDFS im Cluster vorgesehen, weil:

  1. Die HDFS-Nutzung ist kein Signal für das Autoscaling.
  2. HDFS-Daten werden nur auf primären Workern gehostet. Die Anzahl der primären Worker muss ausreichen, um alle HDFS-Daten zu hosten.
  3. Durch die Außerbetriebnahme von HDFS-DataNodes kann das Entfernen von Workern verzögert werden. Datanodes kopieren HDFS-Blöcke auf andere Datanodes, bevor ein Worker entfernt wird. Je nach Datengröße und Replikationsfaktor kann dieser Vorgang Stunden dauern.

• YARN-Knotenlabels: Autoscaling unterstützt weder YARN-Knotenlabels noch das Attribut dataproc:am.primary_only aufgrund von YARN-9088. YARN meldet Clustermesswerte nicht, wenn Knotenlabels verwendet werden.

• Spark Structured Streaming:Das Autoscaling unterstützt kein Spark Structured Streaming (siehe Autoscaling und Spark Structured Streaming).

• Inaktive Cluster: Autoscaling eignet sich nicht zum Herunterskalieren eines Clusters auf die Mindestgröße, wenn der Cluster inaktiv ist. Da das Erstellen eines neuen Clusters genauso schnell geht wie das Ändern seiner Größe, ist es sinnvoller, inaktive Cluster stattdessen zu löschen und neu zu erstellen. Folgende Tools unterstützen dieses "ephemerische" Modell:

   Verwenden Sie Managed Service for Apache Spark-Workflows, um eine Reihe von Jobs in einem dedizierten Cluster zu planen und den Cluster dann zu löschen, wenn die Jobs abgeschlossen sind. Verwenden Sie für eine bessere Orchestrierung Cloud Composer, einen Dienst, der auf Apache Airflow basiert.

  Verwenden Sie für Cluster, die Ad-hoc-Abfragen oder extern geplante Arbeitslasten verarbeiten, Cluster Scheduled Deletion, um den Cluster nach einer bestimmten Dauer oder Zeit der Inaktivität bzw. zu einem bestimmten Zeitpunkt zu löschen.

• Arbeitslasten unterschiedlicher Größe: Wenn kleine und große Jobs in einem Cluster ausgeführt werden, wird bei der ordnungsgemäßen Außerbetriebnahme durch Herunterskalieren gewartet, bis die großen Jobs abgeschlossen sind. Das führt dazu, dass ein lang andauernder Job das Autoscaling von Ressourcen für kleinere Jobs, die im Cluster ausgeführt werden, verzögert, bis der lang andauernde Job abgeschlossen ist. Um dieses Ergebnis zu vermeiden, fassen Sie kleinere Jobs ähnlicher Größe in einem Cluster zusammen und isolieren Sie jeden Job mit langer Dauer in einem separaten Cluster.

Automatische Skalierung aktivieren

So aktivieren Sie Autoscaling in einem Cluster:

1. Erstellen Sie eine Autoscaling-Richtlinie.

2. Entweder:

   1. Autoscaling-Cluster erstellen oder
   2. Aktivieren Sie Autoscaling für einen vorhandenen Cluster

Autoscaling-Richtlinie erstellen

Google Cloud Console

Wenn Sie eine Autoscaling-Richtlinie erstellen möchten, wählen Sie auf der Seite Autoscaling-Richtlinien von Managed Service for Apache Spark in der Google Cloud Console die Option „RICHTLINIE ERSTELLEN“ aus. Auf der Seite Richtlinie erstellen können Sie ein Empfehlungsfeld für Richtlinien auswählen, um die Felder für die Autoscaling-Richtlinie für einen bestimmten Jobtyp oder ein bestimmtes Skalierungsziel auszufüllen.

gcloud-CLI

Sie können eine Autoscaling-Richtlinie mit dem Befehl gcloud dataproc autoscaling-policies import erstellen. Sie liest eine lokale YAML-Datei, die eine Autoscaling-Richtlinie definiert. Das Format und der Inhalt der Datei müssen den Konfigurationsobjekten und Feldern entsprechen, die von der REST API autoscalingPolicies definiert sind.

Im folgenden YAML-Beispiel wird eine Richtlinie für Managed Service for Apache Spark-Standardcluster mit allen erforderlichen Feldern definiert. Außerdem werden die Werte minInstances und maxInstances für die primären Worker, der Wert maxInstances für die sekundären (auf Abruf verfügbaren) Worker und ein cooldownPeriod von 4 Minuten (Standardwert: 2 Minuten) angegeben. Mit workerConfig werden die primären Worker konfiguriert. In diesem Beispiel sind minInstances und maxInstances auf denselben Wert gesetzt, um die primären Worker nicht zu skalieren.

workerConfig:
  minInstances: 10
  maxInstances: 10
secondaryWorkerConfig:
  maxInstances: 50
basicAlgorithm:
  cooldownPeriod: 4m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    gracefulDecommissionTimeout: 1h

Im folgenden YAML-Beispiel wird eine Richtlinie für Standardcluster von Managed Service for Apache Spark mit allen erforderlichen und optionalen Feldern für die Autoscaling-Richtlinie definiert.

clusterType: STANDARD
workerConfig:
  minInstances: 10
  maxInstances: 10
  weight: 1
secondaryWorkerConfig:
  minInstances: 0
  maxInstances: 100
  weight: 1
basicAlgorithm:
  cooldownPeriod: 2m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    scaleUpMinWorkerFraction: 0.0
    scaleDownMinWorkerFraction: 0.0
    gracefulDecommissionTimeout: 1h

Im folgenden YAML-Beispiel wird eine Richtlinie für Cluster mit null Knoten definiert.

Bei auf null skalierten Clustern geben Sie workerConfig nicht an.

clusterType: ZERO_SCALE
secondaryWorkerConfig:
  minInstances: 0
  maxInstances: 100
  weight: 1
basicAlgorithm:
  cooldownPeriod: 2m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    scaleUpMinWorkerFraction: 0.0
    scaleDownMinWorkerFraction: 0.0
    gracefulDecommissionTimeout: 1h

Führen Sie zum Erstellen der Autoscaling-Richtlinie den folgenden gcloud-Befehl über ein lokales Terminal oder in Cloud Shell aus. Benennen Sie die Richtlinie. Dieser Name wird zur Richtlinie id, die Sie in späteren gcloud-Befehlen verwenden können, um auf die Richtlinie zu verweisen. Verwenden Sie das Flag --source, um den lokalen Pfad und den Dateinamen der zu importierenden YAML-Datei für die Autoscaling-Richtlinie anzugeben.

gcloud dataproc autoscaling-policies import policy-name \
    --source=filepath/filename.yaml \
    --region=region

REST API

Erstellen Sie eine Autoscaling-Richtlinie, indem Sie eine AutoscalingPolicy als Teil einer autoscalingPolicies.create-Anfrage definieren.

Autoscaling-Cluster erstellen

Nachdem Sie eine Autoscaling-Richtlinie erstellt haben, erstellen Sie einen Cluster, der die Autoscaling-Richtlinie verwendet. Der Cluster muss sich in derselben Region wie die Autoscaling-Richtlinie befinden.

Google Cloud Console

So wenden Sie eine Autoscaling-Richtlinie auf einen neuen Cluster an:

1. Öffnen Sie die Seite Cluster erstellen für Managed Service for Apache Spark.
2. Wählen Sie im Abschnitt Cluster definieren unter Skalierungsmodus für Worker auswählen die Option Autoscaling und dann im Feld Richtlinie die gewünschte Richtlinie aus.

gcloud-CLI

Führen Sie den folgenden gcloud-Befehl über ein lokales Terminal oder in Cloud Shell aus, um einen Autoscaling-Cluster zu erstellen. Geben Sie einen Namen für den Cluster an und verwenden Sie das Flag --autoscaling-policy, um policy ID (den Namen der Richtlinie, den Sie beim Erstellen der Richtlinie angegeben haben) oder die Richtlinie resource URI (resource name) (siehe die Felder AutoscalingPolicy id und name) anzugeben.

gcloud dataproc clusters create cluster-name \
    --autoscaling-policy=policy id or resource URI \
    --region=region

Den vollständigen Ressourcennamen (oder URI) einer Richtlinie können Sie mit dem folgenden gcloud -Befehl abrufen:

gcloud dataproc autoscaling-policies \
    describe policy-id \
    --region=region

REST API

Erstellen Sie einen Autoscaling-Cluster, indem Sie AutoscalingConfig als Teil einer clusters.create-Anfrage hinzufügen.

Um den AutoscalingConfig.policyUri (Name der Richtlinienressource) anzuzeigen, führen Sie den folgenden gcloud -Befehl aus:

gcloud dataproc autoscaling-policies \
    describe policy-name \
    --region=region

Autoscaling für einen vorhandenen Cluster aktivieren

Nach dem Erstellen einer Autoscaling-Richtlinie können Sie die Richtlinie für einen vorhandenen Cluster in derselben Region aktivieren.

Google Cloud Console

Das Aktivieren einer Autoscaling-Richtlinie für einen vorhandenen Cluster wird in der Google Cloud Console nicht unterstützt.

gcloud-CLI

Führen Sie den folgenden gcloud-Befehl von einem lokalen Terminal oder in Cloud Shell aus, um eine Autoscaling-Richtlinie für einen vorhandenen Cluster zu aktivieren. Geben Sie einen Namen für den Cluster an und verwenden Sie das Flag --autoscaling-policy, um policy ID (den Namen der Richtlinie, den Sie beim Erstellen der Richtlinie angegeben haben) oder die Richtlinie resource URI (resource name) (siehe die AutoscalingPolicy-Felder id und name) anzugeben.

gcloud dataproc clusters update cluster-name \
    --autoscaling-policy=policy id or resource URI \
    --region=region

Der vollständige Ressourcenname (oder URI) einer Richtlinie kann durch Ausführen des folgenden gcloud -Befehls abgerufen werden:

gcloud dataproc autoscaling-policies \
    describe policy-id \
    --region=region

REST API

Um eine Autoscaling-Richtlinie für einen vorhandenen Cluster zu aktivieren, legen Sie den AutoscalingConfig.policyUri der Richtlinie in der updateMask einer clusters.patch-Anfrage fest.

Um den AutoscalingConfig.policyUri (Name der Richtlinienressource) anzuzeigen, führen Sie den folgenden gcloud -Befehl aus:

gcloud dataproc gcloud dataproc autoscaling-policies \
    describe policy-name \
    --region=region

Multi-Cluster-Richtlinien verwenden

• Eine Autoscaling-Richtlinie definiert das Skalierungsverhalten, das auf mehrere Cluster angewendet werden kann. Autoscaling-Richtlinien lassen sich am besten für mehrere Cluster anwenden, wenn die Cluster ähnliche Arbeitslasten gemeinsam verwenden oder Jobs mit ähnlichen Ressourcennutzungsmustern ausführen.

• Sie können eine Richtlinie aktualisieren, die von mehreren Clustern verwendet wird. Die Aktualisierungen wirken sich sofort auf das Autoscaling-Verhalten aller Cluster aus, die die Richtlinie verwenden (siehe autoscalingPolicies.update). Wenn eine Richtlinienaktualisierung nicht auf einen Cluster angewendet werden soll, der die Richtlinie verwendet, deaktivieren Sie das Autoscaling für den Cluster, bevor Sie die Richtlinie aktualisieren.

Google Cloud Console

Das Deaktivieren von Autoscaling für einen Cluster wird in der Google Cloud Console nicht unterstützt.

gcloud-CLI

Führen Sie den folgenden gcloud-Befehl in einem lokalen Terminal oder in Cloud Shell aus, um das Autoscaling für einen Cluster zu deaktivieren.

gcloud dataproc clusters update cluster-name --disable-autoscaling \
    --region=region

REST API

Um Autoscaling auf einem Cluster zu deaktivieren, setzen Sie AutoscalingConfig.policyUri auf den leeren String und legen Sie update_mask=config.autoscaling_config.policy_uri in einer clusters.patch-Anfrage fest.

• Eine Richtlinie, die von einem oder mehreren Clustern verwendet wird, kann nicht gelöscht werden (siehe autoscalingPolicies.delete).

Funktionsweise von Autoscaling

Beim Autoscaling werden die Hadoop-YARN-Messwerte des Clusters während jeder "Cooldown-Zeit" überprüft, um festzustellen, ob der Cluster skaliert werden soll und, wenn ja, in welchem Umfang.

1. Der Wert des YARN-Messwerts für ausstehende Ressourcen (ausstehender Arbeitsspeicher oder ausstehende Kerne) bestimmt, ob hoch- oder herunterskaliert werden soll. Ein Wert größer als 0 bedeutet, dass YARN-Jobs auf Ressourcen warten und möglicherweise eine Aufskalierung erforderlich ist. Der Wert 0 gibt an, dass YARN über ausreichende Ressourcen verfügt, sodass eine Herunterskalierung oder andere Änderungen möglicherweise nicht erforderlich sind.

   Wenn die Anzahl der ausstehenden Ressourcen > 0 ist:

   $estimated\_worker\_count =$

   \[ \Biggl \lceil AVERAGE\ during\ cooldown\ period\Big(\frac{Pending + Available + Allocated + Reserved}{Resource\ per\ worker}\Big)\Biggr \rceil \]

   Wenn die ausstehende Ressource 0 ist:

   $estimated\_worker\_count =$

   \[ \Biggl \lceil AVERAGE\ during\ cooldown\ period\Big(\frac{Allocated + Reserved}{Resource\ per\ worker}\Big)\Biggr \rceil \]

   Ab dem Managed Service for Apache Spark-Image 2.2 überwacht der Autoscaler standardmäßig den YARN-Arbeitsspeicher und die YARN-Cores, sodassestimated_worker_countseparat für Arbeitsspeicher und Cores ausgewertet wird und die resultierende höhere Anzahl von Workern ausgewählt wird. Bei früheren Image-Versionen überwacht das Autoscaling nur den YARN-Arbeitsspeicher, es sei denn, Sie aktivieren das kernbasierte Autoscaling, um sowohl den YARN-Arbeitsspeicher als auch die Kerne zu überwachen.

   $estimated\_worker\_count =$

   \[ max(estimated\_worker\_count\_by\_memory,\ estimated\_worker\_count\_by\_cores) \]

   \[ estimated\ \Delta worker = estimated\_worker\_count - current\_worker\_count \]

   Hinweis: Sekundäre Worker, einschließlich sekundärer Worker, die für die Erstellung geplant sind, sind in der aktuellen Worker-Anzahl enthalten.

2. Anhand der geschätzten Änderung der Anzahl der Worker wird mit scaleUpFactor oder scaleDownFactor die tatsächliche Änderung der Anzahl der Worker berechnet:

   if estimated Δworkers > 0:
     actual Δworkers = ROUND_UP(estimated Δworkers * scaleUpFactor)
     # examples:
     # ROUND_UP(estimated Δworkers=5 * scaleUpFactor=0.5) = 3
     # ROUND_UP(estimated Δworkers=0.8 * scaleUpFactor=0.5) = 1
   else:
     actual Δworkers = ROUND_DOWN(estimated Δworkers * scaleDownFactor)
     # examples:
     # ROUND_DOWN(estimated Δworkers=-5 * scaleDownFactor=0.5) = -2
     # ROUND_DOWN(estimated Δworkers=-0.8 * scaleDownFactor=0.5) = 0
     # ROUND_DOWN(estimated Δworkers=-1.5 * scaleDownFactor=0.5) = 0
   

   Ein scaleUpFactor oder scaleDownFactor von 1,0 bedeutet, dass das Autoscaling so skaliert wird, dass die ausstehende oder verfügbare Ressource 0 ist (perfekte Auslastung).

3. Sobald die Änderung der Anzahl der Worker berechnet wurde, dient entweder scaleUpMinWorkerFraction oder scaleDownMinWorkerFraction als Schwellenwert, um zu bestimmen, ob das Cluster durch Autoscaling skaliert wird. Ein kleiner Bruchteil bedeutet, dass das Autoscaling auch dann skalieren soll, wenn der Δworkers klein ist. Ein größerer Wert bedeutet, dass nur skaliert werden soll, wenn Δworkers groß ist.

   IF (Δworkers >  scaleUpMinWorkerFraction * current_worker_count) then scale up
   

   ODER

   IF (abs(Δworkers) >  scaleDownMinWorkerFraction * current_worker_count),
   THEN scale down.
   

4. Wenn die Anzahl der zu skalierenden Worker groß genug ist, um eine Skalierung auszulösen, verwendet Autoscaling die minInstances/maxInstances-Grenzen von workerConfig und secondaryWorkerConfig und weight (Verhältnis von primären zu sekundären Workern), um zu bestimmen, wie die Anzahl der Worker auf die primären und sekundären Worker-Instanzgruppen aufgeteilt werden soll. Das Ergebnis dieser Berechnungen ist die endgültige Änderung des Clusters, die das Autoscaling in diesem Skalierungszeitraum vornimmt.

5. Anfragen zum Herunterskalieren des Autoscalings werden für Cluster, die mit den Image-Versionen 2.0.57+, 2.1.5+ und höher erstellt wurden, in folgenden Fällen abgebrochen:

   1. eine Herunterskalierung mit einem Graceful Decommissioning-Zeitlimitwert ungleich null läuft und

   2. Die Anzahl der AKTIVEN YARN-Worker („aktive Worker“) plus die vom Autoscaler empfohlene Änderung der Gesamtzahl der Worker (Δworkers) ist gleich oder größer als DECOMMISSIONING YARN-Worker („Worker außer Betrieb nehmen“), wie in der folgenden Formel dargestellt:

      IF (active workers + Δworkers ≥ active workers + decommissioning workers)
      THEN cancel the scaledown operation
      

      In der Formel für die Abbruchbedingung für das Herunterskalieren wird die Anzahl der aktiven Worker berücksichtigt, nicht die current_worker_count (die in den vorherigen Autoscaling-Formeln verwendet wurde).

   Ein Beispiel für das Abbrechen einer Herunterskalierung finden Sie unter Wann wird eine Herunterskalierung durch Autoscaling abgebrochen?.

Empfehlungen für die Autoscaling-Konfiguration

Dieser Abschnitt enthält Empfehlungen zur Konfiguration des Autoscalings.

Primäre Worker nicht skalieren

Primäre Worker führen HDFS-Datanodes aus, während sekundäre Worker nur für die Verarbeitung zuständig sind. Durch die Verwendung sekundärer Worker können Sie Rechenressourcen effizient skalieren, ohne Speicher bereitstellen zu müssen. Das führt zu schnelleren Skalierungsfunktionen. HDFS-Namenodes können mehrere Race Conditions aufweisen, die dazu führen, dass HDFS beschädigt wird und die Außerbetriebnahme auf unbestimmte Zeit hängen bleibt. Vermeiden Sie die Skalierung primärer Worker, um dieses Problem zu umgehen. Beispiel: none workerConfig: minInstances: 10 maxInstances: 10 secondaryWorkerConfig: minInstances: 0 maxInstances: 100

Am Befehl zur Cluster-Erstellung müssen Sie einige Änderungen vornehmen:

1. Legen Sie --num-workers=10 fest, um die Größe der primären Workergruppe der Autoscaling-Richtlinie anzupassen.
2. Legen Sie --secondary-worker-type=non-preemptible fest, um sekundäre Worker als nicht abrufbar zu konfigurieren. (Es sei denn, dass VMs auf Abruf erwünscht sind).
3. Kopieren Sie die Hardwarekonfiguration von primären Worker auf sekundäre Worker. Legen Sie beispielsweise --secondary-worker-boot-disk-size=1000GB auf --worker-boot-disk-size=1000GB fest.

Verwenden Sie den Enhanced Flexibility Mode für Spark-Batchjobs

Verwenden Sie den Enhanced Flexibility Mode (EFM) mit Autoscaling, um:

ermöglichen ein schnelleres Herunterskalieren des Clusters, während Jobs ausgeführt werden.

Unterbrechungen laufender Jobs aufgrund einer Clusterverkleinerung verhindern

Unterbrechungen laufender Jobs aufgrund des vorzeitigen Beendens von sekundären Workern auf Abruf minimieren

Wenn EFM aktiviert ist, muss das Zeitlimit für die ordnungsgemäße Außerbetriebnahme der Autoscaling-Richtlinie auf 0s gesetzt werden. Die Autoscaling-Richtlinie darf nur sekundäre Worker automatisch skalieren.

Zeitlimit für die ordnungsgemäße Außerbetriebnahme auswählen

Autoscaling unterstützt die ordnungsgemäße Außerbetriebnahme von YARN, wenn Knoten aus einem Cluster entfernt werden. Die ordnungsgemäße Außerbetriebnahme ermöglicht es Anwendungen, nach dem Zufallsprinzip Teil der Daten zwischen den Phasen zu verschieben, um den Rückschrittfortschritt zu vermeiden. Das in einer Autoscaling-Richtlinie angegebene Zeitlimit für die ordnungsgemäße Außerbetriebnahme ist die Obergrenze für die Dauer, die YARN auf laufende Anwendungen (Anwendungen, die bei Beginn der Außerbetriebnahme ausgeführt wurden) wartet, bevor Knoten entfernt werden.

Hinweis: Während der ordnungsgemäßen Außerbetriebnahme wird das Autoscaling nicht hochskaliert. Es wird gewartet, bis ein Aktualisierungsvorgang, einschließlich der ordnungsgemäßen Außerbetriebnahme, abgeschlossen ist. Anschließend wird eine weitere Wartezeit (z. B. 2 Minuten) abgewartet, bevor ein weiterer Aktualisierungsvorgang ausgeführt wird.

Wenn ein Prozess nicht innerhalb des angegebenen Zeitlimits für die ordnungsgemäße Außerbetriebnahme abgeschlossen wird, wird der Worker-Knoten zwangsweise heruntergefahren, was zu Datenverlust oder Dienstunterbrechungen führen kann. Um dies zu vermeiden, legen Sie das Zeitlimit für die ordnungsgemäße Außerbetriebnahme auf einen Wert fest, der länger als der längste Job ist, der vom Cluster verarbeitet wird. Wenn Sie beispielsweise erwarten, dass Ihr längster Job eine Stunde lang ausgeführt wird, legen Sie das Zeitlimit auf mindestens eine Stunde (1h) fest.

Erwägen Sie Jobs, die länger als eine Stunde dauern, zu ihren eigenen sitzungsspezifischen Clustern zu migrieren und so eine ordnungsgemäße Außerbetriebnahme zu vermeiden.

scaleUpFactor festlegen

scaleUpFactor steuert, wie intensiv das Autoscaling einen Cluster hochskaliert. Geben Sie eine Zahl zwischen 0.0 und 1.0 an, um den Bruchteilswert der ausstehenden YARN-Ressource festzulegen, der das Hinzufügen von Knoten auslöst.

Wenn beispielsweise 100 ausstehende Container mit jeweils 512 MB vorhanden sind, sind 50 GB YARN-Arbeitsspeicher ausstehend. Wenn „scaleUpFactor“ 0.5 ist, fügt der Autoscaler genügend Knoten hinzu, um 25 GB YARN-Arbeitsspeicher hinzuzufügen. Wenn 0.1 hingegen gleich ist, fügt das Autoscaling genügend Knoten für 5 GB hinzu. Diese Werte entsprechen dem YARN-Arbeitsspeicher und nicht dem gesamten physisch auf einer VM verfügbaren Arbeitsspeicher.

Ein guter Ausgangspunkt ist 0.05 für MapReduce-Jobs und Spark-Jobs mit aktivierter dynamischer Zuweisung. Verwenden Sie für Spark-Jobs mit einer festen Executor-Anzahl und Tez-Jobs 1.0. Ein scaleUpFactor von 1.0 bedeutet, dass das Autoscaling so skaliert wird, dass die ausstehende oder verfügbare Ressource 0 ist (perfekte Auslastung).

Einstellen von scaleDownFactor

scaleDownFactor steuert, wie intensiv das Autoscaling einen Cluster herunterskaliert. Geben Sie eine Zahl zwischen 0.0 und 1.0 an, um den Bruchwert der verfügbaren YARN-Ressource festzulegen, der zum Entfernen von Knoten führt.

Lassen Sie diesen Wert für die meisten Cluster mit mehreren Jobs, die häufig hoch- und herunterskaliert werden müssen, auf 1.0. Aufgrund der ordnungsgemäßen Außerbetriebnahme sind Vorgänge zur horizontalen Skalierung deutlich langsamer als Vorgänge zur vertikalen Skalierung. Wenn Sie scaleDownFactor=1.0 festlegen, wird eine aggressive Herunterskalierungsrate festgelegt. Dadurch wird die Anzahl der Herunterskalierungsvorgänge minimiert, die erforderlich sind, um die entsprechende Clustergröße zu erreichen.

Legen Sie für Cluster, die mehr Stabilität benötigen, einen niedrigeren scaleDownFactor-Wert für eine langsamere Rate für die Herunterskalierung fest.

Legen Sie diesen Wert auf 0.0 fest, um ein Herunterskalieren des Clusters zu verhindern, z. B. bei Verwendung von sitzungsspezifischen oder Einzeljob-Clustern.

Hinweis: Wenn Sie sowohl scaleUpFactor als auch scaleDownFactor auf 0 setzen, wird Ihr Cluster nicht skaliert.

scaleUpMinWorkerFraction und scaleDownMinWorkerFraction festlegen

scaleUpMinWorkerFraction und scaleDownMinWorkerFraction werden mit scaleUpFactor oder scaleDownFactor verwendet und haben den Standardwert 0.0. Sie stellen die Schwellenwerte dar, bei denen der Autoscaler den Cluster hoch- oder herunterskaliert: die minimale Erhöhung oder Verringerung der Clustergröße, die erforderlich ist, um eine Anfrage zum Hoch- oder Herunterskalieren zu senden.

Beispiele: Das Autoscaling sendet keine Aktualisierungsanfrage, um einem Cluster mit 100 Knoten 5 Worker hinzuzufügen, es sei denn, scaleUpMinWorkerFraction ist kleiner oder gleich 0.05 (5%). Wenn der Wert auf 0.1 festgelegt ist, gibt das Autoscaling keine Anfrage zum Hochskalieren des Clusters aus. Wenn scaleDownMinWorkerFraction den Wert 0.05 hat, entfernt das Autoscaling mindestens 5 Knoten.

Der Standardwert von 0.0 gibt keinen Grenzwert an.

Es wird dringend empfohlen, für große Cluster (> 100 Knoten) einen höheren scaleDownMinWorkerFractionthresholds-Wert festzulegen, um kleine, unnötige Skalierungsvorgänge zu vermeiden.

Wartezeit auswählen

Mit cooldownPeriod wird ein Zeitraum festgelegt, in dem das Autoscaling keine Anfragen zur Änderung der Clustergröße ausgibt. Sie können damit die Häufigkeit von Autoscaling-Änderungen an der Clustergröße begrenzen.

Der Mindest- und Standardwert für cooldownPeriod beträgt zwei Minuten. Wenn in einer Richtlinie ein kürzerer cooldownPeriod festgelegt ist, wirken sich Änderungen an der Arbeitslast schneller auf die Clustergröße aus. Cluster können jedoch unnötig hoch- und herunterskaliert werden. Es wird empfohlen, scaleUpMinWorkerFraction und scaleDownMinWorkerFraction einer Richtlinie auf einen Wert ungleich Null zu setzen, wenn eine kürzere cooldownPeriod verwendet wird. So wird sichergestellt, dass der Cluster nur skaliert wird, wenn die Änderung der Ressourcennutzung groß genug ist, um eine Clusteraktualisierung zu rechtfertigen.

Wenn Ihre Arbeitslast empfindlich auf Änderungen der Clustergröße reagiert, können Sie die Wartezeit erhöhen. Wenn Sie beispielsweise einen Batchverarbeitungsjob ausführen, können Sie die Wartefrist auf 10 Minuten oder mehr festlegen. Experimentieren Sie mit verschiedenen Wartezeiten, um den Wert zu finden, der für Ihre Arbeitslast am besten geeignet ist.

Zählgrenzen und Gruppengewicht der Worker

Jede Worker-Gruppe hat minInstances und maxInstances, die ein festes Limit für die Größe jeder Gruppe konfigurieren.

Jede Gruppe hat außerdem einen Parameter namens weight, der das Zielsaldo zwischen den beiden Gruppen konfiguriert. Beachten Sie, dass dieser Parameter nur ein Hinweis ist. Wenn eine Gruppe die Mindest- oder Höchstgröße erreicht, werden Knoten nur der anderen Gruppe hinzugefügt oder daraus entfernt. Daher kann weight fast immer standardmäßig auf 1 bleiben.

Hinweis :Wenn minInstances oder maxInstances in einer Autoscaling-Richtlinie so aktualisiert werden, dass eine Clustergröße jetzt außerhalb des zulässigen Bereichs liegt, wird der Autoscaler nicht sofort auf die neuen Grenzen hoch- oder herunterskaliert. Stattdessen sorgt das Autoscaling dafür, dass der Cluster nicht weiter außerhalb der Grenzen skaliert wird. Weitere Informationen finden Sie unter https://issuetracker.google.com/160640545.

Achtung: Wenn Sie fürminInstances = maxInstances einstellen, wird Ihr Cluster nicht skaliert.

Autoscaling auf Grundlage von Kernen verwenden

Für CPU-intensive Anwendungen empfiehlt es sich, den Dominant Resource Calculator für die Ressourcenzuweisung zu verwenden. Dies ist die standardmäßige YARN-Konfiguration ab Managed Service for Apache Spark-Imageversion 2.2. Bei früheren Image-Versionen konfiguriert Managed Service for Apache Spark YARN so, dass Speichermesswerte für die Ressourcenzuweisung verwendet werden, sofern Sie beim Erstellen eines Clusters nicht die folgende Eigenschaft festlegen, um YARN für die Verwendung des Dominant Resource Calculator zu konfigurieren:

capacity-scheduler:yarn.scheduler.capacity.resource-calculator=org.apache.hadoop.yarn.util.resource.DominantResourceCalculator

Autoscaling-Messwerte und -Logs

Mit den folgenden Ressourcen und Tools können Sie Autoscaling-Vorgänge und deren Auswirkungen auf einen Cluster und seine Jobs überwachen.

Cloud Monitoring

Mit Cloud Monitoring können Sie:

• Von Autoscaling verwendete Messwerte anzeigen lassen
• Anzahl der Knotenmanager in einem Cluster anzeigen lassen
• Informationen dazu erhalten, warum Autoscaling einen Cluster skaliert oder nicht skaliert hat

Cloud Logging

Verwenden Sie Cloud Logging, um Logs vom Managed Service for Apache Spark Autoscaler aufzurufen.

1) Suchen Sie Logs für Ihren Cluster.

2) Wählen Sie dataproc.googleapis.com/autoscaler.

3) Maximieren Sie die Logeinträge, um das Feld status anzuzeigen. Die Logs sind im maschinenlesbaren Format JSON.

4) Erweitern Sie den Logeintrag, um Skalierungsempfehlungen, für Skalierungsentscheidungen verwendete Messwerte, die ursprüngliche Clustergröße und die neue Zielclustergröße zu sehen.

Hintergrund: Autoscaling mit Apache Hadoop und Apache Spark

In den folgenden Abschnitten wird erläutert, wie Autoscaling mit Hadoop YARN und Hadoop Mapreduce sowie mit Apache Spark, Spark Streaming und Spark Structured Streaming interagiert.

Hadoop YARN-Messwerte

Sie können das Autoscaling für jede YARN-basierte Ausführungs-Engine konfigurieren.

Hinweis: Die YARN-Ressource kann hier entweder YARN-Arbeitsspeicher oder YARN-Kern sein.

Das Autoscaling basiert auf den folgenden Hadoop YARN-Messwerten:

1. Allocated resource bezieht sich auf die gesamte YARN-Ressource, die von laufenden Containern im gesamten Cluster belegt wird. Wenn es 6 ausgeführte Container gibt, die bis zu 1 Ressourceneinheit verwenden können, gibt es 6 zugewiesene Ressourcen.

2. Available resource ist die YARN-Ressource im Cluster, die nicht von zugewiesenen Containern verwendet wird. Wenn es insgesamt 10 Ressourceneinheiten für alle Knotenmanager gibt und 6 davon zugewiesen sind, sind 4 Ressourcen verfügbar. Wenn im Cluster verfügbare (nicht verwendete) Ressourcen vorhanden sind, können durch Autoscaling Worker aus dem Cluster entfernt werden.

3. Pending resource ist die Summe der YARN-Ressourcenanfragen für ausstehende Container. Ausstehende Container warten darauf, dass in YARN Speicherplatz frei wird. Die ausstehende Ressource ist nur dann ungleich null, wenn die verfügbare Ressource null oder zu klein ist, um dem nächsten Container zugewiesen zu werden. Wenn ausstehende Container vorhanden sind, fügt Autoscaling dem Cluster gegebenenfalls Worker hinzu.

Sie können diese Messwerte in Cloud Monitoring aufrufen. Standardmäßig beträgt der YARN-Speicher 0,8 * Gesamtspeicher auf dem Cluster. Der verbleibende Speicher ist für andere Daemons und die Betriebssystemnutzung reserviert, z. B. den Seitencache. Sie können den Standardwert mit der YARN-Konfigurationseinstellung "yarn.nodemanager.resource.memory-mb" überschreiben (siehe Apache Hadoop YARN, HDFS, Spark und zugehörige Attribute).

Autoscaling und Hadoop MapReduce

MapReduce führt alle MapReduce-Aufgaben als separaten YARN-Container aus. Wenn ein Job beginnt, sendet MapReduce Containeranfragen für jede Map-Aufgabe, was zu einem großen Anstieg des ausstehenden YARN-Arbeitsspeichers führt. Wenn die Zuordnungsaufgaben abgeschlossen wurden, sinkt der Wert für den ausstehenden Speicher.

Wenn mapreduce.job.reduce.slowstart.completedmaps abgeschlossen ist (standardmäßig 95% bei Managed Service for Apache Spark), stellt MapReduce Containeranfragen für alle Reducer in die Warteschlange, was zu einem weiteren Anstieg des ausstehenden Arbeitsspeichers führt.

Legen Sie keinen hohen Wert für den Autoscaling-scaleUpFactor fest, es sei denn, die Zuordnung und das Reduzieren von Aufgaben dauern mehrere Minuten oder länger. Das Hinzufügen von Workern zum Cluster dauert mindestens 1,5 Minuten. Achten Sie daher darauf, dass genügend ausstehende Arbeitslast vorhanden ist, um neue Worker für einige Minuten zu verwenden. Ein guter Ausgangspunkt ist, scaleUpFactor auf 0,05 (5%) oder 0,1 (10%) des ausstehenden Arbeitsspeichers festzulegen.

Autoscaling und Spark

Spark fügt eine zusätzliche Ebene der Planung neben YARN hinzu. Genauer gesagt stellt die dynamische Zuordnung von Spark Core Anfragen an YARN nach Containern, die Spark-Executors ausführen, und plant dann Spark-Aufgaben für Threads auf diesen Executors. In Managed Service for Apache Spark-Clustern ist die dynamische Zuordnung standardmäßig aktiviert, sodass Executors nach Bedarf hinzugefügt und entfernt werden.

Spark fragt Container immer bei YARN an, aber ohne dynamische Zuordnung fragt es Container nur zu Beginn des Jobs an. Bei der dynamischen Zuordnung werden Container entfernt oder bei Bedarf neue Container angefragt.

Spark beginnt mit einer kleinen Anzahl von Executors – 2 in Autoscaling-Clustern – und verdoppelt die Anzahl der Executors, wenn Aufgaben im Rückstand sind. Dadurch wird ein sprunghafter Anstieg bzw. Abfall bei ausstehendem Speicher seltener. Es wird empfohlen, den Autoscaling-scaleUpFactor für Spark-Jobs auf eine große Zahl zu setzen, z. B. 1,0 (100 %).

Dynamische Zuordnung von Spark deaktivieren

Wenn Sie separate Spark-Jobs ausführen, die nicht von der dynamischen Spark-Zuweisung profitieren, können Sie die dynamische Spark-Zuweisung deaktivieren, indem Sie spark.dynamicAllocation.enabled=false und spark.executor.instances festlegen. Sie können Autoscaling weiterhin verwenden, um Cluster hoch oder herunter zu skalieren, während die einzelnen Spark-Jobs ausgeführt werden.

Spark-Jobs mit im Cache gespeicherten Daten

Legen Sie spark.dynamicAllocation.cachedExecutorIdleTimeout fest oder löschen Sie den Cache von Datasets, wenn sie nicht mehr benötigt werden. Standardmäßig entfernt Spark keine Executors mit im Cache gespeicherten Daten, die das Herunterskalieren des Clusters verhindern würden.

Autoscaling und Spark-Streaming

1. Da Spark Streaming eine eigene Version der dynamischen Zuordnung hat, die streamingspezifische Signale zum Hinzufügen und Entfernen von Executors verwendet, legen Sie spark.streaming.dynamicAllocation.enabled=true fest und deaktivieren Sie die dynamische Zuordnung von Spark Core, indem Sie spark.dynamicAllocation.enabled=false festlegen.

2. Verwenden Sie die ordnungsgemäße Außerbetriebnahme (Autoscaling gracefulDecommissionTimeout) nicht mit Spark Streaming-Jobs. Um Worker mit Autoscaling sicher zu entfernen, konfigurieren Sie stattdessen Checkpointing für Fehlertoleranz.

Alternativ können Sie Spark Streaming ohne Autoscaling verwenden:

1. Deaktivieren Sie die Spark Core-dynamische Zuordnung (spark.dynamicAllocation.enabled=false) und
2. Legen Sie die Anzahl der Executors (spark.executor.instances) für Ihren Job fest. Informationen dazu finden Sie unter Clusterattribute:

Autoscaling und Spark Structured Streaming

Autoscaling ist nicht mit Spark Structured Streaming kompatibel, da Spark Structured Streaming keine dynamische Zuweisung unterstützt (siehe SPARK-24815: Structured Streaming should support dynamic allocation).

Autoscaling durch Partitionierung und Parallelität steuern

Parallelität wird normalerweise durch Clusterressourcen festgelegt oder bestimmt, z. B. steuert die Anzahl der HDFS-Blöcke die Anzahl der Aufgaben. Beim Autoscaling ist jedoch das Gegenteil der Fall: Autoscaling legt die Clusterressourcen (Worker) anhand der Job-Parallelität fest. Diese Richtlinien können dabei helfen, die Job-Parallelität festzulegen:

• Managed Service for Apache Spark legt die Standardanzahl der MapReduce-Reduce-Aufgaben basierend auf der anfänglichen Clustergröße Ihres Clusters fest. Sie können jedoch mapreduce.job.reduces festlegen, um die Parallelität der Reduce-Phase zu erhöhen.
• Spark SQL und DataFrame-Parallelität werden durch spark.sql.shuffle.partitions bestimmt, die standardmäßig auf 200 gesetzt sind.
• Die RDD-Funktionen von Spark sind standardmäßig auf spark.default.parallelism gesetzt. Dieser Wert wird beim Start des Jobs auf die Anzahl der Kerne auf den Worker-Knoten festgelegt. Alle RDD-Funktionen, die Shuffles erstellen, verwenden jedoch einen Parameter für die Anzahl der Partitionen, der spark.default.parallelism überschreibt.

Achten Sie darauf, dass Ihre Daten gleichmäßig partitioniert sind. Wenn ein signifikanter Schlüsselversatz vorliegt, können eine oder mehrere Aufgaben erheblich länger dauern als andere Aufgaben, was zu einer geringen Auslastung führt.

Standardeinstellungen für Spark- und Hadoop-Attribute für Autoscaling

Autoscaling-Cluster haben Standardwerte für Clusterattribute, die dazu beitragen, Jobfehler zu vermeiden, wenn primäre Worker entfernt oder sekundäre Worker unterbrochen werden. Sie können diese Standardwerte überschreiben, wenn Sie einen Cluster mit Autoscaling erstellen. Informationen dazu finden Sie unter Clusterattribute.

Zur Erhöhung der Jobstabilität können Sie einen Cluster mit sekundären Workern auf Abruf erstellen. Ein Beispiel finden Sie unter Instanzen auf Abruf in einem Cluster.

Standardwerte für eine Erhöhung der maximalen Anzahl von Wiederholungen für Aufgaben, Application Master und Phasen:

yarn:yarn.resourcemanager.am.max-attempts=10
mapred:mapreduce.map.maxattempts=10
mapred:mapreduce.reduce.maxattempts=10
spark:spark.task.maxFailures=10
spark:spark.stage.maxConsecutiveAttempts=10

Standardwerte, um Wiederholungszähler zurückzusetzen. Dies kann bei lang andauernden Spark Streaming-Jobs hilfreich sein:

spark:spark.yarn.am.attemptFailuresValidityInterval=1h
spark:spark.yarn.executor.failuresValidityInterval=1h

Standardmäßig soll der Mechanismus für die dynamische Zuordnung von Spark mit einer kleinen Größe beginnen:

spark:spark.executor.instances=2

Hinweis :Auch wenn Sie Shuffle-Abruffehler sehen, wenn primäre Worker entfernt oder sekundäre Worker vorzeitig beendet werden, sollten Sie die Anzahl der Wiederholungsversuche für Shuffle-Abrufe nicht über die Standardwerte hinaus erhöhen (spark.shuffle.io.maxRetries=3; spark.shuffle.io.retryWaitMs=5000 (5 Sekunden) für einen maximalen Gesamtwiederholungszeitraum von 10 Sekunden). Grund: Shuffle-Dateien sind verloren gegangen. Zusätzliche Wiederholungsversuche kosten nur zusätzliche Zeit.

Häufig gestellte Fragen (FAQ)

In diesem Abschnitt finden Sie häufig gestellte Fragen und Antworten zum Autoscaling.

Kann Autoscaling für Cluster mit Hochverfügbarkeit und Einzelknotencluster aktiviert werden?

Autoscaling kann für Cluster mit Hochverfügbarkeit aktiviert werden, aber nicht für Cluster mit einem einzelnen Knoten. (Cluster mit einem einzelnen Knoten unterstützen keine Größenanpassung.)

Kann man Größe eines Autoscaling-Clusters manuell ändern?

Ja. Möglicherweise entscheiden Sie sich dafür, die Größe eines Clusters während der Feinabstimmung einer Autoscaling-Richtlinie manuell als Stopp festzulegen. Diese Änderungen sind jedoch nur vorübergehend wirksam, das Autoscaling übernimmt die Clusterskalierung früher oder später wieder.

Anstatt die Größe eines Autoscaling-Clusters manuell zu ändern, sollten Sie Folgendes in Betracht ziehen:

Aktualisieren der Autoscaling-Richtlinie Alle Änderungen an der Autoscaling-Richtlinie wirken sich auf alle Cluster aus, die die Richtlinie derzeit verwenden** (siehe Richtlinien für mehrere Cluster verwenden).

Richtlinie trennen und Cluster manuell auf die bevorzugte Größe skalieren.

Support für Managed Service for Apache Spark erhalten

Wie unterscheidet sich Managed Service for Apache Spark vom Dataflow-Autoscaling?

Weitere Informationen finden Sie unter Horizontales Dataflow-Autoscaling und Vertikales Dataflow Prime-Autoscaling.

Kann das Managed Service for Apache Spark-Entwicklungsteam den Clusterstatus von ERROR auf RUNNING zurücksetzen?

Im Allgemeinen nicht. Dazu ist ein manueller Aufwand erforderlich, um zu prüfen, ob es sicher ist, den Status des Clusters zurückzusetzen. Oft kann ein Cluster nicht ohne andere manuelle Schritte zurückgesetzt werden, z. B. durch Neustarten des HDFS-NameNode.

Managed Service for Apache Spark setzt den Status eines Clusters auf ERROR, wenn der Status eines Clusters nach einem fehlgeschlagenen Vorgang nicht ermittelt werden kann. Cluster in ERROR werden nicht automatisch skaliert. Das kann folgende Gründe haben:

• Fehler, die von der Compute Engine API zurückgegeben werden, oft während eines Compute Engine-Ausfalls.

• HDFS gerät aufgrund von Fehlern bei der HDFS-Außerbetriebnahme in einen beschädigten Zustand.

• Fehler bei der Dataproc Control API, z. B. „Task lease expired“ (Lease für Aufgabe abgelaufen).

Löschen Sie Cluster mit dem Status ERROR und erstellen Sie sie neu.

Wann wird ein Herunterskalierungsvorgang durch Autoscaling abgebrochen?

Die folgende Grafik zeigt, wann das Autoscaling einen Vorgang zum Herunterskalieren abbricht (siehe auch Funktionsweise von Autoscaling).

Hinweise:

• Für den Cluster ist Autoscaling nur auf Basis von YARN-Arbeitsspeichermesswerten aktiviert (Standardeinstellung).
• T1–T9 stellen Ruhephasen dar, in denen der Autoscaler die Anzahl der Worker auswertet (das Timing von Ereignissen wurde vereinfacht).
• Gestapelte Balken stellen die Anzahl der aktiven, außer Betrieb genommenen und außer Betrieb genommenen YARN-Worker des Clusters dar.
• Die vom Autoscaler empfohlene Anzahl von Workern (schwarze Linie) basiert auf YARN-Speichermesswerten, der Anzahl der aktiven YARN-Worker und den Einstellungen der Autoscaling-Richtlinie (siehe Funktionsweise von Autoscaling).
• Der rote Hintergrundbereich gibt den Zeitraum an, in dem der Herunterskalierungsvorgang ausgeführt wird.
• Der gelbe Hintergrundbereich gibt den Zeitraum an, in dem der Vorgang zum Herunterskalieren abgebrochen wird.
• Der grüne Hintergrundbereich gibt den Zeitraum des Scale-up-Vorgangs an.

Die folgenden Vorgänge finden zu den folgenden Zeiten statt:

• T1: Der Autoscaler initiiert einen ordnungsgemäßen Außerbetriebnahmevorgang, um etwa die Hälfte der aktuellen Cluster-Worker herunterzuskalieren.

• T2: Das Autoscaling überwacht weiterhin die Clustermesswerte. Die Empfehlung zur Herunterskalierung wird nicht geändert und der Vorgang wird fortgesetzt. Einige Worker wurden außer Betrieb genommen und andere werden gerade außer Betrieb genommen (Managed Service for Apache Spark löscht außer Betrieb genommene Worker).

• T3: Das Autoscaling berechnet, dass die Anzahl der Worker weiter herunterskaliert werden kann, möglicherweise weil zusätzlicher YARN-Arbeitsspeicher verfügbar wird. Da die Anzahl der aktiven Worker plus die empfohlene Änderung der Anzahl der Worker jedoch nicht gleich oder größer als die Anzahl der aktiven plus der außer Betrieb genommenen Worker ist, sind die Kriterien für den Abbruch des Herunterskalierens nicht erfüllt und das Autoscaling bricht den Vorgang nicht ab.

• T4: YARN meldet eine Zunahme des ausstehenden Arbeitsspeichers. Das Autoscaling ändert jedoch nicht die Empfehlung für die Anzahl der Worker. Wie in T3 sind die Kriterien für die Abbruch der Herunterskalierung weiterhin nicht erfüllt und der Autoscaler bricht den Herunterskalierungsvorgang nicht ab.

• T5: Der ausstehende YARN-Arbeitsspeicher nimmt zu und die vom Autoscaler empfohlene Änderung der Anzahl der Worker nimmt zu. Da die Anzahl der aktiven Worker plus die empfohlene Änderung der Anzahl der Worker jedoch geringer ist als die Anzahl der aktiven und der zu deaktivierenden Worker, sind die Kündigungskriterien weiterhin nicht erfüllt und der Skalierungsvorgang wird nicht abgebrochen.

• T6: Der ausstehende YARN-Arbeitsspeicher erhöht sich weiter. Die Anzahl der aktiven Worker plus die vom Autoscaler empfohlene Änderung der Anzahl der Worker ist jetzt größer als die Anzahl der aktiven Worker plus der Worker, die außer Betrieb genommen werden. Die Kündigungskriterien sind erfüllt und der Autoscaler bricht den Skalierungsvorgang ab.

• T7: Das Autoscaling wartet auf den Abschluss des Abbruchs des Herunterskalierungsvorgangs. Der Autoscaler bewertet und empfiehlt in diesem Intervall keine Änderung der Anzahl der Worker.

• T8: Der Abbruch des Vorgangs zum Herunterskalieren ist abgeschlossen. Die außer Betrieb genommenen Worker werden dem Cluster hinzugefügt und werden aktiv. Das Autoscaling erkennt den Abschluss des Abbruchs des Herunterskalierungsvorgangs und wartet auf den nächsten Bewertungszeitraum (T9), um die empfohlene Anzahl von Workern zu berechnen.

• T9: Zum Zeitpunkt T9 gibt es keine aktiven Vorgänge. Basierend auf der Autoscaling-Richtlinie und den YARN-Messwerten empfiehlt der Autoscaler einen Hochskalierungsvorgang.