Procéder à l'autoscaling des clusters

.

Qu'est-ce que l'autoscaling ?

Il est difficile d'estimer le nombre "correct" de nœuds de calcul du cluster pour une charge de travail ; la plupart du temps, une taille de cluster unique pour un pipeline entier n'est pas la solution idéale. Le scaling du cluster déclenché par l'utilisateur résout partiellement ce problème, mais nécessite de surveiller l'utilisation du cluster et une intervention manuelle.

L'API AutoscalingPolicies Dataproc fournit un mécanisme permettant d'automatiser la gestion des ressources du cluster et d'activer l'autoscaling du cluster. Les règles Autoscaling Policy sont des configurations réutilisables, qui décrivent comment les clusters utilisant une règle donnée doivent effectuer leur scaling. Elles définissent des limites de scaling, des paramètres de fréquence et d'agressivité afin de fournir un contrôle ultraprécis sur les ressources du cluster tout au long de son existence.

Quand utiliser l'autoscaling

Utiliser l'autoscaling :

pour des clusters qui stockent des données dans des services externes, tels que Cloud Storage ou BigQuery

pour des clusters qui traitent de nombreuses tâches

pour faire effectuer un scaling à la hausse des clusters de tâches uniques

L'autoscaling n'est pas recommandé avec les éléments suivants :

  • Clusters à haute disponibilité : utilisez plutôt des clusters standards, qui sont plus stables après des opérations de redimensionnement successives.

  • HDFS : l'autoscaling n'est pas conçu pour le scaling de cluster HDFS. Si vous utilisez l'autoscaling avec HDFS, assurez-vous que le nombre minimal de nœuds de calcul principaux est suffisant pour gérer toutes les données HDFS. Notez également que la mise hors service des DataNodes HDFS peut retarder le retrait des nœuds de calcul.

  • Libellés des nœuds YARN : l'autoscaling n'est pas compatible avec les libellés de nœuds YARN, ni la propriété dataproc:am.primary_only en raison de YARN-9088. YARN signale incorrectement les métriques de cluster lorsque des libellés de nœuds sont utilisés.

  • Spark Structured Streaming : l'autoscaling n'est pas compatible avec Spark Structured Streaming (consultez la section Autoscaling et Spark Structured Streaming).

  • Clusters inactifs : l'autoscaling n'est pas recommandé pour la réduction de la taille d'un cluster à sa taille minimale lorsqu'il est inactif. La création d'un cluster étant aussi rapide que son redimensionnement, envisagez de supprimer les clusters inactifs et de les recréer au besoin. Les outils suivants facilitent ce modèle "éphémère" :

    Utilisez les workflows Dataproc pour planifier un ensemble de tâches sur un cluster dédié, puis supprimez le cluster lorsque les tâches sont terminées. Pour une orchestration plus avancée, utilisez le service Cloud Composer qui est basé sur Apache Airflow.

    Pour les clusters qui traitent des requêtes adhoc ou des flux de travail planifiés en externe, utilisez la suppression planifiée du cluster pour supprimer le cluster après une période d'inactivité ou une durée spécifiée, ou à une heure spécifique.

Activer l'autoscaling

Pour activer l'autoscaling sur un cluster :

  1. Créez une règle d'autoscaling.

  2. L'une des options ci-dessous :

    1. Créez un cluster d'autoscaling, ou
    2. Activez l'autoscaling sur un cluster existant.

Créer une règle d'autoscaling

Commande gcloud

Vous pouvez utiliser la commande gcloud dataproc autoscaling-policies import pour créer une règle d'autoscaling. Elle lit un fichier YAML local qui définit une règle d'autoscaling. Le format et le contenu du fichier doivent correspondre aux objets de configuration et aux champs définis par l'API REST autoscalingPolicies.

L'exemple YAML suivant définit une règle spécifiant tous les champs obligatoires. Il fournit également des valeurs maxInstances pour les nœuds de calcul principaux et secondaires (préemptifs), et spécifie une valeur cooldownPeriod de 4 minutes (la valeur par défaut est 2 minutes).

workerConfig:
  maxInstances: 100
secondaryWorkerConfig:
  maxInstances: 50
basicAlgorithm:
  cooldownPeriod: 4m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    gracefulDecommissionTimeout: 1h

Voici un autre exemple YAML qui spécifie tous les champs de règles d'autoscaling facultatifs et obligatoires.

workerConfig:
  minInstances: 2
  maxInstances: 100
  weight: 1
