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 de compte de service 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) (consultez Rôles Managed Service pour Apache Spark).

    Solution : identifiez l'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 la 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 pour 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 pour Apache Spark Service Agent 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 zone différente.

  • 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 Google Cloud console.

  • É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. ... Voir le résultat dans : <gs://PATH_TO_STARTUP_SCRIPT_OUTPUT>

    Cause : l'initialisation du nœud de contrôleur du cluster Managed Service pour Apache Spark a échoué.

    Solution:

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

    Cause : l'espace d'adresse 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 avec 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'adresse IP.
    • Attendez que suffisamment d'espace IP 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 se peut que la route vers la passerelle Internet par défaut ou les règles de pare-feusoient manquantes.

    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 autorisant les entrées ou les sorties 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 d'API de contrôle Managed Service pour Apache Spark actuelle. Pour obtenir une adresse IP d'API de contrôle Managed Service pour Apache Spark actuelle, utilisez la commande suivante :
    dig dataproccontrol-REGION.googleapis.com A

    Utilisez l'une des adresses IPv4 de la section de 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 autorisant les sorties sont correctement configurés.

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

  • Erreur due à une mise à jour

    Cause : le cluster a accepté une tâche envoyée au service Managed Service pour Apache Spark, mais n'a pas pu effectuer un scaling à la hausse ou à la baisse manuellement ou via l'autoscaling. Cette erreur peut également être due à une configuration de cluster non standard.

    Solution:

    • Réinitialisation du cluster : ouvrez un ticket d'assistance, incluez un fichier tar de diagnostic, et demandez à ce que le cluster soit réinitialisé à l'état RUNNING.

    • 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 signale 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 d'échec courants.

Symptômes courants

Voici les 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 d'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 des erreurs d'exécution de script et un fichier introuvable.

Examiner les journaux de cluster

Une étape initiale importante lors du diagnostic des échecs de création de clusters consiste à 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 Google Cloud console.
  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. Examinez les entrées de journal :
    • Recherchez les messages de niveau ERROR ou WARNING qui se produisent à peu près au moment de l'échec de la création du cluster.
    • Faites attention aux journaux des composants master-startup, worker-startup et agent pour obtenir des insights sur les problèmes au niveau de la VM ou de l'agent Managed Service pour Apache Spark.
    • Pour obtenir des insights sur les problèmes liés au temps de démarrage de la VM, filtrez les journaux par resource.type="gce_instance" et recherchez les messages 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 de cluster et conseils de dépannage

Cette section décrit les raisons courantes pour lesquelles la création d'un cluster Managed Service pour Apache Spark peut échouer et fournit des conseils de dépannage pour vous aider à résoudre les échecs de cluster.

Autorisations IAM insuffisantes

Le compte de service de la VM utilisé par votre cluster Managed Service pour 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 Google Cloud services.

  • Rôle de nœud de calcul requis : vérifiez que le compte de service de la VM dispose du rôle de 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 de cluster.
  • Autorisations d'accès aux données : si vos tâches lisent ou écrivent dans Cloud Storage ou BigQuery, le compte de service a besoin de 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, tel que le rôle Logging Writer.

Conseils de dépannage

  • Identifier le compte de service : déterminez le compte de service de la VM que votre cluster est configuré pour utiliser. S'il n'est pas spécifié, le compte de service par défaut est le compte de service Compute Engine par défaut.

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

Quotas de ressources dépassés

Les clusters Managed Service pour Apache Spark consomment des ressources à partir de Compute Engine et d'autres Google Cloud services. 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, global pour les adresses IP externes)
    • Quotas de l'API Dataproc, tels que ClusterOperationRequestsPerMinutePerProjectPerRegion

Conseils de dépannage

  • Examiner les quotas : accédez à la page IAM et administration &gt; IAM dans la Google Cloud console. Filtrez par "Service" pour "API Compute Engine" et "API Dataproc".
  • Vérifier 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 création de clusters. Les instances de cluster doivent pouvoir communiquer entre elles et avec les API Google.

  • Réseau VPC et sous-réseau :
    • 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 suffisante d'adresses IP disponibles.
  • Accès privé à Google (PGA) : si les VM du cluster disposent d'adresses IP internes et doivent accéder aux Google APIs 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 pour 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 résolues en adresses IP privées. Notez que l'utilisation de Private Service Connect n'élimine pas la nécessité d'utiliser l'appairage de 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 d'autres réseaux VPC, tels que des projets hôtes de VPC partagé 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, d'un accès privé à Google ou de points de terminaison Private Service Connect.

      • Trafic vers toutes les sources de données ou tous les services externes dont dépendent vos tâches.

  • 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

  • Examiner la configuration réseau : inspectez les paramètres du réseau VPC et du sous-réseau où le cluster est déployé.
  • Vérifier 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é.
  • Tester la connectivité : lancez une VM Compute Engine temporaire dans le sous-réseau du cluster et procédez comme suit :
    • ping ou curl vers des domaines d'API Google externes, tels que storage.googleapis.com.
    • nslookup pour vérifier la résolution DNS en adresses IP attendues (accès privé à Google ou Private Service Connect).
    • Exécutez Google Cloud des tests de connectivité pour diagnostiquer les chemins d'accès d'une VM de test vers les points de terminaison pertinents.

Échecs d'action 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

  • Examiner 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érifier les chemins d'accès et les autorisations des scripts : vérifiez 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 de cluster pour identifier les erreurs. Ajoutez une journalisation détaillée au script.

Disponibilité des ressources régionales (indisponibilité)

Il arrive qu'un type de machine ou une ressource d'une région ou d'une zone connaisse une indisponibilité temporaire. 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 de zone automatique : utilisez la fonctionnalité de sélection de zone automatique de Managed Service pour Apache Spark sélection de zone automatique pour sélectionner automatiquement une zone avec 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
  • Sortie 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 à découvrir les problèmes de création de clusters Managed Service pour Apache Spark suivants en effectuant les vérifications suivantes :

  • Erreurs d'indisponibilité : évalue les journaux de l'explorateur de journaux pour détecter les indisponibilités dans les régions et les zones.
  • Quota insuffisant : vérifie la disponibilité des quotas 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 interprojet incorrecte : recherche les comptes de service interprojets et examine l'application des rôles supplémentaires et des règles d'administration.
  • Rôles IAM de réseau Virtual Private Cloud partagé manquants : si le cluster Managed Service pour Apache Spark utilise un réseau VPC partagé, vérifie l'ajout des rôles de compte de service requis.
  • Échecs d'action d'initialisation : évalue les journaux de l'explorateur de journaux pour détecter les échecs et les délais d'expiration des scripts d'action d'initialisation.

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

Exécuter la commande gcpdiag

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

Google Cloud Console

  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 Google Cloud console 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 de la VM du cluster Managed Service pour Apache Spark .
      • subnetwork : chemin d'accès URI complet du sous-réseau du cluster Managed Service pour Apache Spark .
      • internal_ip_only : Vrai ou faux.
      • cross_project : ID interprojet 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.

Étape suivante