Worker secondari Dataproc

Oltre a utilizzare le VM standard di Compute Engine come Dataproc worker (chiamati worker "primari"), i cluster Dataproc possono utilizzare secondary worker.

Le seguenti caratteristiche si applicano a tutti i worker secondari in un Cluster Dataproc:

  • Solo elaborazione: i worker secondari non archiviano i dati. Solo fungono da nodi di elaborazione. Pertanto, puoi utilizzare ai worker secondari per scalare il computing senza scalare l'archiviazione.

  • Nessun cluster secondario riservato ai worker: il cluster deve avere un cluster principale worker. Se crei un cluster e non specifichi il numero worker principali, Dataproc aggiunge due di fatturazione al cluster.

  • Tipo di macchina: per impostazione predefinita, i worker secondari utilizzano la classe tipo di macchina dei worker principali del cluster. Ad esempio, se crei una cluster con worker principali che utilizzano n1-standard-4 tipi di macchine, tutti i worker secondari aggiunti al cluster utilizzeranno anche n1-standard-4 macchine.

    Anziché utilizzare il tipo di macchina worker principale predefinito per i worker secondari, puoi specificare uno o più elenchi classificati di tipi di macchina per i worker secondari. Per ulteriori informazioni, consulta la sezione VM flessibili Dataproc.

  • Dimensione del disco permanente: per impostazione predefinita, i worker secondari vengono creati con almeno 100 GB o con la dimensione del disco di avvio del worker primario. Questo spazio su disco viene utilizzato per la memorizzazione nella cache locale dei dati e non è disponibile tramite HDFS. Puoi sostituire la dimensione predefinita del disco con gcloud dataproc clusters create --secondary-worker-boot-disk-size durante la creazione del cluster. Puoi specificare questo flag anche se il cluster non dispongono di worker secondari al momento della creazione.

  • Creazione asincrona: quando aggiungi worker secondari creando o facendo lo scale up di un cluster, prima che il provisioning dei worker secondari non venga eseguito l'operazione di creazione o aggiornamento. Il motivo è che Dataproc gestisce i worker secondari utilizzando i gruppi di istanze gestite, che creano Le VM in modo asincrono non appena è possibile eseguirne il provisioning (vedi Verificare lo stato delle istanze gestite ).

Worker secondari prerilasciabili e non prerilasciabili

Esistono tre tipi di worker secondari: VM spot, VM prerilasciabili standard e VM non prerilasciabili. Se specifichi worker secondari per il tuo cluster, devono essere dello stesso tipo. Dataproc predefinito è la VM prerilasciabile standard.

Esempio: se selezioni tre worker secondari quando crei un cluster, puoi specificare che tutte e tre saranno VM Spot, tutte e tre VM prerilasciabili (standard) o tutte e tre VM non prerilasciabili, ma non puoi specificare che ciascuna sarà di un tipo diverso.

Una VM spot è il tipo più recente di Compute Engine VM prerilasciabile. Condivide il modello di prezzi più basso delle VM prerilasciabili standard, ma, a differenza della VM prerilasciabile standard con una durata massima di 24 ore, la VM spot non ha una durata massima. Worker spot e VM prerilasciabile standard vengono recuperate e rimosse da un cluster Dataproc se come richiesto da Google Cloud per altre attività.

