Sekundäre Dataproc-Worker

Zusätzlich zur Verwendung von standardmäßigen Compute Engine-VMs als Dataproc-Worker (als "primäre" Worker bezeichnet) können Dataproc-Cluster secondary-Worker verwenden.

Die folgenden Eigenschaften gelten für alle sekundären Worker in einem Dataproc-Cluster:

• Nur Verarbeitung – Sekundäre Worker speichern keine Daten. Sie funktionieren nur als Knotenknoten. Daher können Sie sekundäre Worker verwenden, um die Computing-Skalierung zu skalieren, ohne den Speicher zu skalieren.

• Keine nur sekundäre-Worker-Cluster: Ihr Cluster muss primäre Worker haben. Wenn Sie einen Cluster erstellen und die Anzahl der primären Worker nicht angeben, fügt Dataproc dem Cluster zwei primäre Worker hinzu.

• Maschinentyp: Sekundäre Worker verwenden standardmäßig den Maschinentyp der primären Worker des Clusters. Wenn Sie beispielsweise einen Cluster mit primären Workern erstellen, die n1-standard-4-Maschinentypen verwenden, werden alle sekundären Worker, die dem Cluster hinzugefügt wurden, ebenfalls n1-standard-4-Maschinen verwenden.

  Anstatt den standardmäßigen primären Worker-Maschinentyp für sekundäre Worker zu verwenden, können Sie eine oder mehrere Ranglisten von Maschinentypen für sekundäre Worker angeben. Weitere Informationen finden Sie unter Flexible Dataproc-VMs.

• Größe des nichtflüchtigen Speichers – Die sekundären Worker werden standardmäßig mit der kleineren Größe von 100 GB oder der Größe des Bootlaufwerks primärer Worker erstellt. Der Speicherplatz wird für das lokale Caching von Daten verwendet und ist nicht über HDFS verfügbar. Sie können die Standardlaufwerksgröße bei der Clustererstellung mit dem Befehl gcloud dataproc clusters create --secondary-worker-boot-disk-size überschreiben. Sie können dieses Flag auch dann angeben, wenn der Cluster beim Erstellen keine sekundären Worker hat.

• Asynchrone Erstellung: Wenn Sie durch Erstellen oder Skalieren eines Clusters sekundäre Worker hinzufügen, werden die sekundären Worker möglicherweise nicht zum Zeitpunkt der Erstellung oder Aktualisierung bereitgestellt. Das liegt daran, dass Dataproc sekundäre Worker mithilfe von verwalteten Instanzgruppen verwaltet, die VMs asynchron erstellen, sobald sie bereitgestellt werden können (sieheStatus verwalteter Instanzen prüfen).

Sekundäre Worker auf Abruf und nicht auf Abruf

Es gibt drei Arten von sekundären Workern: Spot-VMs, Standard-VMs auf Abruf und VMs auf Abruf. Wenn Sie sekundäre Worker für Ihren Cluster angeben, müssen diese vom gleichen Typ sein. Der standardmäßige sekundäre Dataproc-Worker-Typ ist die standardmäßige VM auf Abruf.

Beispiel: Wenn Sie beim Erstellen eines Clusters drei sekundäre Worker auswählen, können Sie festlegen, dass alle drei Spot-VMs oder alle drei (Standard-)VMS auf Abruf sind oder alle drei nicht auf Abruf verfügbare VMs sind. Sie können jedoch nicht angeben, dass es sich um einen anderen Typ handelt.

Eine Spot-VM ist der neueste Typ von Compute Engine-VMs auf Abruf. Es gilt das kostengünstigere Preismodell wie standardmäßige VMs auf Abruf. Im Gegensatz zu einer standardmäßigen VM auf Abruf mit einer maximalen Lebensdauer von 24 Stunden hat die Spot-VM jedoch keine maximale Lebensdauer. Sowohl Spot- als auch Standard-VM-Worker auf Abruf werden zurückgefordert und aus einem Dataproc-Cluster entfernt, wenn sie von Google Cloud für andere Aufgaben benötigt werden.

Worker auf Abruf

Hinweis: Wenn in den folgenden Abschnitten der Begriff „auf Abruf“ für VMs, Worker oder Knoten verwendet wird, bezieht sich dies sowohl auf die standardmäßigen präemptiven VM-Typen als auch auf Spot-VM-Typen auf Abruf, es sei denn, sie bezieht sich ausdrücklich ausschließlich auf den „standardmäßigen VM-Typ auf Abruf“.

