Worker secondari Dataproc

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

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

  • Solo elaborazione: i worker secondari non memorizzano i dati. Svolgono solo la funzione di 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 di worker principali, Dataproc aggiunge due worker principali 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 un cluster con worker principali che utilizzano tipi di macchine n1-standard-4, tutti i worker secondari aggiunti al cluster utilizzeranno anche macchine n1-standard-4.

    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 incrementando un cluster, il provisioning dei worker secondari potrebbe non essere completato al termine dell'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. Il tipo di worker secondario Dataproc predefinito è la VM preassegnabile standard.

Esempio: se selezioni tre worker secondari quando crei un cluster, puoi specificare che tutte e tre saranno VM spot oppure tutte e tre saranno (standard) VM prerilasciabili o tutte e tre saranno VM non prerilasciabili, ma non specificare che sono di 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. I worker VM prerilasciabili sia standard che spot vengono recuperati e rimossi da un cluster Dataproc se sono richiesti da Google Cloud per altre attività.

Worker preemptible

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

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

  • Quando utilizzi worker preemibili, i tuoi job avranno molto probabilmente un numero maggiore di errori transitori delle attività con un solo worker rispetto ai job eseguiti su worker non preemibili. 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. Sebbene l'utilizzo della modalità di flessibilità avanzata (EFM) con le VM prerilasciabili possa contribuire ad attenuare questo risultato, il risparmio complessivo delle VM prerilasciabili varierà in base a ogni 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 VM non prerilasciabili e VM prerilasciabili con EFM, per stimare i costi e trovare la soluzione migliore.

Worker non prerilasciabili

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

Utilizzo di 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 averlo creato per modificare il numero, ma non il tipo, di worker secondari nel cluster.
  • Gli aggiornamenti delle etichette si propagano a tutti i worker secondari prerilasciabili entro 24 ore. Aggiornamenti delle etichette non si propagano ai worker secondari non prerilasciabili esistenti. Gli aggiornamenti delle etichette vengono propagati a tutti i worker aggiunti a un cluster dopo un aggiornamento delle etichette. Ad esempio, se esegui l'aumento di dimensioni 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 nella 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 del riquadro Configura nodi nella pagina Dataproc Crea un cluster della console Google Cloud. Specifica il numero e il tipo di worker nei campi Nodi worker secondari e Prerilasciabilità, rispettivamente.

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 pagina Dettagli cluster. Fai clic sulla scheda CONFIGURAZIONE, poi su MODIFICA e aggiorna il numero nel campo Nodi di lavoro 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 il comando gcloud dataproc clusters create per aggiungere worker secondari a un cluster al momento della sua creazione. Dopo aver creato un cluster, puoi aggiungere o rimuovere worker secondari dal cluster o al cluster con il comando 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 il comando 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 il flag secondary-worker-type per creare "cluster3" con due worker secondari non prelevabili.

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" in modo da utilizzare quattro worker secondari (del tipo predefinito o del tipo specificato durante la 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 il comando gcloud dataproc clusters update con --num-secondary-workers impostato su 0.

Esempio

Il seguente comando 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. In caso di problemi di autorizzazione, i log di Dataproc non segnaleranno l'errore di creazione dei worker secondari, ma i worker non riusciti sono elencati nella scheda Istanze VM della pagina Dettagli cluster nella console Google Cloud senza un segno di spunta verde. Per visualizzare la scheda, apri la pagina Cluster di Dataproc, quindi fai clic sul nome del cluster per aprire la pagina Dettagli cluster del cluster.

  • Problemi relativi alle autorizzazioni dei gruppi di istanze gestite:per verificare se si è verificato un problema. con le autorizzazioni del gruppo di istanze gestite:

    1. Trova il nome del gruppo di istanze gestite (instanceGroupManagerName).

      Console

      1. Apri i cluster Dataproc fai clic sul nome del cluster per aprire la pagina Dettagli cluster per il cluster.
      2. Fai clic su REST equivalente nella parte inferiore della pagina, quindi visualizza il valore config.secondaryWorkerConfig.managedGroupConfig.instanceGroupManagerName.

      Google Cloud CLI

      Esegui il comando gcloud dataproc clusters describe con il flag --format per visualizzare instanceGroupManagerName. 
      gcloud dataproc clusters describe CLUSTER_NAME \
    --region=REGION \
    --format='value(config.secondaryWorkerConfig.managedGroupConfig.instanceGroupManagerName)'

      API REST

      Inviare una clusters.get per restituire il valore di config.secondaryWorkerConfig.managedGroupConfig.instanceGroupManagerName.
    2. Visualizza i log in Esplora log.

    • Seleziona il tipo di risorsa Google Compute Engine Instance Group e filtra in base al nome del gruppo di istanze gestite.

    • In alternativa, puoi applicare un filtro di logging per `resource.type="gce_instance_group" e resource.labels.instance_group_name=INSTANCE_GROUP_MANAGER_NAME.