Flexibilität und Effizienz von Clustern und Jobs maximieren

Auf dieser Seite finden Sie Best Practices und Planungsstrategien, mit denen Sie robuste Managed Service for Apache Spark-Cluster entwerfen können, die die Ressourcenverfügbarkeit in Google Cloud Regionen maximieren, Bereitstellungsverzögerungen reduzieren und Leistungs- und Kostenoptimierungen nutzen.

Übersicht über die Verfügbarkeit von Ressourcen

Wenn Sie Jobs auf starren Managed Service for Apache Spark-Clustern ausführen, entstehen Single Points of Failure, die zu Jobunterbrechungen sowie Cluster- und Jobfehlern aufgrund von lokaler Nichtverfügbarkeit oder Bereitstellungsverzögerungen führen können.

Das Risiko, dass Ressourcen nicht verfügbar sind, ist hoch, wenn Cluster mit einem der folgenden starren Anti-Pattern konfiguriert sind:

  • Feste Zonenplatzierung: Eine einzelne Zone wird mit dem Flag oder Feld zone hartcodiert, anstatt Managed Service for Apache Spark AutoZone zu erlauben, den Cluster dynamisch in der optimalen Zone zu platzieren. Dieses Anti-Pattern verhindert, dass bei der Clustererstellung Rechenressourcen verwendet werden, die in benachbarten Zonen verfügbar sind.
  • Einzelner Maschinentyp oder einzelne Generation pro Knotenrolle: Knotenrollen auf eine einzelne Maschinengeneration oder einen einzelnen Maschinentyp beschränken. Dieses Anti-Pattern verhindert, dass der Cluster auf Alternativen zurückgreift.
  • Zu wenige Maschinenfamilien mit dem höchsten Prioritätsrang: Es werden nur eine oder zwei Maschinenfamilien auf Rang 0 einer flexiblen VM-Richtlinie aufgeführt, auch wenn Fallback-Ränge definiert sind. Dieses Anti-Pattern schränkt den Pool an Ressourcen ein, aus dem Managed Service for Apache Spark zuerst schöpfen kann. Dadurch erhöht sich die Wahrscheinlichkeit, dass auf niedrigere Ränge zurückgegriffen wird oder es zu Verzögerungen bei der Bereitstellung kommt.
  • Vertikale Skalierung mit weniger großen VMs: Cluster werden vertikal skaliert, um eine kleine Anzahl großer VM-Formen zu verwenden. Dieses Anti-Pattern schränkt die Flexibilität bei der Planung ein.
  • Alles-oder-nichts-Clustererstellung: Alle Worker-Knoten müssen gleichzeitig bereitgestellt werden, anstatt die teilweise Clustererstellung in Kombination mit Autoscaling zu verwenden. Dieses Anti-Pattern führt dazu, dass die Clustererstellung fehlschlägt, wenn ein Worker-Knoten aufgrund vorübergehender Ressourcenunverfügbarkeit nicht zugewiesen werden kann.
  • Spitzen bei der Planung: Auslösen großer Batch-Pipelines während der Spitzenzeiten, was zu mehr regionalen Konflikten führt.

Ressourcenverfügbarkeit bedeutet, dass Jobs so konzipiert werden, dass sie hardwareflexibel, multizonal und skalierbar sind. Durch die Entkopplung von Clustern von starren Konfigurationen und die Aktivierung von Fallbacks für mehrere Maschinenfamilien können Sie die Erfolgsraten bei der Erstellung erhöhen, die Startlatenz minimieren und SLAs konsistent einhalten.

Empfehlungen zur Ressourcenbeschaffung

Wenden Sie die folgenden Optimierungen an, um die Ressourcenverfügbarkeit und Jobstabilität zu verbessern:

Flexible VMs verwenden

Mit dem Feature Flexible VM können Sie eine sortierte Liste von VM-Typen für Master-, primäre und sekundäre Worker-Knoten angeben. Dadurch wird die Erfolgsquote bei der Erstellung erhöht, da die aufgeführten VM-Typen ausgewertet und automatisch Zonen mit verfügbarer Kapazität ausgewählt werden.

Empfehlungen: Verwenden Sie flexible VMs mit Laufwerksüberschreibungen, damit Sie verschiedene Laufwerkstypen wie Hyperdisk und Persistent Disk für verschiedene Kandidaten-Maschinenfamilien in derselben Clusterrichtlinie angeben können. Sie können auch Gen2- und Gen4-Maschinenfamilien in einer einzigen Richtlinie kombinieren, um Jobs über einen größeren Pool zu skalieren und Kapazitätslimits zu umgehen.

Geben Sie mindestens drei verschiedene Maschinenfamilien mit Rang 0 an. Managed Service for Apache Spark greift zuerst auf die Liste mit der höchsten Priorität (Rang 0) zurück. Ein breiter Rang 0 bietet also den größten Pool an Kandidatenressourcen für die Clustererstellung, bevor auf niedrigere Ränge zurückgegriffen wird. Die Kombination von Gen4- und Gen2-Familien auf Rang 0 ist die effektivste Methode, um diesen Pool zu erweitern.