secondaryWorkerConfig:
  minInstances: 0
  maxInstances: 100
  weight: 1
basicAlgorithm:
  cooldownPeriod: 4m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    scaleUpMinWorkerFraction: 0.0
    scaleDownMinWorkerFraction: 0.0
    gracefulDecommissionTimeout: 1h

Exécutez la commande gcloud suivante à partir d'un terminal local ou dans Cloud Shell pour créer la règle d'autoscaling. Nommez la règle. Ce nom deviendra la règle id, que vous pourrez utiliser dans les commandes gcloud ultérieures pour faire référence à la règle. Utilisez l'option --source pour spécifier le chemin d'accès au fichier local et le nom du fichier YAML de la règle d'autoscaling à importer.

gcloud dataproc autoscaling-policies import policy-name \
    --source=filepath/filename.yaml \
    --region=region

API REST

Créez une règle d'autoscaling en définissant AutoscalingPolicy dans le cadre d'une requête autoscalingPolicies.create.

Console

Actuellement, la création d'une règle d'autoscaling n'est pas possible dans Google Cloud Console.

Créer un cluster d'autoscaling

Après avoir créé une règle d'autoscaling, créez un cluster qui utilisera la règle d'autoscaling. Le cluster doit se trouver dans la même région que la règle d'autoscaling.

Commande gcloud

Exécutez la commande gcloud suivante à partir d'un terminal local ou dans Cloud Shell pour créer un cluster d'autoscaling. Attribuez un nom au cluster et utilisez l'option --autoscaling-policy pour spécifier policy id (nom de la règle que vous avez spécifiée lors de la création de la règle) ou de la règle resource URI (resource name) (voir les champs AutoscalingPolicy id et name).

gcloud dataproc clusters create cluster-name \
    --autoscaling-policy=policy id or resource URI \
    --region=region

API REST

Créez un cluster d'autoscaling en incluant AutoscalingConfig dans le cadre d'une requête clusters.create.

Console

Vous pouvez sélectionner une règle d'autoscaling existante à appliquer à un nouveau cluster dans la section Règle d'autoscaling de la page Créer un cluster Dataproc de Cloud Console.

Activer l'autoscaling sur un cluster existant

Après avoir créé une règle d'autoscaling, vous pouvez l'activer sur un cluster existant dans la même région.

Commande gcloud

Exécutez la commande gcloud suivante à partir d'un terminal local ou dans Cloud Shell pour activer une règle d'autoscaling sur un cluster existant. Attribuez un nom au cluster et utilisez l'option --autoscaling-policy pour spécifier policy id (nom de la règle que vous avez spécifiée lors de la création de la règle) ou de la règle resource URI (resource name) (voir les champs AutoscalingPolicy id et name ).

gcloud dataproc clusters update cluster-name \
    --autoscaling-policy=policy id or resource URI \
    --region=region

API REST

Pour activer une règle d'autoscaling sur un cluster existant, définissez l'élément AutoscalingConfig.policyUri de la règle dans le paramètre updateMask d'une requête clusters.patch.

Console

Actuellement, l'activation d'une règle d'autoscaling sur un cluster existant n'est pas possible dans Google Cloud Console.

Fonctionnement de l'autoscaling

