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 principal qui tente de créer le cluster Dataproc ne dispose pas des autorisations nécessaires pour utiliser le compte de service spécifié. Les utilisateurs de Dataproc doivent disposer de l'autorisation de compte de service ActAs pour déployer des ressources Dataproc. Cette autorisation est incluse dans le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) (voir Rôles Dataproc).

    Solution : identifiez l'utilisateur ou le compte de service qui tente de créer le cluster Dataproc. Attribuez à ce 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 Dataproc).

  • 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 Dataproc à l'aide d'un réseau VPC dans un autre projet et que le compte de service de l'agent de service Dataproc 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:

  • 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 la sortie dans : <gs://PATH_TO_STARTUP_SCRIPT_OUTPUT>

    Cause : l'initialisation du nœud de contrôleur du cluster Dataproc 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 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 dépassé pour que l'instance DATAPROC_CLUSTER_VM_NAME se signale ou Le réseau est inaccessible : dataproccontrol-REGION.googleapis.com

    Cause : ces messages d'erreur indiquent que la configuration réseau de votre cluster Dataproc est incomplète : il se peut que la route vers la passerelle Internet par défaut ou les règles de pare-feu soient 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 Dataproc. Le résultat de ce test vous aidera à déterminer si les règles de pare-feu d'autorisation 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 Dataproc et une adresse IP actuelle de l'API de contrôle Dataproc. Pour obtenir une adresse IP actuelle de l'API de contrôle Dataproc, exécutez la commande suivante :
    dig dataproccontrol-REGION.googleapis.com A

    Utilisez l'une des adresses IPv4 de la section de réponse de la sortie.

    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 d'autorisation 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é une tâche envoyée au service Dataproc, mais n'a pas pu être mis à l'échelle 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 Dataproc.

Lorsqu'un cluster Dataproc 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 enregistré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 des erreurs d'exécution de script et des fichiers introuvables.

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 Dataproc :
    • Dans le menu déroulant Ressource, sélectionnez Cloud Dataproc 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 Dataproc.
    • 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 Dataproc peut échouer et fournit des conseils de dépannage pour vous aider à résoudre les problèmes d'échec de cluster.

Autorisations IAM insuffisantes

Le compte de service de VM utilisé par votre cluster Dataproc 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 VM dispose du rôle Nœud de calcul Dataproc (roles/dataproc.worker). Ce rôle dispose des autorisations minimales requises pour que Dataproc 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 VM que votre cluster est configuré pour utiliser. S'il n'est pas spécifié, la valeur par défaut est le compte de service par défaut de Compute Engine.

  • Vérifier les rôles IAM : accédez à la page IAM et administration > IAM de la Google Cloud console, recherchez le compte de service de 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 Dataproc consomment des ressources 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 Dataproc 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 > IAM de 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 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 Dataproc 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 Dataproc dépend, 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 aux points de terminaison pertinents.

Échecs d'action d'initialisation

Les actions d'initialisation Dataproc sont des scripts qui s'exécutent sur les VM de 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 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 automatique des zones : utilisez la fonctionnalité de sélection automatique des zones de Dataproc pour 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 de 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 à découvrir les problèmes de création de clusters Dataproc 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 Dataproc.
  • 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 Cloud privé virtuel partagé manquants : si le cluster Dataproc 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'attente des scripts d'action d'initialisation.

Pour obtenir la liste des étapes de création de cluster gcpdiag, consultez la section Étapes potentielles.

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 dataproc/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 dataproc/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 Dataproc 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 Dataproc cible dans votre projet
      • service_account : compte de service de VM du cluster Dataproc
      • subnetwork : chemin d'accès URI complet du sous-réseau du cluster Dataproc
      • internal_ip_only : Vrai ou faux
      • cross_project : ID interprojet si le cluster Dataproc 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