Verwenden Sie für Arbeitslasten für allgemeine Zwecke, z. B. Jobs, die derzeit auf N2- oder N2D-Maschinen ausgeführt werden, die folgenden Rankings:

  • Rang 0: N4, N4D (mit Hyperdisk Balanced), N2, N2D
  • Rang 1: C4, C4D (mit Hyperdisk Balanced), C2D. Lokale SSDs können mit C4 und C4D verwendet werden, aber in der Regel unterstützen 8 oder 16 Kerne nur 1–2 lokale SSDs.
  • Rang 2: E2 (geringere Leistung; nur bei Bedarf verwenden)

Für Jobs, die n2d-standard-16 verwenden, sind die Rankings beispielsweise:

  • Rang 0: n4-standard-16, n4d-standard-16, n2-standard-16, n2d-standard-16
  • Rang 1: c4-standard-16, c4d-standard-16, c2d-standard-16
  • Rang 2: e2-standard-16

Da N4 und N4D Hyperdisk erfordern und N2 und N2D nichtflüchtigen Speicher verwenden, definieren Sie Rang 0 als zwei Instanzauswahlen, die denselben Rang haben, aber unterschiedliche diskConfig-Werte verwenden. Mit den folgenden gcloud dataproc clusters create-Flags wird beispielsweise die Richtlinie für primäre Worker für das vorherige Beispiel definiert:

gcloud dataproc clusters create CLUSTER_NAME \
    --region=REGION \
    --zone="" \
    --num-workers=NUM_WORKERS \
    --worker-instance-selection='{"machineTypes":["n4-standard-16","n4d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["n2-standard-16","n2d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["c4-standard-16","c4d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["c2d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["e2-standard-16"],"rank":2,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}'

Beachten Sie bei der Verwendung flexibler VMs die folgenden Faktoren:

  • Unterstützung für gemischte Laufwerkstypen: Gen3- und Gen4-Maschinentypen unterstützen nur Hyperdisk-Laufwerkstypen und keine Persistent Disk-Typen. Wenn Sie Gen2 und Gen4 kombinieren, geben Sie für jede Instanzauswahl in der instanceFlexibilityPolicy einen diskConfig an. Weitere Informationen finden Sie unter Laufwerksüberschreibungen.

  • Ressourcenkontingente: Wenn Sie eine flexible VM-Richtlinie mit Fallback-Typen definieren, prüft Compute Engine die Kontingente für alle Kandidatentypen und Laufwerke in der Region. Achten Sie darauf, dass Ihrem Projekt für alle konfigurierten Elemente ausreichende Compute- und Laufwerkskontingente zugewiesen sind.

  • Compute Engine-Rabatte: Nutzen Sie flexible Rabatte für zugesicherte Nutzung (CUDs), um ausgabenbasierte Einsparungen für mehrere VM-Familien und Regionen zu erzielen.

  • Preise: Mit dem Google Cloud -Preisrechner können Sie die Kosten für jeden Rang in Ihrer Richtlinie vergleichen.

Konfigurationsvorlagen und Bereitstellungsbeispiele finden Sie hier:

Automatische Zonenplatzierung verwenden

Mit der AutoZone-Platzierung kann Managed Service for Apache Spark die beste Zone für die Bereitstellung von Ressourcen auswählen. Wenn Sie benutzerdefinierte VPC-Netzwerke (Virtual Private Cloud) verwenden, achten Sie darauf, dass das Subnetz in allen regionalen Zonen genügend IP-Adressen hat.

Kleinere Maschinenformen verwenden

Entwerfen Sie Jobs so, dass sie horizontal über kleinere Maschinentypen (4, 8 oder 16 Kerne) skaliert werden, anstatt vertikal mit größeren VMs. Kleinere VM-Größen haben eine höhere Verfügbarkeit in allen Zonen, was Verzögerungen bei der Erstellung verhindert.

  • Überprüfen Sie Jobs, die große Maschinentypen für Treiberknoten verwenden, und passen Sie sie an.
  • Prüfen Sie Jobs, die nur Treiberknoten ohne Worker-Knoten ausführen (Cluster mit einem einzelnen Knoten). Jobs, die auf Clustern mit einem einzelnen Knoten ausgeführt werden, können nicht dynamisch skaliert werden und binden die Ausführung an einen einzelnen physischen Host.

Cluster-Autoscaling verwenden

Verwenden Sie Cluster-Autoscaling mit einer ausreichenden maximalen Anzahl von Instanzen, um die Kapazität für Jobs mit Ressourcenschwankungen (Spitzen) zu verwalten.

Teilweise Clustererstellung mit Autoscaling verwenden

Verwenden Sie die partielle Clustererstellung, mit der Sie eine Mindestanzahl von primären Workern mit Autoscaling angeben können. Wenn der Cluster mit weniger Workern als angefordert gestartet wird, kann das Autoscaling dynamisch weitere Worker hinzufügen, sobald Ressourcen verfügbar sind.

Jobs außerhalb der Spitzenzeiten planen

Planen Sie Jobs außerhalb der Spitzenzeiten, z. B. mittags und am Wochenende. Planen Sie zu unüblichen Zeiten, z. B. um 10:07 statt um 10:00, um Planungsspitzen zu vermeiden.

Nächste Schritte