Oltre a utilizzare le VM standard di Compute Engine come worker Dataproc (chiamati worker "primari"), i cluster Dataproc possono usare i worker secondary.
Le seguenti caratteristiche si applicano a tutti i worker secondari in un cluster Dataproc:
Solo elaborazione: i lavoratori secondari non archiviano dati. Funzionano solo come nodi di elaborazione. Di conseguenza, puoi utilizzare worker secondari per scalare il calcolo senza scalare lo spazio di archiviazione.
Nessun cluster solo worker secondari: il cluster deve avere worker principali. 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 il tipo di macchina dei worker principali del cluster. Ad esempio, se crei un cluster con worker principali che usano tipi di macchine
n1-standard-4, anche tutti i worker secondari aggiunti al cluster utilizzeranno macchinen1-standard-4.Invece di 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 VM flessibili di Dataproc.
Dimensioni del disco permanente: per impostazione predefinita, i worker secondari vengono creati con la dimensione inferiore, pari a 100 GB o al disco di avvio del worker principale. Questo spazio su disco viene utilizzato per la memorizzazione nella cache locale dei dati e non è disponibile tramite HDFS. Puoi eseguire l'override della dimensione predefinita del disco con il comando
gcloud dataproc clusters create --secondary-worker-boot-disk-sizedurante la creazione del cluster. Puoi specificare questo flag anche se il cluster non avrà worker secondari al momento della creazione.Creazione asincrona: quando aggiungi worker secondari creando o scalando un cluster, è possibile che non sia stato eseguito il provisioning dei worker secondari entro il 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 (consulta la pagina relativa al controllo dello 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 cluster, devono essere dello stesso tipo. Il tipo di worker secondario predefinito di Dataproc è la VM prerilasciabile standard.
Esempio: se selezioni tre worker secondari quando crei un cluster, puoi specificare che tutti e tre saranno VM spot o tutte e tre saranno VM prerilasciabili (standard) oppure tutte e tre saranno VM non prerilasciabili, ma non puoi specificare che ognuna sarà di tipo diverso.
Una VM spot è l'ultimo tipo di VM prerilasciabile di Compute Engine. Condivide il modello di prezzi a basso costo 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 prerilasciabile spot e standard vengono recuperati e rimossi da un cluster Dataproc se sono necessari da Google Cloud per altre attività.
Worker prerilasciabili
Sebbene la potenziale rimozione dei worker prerilasciabili possa influire sulla stabilità dei job, puoi decidere di utilizzare le istanze prerilasciabili per ridurre i costi orari di calcolo per l'elaborazione dei dati non critica o per creare cluster molto grandi a un costo totale inferiore (puoi utilizzare il Calcolatore prezzi di Google Cloud per una stima dei costi).
Per ottenere risultati ottimali, il numero di worker prerilasciabili nel cluster deve essere inferiore al 50% del numero totale di tutti i worker (primari più tutti i worker secondari) nel cluster.
Quando utilizzi worker prerilasciabili, è molto probabile che i tuoi job riscontreranno un numero maggiore di errori temporanei delle attività single-worker rispetto ai job eseguiti su worker non prerilasciabili. Per aumentare la tolleranza dei job agli errori delle attività di basso livello, puoi impostare valori delle proprietà del cluster simili ai valori predefiniti delle proprietà utilizzati con i cluster con scalabilità automatica per aumentare il numero massimo di nuovi tentativi delle attività ed evitare errori dei job.
Un aspetto per il risparmio sui costi: l'utilizzo delle VM prerilasciabili non sempre comporta un risparmio sui costi, poiché le prerilasci possono causare un'esecuzione dei job più lunga e, di conseguenza, maggiori costi per i job. Sebbene l'utilizzo della modalità di flessibilità avanzata (EFM) con le VM prerilasciabili possa aiutare a mitigare questo risultato, il risparmio complessivo dei costi delle VM prerilasciabili varia a seconda del caso d'uso. In genere, i job di breve durata sono più adatti all'utilizzo delle VM prerilasciabile, poiché la probabilità di prerilascio durante l'esecuzione del job sarà inferiore. Prova diverse opzioni di job, come nessuna VM 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. Per farlo, 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 la sua creazione 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. Gli aggiornamenti delle etichette non si propagano ai worker secondari non prerilasciabili esistenti. Gli aggiornamenti delle etichette si propagano a tutti i worker aggiunti a un cluster dopo un aggiornamento delle etichette. Ad esempio, se esegui lo scale up del cluster, tutti i nuovi worker principali e secondari avranno le nuove etichette.
Console
Puoi specificare il numero di worker secondari durante la creazione di un cluster Dataproc dalla console Google Cloud. Dopo la creazione di 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 del riquadro Configura nodi nella pagina Crea un cluster di Dataproc della console Google Cloud. Specifica il numero e il tipo di worker secondari 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 cluster nella pagina Cluster della console Google Cloud. Nella pagina Dettagli del cluster. Fai clic sulla scheda CONFIGURAZIONE, quindi su MODIFICA e aggiorna il numero 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 il comando gcloud dataproc clusters create per aggiungere worker secondari a un cluster quando viene creato.
Dopo la creazione di un cluster, puoi aggiungere o rimuovere worker secondari al o dal cluster con il comando gcloud dataproc clusters update (è possibile aggiornare il numero di worker secondari, ma non il tipo).
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 i 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).
Il seguente comando crea "cluster1" con due worker secondari standard prerilasciabili (tipo predefinito).
gcloud dataproc clusters create cluster1 \ --num-secondary-workers=2 \ --region=us-central1Esempio 2
Il seguente comando utilizza il flag 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 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
Per aggiornare un cluster al fine di aggiungere o rimuovere worker secondari, utilizza il comando gcloud dataproc clusters update con l'argomento --num-secondary-workers.
Il seguente comando aggiorna "example-cluster" in modo da 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 il comando gcloud dataproc clusters update con --num-secondary-workers impostato su 0.
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
Utilizza l'API Dataproc clusters.create per aggiungere worker secondari a un cluster al momento della creazione del cluster. Tieni presente che i worker secondari sono VM prerilasciabili standard per impostazione predefinita.
Esempio 1La 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 2La 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
Utilizza l'API Dataproc clusters.patch per aggiungere e rimuovere worker secondari.
EsempioLa seguente richiesta PATCH aggiorna un cluster in modo che abbia quattro 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 relativi ai worker secondari
Problemi relativi alle autorizzazioni per l'account di servizio: i worker secondari vengono creati tramite un
gruppo di istanze gestite
e Compute Engine utilizza l'account di servizio dell'agente di servizio delle API di Google
del tuo progetto per eseguire operazioni sui gruppi di istanze gestite. Il nome di questo account di servizio è formattato come segue:
project-id@cloudservices.gserviceaccount.com.
Se si verifica un problema di autorizzazione con questo account di servizio, i log di Dataproc non riporteranno l'errore durante la creazione dei worker secondari, ma i worker che hanno avuto esito negativo verranno elencati nella scheda ISTANZE VM della pagina Dettagli cluster della console Google Cloud senza un segno di spunta verde (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 per i gruppi di istanze gestite: per verificare se c'è un problema con le autorizzazioni per i gruppo di istanze gestite, visualizza i log in Esplora log 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à il nome del gruppo di istanze nel formato
dataproc-CLUSTER NAME-swe l'ID gruppo di istanze verrà completato automaticamente nella query di logging. Anziché utilizzare i filtri a discesa, puoi applicare un filtro di logging perresource.type="gce_instance_group"eresource.labels.instance_group_name="dataproc-CLUSTER NAME-sw".Problemi di autorizzazione per le immagini personalizzate: se le VM del cluster Dataproc vengono create con immagini personalizzate recuperate da un altro progetto, il ruolo
Compute Image Userdeve essere assegnato all'account di servizioproject-id@cloudservices.gserviceaccount.comdel tuo progetto (consulta Concedere a un gruppo di istanze gestite l'accesso alle immagini). Se non viene assegnato il ruolo corretto, nei log verrà visualizzato questo messaggio di errore:Required 'compute.images.useReadOnly' permission for 'projects/[IMAGE PROJECT]/global/images/[IMAGE NAME]