L'autoscaling vérifie les métriques Hadoop YARN du cluster à la fin de l'intervalle entre chaque période d'autoscaling pour déterminer si le cluster doit être redimensionné et, le cas échéant, l'ampleur de la mise à jour.

  1. Lors de chaque évaluation, l'autoscaling examine la mémoire de cluster en attente et disponible moyennée sur le dernier intervalle entre chaque période d'autoscaling cooldown_period afin de déterminer le changement exact à apporter au nombre de nœuds de calcul :

    exact Δworkers = avg(pending memory - available memory) / memory per node manager

    • pending memory indique que le cluster a des tâches en file d'attente qui n'ont pas encore été exécutées ; vous devrez donc peut-être augmenter les nœuds de calcul du cluster pour une meilleure gestion de sa charge de travail.
    • available memory indique que le cluster dispose d'une bande passante supplémentaire sur les nœuds opérationnels et qu'il peut être nécessaire de réduire le nombre de nœuds pour conserver les ressources.
    • Consultez la section Autoscaling avec Hadoop et Spark pour plus d'informations sur les métriques Apache Hadoop YARN.
  2. Compte tenu de la modification exacte du nombre de nœuds de calcul, l'autoscaling utilise une valeur scaleUpFactor ou scaleDownFactor pour calculer la modification réelle du nombre de nœuds de calcul :

    if exact Δworkers > 0:
      actual Δworkers = ROUND_UP(exact Δworkers * scaleUpFactor)
      # examples:
      # ROUND_UP(exact Δworkers=5 * scaleUpFactor=0.5) = 3
      # ROUND_UP(exact Δworkers=0.8 * scaleUpFactor=0.5) = 1
    else:
      actual Δworkers = ROUND_DOWN(exact Δworkers * scaleDownFactor)
      # examples:
      # ROUND_DOWN(exact Δworkers=-5 * scaleDownFactor=0.5) = -2
      # ROUND_DOWN(exact Δworkers=-0.8 * scaleDownFactor=0.5) = 0
      # ROUND_DOWN(exact Δworkers=-1.5 * scaleDownFactor=0.5) = 0
    
    Une valeur scaleUpFactor ou scaleDownFactor définie sur 1.0 signifie que l'autoscaling est exécuté de manière à ce que la mémoire en attente/disponible soit égale à 0 (utilisation parfaite).

  3. Une fois que la modification réelle du nombre de nœuds de calcul est calculée, une fraction scaleUpMinWorkerFraction ou scaleDownMinWorkerFraction agit en tant que seuil pour déterminer si l'autoscaling du cluster doit être exécuté. Une fraction de valeur faible signifie que l'autoscaling doit être exécuté même si l'élément Δworkers a une valeur faible. Une fraction de valeur plus importante signifie que l'autoscaling ne doit être exécuté que lorsque l'élément Δworkers atteint une valeur plus importante.

    if (Δworkers >  scaleUpMinWorkerFraction* cluster size) then scale up
    ou
    if (abs(Δworkers) >  scaleDownMinWorkerFraction* cluster size) then scale down

  4. Si le nombre de nœuds de calcul est suffisant pour déclencher le processus de scaling, l'autoscaling utilise les limites minInstances maxInstances de workerConfig ainsi que secondaryWorkerConfig et weight (ratio des nœuds de calcul principaux à secondaires) pour déterminer comment diviser le nombre de nœuds de calcul entre les groupes d'instances primaires et secondaires. Le résultat de ces calculs représente la modification finale de l'autoscaling du cluster pour la période de scaling.

Mise hors service concertée

L'autoscaling est compatible avec la mise hors service concertée YARN lors de la suppression des nœuds d'un cluster. La mise hors service concertée permet aux applications de terminer le brassage des données entre les étapes pour éviter de retarder la progression de la tâche. Le délai de mise hors service concertée indiqué dans une règle d'autoscaling correspond à la limite supérieure de la durée pendant laquelle YARN attend que les applications en cours d'exécution au début de la mise hors service se termine avant de supprimer des nœuds.

Utilisation des règles multi-cluster

  • Une règle d'autoscaling définit un comportement de scaling pouvant être appliqué à plusieurs clusters. Une règle d'autoscaling est mieux appliquée à plusieurs clusters lorsque ceux-ci partagent des charges de travail similaires ou exécutent des tâches avec des modèles d'utilisation des ressources similaires.

  • Vous pouvez mettre à jour une règle utilisée par plusieurs clusters. Les mises à jour affectent immédiatement le comportement de l'autoscaling pour tous les clusters utilisant la règle (voir autoscalingPolicies.update). Si vous ne souhaitez pas qu'une mise à jour de règle s'applique à un cluster qui utilise cette règle, désactivez l'autoscaling sur le cluster avant de mettre à jour la règle.

Commande gcloud

Exécutez la commande gcloud suivante depuis un terminal local ou dans Cloud Shell pour désactiver l'autoscaling sur un cluster.

gcloud dataproc clusters update cluster-name --disable-autoscaling \
    --region=region

API REST

Pour désactiver l'autoscaling sur un cluster, définissez AutoscalingConfig.policyUri sur la chaîne vide et définissez update_mask=config.autoscaling_config.policy_uri dans une requête clusters.patch.

Console

Actuellement, la désactivation de l'autoscaling sur un cluster n'est pas possible dans Google Cloud Console.

