Per evitare di incorrere in Google Cloud addebiti per un cluster inattivo o la necessità di eliminare e ricreare un cluster per evitare addebiti per il cluster, utilizza la funzionalità di arresto pianificato del cluster Dataproc, che arresta tutte le VM del cluster. Non ti vengono addebitati costi per le VM arrestate, ma continuano gli addebiti per le risorse associate, come i dischi permanenti.
L'arresto di un cluster arresta tutte le VM del cluster e causa l'errore di tutti i job in esecuzione. Quando un cluster viene arrestato, non puoi aggiornarlo, inviare job al cluster o accedere ai componenti facoltativi sul cluster utilizzando il gateway dei componenti di Dataproc. Dopo aver arrestato un cluster, puoi riavviarlo e riprendere il lavoro.
L'arresto pianificato del cluster è disponibile per i cluster creati con le versioni 2.2.42+, 2.1.76+ e 2.0.57+ e successive delle immagini.
Funzionalità
Puoi arrestare i cluster dopo un determinato periodo di inattività, in un orario futuro oppure dopo un periodo di tempo specificato dalla richiesta di creazione del cluster.
L'arresto pianificato del cluster supporta i cluster con worker secondari e i cluster con scalabilità a zero.
Puoi aggiornare o annullare la configurazione dell'arresto pianificato del cluster.
Limitazioni e considerazioni
- L'arresto pianificato del cluster non è supportato per i cluster con SSD locali.
- Non puoi impostare i valori di arresto pianificato del cluster utilizzando la console Google Cloud .
- Anche se puoi aggiornare una configurazione di arresto pianificato del cluster, un'operazione di arresto avviata continuerà. Per verificare se l'operazione di arresto è iniziata, esamina i log del cluster in Cloud Logging.
- L'aggiornamento di una pianificazione di arresto su un cluster che ha superato l'ora di arresto pianificata rimuove la configurazione di arresto pianificata. Per riattivare l'interruzione pianificata, includi un orario futuro nella richiesta di aggiornamento.
Azioni che disabilitano l'arresto pianificato del cluster
Mentre un cluster è in esecuzione, le seguenti azioni disabilitano l'arresto pianificato del cluster finché l'azione di disattivazione non viene annullata:
- Rimozione del ruolo Agente di servizio Dataproc IAM nell'account di servizio Agente di servizio Dataproc
- Disattivazione dell'API Dataproc nel progetto cluster
- Attivazione di Controlli di servizio VPC se l'account di servizio dell'agente di servizio (identità del control plane) di Dataproc non rientra nel perimetro.
Calcolo del tempo di inattività del cluster
Affinché un cluster venga considerato inattivo, devono essere soddisfatte le seguenti condizioni:
- La creazione del cluster è terminata (il tempo impiegato per il provisioning e l'avvio del cluster è escluso dal calcolo del tempo di inattività)
- nessun job è in esecuzione sul cluster
- il cluster non è in stato
STOPPED
L'invio di un job al cluster o l'arresto di un cluster reimposta il calcolo del tempo di inattività.
La dataproc:dataproc.cluster-ttl.consider-yarn-activity
proprietà del cluster
influisce sul calcolo del tempo di inattività del cluster nel seguente modo:
- Questa proprietà è attivata (impostata su
true
) per impostazione predefinita. - Quando questa proprietà è abilitata, sia l'attività dell'API YARN sia quella dell'API Dataproc Jobs deve essere inattiva per avviare e continuare a incrementare il calcolo del tempo di inattività del cluster.
- L'attività YARN include le applicazioni YARN in attesa e in esecuzione.
- L'attività dell'API Dataproc Jobs include i job in attesa e in esecuzione inviati all'API Dataproc Jobs.
- Quando questa proprietà è impostata su
false
, il calcolo del tempo di inattività del cluster inizia e continua solo quando l'attività dell'API Dataproc Jobs è inattiva.
Utilizzare l'arresto pianificato del cluster
Interfaccia a riga di comando gcloud
Puoi impostare i valori di arresto pianificato quando crei un cluster utilizzando Google Cloud CLI o l'API Dataproc. Dopo aver creato il cluster, puoi aggiornarlo per modificare o eliminare i valori di arresto pianificato del cluster impostati in precedenza.
Flag | Descrizione | Granularità più fine | Valore min | Valore massimo |
---|---|---|---|---|
--stop-max-idle 1 |
Si applica ai comandi di creazione e aggiornamento dei cluster.
La durata dal momento in cui il cluster entra nello stato inattivo
(dopo la creazione o l'avvio) al momento in cui il cluster inizia ad arrestarsi.
Fornisci la durata nel formato IntegerUnit , dove l'unità può
essere "s, m, h, d" (secondi, minuti, ore, giorni, rispettivamente). Esempi:
"30m" o "1d" (30 minuti o 1 giorno da quando il cluster diventa inattivo). |
1 secondo | 5 minuti | 14 giorni |
--no-stop-max-idle |
Si applica solo al comando di aggiornamento del cluster.
Annulla l'arresto pianificato del cluster in base al flag
--stop-max-idle impostato in precedenza |
Non applicabile | Non applicabile | Non applicabile |
--stop-expiration-time 2 |
Si applica ai comandi di creazione e aggiornamento dei cluster. L'ora in cui iniziare l'arresto del cluster nel formato datetime ISO 8601. Puoi generare la data e l'ora nel formato corretto utilizzando lo strumento di generazione dei timestamp. Ad esempio, "2017-08-22T13:31:48-08:00" specifica un orario di scadenza di 13:21:48 nel fuso orario UTC -8:00. | 1 secondo | 10 minuti da ora corrente | 14 giorni a partire dall'ora corrente |
--stop-max-age 2 |
Si applica ai comandi di creazione e aggiornamento dei cluster.
La durata dal momento dell'invio della richiesta di creazione del cluster
al momento in cui il cluster inizia a arrestarsi. Fornisci la durata
nel formato IntegerUnit , dove l'unità può essere "s, m, h, d"
(secondi, minuti, ore, giorni). Esempi: "30m": 30 minuti da ora;
"1d": 1 giorno da ora. |
1 secondo | 10 minuti | 14 giorni |
- Puoi passare il flag
stop-max-idle
con il flagstop-expiration-time
ostop-max-age
nella richiesta di creazione o aggiornamento del cluster. La prima condizione che diventa vera ha effetto per arrestare il cluster. - Puoi trasmettere il flag c
stop-expiration-time
o il flagstop-max-age
al comando di creazione o aggiornamento del cluster, ma non entrambi.
Esempio di creazione del cluster:
gcloud dataproc clusters create CLUSTER_NAME \ --region=REGION \ --stop-max-idle=DURATION \ --stop-expiration-time=TIME \ ... other flags ...
Esempio di aggiornamento del cluster:
Ad esempio:
gcloud dataproc clusters update CLUSTER_NAME \ --region=REGION \ --stop-max-idle=DURATION \ --no-stop-max-age \ ... other flags
API REST
Puoi creare o aggiornare i valori di arresto pianificato su un cluster impostando i campi e i valori ClusterLifecycleConfig dell'API Dataproc elencati nella tabella seguente nell'ambito di una richiesta API Dataproc cluster.create o cluster.patch.
Flag | Descrizione | Granularità più fine | Valore min | Valore massimo |
---|---|---|---|---|
idleStopTtl 1 |
Si applica ai comandi di creazione e aggiornamento dei cluster.
La durata dal momento in cui il cluster entra nello stato inattivo
dopo la creazione o l'aggiornamento del cluster al momento in cui il cluster
inizia a arrestarsi.
Fornisci una durata in secondi con un massimo di nove cifre frazionarie,
terminata da "s". Esempio: "3,5 s".
Invia una richiesta cluster.patch con una
durata vuota per annullare un valore idleDeleteTtl
impostato in precedenza. |
1 secondo | 5 minuti |
14 giorni |
autoStopTime 2 |
Si applica ai comandi di creazione e aggiornamento dei cluster. L'ora in cui iniziare ad arrestare il cluster. Fornisci un timestamp in formato RFC 3339 UTC "Zulu", preciso al nanosecondo. Esempio: "2014-10-02T15:01:23.045123456Z". | 1 secondo | 10 minuti dall'ora corrente | 14 giorni a partire dall'ora corrente |
autoStopTtl 2 |
Il periodo di tempo che intercorre tra l'invio della richiesta di creazione o aggiornamento del cluster e il momento in cui il cluster inizia a arrestarsi. Fornisci una durata in secondi con un massimo di nove cifre frazionarie, terminata da "s". Esempio: "3,5 s". | 1 secondo | 10 minuti. Invia una richiesta cluster.patch con una durata
vuota per annullare un valore autoStopTtl impostato in precedenza. |
14 giorni |
- Puoi passare il flag
stop-max-idle
con il flagstop-expiration-time
ostop-max-age
nella richiesta di creazione o aggiornamento del cluster. La prima condizione che diventa vera ha effetto per arrestare il cluster. - Puoi trasmettere il flag c
stop-expiration-time
o il flagstop-max-age
al comando di creazione o aggiornamento del cluster, ma non entrambi.
Utilizzo dell'arresto pianificato con l'eliminazione programmata
Se utilizzi sia l'arresto pianificato del cluster sia l'eliminazione pianificata del cluster durante la creazione o l'aggiornamento di un cluster, tieni presente i seguenti vincoli:
Il periodo
stop-max-idle
deve essere più breve o uguale al periododelete-max-idle
o al periodo risultante dadelete-max-age
odelete-expiration-time
.stop-max-age
estop-expiration-time
devono essere successive adelete-max-age
edelete-expiration-time
rispettivamente.
Visualizzare le impostazioni del cluster Sosta programmata
Interfaccia a riga di comando gcloud
Puoi utilizzare il comando gcloud dataproc clusters list
per
confermare che l'arresto pianificato di un cluster è abilitato.
gcloud dataproc clusters list \ --region=REGION
Esempio di output:
... NAME WORKER_COUNT ... SCHEDULED_STOP CLUSTER_ID NUMBER ... enabled ...
Puoi utilizzare il comando gcloud dataproc clusters describe
per
controllare le impostazioni di arresto pianificato del cluster LifecycleConfig
.
gcloud dataproc clusters describe CLUSTER_NAME \ --region=REGION
Esempio di output:
... lifecycleConfig: autoStopTime: '2018-11-28T19:33:48.146Z' idleStopTtl: 1800s idleStartTime: '2018-11-28T18:33:48.146Z' ...
I valori autoStopTime
e idleStopTtl
vengono impostati dall'utente. Dataproc genera il valore
idleStartTime
, ovvero l'ora di inizio di inattività più recente del cluster.
Mentre Dataproc calcola idleStartTime
in base
all'interruzione dell'attività del job, il meccanismo di arresto pianificato del cluster
prende in considerazione sia idleStartTime
sia l'ultima ora di inizio del cluster.
Nello specifico, se un cluster viene arrestato da un utente o da Dataproc,
il calcolo dell'inattività per la funzionalità di arresto pianificato viene reimpostato. Ciò significa che il conto alla rovescia per un arresto pianificato viene riavviato al successivo avvio del cluster. Tuttavia,
il idleStartTime
stesso non viene reimpostato quando viene riavviato un cluster arrestato. Continua a riflettere l'ultima occorrenza di inattività del job prima dell'interruzione.
Pertanto, affinché Dataproc
arresti un cluster in base a idleStopTtl
, devono essere soddisfatte due condizioni:
- Il cluster deve essere rimasto inattivo per la durata specificata da
idleStopTtl
dall'ultimo avvio. - Il cluster deve essere rimasto inattivo per la durata specificata da
idleStopTtl
dall'ultimo ripristino diidleStartTime
.
API REST
Puoi effettuare una richiesta
clusters.list
per confermare che l'arresto pianificato è abilitato per un cluster.