Oltre a utilizzare le VM di Compute Engine standard come worker di Dataproc (chiamati worker "principali"), i cluster Dataproc possono utilizzare i worker di secondary.
Le seguenti caratteristiche si applicano a tutti i worker secondari in un cluster Dataproc:
Solo elaborazione: i worker secondari non archiviano i dati. Funzionano solo come nodi di elaborazione. Puoi quindi utilizzare worker secondari per scalare il calcolo senza scalare lo spazio di archiviazione.
Nessun cluster riservato ai lavoratori 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: i worker secondari utilizzano il tipo di macchina dei worker principali del cluster. Ad esempio, se crei un cluster con worker principali che utilizzano i tipi di macchine
n1-standard-4, tutti i worker secondari aggiunti al cluster utilizzeranno anche macchinen1-standard-4.Dimensioni del disco permanente: come opzione predefinita, i worker secondari vengono creati con dimensioni inferiori a 100 GB o con il disco di avvio principale. 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 il comando
gcloud dataproc clusters create --secondary-worker-boot-disk-sizeal momento della creazione del cluster. Puoi specificare questo flag anche se il cluster non avrà worker secondari al momento della sua creazione.Creazione asincrona: quando aggiungi worker secondari creando o scalando un cluster, il provisioning dei worker secondari potrebbe non essere eseguito prima del termine dell'operazione di creazione o aggiornamento. Questo perché Dataproc gestisce i worker secondari utilizzando i gruppi di istanze gestite, che creano 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 cluster, questi devono essere dello stesso tipo. Il tipo di worker secondario 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 o tutte e tre saranno VM prerilasciabili (standard) oppure tutte e tre saranno VM non prerilasciabili, ma non puoi specificare che saranno di tipo diverso.
Una VM spot è il tipo più recente di VM prerilasciabile di Compute Engine. Condivide il modello di prezzo con costo inferiore 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 di VM prerilasciabili e standard vengono recuperati e rimossi da un cluster Dataproc se sono richiesti 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 istanze prerilasciabili per ridurre i costi orari di calcolo per l'elaborazione dei dati non critici o creare cluster di grandi dimensioni a un costo totale inferiore (puoi utilizzare il Calcolatore prezzi di Google Cloud per stimare i costi).
Per ottenere risultati ottimali, il numero di worker prerilasciabili nel cluster deve essere inferiore al 50% del numero totale di tutti i worker (principale e tutti i worker secondari) nel cluster.
Quando utilizzi i worker prerilasciabili, è molto probabile che i job ricevano un numero maggiore di errori temporanei delle attività di singoli lavoratori rispetto ai job eseguiti su worker non prerilasciabili. Per aumentare la tolleranza dei job agli errori di attività di basso livello, puoi impostare valori delle proprietà del cluster simili ai valori delle proprietà predefiniti utilizzati con i cluster a scalabilità automatica, per aumentare il numero massimo di nuovi tentativi di attività ed evitare errori dei job.
Una considerazione per il risparmio sui costi: l'utilizzo di VM prerilasciabili non sempre consente di risparmiare sui costi, poiché i prerilasciamenti possono causare un'esecuzione dei job più lunga con conseguente aumento dei costi dei job. L'utilizzo della modalità di flessibilità avanzata (EFM) con le VM prerilasciabili può aiutare a mitigare questo risultato, ma il risparmio sui costi complessivi delle VM prerilasciabili varia a seconda del caso d'uso. In generale, i job di breve durata sono più adatti per l'uso di VM prerilasciabili, poiché la probabilità di prerilasci durante l'esecuzione del job sarà inferiore. Prova diverse opzioni dei job, ad esempio nessuna VM prerilasciabile 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 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 creazione per modificare il numero, ma non il tipo, dei worker secondari nel cluster.
- Gli aggiornamenti delle etichette vengono propagati a tutti i worker secondari prerilasciabili entro 24 ore. Gli aggiornamenti delle etichette non vengono propagati ai worker secondari non prerilasciabili esistenti. Gli aggiornamenti delle etichette vengono propagati a tutti i worker aggiunti a un cluster dopo un aggiornamento dell'etichetta. Ad esempio, se fai lo scale up del cluster, tutti i nuovi worker primaria e secondaria avranno le nuove etichette.
Console
Puoi specificare il numero di worker secondari durante la creazione di un cluster Dataproc dalla console Google Cloud. Dopo aver creato un cluster, puoi aggiungere e rimuovere i 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 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 gcloud
Utilizza il comando gcloud dataproc clusters create per aggiungere worker secondari a un cluster quando viene creato.
Dopo aver creato un cluster, puoi aggiungere o rimuovere worker secondari da o verso il cluster con il comando gcloud dataproc clusters update (è possibile aggiornare il numero ma non i tipi 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 i worker secondari non prerilasciabili durante la creazione di un cluster impostando --secondary-worker-type=non-preemptible (vedi esempio 2).
Il comando seguente 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 comando seguente 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 per aggiungere o rimuovere worker secondari, utilizza il comando gcloud dataproc clusters update con l'argomento --num-secondary-workers.
Il seguente comando aggiorna "example-cluster" per utilizzare quattro worker secondari (del tipo o del tipo predefiniti specificati 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 sua creazione. 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 i worker secondari.
EsempioLa seguente richiesta PATCH aggiorna un cluster in modo che abbia quattro worker secondari (del tipo o del tipo predefinito specificati quando hai creato il 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 all'autorizzazione dell'account di servizio: i worker secondari vengono creati tramite un
gruppo di istanze gestite
e Compute Engine utilizza
l'account di servizio Agente di servizio API di Google
del tuo progetto per eseguire operazioni con i gruppi di istanze gestite. Il formato del nome di questo account di servizio è il seguente:
project-id@cloudservices.gserviceaccount.com.
Se si verifica un problema di autorizzazione con questo account di servizio, i log di Dataproc non segnaleranno l'errore della creazione di worker secondari, ma i worker non riusciti saranno elencati nella scheda Istanze VM della pagina Dettagli cluster nella console Google Cloud senza segno di spunta verde (apri la pagina Dataproc Cluster, quindi fai clic sul nome del cluster per aprire la pagina Dettagli cluster).
Problemi relativi alle autorizzazioni per i gruppi di istanze gestite: per verificare se c'è un problema con le autorizzazioni per gruppi 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 corrispondenti. Il filtro per l'ID del gruppo di istanze mostrerà il nome del gruppo di istanze nel formato
dataproc-CLUSTER NAME-swe l'ID del gruppo di istanze sarà inserito automaticamente nella query di logging. Anziché utilizzare i filtri a discesa, puoi anche applicare un filtro di logging perresource.type="gce_instance_group"eresource.labels.instance_group_name="dataproc-CLUSTER NAME-sw".Problemi di autorizzazione delle 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 progetto (consulta l'articolo Concedere a un gruppo di istanze gestite l'accesso alle immagini). Se non viene 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]