Recommandations liées à l'autoscaling

  • Temps d'attente : la durée minimale par défaut de cooldownPeriod est de deux minutes. Si une valeur cooldownPeriod plus courte est définie dans une règle, les modifications apportées à la charge de travail affecteront plus rapidement la taille du cluster, mais les clusters risquent d'effectuer un scaling à la hausse ou à la baisse inutilement. Il est recommandé de définir scale_up, scale_down et min_worker_fractions sur une valeur différente de zéro si vous utilisez une valeur cooldownPeriod plus courte. Cela garantit que le cluster ne fait pas de scaling à la hausse ou à la baisse lorsque la modification de l'utilisation de la mémoire est suffisante pour garantir une mise à jour du cluster.

  • Scaling à la baisse : MapReduce et Spark écrivent des données de brassage intermédiaires sur le disque local. La suppression de nœuds de calcul avec des données de brassage retardera la progression de la tâche, car les tâches de mappage devront être réexécutées pour reproduire les données de brassage. Spark exécute de nouveau des étapes complètes s'il détecte que des fichiers de conversion aléatoire sont manquants.

    • Pour fair un scaling à la baisse uniquement lorsqu'un cluster est inactif, définissez scale_down factor et scale_down min_worker_fraction sur 1,0.

    • Pour des clusters avec chargement continu, configurer le scaling à la baisse entre les tâches en définissant le facteur scale_down sur 1,0 et une valeur graceful_decommission_timeout différente de zéro pour supprimer des nœuds de cluster lorsqu'ils n'exécutent pas de conteneurs YARN (consultez la section Mise hors service concertée). Définissez la valeur graceful_decommission_timeout de sorte à être plus longue que la tâche de cluster la plus longue pour vous assurer que les nœuds ne seront pas forcément désactivés avant la fin d'un projet.

    • Pensez à utiliser le Mode de flexibilité améliorée pour éviter ou réduire le risque de perdre la progression de la tâche lors de la suppression des nœuds.

  • Tâches Spark avec données en cache : définissez spark.dynamicAllocation.cachedExecutorIdleTimeout ou supprimez la mise en cache des ensembles de données lorsqu'ils ne sont plus nécessaires. Par défaut, Spark ne supprime pas les exécuteurs ayant mis en cache des données.

Autoscaling avec Apache Hadoop et Apache Spark

Les sections suivantes expliquent comment l'autoscaling interagit (ou non) avec Hadoop YARN et Hadoop Mapreduce, et Apache Spark, Spark Streaming et Spark Structured Streaming.

Métriques Hadoop YARN

L'autoscaling configure Hadoop YARN pour planifier les tâches en fonction des requêtes de mémoire YARN, et non des requêtes de cœur YARN.

L'autoscaling s'articule autour des métriques Hadoop YARN suivantes :

  1. Allocated memory correspond à la quantité totale de mémoire YARN utilisée par l'exécution de conteneurs sur l'ensemble du cluster. Si 6 conteneurs en cours d'exécution peuvent utiliser jusqu'à 1 Go, cela signifie que 6 Go de mémoire sont alloués.

  2. Available memory correspond à la mémoire YARN du cluster qui n'est pas utilisée par les conteneurs alloués. Si 10 Go de mémoire sont disponibles sur tous les gestionnaires de nœuds et qu'il existe 6 Go de mémoire allouée, il reste 4 Go de mémoire disponible. Si le cluster contient de la mémoire disponible (inutilisée), l'autoscaling peut supprimer des nœuds de calcul du cluster.

  3. Pending memory correspond à la somme des requêtes de mémoire YARN pour les conteneurs en attente. Ces conteneurs attendent que de l'espace soit disponible dans YARN. La mémoire en attente n'est une valeur non nulle que si la mémoire disponible est nulle ou trop petite pour être allouée au conteneur suivant. Si des conteneurs sont en attente, l'autoscaling peut ajouter des nœuds de calcul au cluster.

Vous pouvez afficher ces métriques dans Cloud Monitoring. Par défaut, la mémoire YARN correspond à 0,8 x mémoire totale sur le cluster, la mémoire restante étant réservée à d'autres daemons et systèmes d'exploitation, tels que le cache de pages. Vous pouvez remplacer la valeur par défaut par le paramètre de configuration YARN "yarn.nodemanager.resource.memory-mb" (voir Apache Hadoop YARN, HDFS, Spark et les propriétés associées).

Autoscaling et Hadoop MapReduce

MapReduce exécute chaque tâche de mappage et réduction en tant que conteneur YARN distinct. Lorsqu'une tâche commence, MapReduce soumet des requêtes de conteneur pour chaque tâche de mappage, ce qui entraîne un pic important dans la mémoire YARN en attente. Au fur et à mesure que les tâches de mappage se terminent, la mémoire en attente diminue.

Lorsque la tâche mapreduce.job.reduce.slowstart.completedmaps se termine (95 % par défaut sur Dataproc), MapReduce met en file d'attente les requêtes de conteneur pour tous les réducteurs, ce qui entraîne un nouveau pic dans la mémoire en attente.

