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

Utiliser l'outil gcpdiag

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

L'outil gcpdiag vous aide à identifier les problèmes de création de clusters Dataproc 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 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 inter-projets incorrecte : vérifie les comptes de service inter-projets et examine l'application des rôles et des règles d'administration supplémentaires.
  • Rôles IAM manquants pour le réseau de cloud privé virtuel partagé : si le cluster Dataproc 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 de création de clusters gcpdiag, consultez Étapes potentielles.

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 dataproc/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 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 : le compte de service de VM du cluster Dataproc
      • subnetwork : chemin d'accès complet à l'URI du sous-réseau du cluster Dataproc
      • internal_ip_only : vrai ou faux
      • cross_project : ID multiprojet 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.

Comprendre et corriger les erreurs de création de cluster

Cette section répertorie les messages d'erreur Dataproc, ainsi que leurs causes et solutions courantes.

  • 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 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 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 : L'initialisation du nœud du contrôleur de cluster Dataproc a échoué.

    Solution :

  • Échec de la création du cluster : espace d'adresses 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 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 comporte plus de fichier Release

    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 Dataproc 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 Dataproc. 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 Dataproc et une adresse IP actuelle de l'API de contrôle Dataproc. Pour obtenir l'adresse IP actuelle de l'API de contrôle Dataproc, utilisez la commande suivante :
    dig dataproccontrol-REGION.googleapis.com A

    Utilisez l'une des adresses IPv4 de la section "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 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 Dataproc, mais n'a pas pu être mis à l'échelle 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 Dataproc.

Lorsqu'un cluster Dataproc 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 d'échec courants.

Problèmes constatés et messages d'erreur courants

Voici les symptômes et messages d'erreur 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 clusters 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 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. Examiner les entrées de journal :
    • Recherchez les messages de niveau ERROR ou WARNING qui se sont produits peu avant l'échec de la création du cluster.
    • Portez une attention particulière aux journaux des composants master-startup, worker-startup et agent pour obtenir des informations sur les problèmes au niveau de la VM ou de l'agent Dataproc.
    • 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 décrit les raisons courantes pour lesquelles la création d'un cluster Dataproc peut échouer et fournit des conseils de dépannage pour résoudre les problèmes liés aux clusters.

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 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 Dataproc (roles/dataproc.worker). Ce rôle dispose des autorisations minimales requises pour que Dataproc 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 elle n'est pas 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 Dataproc 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 Dataproc 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 dans 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 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 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 Dataproc, 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 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 Dataproc 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 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 Dataproc pour sélectionner automatiquement une zone avec de la 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 l'assistance 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.

Étapes suivantes