Arrêt planifié du cluster

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 :

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 seconde10 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
Remarques :
  1. Vous pouvez transmettre l'option stop-max-idle avec l'option stop-expiration-time ou stop-max-age dans 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.
  2. Vous pouvez transmettre l'option stop-expiration-time ou l'option stop-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
Remarques :
  1. Vous pouvez transmettre l'option stop-max-idle avec l'option stop-expiration-time ou stop-max-age dans 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.
  2. Vous pouvez transmettre l'option stop-expiration-time ou l'option stop-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

Si vous utilisez à la fois l'arrêt planifié du cluster et la suppression planifiée du cluster lors de la création ou de la mise à jour d'un cluster, tenez compte des contraintes suivantes :

  • La période stop-max-idle doit être inférieure ou égale à la delete-max-idle période, ou à la période résultant de delete-max-age ou delete-expiration-time.

  • Les stop-max-age et stop-expiration-time doivent être postérieurs à delete-max-age et delete-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 :

  1. Le cluster doit être inactif pendant la durée spécifiée par idleStopTtl depuis son dernier démarrage.
  2. Le cluster doit être inactif pendant la durée spécifiée par idleStopTtl depuis la dernière idleStartTime réinitialisation.

API REST

Vous pouvez envoyer une clusters.list requête pour confirmer qu'un cluster a l'arrêt planifié activé.