Worker prerilasciabili

  • Sebbene la potenziale rimozione di worker prerilasciabili possa influire sulla stabilità dei job, puoi decidere di utilizzare istanze prerilasciabili per ridurre i costi di calcolo per ora per l'elaborazione di dati non critici o per creare cluster di grandi dimensioni a un costo inferiore totale (puoi utilizzare il Calcolatore prezzi di Google Cloud per stimare i costi).

  • Per risultati ottimali, il numero di worker prerilasciabili nel cluster deve essere inferiore al 50% del numero totale di tutti i worker (principali più tutti i worker secondari) nel cluster.

  • Quando utilizzi worker prerilasciabili, è molto probabile che i job subiscano un di errori temporanei delle attività con un singolo worker rispetto ai job su worker non prerilasciabili. Per aumentare la tolleranza del job al livello basso delle attività non riuscite, puoi impostare valori delle proprietà del cluster simili valori predefiniti delle proprietà utilizzati con i cluster a scalabilità automatica per aumentare il numero massimo di nuovi tentativi delle attività ed evitare job errori.

  • Una considerazione per risparmiare sui costi: l'utilizzo di VM prerilasciabili non sempre consente di risparmiare poiché i prerilascio possono causare un'esecuzione del job più lunga con costi del lavoro più elevati. Anche se utilizzi la modalità di flessibilità avanzata (EFM) con le VM prerilasciabili può aiutare a mitigare questo risultato, il risparmio le VM prerilasciabili variano a seconda del caso d'uso. In genere, i job di breve durata sono più adatti all'utilizzo di VM prerilasciabili, poiché la probabilità di prerilanci durante l'esecuzione del job sarà inferiore. Prova diverse opzioni di job, ad esempio nessuna VM prerilasciabili e VM prerilasciabili con EFM, per stimare i costi e arrivare alla soluzione migliore.

Worker non prerilasciabili

  • Puoi creare un cluster con worker secondari non prerilasciabili da scalare senza sacrificare la stabilità del job. A questo scopo, specifica "non prerilasciabile" come tipo di worker secondario.

Utilizzo dei worker secondari

Puoi specificare il numero e il tipo di worker secondari quando crei un cluster utilizzando la console Google Cloud. gcloud CLI o l'API Dataproc.

  • I worker secondari devono essere dello stesso tipo.
  • Puoi aggiornare il cluster Dopo la creazione, per modificare il numero, ma non il tipo, di worker secondari nel tuo cluster.
  • Gli aggiornamenti delle etichette vengono propagati a tutti i worker secondari prerilasciabili entro 24 ore. Aggiornamenti delle etichette non si propagano ai worker secondari non prerilasciabili esistenti. Aggiornamenti delle etichette si propagano a tutti i worker aggiunti a un cluster dopo un aggiornamento delle etichette. Ad esempio: se fai lo scale up del cluster, tutti i nuovi worker principali e secondari avranno le nuove etichette.

Console

Puoi specificare il numero di worker secondari quando crei un cluster Dataproc dalla console Google Cloud. Dopo aver creato un cluster, puoi aggiungere e rimuovere worker secondari modificando la configurazione del cluster dalla console Google Cloud.

Creazione di un cluster con worker secondari

Puoi impostare il numero e il tipo di worker secondari da applicare a un nuovo cluster dalla sezione Nodi worker secondari della sezione Configura nodi nel riquadro Dataproc Crea un cluster della console Google Cloud. Specifica il numero e il tipo di worker secondari rispettivamente nei campi Nodi worker secondari e Prerilasciabilità.

Aggiornamento di un cluster con istanze secondarie

Per aggiornare il numero di worker secondari in un cluster, fai clic sul nome del in un cluster Kubernetes Cluster della console Google Cloud. Nella sezione Dettagli cluster . Fai clic sulla scheda CONFIGURAZIONE, quindi su MODIFICA e aggiorna nel campo Nodi worker secondari.

Rimozione di tutte le istanze secondarie da un cluster

Per rimuovere tutti i worker secondari da un cluster, aggiorna la configurazione del cluster come spiegato in precedenza, specificando 0 nel campo Nodi worker secondari.

Comando g-cloud

Utilizza la gcloud dataproc clusters create per aggiungere worker secondari a un cluster quando quest'ultimo viene creato. Dopo aver creato un cluster, puoi aggiungere o rimuovere worker secondari a o dal cluster con gcloud dataproc clusters update (è possibile aggiornare il numero ma non il tipo di worker secondari).

Creazione di un cluster con worker secondari

Per creare un cluster con worker secondari, utilizza gcloud dataproc clusters create con l'argomento --num-secondary-workers. Tieni presente che i worker secondari sono VM prerilasciabili standard per impostazione predefinita. Puoi specificare worker secondari non prerilasciabili quando crei un cluster impostando --secondary-worker-type=non-preemptible (la proprietà dataproc:secondary-workers.is-preemptible.override non viene più utilizzata per specificare il tipo di worker secondario).

Esempio 1