Ne définissez pas scaleUpFactor sur une valeur élevée, à moins que les tâches de mappage et de réduction prennent plusieurs minutes ou plus. L'ajout de nœuds de calcul au cluster prend au moins une minute et demie. Assurez-vous qu'il reste suffisamment de tâches en attente pour utiliser le nouveau nœud de calcul pendant plusieurs minutes. Un bon point de départ consiste à définir scaleUpFactor sur 0,05 (5 %) ou 0,1 (10 %) de la quantité de mémoire en attente.

Autoscaling et Spark

Spark ajoute une couche supplémentaire de planification en plus de YARN. Plus précisément, l'allocation dynamique de Spark Core envoie des requêtes à YARN pour que les conteneurs exécutent les exécuteurs Spark, puis planifie les tâches Spark sur les fils d'exécution de ces exécuteurs. Les clusters Dataproc activent l'allocation dynamique par défaut. Ainsi, les exécuteurs sont ajoutés et supprimés si nécessaire.

Spark demande toujours des conteneurs à YARN, mais sans allocation dynamique, il ne demande des conteneurs qu'au début de la tâche. L'allocation dynamique permet de supprimer les conteneurs ou en demander de nouveaux, au besoin.

Spark commence à partir d'un petit nombre d'exécuteurs (deux sur des clusters d'autoscaling) et continue à doubler le nombre d'exécuteurs tant qu'il y a des tâches en attente. Cela permet de réguler la quantité de mémoire en attente (moins de pics de mémoire en attente). Il est recommandé de définir le facteur d'autoscaling scaleUpFactor sur un nombre élevé, tel que 1 (100 %), pour les tâches Spark.

Désactiver l'allocation dynamique Spark

Si vous exécutez des tâches Spark distinctes ne bénéficiant pas de l'allocation dynamique Spark, vous pouvez désactiver l'allocation dynamique Spark en définissant spark.dynamicAllocation.enabled=false et spark.executor.instances. Vous pouvez toujours utiliser l'autoscaling sur des clusters pendant que les tâches Spark distinctes sont exécutées.

Autoscaling et Spark Streaming

  1. Spark Streaming possède sa propre version d'allocation dynamique qui utilise des signaux spécifiques au streaming pour ajouter et supprimer des exécuteurs. Définissez ainsi spark.streaming.dynamicAllocation.enabled=true et désactivez l'allocation dynamique de Spark Core en définissant spark.dynamicAllocation.enabled=false.

  2. N'utilisez pas la mise hors service concertée (autoscaling gracefulDecommissionTimeout) avec les tâches Spark Streaming. À la place, pour supprimer les nœuds de calcul avec autoscaling en toute sécurité, configurez les points de contrôle pour la tolérance aux pannes.

Vous pouvez également utiliser Spark Streaming sans l'autoscaling :

  1. Désactivez l'allocation dynamique de Spark Core (spark.dynamicAllocation.enabled=false), et
  2. Définissez le nombre d'exécuteurs (spark.executor.instances) pour votre tâche. Consultez la section Propriétés du cluster.

Autoscaling et Spark Structured Streaming

L'autoscaling n'est pas compatible avec Spark Structured Streaming, car Spark Structured Streaming ne gère actuellement pas l'allocation dynamique (consultez la page SPARK-24815: Structured Streaming should support dynamic allocation).

Contrôler l'autoscaling par partitionnement et parallélisme

Tandis que le parallélisme est généralement défini ou déterminé par les ressources du cluster (par exemple, le nombre de blocs HDFS est contrôlé par le nombre de tâches), l'inverse s'applique avec l'autoscaling. L'autoscaling définit le nombre de nœuds de calcul en fonction du parallélisme des tâches. Vous trouverez ci-dessous des instructions pour vous aider à définir le parallélisme des tâches :

  • Bien que Dataproc définisse le nombre par défaut de tâches de réduction MapReduce en fonction de la taille initiale de votre cluster, vous pouvez définir mapreduce.job.reduces pour augmenter le parallélisme de la phase de réduction.
  • Le parallélisme Spark SQL et DataFrame est déterminé par spark.sql.shuffle.partitions, dont la valeur par défaut est 200.
  • Les fonctions RDD de Spark sont définies par défaut sur spark.default.parallelism, qui est défini sur le nombre de cœurs sur les nœuds de calcul au démarrage de la tâche. Cependant, toutes les fonctions RDD qui créent des brassages utilisent un paramètre pour le nombre de partitions, qui remplace spark.default.parallelism.

Vous devez vous assurer que vos données sont partitionnées de manière égale. En cas de décalage important, une ou plusieurs tâches peuvent prendre beaucoup plus de temps que d'autres, ce qui entraîne une faible utilisation.

Autoscaling des paramètres de propriété Spark/Hadoop par défaut

Les clusters d'autoscaling ont des valeurs de propriété de cluster par défaut qui permettent d'éviter l'échec de tâches lorsque des nœuds de calcul primaires sont supprimés ou des nœuds de calcul secondaires sont préemptés. Vous pouvez remplacer ces valeurs par défaut lorsque vous créez un cluster avec autoscaling (voir Propriétés du cluster).

Paramètres par défaut pour augmenter le nombre maximal de tentatives pour les tâches, les applications maîtres et les étapes :

yarn:yarn.resourcemanager.am.max-attempts=10
mapred:mapreduce.map.maxattempts=10
mapred:mapreduce.reduce.maxattempts=10
spark:spark.task.maxFailures=10
spark:spark.stage.maxConsecutiveAttempts=10

Paramètres par défaut pour réinitialiser les compteurs de nouvelles tentatives (utiles pour les travaux Spark Streaming de longue durée) :

spark:spark.yarn.am.attemptFailuresValidityInterval=1h
spark:spark.yarn.executor.failuresValidityInterval=1h

Paramètres par défaut pour procéder au démarrage lent du mécanisme d'allocation dynamique Spark à partir d'une petite taille :

spark:spark.executor.instances=2

Métriques et journaux de l'autoscaling

Les ressources et les outils suivants peuvent vous aider à surveiller les opérations d'autoscaling et leurs effets sur le cluster et ses tâches.

Cloud Monitoring

Utilisez Cloud Monitoring pour :

  • Afficher les métriques utilisées par l'autoscaling
  • Afficher le nombre de gestionnaires de nœuds dans votre cluster
  • Comprendre pourquoi l'autoscaling a été exécuté ou non sur votre cluster autoscaling-stackdriver1 autoscaling-stackdriver2 autoscaling-stackdriver3

Cloud Logging

Utilisez Cloud Logging pour afficher les journaux de l'autoscaler Cloud Dataproc.

1) Recherchez les journaux de votre cluster.