• Die mögliche Entfernung von Workern auf Abruf kann die Stabilität des Jobs beeinträchtigen. Sie können sich aber auch für die Verwendung von Instanzen auf Abruf entscheiden, um die Computing-Kosten pro Stunde für nicht kritische Datenverarbeitung zu senken, oder um sehr große Cluster mit niedrigeren Gesamtkosten zu erstellen (die Kosten können Sie mit dem Google Cloud-Preisrechner schätzen).

• Die besten Ergebnisse erzielen Sie, wenn die Anzahl der Worker auf Abruf in Ihrem Cluster weniger als 50% der Gesamtzahl aller Worker (primäre und sekundäre Worker) im Cluster betragen sollte.

• Wenn Sie Worker auf Abruf verwenden, kommt es bei Ihren Jobs höchstwahrscheinlich zu einer größeren Anzahl vorübergehender Fehler bei Aufgaben einzelner Worker. Um die Jobtoleranz für Fehler auf niedriger Ebene zu erhöhen, können Sie Clusterattributwerte ähnlich den Standardattributwerten, die bei Autoscaling-Clustern verwendet werden festlegen, um die maximale Anzahl von Aufgabenwiederholungen zu erhöhen und Jobfehler zu vermeiden.

  Ziehen Sie den Modus für erhöhte Flexibilität in Betracht, wenn Sie VMs auf Abruf mit Spark verwenden.

• Kosteneinsparungen: Die Verwendung von VMs auf Abruf spart nicht immer Kosten, da vorzeitige Beenden-Vorgänge eine längere Jobausführung mit höheren Jobkosten verursachen können. Obwohl die Verwendung des Modus für erhöhte Flexibilität (Enhanced Flexibility Mode, EFM) mit VMs auf Abruf dieses Ergebnis abschwächen kann, variieren die Gesamtkosteneinsparungen durch VMs auf Abruf je nach Anwendungsfall. Im Allgemeinen sind kurzlebige Jobs besser für die Verwendung von VMs auf Abruf geeignet, da die Wahrscheinlichkeit eines vorzeitigen Beendens während der Jobausführung geringer ist. Probieren Sie verschiedene Joboptionen aus, z. B. keine VMs auf Abruf und VMs auf Abruf mit EFM, um die Kosten zu schätzen und die beste Lösung zu finden.

Nicht auf Abruf verfügbare Worker

• Sie können einen Cluster mit sekundären Workern erstellen, die nicht auf Abruf sind, um Computing-Ressourcen zu skalieren, ohne die Stabilität des Jobs zu beeinträchtigen. Geben Sie dazu als sekundären Worker-Typ "Nicht auf Abruf" an.

Sekundäre Worker verwenden

Sie können die Anzahl und den Typ der sekundären Worker angeben, wenn Sie einen Cluster über die Google Cloud Console, die gcloud CLI oder Dataproc API erstellen.

• Sekundäre Worker müssen vom gleichen Typ sein.
• Sie können den Cluster aktualisieren, nachdem er erstellt wurde, um die Anzahl zu ändern, jedoch nicht den Typ der sekundären Worker im Cluster.
• Labelaktualisierungen werden innerhalb von 24 Stunden an alle sekundären Worker auf Abruf übertragen. Labelaktualisierungen werden nicht an vorhandene sekundäre Worker, die nicht auf Abruf sind, weitergegeben. Labelaktualisierungen werden an alle Worker weitergegeben, die einem Cluster nach einer Labelaktualisierung hinzugefügt wurden. Wenn Sie beispielsweise den Cluster hochskalieren, haben alle neuen primären und sekundären Worker die neuen Labels.

Wenn Sie einem Cluster später sekundäre Worker hinzufügen möchten. Sie können beim Erstellen des Clusters 0 sekundäre Worker angeben (Beispiel für das gcloud-Befehls-Flag --num-secondary-workers=0) und den Cluster später aktualisieren, um eine positive Zahl und den Typ der sekundären Worker anzugeben. Wenn Sie den Cluster später aktualisieren möchten, um sekundäre Worker einzubeziehen, müssen Sie beim Erstellen des Clusters den "secondary-worker-type" angeben.

Console

Beim Erstellen eines Dataproc-Clusters über die Google Cloud Console können Sie die Anzahl der sekundären Worker angeben. Nachdem ein Cluster erstellt wurde, können Sie durch Bearbeiten der Clusterkonfiguration in der Google Cloud Console sekundäre Worker hinzufügen und entfernen.

Cluster mit sekundären Workern erstellen

Sie können die Anzahl und den Typ der sekundären Worker, die auf einen neuen Cluster angewendet werden sollen, im Bereich „Knoten konfigurieren“ der Dataproc-Seite Cluster erstellen der Google Cloud Console im Bereich „Knoten konfigurieren“ unter „Sekundäre Worker-Knoten“ festlegen. Geben Sie die Anzahl und den Typ der sekundären Worker in den Feldern "Sekundäre Worker-Knoten" und "Präemptivität" an.

