Résoudre les problèmes de création de clusters

Ce document explique les messages d'erreur courants liés à la création de clusters et fournit des conseils pour résoudre les problèmes de création de clusters.

Messages d'erreur courants liés à la création de clusters

  • L'utilisateur n'est pas autorisé à agir en tant que compte de service

    Cause : le compte principal qui tente de créer le cluster Managed Service pour Apache Spark ne dispose pas des autorisations nécessaires pour utiliser le compte de service spécifié. Les utilisateurs de Managed Service pour Apache Spark doivent disposer de l'autorisation ActAs pour déployer des ressources Managed Service pour Apache Spark. Cette autorisation est incluse dans le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) (voir Rôles Managed Service pour Apache Spark).

    Solution : Identifiez le compte utilisateur ou le compte de service qui tente de créer le cluster Managed Service pour Apache Spark. Attribuez à ce compte principal le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur le compte de service que le cluster est configuré pour utiliser (généralement le compte de service de VM Managed Service pour Apache Spark).

  • L'opération a expiré : seuls 0 des deux gestionnaires de nœuds/nœuds de données minimum requis sont en cours d'exécution.

    Cause : Le nœud de contrôleur ne peut pas créer le cluster, car il ne peut pas communiquer avec les nœuds de calcul.

    Solution :

  • Autorisation compute.subnetworks.use requise pour projects/{projectId}/regions/{region}/subnetworks/{subnetwork}

    Cause : cette erreur peut se produire lorsque vous essayez de configurer un cluster Managed Service for Apache Spark à l'aide d'un réseau VPC dans un autre projet et que le compte de service de l'agent de service Managed Service for Apache Spark ne dispose pas des autorisations nécessaires sur le projet VPC partagé qui héberge le réseau.

    Solution: suivez la procédure décrite dans la section Créer un cluster utilisant un réseau VPC dans un autre projet.

  • La zone projects/zones/{zone} ne dispose pas de suffisamment de ressources pour répondre à la requête (resource type:compute)

    Cause: La zone utilisée pour créer le cluster ne dispose pas de ressources suffisantes.

    Solution :

    • Utilisez la fonctionnalité de sélection de zone automatique de Managed Service pour Apache Spark pour créer le cluster dans l'une des zones d'une région disposant de ressources disponibles.
    • Créez le cluster dans une autre zone.

  • Erreurs de dépassement de quota

    Quota de CPUS/CPUS_ALL_REGIONS insuffisant
    Quota insuffisant pour "DISKS_TOTAL_GB"
    Quota insuffisant pour "IN_USE_ADDRESSES"

    Cause: votre requête de processeur, de disque ou d'adresse IP dépasse votre quota disponible.

    Solution : Demandez des quotas supplémentaires à partir de la consoleGoogle Cloud .

  • Échec de l'action d'initialisation

    Cause: l'installation de l'action d'initialisation fournie lors de la création du cluster a échoué.

    Solution :

  • Échec de l'initialisation du nœud CLUSTER-NAME-m. ... Afficher le résultat dans : <gs://PATH_TO_STARTUP_SCRIPT_OUTPUT>

    Cause : le nœud de contrôleur du cluster Managed Service pour Apache Spark n'a pas pu être initialisé.

    Solution :

  • Échec de la création du cluster : espace d'adressage IP épuisé

    Cause : L'espace d'adresses IP nécessaire pour provisionner les nœuds de cluster demandés n'est pas disponible.

    Solution :

    • Créez un cluster avec moins de nœuds de calcul, mais un type de machine plus volumineux.
    • Créez un cluster sur un autre sous-réseau ou réseau.
    • Réduisez l'utilisation du réseau pour libérer de l'espace d'adresses IP.
    • Attendez qu'un espace d'adresses IP suffisant soit disponible sur le réseau.

  • Message d'erreur du script d'initialisation : le dépôt REPO_NAME ne contient plus de fichier de version

    Cause : Le dépôt de rétroportages Debian oldstable a été supprimé.

    Solution :

    Ajoutez le code suivant avant le code qui exécute apt-get dans votre script d'initialisation.

    oldstable=$(curl -s https://deb.debian.org/debian/dists/oldstable/Release | awk '/^Codename/ {print $2}');
stable=$(curl -s https://deb.debian.org/debian/dists/stable/Release | awk '/^Codename/ {print $2}');

matched_files="$(grep -rsil '\-backports' /etc/apt/sources.list*)"
if [[ -n "$matched_files" ]]; then
  for filename in "$matched_files"; do
    grep -e "$oldstable-backports" -e "$stable-backports" "$filename" || \
      sed -i -e 's/^.*-backports.*$//' "$filename"
  done
fi

  • Délai d'attente expiré pour l'instance DATAPROC_CLUSTER_VM_NAME ou Réseau inaccessible : dataproccontrol-REGION.googleapis.com

    Cause : Ces messages d'erreur indiquent que la configuration réseau de votre cluster Managed Service pour Apache Spark est incomplète. Il peut manquer la route vers la passerelle Internet par défaut ou les règles de pare-feu.

    Solution :

    Pour résoudre ce problème, vous pouvez créer les tests de connectivité suivants :

    • Créez un test de connectivité entre deux VM de cluster Managed Service pour Apache Spark. Le résultat de ce test vous aidera à déterminer si les règles de pare-feu d'entrée ou de sortie de votre réseau s'appliquent correctement aux VM du cluster.
    • Créez un test de connectivité entre une VM de cluster Managed Service pour Apache Spark et une adresse IP actuelle de l'API de contrôle Managed Service pour Apache Spark. Pour obtenir l'adresse IP actuelle de l'API de contrôle Managed Service pour Apache Spark, utilisez la commande suivante :
    dig dataproccontrol-REGION.googleapis.com A

    Utilisez l'une des adresses IPv4 dans la section "Réponse" du résultat.

    Le résultat du test de connectivité vous aidera à déterminer si la route vers la passerelle Internet par défaut et le pare-feu de sortie sont correctement configurés.

    En fonction des résultats des tests de connectivité :

  • Erreur due à la mise à jour

    Cause : Le cluster a accepté un job envoyé au service Managed Service pour Apache Spark, mais n'a pas pu effectuer de scaling à la hausse ou à la baisse manuellement ni par autoscaling. Cette erreur peut également être due à une configuration de cluster non standard.

    Solution :

    • Réinitialisation du cluster : ouvrez une demande d'assistance, incluez un fichier tar de diagnostic et demandez à ce que le cluster soit réinitialisé à l'état "RUNNING" (EN COURS D'EXÉCUTION).

    • Nouveau cluster : recréez le cluster avec la même configuration. Cette solution peut être plus rapide qu'une réinitialisation fournie par l'assistance.

Conseils de dépannage pour les clusters

Cette section fournit des conseils supplémentaires pour résoudre les problèmes courants qui peuvent empêcher la création de clusters Managed Service pour Apache Spark.

Lorsqu'un cluster Managed Service pour Apache Spark ne parvient pas à être provisionné, il génère souvent un message d'erreur générique ou affiche un état PENDING ou PROVISIONING avant d'échouer. Pour diagnostiquer et résoudre les problèmes d'échec de cluster, il est essentiel d'examiner les journaux de cluster et d'évaluer les points de défaillance courants.

Symptômes courants

Voici quelques symptômes courants associés aux échecs de création de clusters :

  • L'état du cluster reste PENDING ou PROVISIONING pendant une période prolongée.
  • Le cluster passe à l'état ERROR.
  • Erreurs d'API génériques lors de la création du cluster, telles que Operation timed out.

  • Messages d'erreur consignés ou de réponse de l'API, tels que :

    • RESOURCE_EXHAUSTED : lié aux quotas de processeur, de disque ou d'adresse IP
    • Instance failed to start
    • Permission denied
    • Unable to connect to service_name.googleapis.com ou Could not reach required Google APIs
    • Connection refused ou network unreachable
    • Erreurs liées à l'échec des actions d'initialisation, telles que les erreurs d'exécution de script et les fichiers introuvables.

Examiner les journaux de cluster

Pour diagnostiquer les échecs de création de clusters, il est important de commencer par examiner les journaux de cluster détaillés disponibles dans Cloud Logging.

  1. Accédez à l'explorateur de journaux : ouvrez l'explorateur de journaux dans la console Google Cloud .
  2. Filtrez les clusters Managed Service pour Apache Spark :
    • Dans le menu déroulant Ressource, sélectionnez Cloud Managed Service for Apache Spark Cluster.
    • Saisissez votre cluster_name et votre project_id. Vous pouvez également filtrer par location (région).
  3. Examiner les entrées de journal :
    • Recherchez les messages de niveau ERROR ou WARNING qui se produisent peu de temps avant l'échec de la création du cluster.
    • Examinez attentivement les journaux des composants master-startup, worker-startup et agent pour obtenir des informations sur les problèmes liés aux agents au niveau des VM ou de Managed Service pour Apache Spark.
    • Pour obtenir des informations sur les problèmes de temps de démarrage des VM, filtrez les journaux par resource.type="gce_instance" et recherchez les messages provenant des noms d'instance associés aux nœuds de votre cluster, tels que CLUSTER_NAME-m ou CLUSTER_NAME-w-0. Les journaux de la console série peuvent révéler des problèmes de configuration réseau, des problèmes de disque et des échecs de script qui se produisent au début du cycle de vie de la VM.

Causes courantes d'échec des clusters et conseils de dépannage

Cette section présente les raisons courantes pour lesquelles la création d'un cluster Managed Service pour Apache Spark peut échouer. Elle fournit également des conseils de dépannage pour vous aider à résoudre les problèmes liés aux clusters.

Autorisations IAM insuffisantes

Le compte de service de la VM utilisé par votre cluster Managed Service for Apache Spark doit disposer des rôles IAM appropriés pour provisionner des instances Compute Engine, accéder aux buckets Cloud Storage, écrire des journaux et interagir avec d'autres services Google Cloud .

  • Rôle de nœud de calcul requis : vérifiez que le compte de service de VM dispose du rôle Nœud de calcul Managed Service pour Apache Spark (roles/dataproc.worker). Ce rôle dispose des autorisations minimales requises pour que Managed Service pour Apache Spark gère les ressources du cluster.
  • Autorisations d'accès aux données : si vos jobs lisent ou écrivent des données dans Cloud Storage ou BigQuery, le compte de service a besoin des rôles associés, tels que Storage Object Viewer, Storage Object Creator ou Storage Object Admin pour Cloud Storage, ou BigQuery Data Viewer ou BigQuery Editor pour BigQuery.
  • Autorisations de journalisation : le compte de service doit disposer d'un rôle avec les autorisations nécessaires pour écrire des journaux dans Cloud Logging, comme le rôle Logging Writer.

Conseils de dépannage

  • Identifiez le compte de service : déterminez le compte de service de la VM que votre cluster est configuré pour utiliser. Si aucune valeur n'est spécifiée, la valeur par défaut est le compte de service Compute Engine par défaut.

  • Vérifiez les rôles IAM : accédez à la page IAM et administration > IAM de la console Google Cloud , recherchez le compte de service de la VM du cluster, puis vérifiez qu'il dispose des rôles nécessaires aux opérations du cluster. Attribuez les rôles manquants.

Quotas de ressources dépassés

Les clusters Managed Service pour Apache Spark consomment des ressources de Compute Engine et d'autres services Google Cloud . Le dépassement des quotas de projet ou régionaux peut entraîner des échecs de création de clusters.

  • Quotas Managed Service pour Apache Spark courants à vérifier :
    • CPUs (régional)
    • DISKS_TOTAL_GB (régional)
    • IN_USE_ADDRESSES (régional pour les adresses IP internes, mondial pour les adresses IP externes)
    • Quotas de l'API Dataproc, tels que ClusterOperationRequestsPerMinutePerProjectPerRegion

Conseils de dépannage

  • Consulter les quotas : accédez à la page IAM et administration > IAM de la console Google Cloud . Filtrez par "Service" pour "API Compute Engine" et "API Dataproc".
  • Vérifiez l'utilisation par rapport à la limite : identifiez les quotas qui sont à leur limite ou qui s'en approchent.
  • Si nécessaire, demandez une augmentation de quota.

Problèmes de configuration réseau

Les problèmes de configuration réseau, tels qu'une configuration incorrecte du réseau VPC, du sous-réseau, du pare-feu ou du DNS, sont une cause fréquente d'échec de la création de clusters. Les instances de cluster doivent pouvoir communiquer entre elles et avec les API Google.

  • Réseau et sous-réseau VPC :
    • Vérifiez que le réseau VPC et le sous-réseau du cluster existent et sont correctement configurés.
    • Vérifiez que le sous-réseau dispose d'une plage d'adresses IP disponibles suffisante.
  • Accès privé à Google : si les VM du cluster disposent d'adresses IP internes et doivent accéder aux API Google pour Cloud Storage, Cloud Logging et d'autres opérations, vérifiez que l'accès privé à Google est activé sur le sous-réseau. Par défaut, les clusters Managed Service pour Apache Spark créés avec des versions d'image 2.2 ou ultérieures provisionnent des VM avec des adresses IP internes uniquement, et l'accès privé à Google est activé sur le sous-réseau régional du cluster.
  • Private Service Connect (PSC) : si vous utilisez Private Service Connect pour accéder aux API Google, vérifiez que les points de terminaison Private Service Connect nécessaires sont correctement configurés pour les API Google dont dépend Managed Service for Apache Spark, telles que dataproc.googleapis.com, storage.googleapis.com, compute.googleapis.com et logging.googleapis.com. Les entrées DNS des API doivent être associées à des adresses IP privées. Notez que l'utilisation de Private Service Connect ne dispense pas d'utiliser l'appairage de réseaux VPC pour communiquer avec d'autres réseaux VPC gérés par le client.
  • Appairage de VPC : si votre cluster communique avec des ressources dans d'autres réseaux VPC, tels que des projets hôtes VPC partagés ou d'autres VPC clients, vérifiez que l'appairage de VPC est correctement configuré et que les routes sont propagées.

  • Règles de pare-feu :

    • Règles par défaut : vérifiez que les règles de pare-feu par défaut, telles que allow-internal ou allow-ssh, ne sont pas trop restrictives.

    • Règles personnalisées : si des règles de pare-feu personnalisées sont en place, vérifiez qu'elles autorisent les chemins de communication nécessaires :

      • Communication interne au sein du cluster (entre les nœuds -m et -w).

      • Trafic sortant des VM du cluster vers les API Google, à l'aide d'adresses IP publiques ou d'une passerelle Internet, de l'accès privé à Google ou de points de terminaison Private Service Connect.

      • Trafic vers les sources de données ou services externes dont dépendent vos jobs.

  • Résolution DNS : vérifiez que les instances de cluster peuvent résoudre correctement les noms DNS pour les API Google et tous les services internes ou externes.

Conseils de dépannage

  • Vérifiez la configuration réseau : inspectez les paramètres du réseau VPC et du sous-réseau où le cluster est déployé.
  • Vérifiez les règles de pare-feu : examinez les règles de pare-feu dans le réseau VPC ou le projet hôte de VPC partagé.
  • Testez la connectivité : lancez une VM Compute Engine temporaire dans le sous-réseau du cluster et procédez comme suit :
    • ping ou curl aux domaines d'API Google externes, tels que storage.googleapis.com.
    • nslookup pour vérifier la résolution DNS vers les adresses IP attendues (accès privé à Google ou Private Service Connect).
    • Exécutez des tests de connectivité Google Cloud pour diagnostiquer les chemins d'accès d'une VM de test aux points de terminaison concernés.

Échecs des actions d'initialisation

Les actions d'initialisation Managed Service pour Apache Spark sont des scripts qui s'exécutent sur les VM du cluster lors de la création du cluster. Les erreurs dans ces scripts peuvent empêcher le démarrage du cluster.

Conseils de dépannage

  • Examinez les journaux pour détecter les erreurs d'action d'initialisation : recherchez les entrées de journal liées à init-actions ou startup-script pour les instances de cluster dans Cloud Logging.
  • Vérifiez les chemins d'accès et les autorisations des scripts : assurez-vous que les scripts d'action d'initialisation sont correctement situés dans Cloud Storage et que le compte de service de la VM du cluster dispose du rôle Storage Object Viewer nécessaire pour lire les scripts Cloud Storage.
  • Déboguer la logique du script : testez la logique du script sur une VM Compute Engine distincte qui imite l'environnement du cluster pour identifier les erreurs. Ajoutez une journalisation détaillée au script.

Disponibilité régionale des ressources (ruptures de stock)

Il arrive qu'un type de machine ou une ressource dans une région ou une zone soient temporairement indisponibles (rupture de stock). En règle générale, cela entraîne des erreurs RESOURCE_EXHAUSTED sans rapport avec les problèmes de quota de projet.

Conseils de dépannage

  • Essayez une autre zone ou région : essayez de créer le cluster dans une autre zone de la même région ou dans une autre région.
  • Utilisez la sélection automatique des zones : utilisez la fonctionnalité de sélection automatique des zones de Managed Service pour Apache Spark afin de sélectionner automatiquement une zone disposant de capacité.
  • Ajustez le type de machine : si vous utilisez un type de machine personnalisé ou spécialisé, essayez un type de machine standard pour voir si cela résout le problème.

Contacter Cloud Customer Care

Si vous continuez à rencontrer des problèmes d'échec de cluster, contactez Cloud Customer Care. Décrivez le problème d'échec du cluster et les étapes de dépannage effectuées. Fournissez également les informations suivantes :

  • Données de diagnostic du cluster
  • Résultat de la commande suivante : 
      gcloud dataproc clusters describe CLUSTER_NAME \
      --region=REGION
  • Journaux exportés pour le cluster en échec.

Utiliser l'outil gcpdiag

gcpdiag est un outil Open Source. Il ne s'agit pas d'un produit Google Cloud officiellement pris en charge. Vous pouvez utiliser l'outil gcpdiag pour vous aider à identifier et à résoudre les problèmes liés au projet Google Cloud. Pour plus d'informations, consultez le projet gcpdiag sur GitHub.

L'outil gcpdiag vous aide à identifier les problèmes de création de clusters Managed Service pour Apache Spark suivants en effectuant les vérifications suivantes :

  • Erreurs de rupture de stock : évalue les journaux de l'explorateur de journaux pour détecter les ruptures de stock dans les régions et les zones.
  • Quota insuffisant : vérifie la disponibilité du quota dans le projet de cluster Managed Service pour Apache Spark.
  • Configuration réseau incomplète : effectue des tests de connectivité réseau, y compris des vérifications des règles de pare-feu nécessaires et de la configuration des adresses IP externes et internes. Si le cluster a été supprimé, l'outil gcpdiag ne peut pas effectuer de vérification de la connectivité réseau.
  • Configuration incorrecte entre projets : vérifie les comptes de service entre projets et examine l'application des rôles supplémentaires et des règles d'administration.
  • Rôles IAM manquants pour le réseau cloud privé virtuel partagé : si le cluster Managed Service for Apache Spark utilise un réseau VPC partagé, vérifie l'ajout des rôles de compte de service requis.
  • Échecs d'actions d'initialisation : évalue les journaux de l'explorateur de journaux pour détecter les échecs et les délais d'expiration des scripts d'actions d'initialisation.

Pour obtenir la liste des étapes gcpdiag Dataproc, y compris les étapes de création de cluster, consultez Étapes Managed Service pour Apache Spark.

Exécuter la commande gcpdiag

Vous pouvez exécuter la commande gcpdiag à partir de Cloud Shell dans la consoleGoogle Cloud ou dans un conteneur Docker.

ConsoleGoogle Cloud

  1. Terminez l'exécution, puis copiez la commande suivante. 
    2. gcpdiag runbook managed-spark/cluster-creation \
    --parameter project_id=PROJECT_ID \
    --parameter cluster_name=CLUSTER_NAME \
    --parameter OPTIONAL_FLAGS
  2. Ouvrez la console Google Cloud et activez Cloud Shell.
    3. Ouvrir la console Cloud
  3. Collez la commande copiée.
  4. Exécutez la commande gcpdiag, qui télécharge l'image Docker gcpdiag, puis effectue des vérifications de diagnostic. Le cas échéant, suivez les instructions de sortie pour corriger les échecs de vérification.

Docker

Vous pouvez exécuter gcpdiag à l'aide d'un wrapper qui démarre gcpdiag dans un conteneur Docker. Docker ou Podman doivent être installés.

  1. Copiez et exécutez la commande suivante sur votre station de travail locale.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Exécutez la commande gcpdiag. 
    ./gcpdiag runbook managed-spark/cluster-creation \
    --parameter project_id=PROJECT_ID \
    --parameter cluster_name=CLUSTER_NAME \
    --parameter OPTIONAL_FLAGS

Affichez les paramètres disponibles pour ce runbook.

Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet contenant la ressource
    • CLUSTER_NAME : nom du cluster Managed Service pour Apache Spark cible dans votre projet.
    • OPTIONAL_PARAMETERS : ajoutez un ou plusieurs des paramètres facultatifs suivants. Ces paramètres sont obligatoires si le cluster a été supprimé.
      • cluster_uuid : UUID du cluster Managed Service pour Apache Spark cible dans votre projet.
      • service_account : compte de service VM du cluster Managed Service pour Apache Spark
      • subnetwork : chemin d'URI complet du sous-réseau du cluster Managed Service pour Apache Spark
      • internal_ip_only : vrai ou faux
      • cross_project : ID multiprojet si le cluster Managed Service pour Apache Spark utilise un compte de service de VM dans un autre projet

Options utiles :

Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.

Étapes suivantes