autoscaling-logs-for-cluster

2) Sélectionnez dataproc.googleapis.com/autoscaler.

autoscaling-log-file

3) Développez les messages de journal pour afficher le champ status. Les journaux sont au format JSON, un format lisible par un ordinateur.

autoscaling-three-logs autoscaling-update-operation

4) Développez le message de journal pour afficher les recommandations de scaling, les métriques utilisées pour les décisions de scaling, la taille du cluster d'origine et la nouvelle taille du cluster cible.

autoscaling-recommendation-message

Questions fréquentes

L'autoscaling peut-il être activé sur les clusters à haute disponibilité et les clusters à nœud unique ?

L'autoscaling peut être activé sur les clusters à haute disponibilité, mais pas sur les clusters à nœud unique (les clusters à nœud unique ne sont pas compatibles avec le redimensionnement).

Un cluster d'autoscaling peut-il être redimensionné manuellement ?

Oui. Vous pouvez décider de redimensionner manuellement un cluster en tant que mesure provisoire lorsque vous ajustez une règle d'autoscaling. Toutefois, ces modifications n'auront qu'un effet temporaire et l'autoscaling réduira finalement le cluster.

Au lieu de redimensionner manuellement un cluster d'autoscaling, envisagez de :

Mettre à jour de la règle d'autoscaling. Toute modification apportée à la règle d'autoscaling affectera tous les clusters qui l'utilisent actuellement (voir la section Utilisation des règles multi-cluster).

Dissocier la règle et faire un scaling manuel du cluster à la taille souhaitée.

Demander l'assistance Dataproc.

Quelles versions d'image sont compatibles avec l'autoscaling ? Quelles versions d'API ?

L'autoscaling est compatible via l'API v1 sur les versions en images de cluster 1.0.99+, 1.1.90+, 1.2.22+, 1.3.0+ et 1.4.0+ (voir la Liste des versions Cloud Dataproc) et via les commandes gcloud dataproc autoscaling-policies.

En quoi Dataproc est-il différent de l'autoscaling Dataflow ?

Consultez la section Comparaison entre l'autoscaling de Cloud Dataflow, et celui de Spark et Hadoop.