Cluster mit sekundären Instanzen aktualisieren

Klicken Sie in der Google Cloud Console auf der Seite Cluster auf den Namen des Clusters, um die Anzahl der sekundären Worker in einem Cluster zu aktualisieren. Auf der Seite Clusterdetails. Klicken Sie auf den Tab KONFIGURATION und dann auf BEARBEITEN und aktualisieren Sie die Nummer im Feld „Sekundäre Worker-Knoten”.

Alle sekundären Instanzen aus einem Cluster entfernen

Wenn Sie alle sekundären Worker aus einem Cluster entfernen möchten, aktualisieren Sie die Clusterkonfiguration wie zuvor beschrieben und geben Sie im Feld "Sekundäre Worker-Knoten" 0 an.

gcloud-Befehl

Verwenden Sie den Befehl gcloud dataproc clusters create, um einem Cluster beim Erstellen sekundäre Worker hinzuzufügen. Nachdem ein Cluster erstellt wurde, können Sie mit dem Befehl gcloud dataproc clusters update sekundäre Worker hinzufügen oder entfernen. Die Anzahl der sekundären Worker, jedoch nicht der Typ, kann aktualisiert werden.

Cluster mit sekundären Workern erstellen

Verwenden Sie zum Erstellen eines Clusters mit sekundären Workern den Befehl gcloud dataproc clusters create mit dem Argument --num-secondary-workers. Beachten Sie, dass sekundäre Worker standardmäßig VMs auf Abruf sind. Sie können beim Erstellen eines Clusters sekundäre Worker angeben, die nicht auf Abruf sind. Legen Sie dazu --secondary-worker-type=non-preemptible fest. Das Attribut dataproc:secondary-workers.is-preemptible.override wird nicht mehr verwendet, um den Typ des sekundären Workers anzugeben.

Beispiel 1

Der folgende Befehl erstellt "cluster1" mit zwei sekundären Standard-Workern auf Abruf (Standardtyp).

gcloud dataproc clusters create cluster1 \
    --num-secondary-workers=2 \
    --region=us-central1

Beispiel 2

Im folgenden Befehl wird das Flag secondary-worker-type verwendet, um "cluster2" mit zwei sekundären Spot-Workern (auf Abruf) zu erstellen.

gcloud dataproc clusters create cluster2 \
    --num-secondary-workers=2 \
    --secondary-worker-type=spot \
    --region=us-central1

Beispiel 3:

Im folgenden Befehl wird das Flag secondary-worker-type verwendet, um "cluster3" mit zwei sekundären Workern nicht auf Abruf zu erstellen.

gcloud dataproc clusters create cluster3 \
    --num-secondary-workers=2 \
    --secondary-worker-type=non-preemptible \
    --region=us-central1

So ändern Sie die Größe des Bootlaufwerks der sekundären Worker: Standardmäßig werden alle sekundären Worker mit dem kleineren Speicherplatz von 100 GB oder der Größe des Bootlaufwerks des primären Workers erstellt. Der Speicherplatz wird für das lokale Caching von Daten verwendet und ist nicht über HDFS verfügbar. Sie können die Standardlaufwerksgröße beim Erstellen des Clusters mit dem Befehl gcloud dataproc clusters create --secondary-worker-boot-disk-size überschreiben. Dieses Flag kann auch dann angegeben werden, wenn der Cluster bei der Erstellung keine sekundären Worker hat.

Lassen Sie die Google Cloud Console Ihre Anfrage zur Clustererstellung erstellen. Sie können unten links auf der Dataproc-Seite Cluster erstellen auf den Link Entsprechende REST- oder Befehlszeile klicken, damit die Google Cloud Console eine entsprechende API REST-Anfrage oder einen Befehl des gcloud-Tools erstellt.

Cluster mit sekundären Workern aktualisieren

Wenn Sie einen Cluster aktualisieren möchten, um sekundäre Worker hinzuzufügen oder zu entfernen, verwenden Sie den Befehl gcloud dataproc clusters update mit dem Argument --num-secondary-workers.

Beispiel

Der folgende Befehl aktualisiert "example-cluster" so, dass vier sekundäre Worker des Standardtyps oder -typs verwendet werden, der beim Erstellen des Clusters angegeben wurde.

gcloud dataproc clusters update example-cluster \
    --num-secondary-workers=4 \
    --region=us-central1

Alle sekundären Worker aus einem Cluster entfernen

Verwenden Sie den Befehl gcloud dataproc clusters update, wobei --num-secondary-workers auf 0 gesetzt ist, um alle sekundären Worker aus einem Cluster zu entfernen.

