Résoudre les problèmes de calcul

Cet article vous fournit des ressources que vous pouvez utiliser dans le cas où vous devez résoudre des problèmes de comportement de calcul dans votre espace de travail. Les rubriques de cet article concernent les problèmes de démarrage du calcul.

Pour obtenir d’autres résolutions de problèmes, consultez :

• Débogage avec l’interface utilisateur Spark
• Diagnostiquer des problèmes de coût et de performances à l’aide de l’interface utilisateur Spark
• Gestion de grandes requêtes dans des workflows interactifs.

Utiliser l’Assistant pour déboguer les erreurs d’environnement de calcul

L’Assistant Databricks peut vous aider à diagnostiquer et suggérer des correctifs pour les erreurs d’installation de bibliothèque.

Sur la page Bibliothèques de l'unité de calcul, Le bouton Diagnostiquer l’erreur s’affiche à côté du nom du paquet ayant échoué et sur la fenêtre détaillée qui s’affiche lorsque vous cliquez sur le paquet ayant échoué. Cliquez sur l’icône Sparkle. Utilisez l’Assistant pour diagnostiquer l’erreur et vous aider à la résoudre. L’Assistant diagnostiquera l’erreur et suggérera des solutions possibles.

Vous pouvez également utiliser l’Assistant pour déboguer les erreurs d’environnement de calcul dans un notebook. Consultez les erreurs d’environnement de débogage.

Un nouveau calcul ne répond pas ou l’erreur « le réseau du plan de calcul est mal configuré » est consignée dans le journal des événements

Problème : après le déploiement d’un espace de travail réussi, votre premier calcul de test ne répond pas. Après environ 20 à 30 minutes, si vous consultez le journal des événements de votre calcul, un message d’erreur semblable au suivant s’affiche :

The compute plane network is misconfigured. Please verify that the network for your compute plane is configured correctly. Error message: Node daemon ping timeout in 600000 ms …

Cause : le message d’erreur précédent indique que le routage ou le pare-feu est incorrect. Azure Databricks a demandé des instances de machine virtuelle pour un nouveau calcul, mais le démarrage de l’instance de machine virtuelle et sa connexion au plan de contrôle ont été longuement retardés. Le gestionnaire de calcul termine les instances et signale cette erreur.

Correctif recommandé : votre configuration réseau doit autoriser les instances de nœud de calcul à se connecter au plan de contrôle Databricks. Pour une technique de résolution des problèmes plus rapide que l’utilisation d’un calcul, vous pouvez déployer une instance de machine virtuelle dans l’un des sous-réseaux de l’espace de travail et effectuer des étapes de dépannage réseau classiques telles que nc, ping, telnet ou traceroute.

Consultez les adresses du plan de contrôle Azure Databricks pour les domaines d’accès, adresses IP et relais CNAMEs par région. Pour le stockage d’artefacts, vérifiez qu’il existe une connexion réseau opérationnelle vers Azure Blob Storage.

L’exemple suivant utilise la région Azure westus :

# Verify access to the web application
nc -zv 40.118.174.12 443
nc -zv 20.42.129.160 443

# Verify access to the secure compute connectivity relay
nc -zv tunnel.westus.azuredatabricks.net 443

# Verify Artifact Blob storage access
nc -zv dbartifactsprodwestus.blob.core.windows.net 443
nc -zv arprodwestusa1.blob.core.windows.net 443
..
nc -zv arprodwestusa15.blob.core.windows.net 443
nc -zv dbartifactsprodwestus2.blob.core.windows.net 443

# Verify Metastore Database access
nc -zv consolidated-westus-prod-metastore.mysql.database.azure.com 3306
nc -zv consolidated-westus-prod-metastore-addl-1.mysql.database.azure.com 3306
nc -zv consolidated-westus-prod-metastore-addl-2.mysql.database.azure.com 3306
nc -zv consolidated-westus-prod-metastore-addl-3.mysql.database.azure.com 3306
nc -zv consolidated-westus2c2-prod-metastore-addl-1.mysql.database.azure.com 3306

# Verify Log Blob storage access
nc -zv dblogprodwestus.blob.core.windows.net 443

Si les commandes précédentes s’exécutent correctement, le chemin de mise en réseau peut être configuré correctement, mais l’utilisation d’un pare-feu peut occasionner un autre problème. Le pare-feu peut effectuer une inspection approfondie des paquets, une inspection SSL ou autre chose qui provoque l’échec des commandes Azure Databricks. En utilisant une instance de machine virtuelle dans le sous-réseau Azure Databricks, exécutez la commande suivante, en remplaçant <token> par votre jeton d’accès personnel et <workspace-url> par l’URL de votre espace de travail :

curl -X GET -H 'Authorization: Bearer <token>' [https://](https://):re[workspace-url]/api/2.0/clusters/spark-versions

En cas d’échec de la requête précédente, réexécutez la commande avec l’option -k pour supprimer la vérification SSL. Si cela fonctionne, alors le pare-feu provoque un problème avec des certificats SSL.

Examinez les certificats SSL en exécutant la commande suivante, en remplaçant <workspace-url> par l’URL de votre espace de travail :

openssl s_client -showcerts -connect <workspace-url>:443

La commande précédente affiche le code de retour et les certificats Azure Databricks. S’il retourne une erreur, votre pare-feu peut être mal configuré.

Remarquez que les problèmes SSL ne sont pas un problème lié à la couche réseau. L’affichage du trafic sur le pare-feu n’affiche pas ces problèmes SSL. L’analyse des requêtes de source et de destination fonctionne comme prévu.

Problèmes liés à l’utilisation de votre metastore ou événements METASTORE_DOWN figurant dans le journal des événements du calcul

Problème : votre espace de travail semble être configuré et vous pouvez configurer le calcul, mais vous avez METASTORE_DOWN des événements dans votre journal des événements de calcul, ou votre metastore ne semble pas fonctionner.

Correctif recommandé : assurez-vous d’utiliser un pare-feu d’applications web (WAF) comme proxy Squid. Les membres de calcul doivent se connecter à plusieurs services qui ne fonctionnent pas avec un WAF.