Il seguente comando crea "cluster1" con due worker secondari prerilasciabili (tipo predefinito) standard.

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

Il seguente comando utilizza secondary-worker-type per creare "cluster2" con due worker secondari spot (prerilasciabili).

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

Esempio 3

Il seguente comando utilizza secondary-worker-type per creare "cluster3" con due worker secondari non prerilasciabili.

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

Aggiornamento di un cluster con worker secondari in corso...

Per aggiornare un cluster per aggiungere o rimuovere worker secondari, utilizza gcloud dataproc clusters update con l'argomento --num-secondary-workers.

Esempio

Il seguente comando aggiorna "example-cluster" di utilizzare quattro worker secondari (del tipo o del tipo predefinito specificato al momento della creazione del cluster).

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

Rimozione di tutti i worker secondari da un cluster

Per rimuovere tutti i worker secondari da un cluster, utilizza gcloud dataproc clusters update con --num-secondary-workers impostato su 0.

Esempio

Il comando seguente rimuove tutti i worker secondari da "example-cluster".

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

API REST

Creazione di un cluster con worker secondari

Utilizzo di Dataproc clusters.create L'API consente di aggiungere worker secondari a un cluster al momento della creazione del cluster. Tieni presente che per impostazione predefinita i worker secondari sono VM prerilasciabili standard.

Esempio 1

La seguente richiesta POST crea un "cluster1" con due worker VM standard prerilasciabili (tipo predefinito).


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

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

La seguente richiesta POST crea un "cluster2" con due worker VM spot (prerilasciabili).


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

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

Esempio 3

La seguente richiesta POST crea "cluster3" con due worker secondari non prerilasciabili.


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

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

Aggiornamento di un cluster con worker secondari

Utilizzo di Dataproc clusters.patch API per aggiungere e rimuovere worker secondari.

Esempio

La seguente richiesta PATCH aggiorna un cluster in modo da avere worker secondari (del tipo o del tipo predefinito specificato al momento della creazione del cluster).


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

Risoluzione dei problemi dei worker secondari

Problemi di autorizzazione dell'account di servizio: i worker secondari vengono creati tramite un gruppo di istanze gestite e Compute Engine utilizza agente di servizio API di Google del progetto l'account di servizio per eseguire operazioni con gruppo di istanze gestite. Questo servizio il nome dell'account ha il seguente formato: project-id@cloudservices.gserviceaccount.com.

Se si verifica un problema di autorizzazione con questo account di servizio, Dataproc log non segnaleranno l'errore di creazione di worker secondari, ma di worker non riusciti verrà elencato nella scheda ISTANZE VM della pagina Dettagli cluster Console Google Cloud senza un segno di spunta verde (apri Dataproc Cluster, quindi fai clic sul cluster per aprire la pagina Dettagli cluster relativa al cluster).

  • Problemi con le autorizzazioni dei gruppi di istanze gestite: per verificare se è presente un problema con le autorizzazioni dei gruppi di istanze gestite, visualizza i log in Logs Explorer per il tipo di risorsa "Gruppo di istanze Google Compute Engine" e filtra in base all'ID gruppo di istanze corrispondente. Il filtro ID gruppo di istanze mostrerà nome del gruppo di istanze nel formato dataproc-CLUSTER NAME-sw e l'ID gruppo di istanze verrà compilato automaticamente nella query di logging. Invece di usando i filtri del menu a discesa, puoi anche applicare un filtro di logging per resource.type="gce_instance_group" e resource.labels.instance_group_name="dataproc-CLUSTER NAME-sw".

  • Problemi relativi alle autorizzazioni per le immagini personalizzate: se le VM del cluster Dataproc sono creato con immagini personalizzate recuperate da un altro progetto, È necessario assegnare il ruolo Compute Image User al ruolo Servizio project-id@cloudservices.gserviceaccount.com (vedi Concedere a un gruppo di istanze gestite l'accesso alle immagini). Se non è assegnato il ruolo corretto, verrà visualizzato questo messaggio di errore nei log: Required 'compute.images.useReadOnly' permission for 'projects/[IMAGE PROJECT]/global/images/[IMAGE NAME]