Pour éviter les Google Cloud frais pour 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é de cluster Dataproc, qui arrête toutes les VM du cluster. Les VM arrêtées ne sont pas facturées, mais les ressources associées, telles que les disques persistants, continuent de l'être.
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 de tâches ni accéder aux composants facultatifs à l'aide de la passerelle des composants Dataproc. Après avoir arrêté un cluster, vous pouvez le redémarrer et reprendre votre travail.
L'arrêt planifié des clusters est disponible pour les clusters créés avec les versions d'image 2.2.42+, 2.1.76+ et 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 demande de création du cluster.
L'arrêt planifié des clusters est compatible avec les clusters comportant des nœuds de calcul secondaires et les clusters à zéro nœud.
Vous pouvez modifier ou annuler la configuration de l'arrêt programmé du cluster.
Limites et points à noter
- L'arrêt planifié des clusters n'est pas compatible avec les clusters dotés de SSD locaux.
- Vous ne pouvez pas définir de valeurs d'arrêt planifié de cluster à l'aide de la console Google Cloud .
- Bien que vous puissiez mettre à jour la configuration d'arrêt planifié d'un cluster, une opération d'arrêt lancée se poursuivra. Pour vérifier si l'opération d'arrêt a commencé, examinez les journaux du cluster dans Cloud Logging.
- Si vous modifiez un programme d'arrêt sur un cluster dont l'heure d'arrêt planifiée est passée, la configuration de l'arrêt planifié est supprimée. Pour réactiver l'arrêt programmé, incluez une heure future dans votre demande de modification.
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 d'agent de service Dataproc IAM sur le compte de service de l'agent de service Dataproc
- Désactivation de l'API Dataproc dans le projet du 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'un job 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 celle de l'API Dataproc Jobs doivent être inactives pour que le calcul du temps d'inactivité du cluster commence et continue d'augmenter.
- L'activité YARN inclut les applications YARN en attente et en cours d'exécution.
- L'activité de l'API Jobs Dataproc inclut les tâches en attente et en cours d'exécution envoyées à l'API Jobs 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 Dataproc Jobs est inactive.
Utiliser l'arrêt planifié du cluster
gcloud CLI
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 de cluster scheduledstop précédemment définies.
Option | Description | Précision | Valeur minimale | Valeur maximale |
---|---|---|---|---|
--stop-max-idle 1 |
S'applique aux commandes de création et de mise à jour des clusters.
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 du cluster.
Annule l'arrêt planifié du cluster par l'indicateur --stop-max-idle précédemment défini. |
Non applicable | Non applicable | Non applicable |
--stop-expiration-time 2 |
S'applique aux commandes de création et de mise à jour des clusters. 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-age 2 |
S'applique aux commandes de création et de mise à jour des clusters.
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-idle
avec l'optionstop-expiration-time
oustop-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. - Vous pouvez transmettre l'option
stop-expiration-time
ou 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 les valeurs d'arrêt planifié d'un cluster en définissant les champs et les valeurs ClusterLifecycleConfig de l'API Dataproc listés dans le tableau suivant dans le cadre d'une requête d'API cluster.create ou cluster.patch de Dataproc.
Option | Description | Précision | Valeur minimale | Valeur maximale |
---|---|---|---|---|
idleStopTtl 1 |
S'applique aux commandes de création et de mise à jour des clusters.
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 |
autoStopTime 2 |
S'applique aux commandes de création et de mise à jour des clusters. 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 |
autoStopTtl 2 |
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 requête cluster.patch avec une durée vide pour annuler une valeur autoStopTtl précédemment définie. |
14 jours |
- Vous pouvez transmettre l'option
stop-max-idle
avec l'optionstop-expiration-time
oustop-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. - Vous pouvez transmettre l'option
stop-expiration-time
ou l'optionstop-max-age
à la commande de création ou de mise à jour de cluster, mais pas les deux.
Utiliser l'arrêt programmé avec la suppression programmé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, notez les contraintes suivantes :
La période
stop-max-idle
doit être inférieure ou égale à la périodedelete-max-idle
, ou à la période résultant dedelete-max-age
oudelete-expiration-time
.Les
stop-max-age
etstop-expiration-time
doivent être ultérieurs àdelete-max-age
etdelete-expiration-time
, respectivement.
Afficher les paramètres du cluster avec arrêt programmé
gcloud CLI
Vous pouvez utiliser la commande gcloud dataproc clusters list
pour vérifier que l'arrêt planifié d'un cluster est 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
d'un 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.
Alors que Dataproc calcule idleStartTime
en fonction de l'arrêt de l'activité des tâches, le mécanisme d'arrêt planifié des clusters tient compte à la fois de idleStartTime
et de 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 de l'inactivité pour la fonctionnalité d'arrêt planifié est réinitialisé. Cela signifie que le compte à rebours avant un arrêt programmé 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é du job 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
idleStopTtl
depuis sa dernière activation. - Le cluster doit être inactif pendant la durée spécifiée par
idleStopTtl
depuis la dernière réinitialisationidleStartTime
.
API REST
Vous pouvez faire une requête clusters.list
pour confirmer que l'arrêt planifié d'un cluster est activé.