Pour éviter les Google Cloud frais liés à un cluster inactif ou la nécessité de supprimer et de recréer un cluster pour éviter les frais liés au cluster, utilisez la fonctionnalité d'arrêt planifié du cluster Dataproc, qui arrête toutes les VM du cluster. Les VM arrêtées ne vous sont pas facturées, mais les frais continuent de s'appliquer aux ressources associées, telles que les disques persistants.
L'arrêt d'un cluster arrête toutes les VM du cluster et entraîne l'échec de toutes les tâches en cours d'exécution. Lorsqu'un cluster est arrêté, vous ne pouvez pas le mettre à jour, lui envoyer des tâches ni accéder aux composants facultatifs du cluster à l'aide de la passerelle de composants Dataproc. Après avoir arrêté un cluster, vous pouvez redémarrer le cluster et reprendre votre travail.
L'arrêt planifié du cluster est disponible pour les clusters créés avec les versions d'image 2.2.42+, 2.1.76+, 2.0.57+ et ultérieures.
Fonctionnalités
Vous pouvez arrêter les clusters après une période d'inactivité spécifiée, à une date et une heure ultérieures données ou après une période spécifiée à partir de la requête de création du cluster.
L'arrêt planifié du cluster est compatible avec les clusters avec nœuds de calcul secondaires et les clusters à zéro nœud.
Vous pouvez modifier ou annuler la configuration d'arrêt planifié du cluster.
Limites et points à noter
- L'arrêt planifié du cluster n'est pas compatible avec les clusters dotés de disques SSD locaux.
- Vous ne pouvez pas définir de valeurs d'arrêt planifié du cluster à l'aide de la Google Cloud console.
- Bien que vous puissiez modifier une configuration d'arrêt planifié du cluster, une opération d'arrêt lancée se poursuivra. Pour vérifier si l'opération d'arrêt a démarré, examinez les journaux du cluster dans Cloud Logging.
- La mise à jour d'une programmation d'arrêt sur un cluster dont l'heure d'arrêt planifiée est passée supprime la configuration d'arrêt planifié. Pour réactiver l'arrêt planifié, incluez une heure future dans votre requête de mise à jour.
Actions qui désactivent l'arrêt planifié du cluster
Lorsqu'un cluster est en cours d'exécution, les actions suivantes désactivent l'arrêt planifié du cluster jusqu'à ce qu'elles soient annulées :
- Suppression du rôle IAM Agent de service Dataproc sur le compte de service de l'agent de service Dataproc
- Désactivation de l'API Dataproc dans le projet de cluster
- Activation de VPC-Service Controls si le compte de service de l'agent de service Dataproc (identité du plan de contrôle) ne se trouve pas dans les limites du périmètre
Calcul du temps d'inactivité du cluster
Pour qu'un cluster soit considéré comme inactif, les conditions suivantes doivent être remplies :
- La création du cluster est terminée (le temps nécessaire au provisionnement et au démarrage du cluster est exclu du calcul du temps d'inactivité).
- Aucune tâche n'est en cours d'exécution sur le cluster.
- Le cluster n'est pas à l'état
STOPPED.
L'envoi d'une tâche au cluster ou l'arrêt d'un cluster réinitialise le calcul du temps d'inactivité.
La propriété de cluster dataproc:dataproc.cluster-ttl.consider-yarn-activity
affecte le calcul du temps d'inactivité du cluster, comme suit :
- Cette propriété est activée (définie sur
true) par défaut. - Lorsque cette propriété est activée, l'activité YARN et l'activité de l'API Jobs de Dataproc
doivent être inactives pour démarrer et continuer à incrémenter le calcul du temps d'inactivité du cluster.
- L'activité YARN inclut les applications YARN en attente et en cours d'exécution.
- L'activité de l'API Jobs de Dataproc inclut les tâches en attente et en cours d'exécution envoyées à l'API Jobs de Dataproc.
- Lorsque cette propriété est définie sur
false, le calcul du temps d'inactivité du cluster ne démarre et ne se poursuit que lorsque l'activité de l'API Jobs de Dataproc est inactive.
Utiliser l'arrêt planifié du cluster
CLI gcloud
Vous pouvez définir des valeurs d'arrêt planifié lorsque vous créez un cluster à l'aide de la Google Cloud CLI ou de l'API Dataproc. Une fois le cluster créé, vous pouvez le mettre à jour pour modifier ou supprimer les valeurs d'arrêt planifié du cluster précédemment définies sur le cluster.
| Option | Description | Précision | Valeur minimale | Valeur maximale |
|---|---|---|---|---|
--stop-max-idle1 |
S'applique aux commandes de création et de mise à jour de cluster.
Durée entre le moment où le cluster passe à l'état inactif
(après sa création ou son démarrage) et le moment où il commence à s'arrêter.
Indiquez la durée au format IntegerUnit, où l'unité peut
être "s, m, h, d" (respectivement : secondes, minutes, heures, jours). Exemples :
"30m" ou "1d" (30 minutes ou 1 jour après le moment où le cluster devient inactif). |
1 seconde | 5 minutes | 14 jours |
--no-stop-max-idle |
S'applique uniquement à la commande de mise à jour de cluster.
Annule l'arrêt planifié du cluster en fonction de l'option
--stop-max-idle précédemment définie. |
Non applicable | Non applicable | Non applicable |
--stop-expiration-time2 |
S'applique aux commandes de création et de mise à jour de cluster. Heure de début de l'arrêt du cluster au format date/heure ISO 8601. Vous pouvez générer la date et l'heure au format correct à l'aide du générateur d'horodatage. Par exemple, "2017-08-22T13:31:48-08:00" définit l'heure d'expiration sur 13:21:48 dans le fuseau horaire UTC -8:00. | 1 seconde | 10 minutes à partir de l'heure actuelle | 14 jours à partir de l'heure actuelle |
--stop-max-age2 |
S'applique aux commandes de création et de mise à jour de cluster.
Durée entre la soumission de la requête de création du cluster
et le moment où le cluster commence à s'arrêter. Indiquez la durée
au format IntegerUnit où l'unité peut être "s, m, h, d"
(respectivement : secondes, minutes, heures, jours). Exemples : "30m" (30 minutes à partir de maintenant) ;
"1d" (1 jour à partir de maintenant). |
1 seconde | 10 minutes | 14 jours |
- Vous pouvez transmettre l'option
stop-max-idleavec l'optionstop-expiration-timeoustop-max-agedans votre requête de création ou de mise à jour de cluster. La première option dont les paramètres sont remplis prend effet pour arrêter le cluster. - Vous pouvez transmettre l'option
stop-expiration-timeou l'optionstop-max-ageà la commande de création ou de mise à jour de cluster, mais pas les deux.
Exemple de création de cluster :
gcloud dataproc clusters create CLUSTER_NAME \ --region=REGION \ --stop-max-idle=DURATION \ --stop-expiration-time=TIME \ ... other flags ...
Exemple de mise à jour de cluster :
Exemple :
gcloud dataproc clusters update CLUSTER_NAME \ --region=REGION \ --stop-max-idle=DURATION \ --no-stop-max-age \ ... other flags
API REST
Vous pouvez créer ou mettre à jour des valeurs d'arrêt planifié sur un cluster en définissant les champs et les valeurs Dataproc API ClusterLifecycleConfig listés dans le tableau suivant dans le cadre d'une requête d'API Dataproc cluster.create ou cluster.patch.
| Option | Description | Précision | Valeur minimale | Valeur maximale |
|---|---|---|---|---|
idleStopTtl1 |
S'applique aux commandes de création et de mise à jour de cluster.
Durée entre le moment où le cluster passe à l'état inactif
après sa création ou sa mise à jour et le moment où il commence à s'arrêter.
Indiquez une durée en secondes avec un maximum de neuf chiffres après la virgule,
se termine par « s ». Exemple : "3.5s".
Envoyez une requête cluster.patch avec une durée vide pour annuler une valeur idleDeleteTtl
précédemment définie. |
1 seconde | 5 minutes |
14 jours |
autoStopTime2 |
S'applique aux commandes de création et de mise à jour de cluster. Heure de début de l'arrêt du cluster. Fournit un horodatage au format RFC 3339 UTC "Zulu", d'une justesse à la nanoseconde près. Exemple : « 2014-10-02T15:01:23.045123456Z ». | 1 seconde | 10 minutes à partir de l'heure actuelle | 14 jours à partir de l'heure actuelle |
autoStopTtl2 |
Durée entre la soumission de la requête de création ou de mise à jour du cluster et le moment où le cluster commence à s'arrêter. Indiquez une durée en secondes avec un maximum de neuf chiffres après la virgule. Se termine par « s ». Exemple : "3.5s". | 1 seconde | 10 minutes. Envoyez une cluster.patch requête avec une durée vide pour annuler une valeur autoStopTtl précédemment définie. |
14 jours |
- Vous pouvez transmettre l'option
stop-max-idleavec l'optionstop-expiration-timeoustop-max-agedans votre requête de création ou de mise à jour de cluster. La première option dont les paramètres sont remplis prend effet pour arrêter le cluster. - Vous pouvez transmettre l'option
stop-expiration-timeou l'optionstop-max-ageà la commande de création ou de mise à jour de cluster, mais pas les deux.
Utiliser l'arrêt planifié avec la suppression planifiée
La période
stop-max-idledoit être inférieure ou égale à ladelete-max-idlepériode, ou à la période résultant dedelete-max-ageoudelete-expiration-time.Les
stop-max-ageetstop-expiration-timedoivent être postérieurs àdelete-max-ageetdelete-expiration-time, respectivement.
Afficher les paramètres du cluster avec arrêt planifié
CLI gcloud
Vous pouvez utiliser la commande gcloud dataproc clusters list pour
confirmer qu'un cluster a l'arrêt planifié activé.
gcloud dataproc clusters list \ --region=REGION
Exemple de résultat :
... NAME WORKER_COUNT ... SCHEDULED_STOP CLUSTER_ID NUMBER ... enabled ...
Vous pouvez utiliser la commande gcloud dataproc clusters describe pour
vérifier les paramètres d'arrêt planifié LifecycleConfig du cluster.
gcloud dataproc clusters describe CLUSTER_NAME \ --region=REGION
Exemple de résultat :
... lifecycleConfig: autoStopTime: '2018-11-28T19:33:48.146Z' idleStopTtl: 1800s idleStartTime: '2018-11-28T18:33:48.146Z' ...
Les valeurs autoStopTime et idleStopTtl
sont définies par l'utilisateur. Dataproc génère la valeur
idleStartTime, qui correspond à la dernière heure de début d'inactivité du cluster.
Bien que Dataproc calcule idleStartTime en fonction de
l'arrêt de l'activité de la tâche, le mécanisme d'arrêt planifié du cluster
prend en compte à la fois idleStartTime et la dernière heure de démarrage du cluster.
Plus précisément, si un cluster est arrêté par un utilisateur ou par Dataproc,
le calcul d'inactivité de la fonctionnalité d'arrêt planifié est réinitialisé. Cela signifie que le
compte à rebours jusqu'à un arrêt planifié redémarre au prochain démarrage du cluster. Toutefois,
le idleStartTime lui-même n'est pas réinitialisé lorsqu'un cluster arrêté est
redémarré. Il continue de refléter la dernière occurrence d'inactivité de la tâche avant
l'arrêt.
Par conséquent, deux conditions doivent être remplies pour que Dataproc
arrête un cluster en fonction de idleStopTtl :
- Le cluster doit être inactif pendant la durée spécifiée par
idleStopTtldepuis son dernier démarrage. - Le cluster doit être inactif pendant la durée spécifiée par
idleStopTtldepuis la dernièreidleStartTimeréinitialisation.
API REST
Vous pouvez envoyer une
clusters.list
requête pour confirmer qu'un cluster a l'arrêt planifié activé.