Beispiel

Mit dem folgenden Befehl werden alle sekundären Worker aus "example-cluster" entfernt.

gcloud dataproc clusters update example-cluster \
    --num-secondary-workers=0 \
    --region=us-central1

REST API

Cluster mit sekundären Workern erstellen

Die clusters.create fügt sekundäre Worker einem Cluster hinzu, wenn der Cluster erstellt wird. Beachten Sie, dass sekundäre Worker standardmäßig VMs auf Abruf sind.

Beispiel 1

Mit der folgenden POST-Anfrage wird ein „cluster1“ mit zwei standardmäßigen VM-Workern (Standardtyp) auf Abruf erstellt.

POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster1",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2
    }
  }
}

Beispiel 2

Mit der folgenden POST-Anfrage wird ein „cluster2“ mit zwei Spot-VM-Workern (auf Abruf) erstellt.

POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster2",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2,
      "preemptibility": "SPOT"
    }
  }
}

Beispiel 3:

Die folgende POST-Anfrage erstellt "cluster3" mit zwei sekundären Workern, die nicht auf Abruf verfügbar sind.

POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster3",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2,
      "preemptibility": "NON_PREEMPTIBLE"
    }
  }
}

Cluster mit sekundären Workern aktualisieren

Mit der clusters.patch können Sie sekundäre Worker hinzufügen und entfernen.

Beispiel

Mit der folgenden PATCH-Anfrage wird ein Cluster so aktualisiert, dass er vier sekundäre Worker des Standardtyps oder ‐typs hat, der beim Erstellen des Clusters angegeben wurde.

PATCH /v1/projects/project-id/regions/region/clusters/cluster-name?updateMask=config.secondary_worker_config.num_instances
{
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 4
    }
  }
}

Lassen Sie die Google Cloud Console Ihre Anfrage zur Clustererstellung erstellen. Sie können unten links auf der Dataproc-Seite Cluster erstellen auf den Link Entsprechende REST- oder Befehlszeile klicken, damit die Google Cloud Console eine entsprechende API REST-Anfrage oder einen Befehl des gcloud-Tools erstellt.

Fehlerbehebung bei sekundären Workern

Probleme mit Dienstkontoberechtigungen: Sekundäre Worker werden über eine verwaltete Instanzgruppe erstellt und Compute Engine verwendet den Google APIs-Dienst Ihres Projekts Agent-Dienstkonto, um verwaltete Instanzgruppenvorgänge auszuführen. Der Name dieses Dienstkontos wird so formatiert: [e-mail].

Bei einem Berechtigungsproblem mit diesem Dienstkonto melden Dataproc-Logs nicht, dass sekundäre Worker nicht erstellt werden konnten. Fehlgeschlagene Worker werden jedoch auf der Seite Clusterdetails der Seite Clusterdetails in der Google Cloud Console ohne grünes Häkchen aufgeführt. Öffnen Sie dazu die Dataproc-Seite Cluster und klicken Sie auf den Clusternamen, um die Seite Clusterdetails für den Cluster zu öffnen.

• Probleme mit Berechtigungen für verwaltete Instanzgruppen: Wenn Sie prüfen möchten, ob ein Problem mit den Berechtigungen für verwaltete Instanzgruppen vorliegt, rufen Sie die Logs im Log-Explorer für "Google Compute Engine", Ressourcentyp der Instanzgruppe auf und filtern Sie nach der entsprechenden Instanzgruppen-ID. Über den Filter für die Instanzgruppen-ID wird der Name der Instanzgruppe im Format dataproc-CLUSTER NAME-sw angezeigt. Die Instanzgruppen-ID wird in der Logging-Abfrage automatisch eingefügt. Statt die Drop-down-Filter zu verwenden, können Sie auch einen Logging-Filter für resource.type="gce_instance_group" und resource.labels.instance_group_name="dataproc-CLUSTER NAME-sw" anwenden.

• Probleme mit Berechtigungen für benutzerdefinierte Images: Wenn Dataproc-Cluster-VMs mit benutzerdefinierten Images erstellt werden, die aus einem anderen Projekt abgerufen wurden, muss die Compute Image User Rolle dem folgenden Projekt zugewiesen werden:[e-mail] Dienstkonto (sieheEiner verwalteten Instanzgruppe Zugriff auf Images gewähren). Wenn nicht die richtige Rolle zugewiesen wurde, wird diese Fehlermeldung in den Logs angezeigt: Required 'compute.images.useReadOnly' permission for 'projects/[IMAGE PROJECT]/global/images/[IMAGE NAME]