Partager via

Gérer des clusters

  • Article

Cet article décrit la façon dont gérer les clusters Azure Databricks, notamment l’affichage, la modification, le démarrage, l’arrêt, la suppression, le contrôle d’accès et la surveillance des performances et des journaux.

Afficher les clusters

Pour afficher les clusters dans votre espace de travail, cliquez sur compute iconCalcul dans la barre latérale.

Deux colonnes à gauche indiquent si le cluster a été épinglé, ainsi que son état. Pointez le curseur sur l’état pour obtenir plus d’informations.

Épingler un cluster

Le cluster est définitivement supprimé 30 jours après son arrêt. Un administrateur peut épingler le cluster pour conserver une configuration de cluster à usage général après l’arrêt d’un cluster depuis plus de 30 jours. Jusqu’à 100 clusters peuvent être épinglés.

Les administrateurs peuvent épingler un cluster depuis la liste des clusters ou de la page des détails du cluster en cliquant sur l’icône d’épingle.

Vous pouvez également appeler le point de terminaison de l’API Clusters pour épingler un cluster de manière programmatique.

Afficher une configuration de cluster sous forme de fichier JSON

Parfois, il peut être utile d’afficher la configuration de votre cluster au format JSON. Cela s’avère particulièrement utile lorsque vous souhaitez créer des clusters similaires à l’aide de l’API de clusters. Lorsque vous affichez un cluster existant, accédez à l’onglet Configuration, cliquez sur JSON en haut à droite de l’onglet, copiez le fichier JSON, puis collez-le dans votre appel d’API. La vue du JSON est en lecture seule.

Modifier un cluster

Vous pouvez modifier une configuration de cluster à partir de l’IU des détails du cluster. Vous pouvez également appeler le point de terminaison de l’API Clusters pour modifier le cluster de manière programmatique.

Notes

  • Les notebooks et les travaux qui étaient attachés au cluster restent attachés après modification.
  • Les bibliothèques installées sur le cluster restent installées après modification.
  • Si vous modifiez un attribut d’un cluster en cours d’exécution (à l’exception de la taille et des autorisations du cluster), vous devez le redémarrer. Cela peut perturber les utilisateurs qui utilisent actuellement le cluster.
  • Vous pouvez uniquement modifier des clusters en cours d’exécution ou arrêtés. Toutefois, vous pouvez mettre à jour des autorisations de clusters qui ne se trouvent pas dans ces états sur la page des détails du cluster.

Cloner un cluster

Pour cloner un cluster existant, sélectionnez Cloner dans le Kebab menu du cluster (également connu sous le nom de menu à trois points).

Une fois que vous avez sélectionné la fonction de clonage, l’IU de création de cluster s’ouvre avec la configuration du cluster préremplie. Les attributs suivants ne sont pas inclus dans le clone :

  • Autorisations de cluster
  • Bibliothèques installées
  • Notebooks attachés

Contrôler l’accès aux clusters

Le contrôle d’accès au cluster dans la page des paramètres d’administration permet aux administrateurs de l’espace de travail d’accorder à d’autres utilisateurs un accès affiné aux clusters. Il existe deux types de contrôle d'accès au cluster :

  • Autorisation de création de cluster : les administrateurs de l’espace de travail peuvent choisir les utilisateurs autorisés à créer des clusters.
  • Autorisations au niveau du cluster : un utilisateur disposant de l’autorisation Peut gérer pour un cluster peut configurer si d’autres utilisateurs peuvent redémarrer, redimensionner, gérer et attacher à ce cluster.

Si vous souhaitez modifier les autorisations d’un cluster, sélectionnez Modifier les autorisations dans le Kebab menu du cluster.

Pour plus d’informations sur le contrôle d’accès au cluster et les autorisations au niveau du cluster, consultez Contrôle d’accès au cluster.

Terminer un cluster

Pour enregistrer des ressources de cluster, vous pouvez arrêter un cluster. La configuration du cluster terminé est stockée afin qu’elle puisse être ultérieurement réutilisée (ou, dans le cas de tâches, automatiquement démarrée). Vous pouvez arrêter un cluster manuellement ou bien le configurer pour qu’il s’arrête automatiquement après une période d’inactivité spécifiée. Lorsque le nombre de clusters terminés dépasse 150, les clusters les plus anciens sont supprimés.

À moins qu’un cluster ne soit épinglé ou redémarré, il est automatiquement et définitivement supprimé 30 jours après son arrêt.

Les clusters arrêtés apparaissent dans la liste des clusters avec un cercle gris à gauche du nom du cluster.

Notes

Lorsque vous exécutez un travail sur un Nouveau cluster de travail (ce qui est généralement recommandé), le cluster s’arrête et ne peut pas être redémarré lorsque le travail est terminé. D’autre part, si vous planifiez l’exécution d’un travail sur un Cluster à usage général existant qui a été arrêté, ce cluster démarre automatiquement.

Important

Si vous utilisez une Espace de travail d’essai Premium, tous les clusters en cours d’exécution sont arrêtés :

  • Lorsque vous mettez à niveau un espace de travail vers un plan Premium complet.
  • Si l’espace de travail n’est pas mis à niveau et que la période d’essai expire.

Arrêt manuel

Vous pouvez terminer manuellement un cluster à partir de la liste des clusters (en cliquant sur le carré de la ligne du cluster) ou de la page des détails du cluster (en cliquant sur Terminer).

Arrêt automatique

Vous pouvez également définir un arrêt automatique pour un cluster. Pendant la création du cluster, vous pouvez spécifier une période d’inactivité en minutes après laquelle vous souhaitez que le cluster s’arrête.

Si la différence entre l’heure actuelle et la dernière commande exécutée sur le cluster est supérieure à la période d’inactivité spécifiée, Azure Databricks arrête automatiquement ce cluster.

Un cluster est considéré comme inactif lorsque toutes les commandes du cluster, y compris les travaux Spark, Structured Streaming et les appels JDBC, ont terminé leur exécution.

Avertissement

  • Les clusters ne signalent pas l’activité résultant de l’utilisation de DStreams. Cela signifie qu’un cluster s’arrêtant automatiquement peut être arrêté lorsqu’il exécute DStreams. Désactivez l’arrêt automatique pour les clusters exécutant DStreams ou envisagez d’utiliser Structured Streaming.
  • La fonctionnalité d’arrêt automatique analyse uniquement les travaux Spark, pas les processus locaux définis par l’utilisateur. Par conséquent, si tous les travaux Spark sont terminés, vous pouvez arrêter un cluster même si des processus locaux sont en cours d’exécution.
  • Les clusters inactifs continuent à accumuler les frais des instances DBU et Cloud pendant la période d’inactivité avant la fin de l’opération.

Configurer l’arrêt automatique

Vous pouvez configurer l’arrêt automatique dans l’interface utilisateur de création de cluster. Vérifiez que la case est cochée et saisissez un nombre de minutes dans le paramètre Terminer après ___ minutes d’inactivité.

Vous pouvez refuser l’arrêt automatique en décochant la case Arrêt automatique ou en spécifiant une période d’inactivité de 0.

Notes

L’arrêt automatique est mieux pris en charge dans les dernières versions Spark. Les anciennes versions Spark présentent des limitations connues qui peuvent entraîner des rapports inexacts sur l’activité du cluster. Par exemple, les clusters qui exécutent des commandes JDBC, R ou streaming peuvent signaler un temps d’activité obsolète entraînant l’arrêt prématuré du cluster. Effectuez une mise à niveau vers la version la plus récente de Spark pour profiter au maximum des correctifs de bogues et des améliorations de l’arrêt automatique.

Arrêt inattendu

Parfois, un cluster est arrêté de manière inattendue, et non à la suite d’un arrêt manuel ou d’un arrêt automatique configuré.

Pour obtenir la liste des raisons d’arrêt et des étapes de correction, consultez la Base de connaissances.

Supprimer un cluster

La suppression d’un cluster arrête le cluster et supprime sa configuration. Pour supprimer un cluster, sélectionnez Supprimer dans le Kebab menu du cluster.

Avertissement

Vous ne pouvez pas annuler cette action.

Un cluster épinglé doit d’abord être détaché par un administrateur pour être supprimé.

Vous pouvez également appeler le point de terminaison de l’API Clusters pour supprimer un cluster de manière programmatique.

Redémarrer un cluster

Vous pouvez redémarrer un cluster précédemment terminé à partir de la liste des clusters, de la page des détails du cluster ou d’un notebook. Vous pouvez également appeler le point de terminaison de l’API Clusters pour démarrer un cluster de manière programmatique.

Azure Databricks identifie un cluster à l’aide de son ID de cluster unique. Lorsque vous démarrez un cluster terminé, Databricks recrée le cluster avec le même identifiant, installe automatiquement toutes les bibliothèques et rattache les notebooks.

Notes

Si vous utilisez un Espace de travail d’essai gratuit et que la période d’essai a expiré, vous ne pouvez pas démarrer un cluster.

Redémarrer un cluster pour le mettre à jour avec les dernières images

Lorsque vous redémarrez un cluster, celui-ci obtient les dernières images pour les conteneurs de ressources de calcul et les hôtes de machines virtuelles. Il est important de planifier des redémarrages réguliers pour des clusters de longue durée, tels que ceux utilisés pour le traitement de données de diffusion en continu.

Il vous incombe de redémarrer régulièrement toutes les ressources de calcul pour maintenir l’image à jour avec sa dernière version.

Important

Si vous activez le profil de sécurité-conformité pour votre compte ou votre espace de travail, les clusters de longue durée sont automatiquement redémarrés après 25 jours. Databricks recommande aux administrateurs de l’espace de travail de redémarrer manuellement les clusters pendant une fenêtre de maintenance planifiée. Cela réduit le risque d’interruption d’un travail planifié par un redémarrage automatique.

Exemple de Notebook : Recherche de groupes de clusters de longue durée

Si vous êtes un administrateur d’espaces de travail, vous pouvez exécuter un script déterminant la durée d’exécution de chacun de vos clusters, et éventuellement les redémarrer s’ils ont dépassé un nombre spécifié de jours d’exécution. Azure Databricks fournit ce script en tant que notebook.

Les premières lignes du script définissent des paramètres de configuration :

  • min_age_output : nombre maximal de jours d’exécution d’un cluster. 1 constitue la valeur par défaut.
  • perform_restart : si True, le script redémarre les clusters dont le nombre de jours d’exécution est supérieur au nombre de jours spécifié par min_age_output. La valeur par défautFalse identifie les clusters de longue durée mais ne les redémarre pas.
  • secret_configuration : remplacez REPLACE_WITH_SCOPE et REPLACE_WITH_KEY par une étendue de secrets et un nom de clé. Pour plus d’informations sur la configuration des secrets, consultez le notebook.

Avertissement

Si vous définissez perform_restart sur True, le script redémarre automatiquement les clusters éligibles, ce qui peut entraîner l’échec de travaux actifs et la réinitialisation de notebooks ouverts. Pour réduire le risque de perturber les travaux vitaux de votre espace de travail, planifiez une fenêtre de maintenance et veillez à en informer les utilisateurs de l’espace de travail.

Identifier et redémarrer éventuellement un notebook de clusters de longue durée

Obtenir le notebook

Démarrage automatique de cluster pour les tâches et les requêtes JDBC/ODBC

Lorsqu’un travail attribué à un cluster terminé existant est planifié pour s’exécuter ou que vous vous connectez à un cluster terminé à partir d’une interface JDBC/ODBC, le cluster est redémarré automatiquement. Consultez Créer un travail et connexion JDBC.

Le démarrage automatique de clusters vous permet de configurer l’arrêt automatique de clusters, sans nécessiter une intervention manuelle pour redémarrer les clusters pour des travaux planifiés. En outre, vous pouvez planifier l’initialisation du cluster en planifiant l’exécution d’un travail sur un cluster arrêté.

Avant qu’un cluster ne soit redémarré automatiquement, les autorisations de contrôle d’accès du cluster et du travail sont vérifiées.

Notes

Si votre cluster a été créé sur la plateforme Azure Databricks version 2.70 ou antérieure, il n’existe pas de démarrage automatique : les travaux planifiés pour s’exécuter sur les clusters arrêtés échoueront.

Afficher des informations de cluster dans l’IU Apache Spark

Vous pouvez afficher des informations détaillées sur les tâches Spark en sélectionnant l’onglet IU Spark dans la page de détails du cluster.

Si vous redémarrez un cluster terminé, l’interface utilisateur Spark affiche des informations sur le cluster redémarré, pas des informations d’historique pour le cluster arrêté.

Afficher les journaux de cluster

Azure Databricks fournit trois types de journalisation de l’activité liée aux clusters :

  • Les journaux des événements de cluster, qui capturent les événements de cycle de vie du cluster, tels que la création, l’arrêt et les modifications de configuration.
  • Les journaux worker et des pilotes Apache Spark, que vous pouvez utiliser pour le débogage.
  • Les journaux de scripts d’initialisation de cluster, qui sont utiles pour le débogage des scripts d’initialisation.

Cette section décrit les journaux des événements de cluster et les journaux des pilotes et des Worker. Pour plus d’informations sur les journaux init-script, consultez Journalisation des scripts d’initialisation.

Journaux des événements de cluster

Le journal des événements de cluster affiche les événements importants du cycle de vie du cluster qui sont déclenchés manuellement par des actions utilisateur ou automatiquement par Azure Databricks. Ces événements affectent le fonctionnement du cluster dans son ensemble et les travaux en cours d’exécution dans le cluster.

Pour plus d’informations sur les types d’événements pris en charge, consultez la structure de données de l’API de Clusters.

Les événements sont stockés pendant 60 jours, ce qui est comparable à d’autres durées de conservation des données dans Azure Databricks.

Afficher un journal des événements de cluster

Si vous souhaitez afficher le journal des événements du cluster, sélectionnez l’onglet Journal des événements dans les pages des détails du cluster.

Pour obtenir plus d’informations sur un événement, cliquez sur sa ligne dans le journal, puis sur l’onglet JSON pour afficher plus de détails.

Journaux worker et des pilotes du cluster

Les instructions directes d’impression et de journal de vos notebooks, travaux et bibliothèques sont dirigées vers les journaux des pilotes Spark. Vous pouvez accéder à ces fichiers à partir de l’onglet Journaux du pilote dans la page de détails du cluster. Cliquez sur le nom d’un fichier journal pour le télécharger.

Ces journaux ont trois sorties :

  • Sortie standard
  • Erreur standard
  • Journaux Log4j

Utilisez l’onglet IU Spark pour afficher les journaux Worker Spark. Vous pouvez également configurer un emplacement de livraison des journaux pour le cluster. Les journaux de Worker et de cluster sont remis à l’emplacement que vous spécifiez.

Superviser la performance

Pour vous aider à surveiller les performances des clusters Azure Databricks, cette dernière permet d’accéder aux métriques à partir de la page des détails du cluster. Azure Databricks fournit l’accès aux métriques Ganglia pour Databricks Runtime 12.2 et ses versions antérieures. Les métriques de cluster sont fournies par Azure Databricks pour Databricks Runtime 13.0 et ses versions ultérieures.

En outre, vous pouvez configurer un cluster Azure Databricks pour envoyer des métriques à un espace de travail Log Analytics dans Azure Monitor, la plateforme de monitoring pour Azure.

Vous pouvez également installer des agents Datadog sur des nœuds de cluster pour envoyer des métriques Datadog à votre compte Datadog.

Métriques de cluster

Les métriques de cluster sont l’outil de supervision par défaut pour Databricks Runtime 13.0 et ses versions ultérieures. Pour accéder à l’IU des métriques de cluster, accédez à l’onglet Métriques sur la page des détails du cluster.

Vous pouvez afficher les métriques historiques en sélectionnant une plage de temps à l’aide du filtre du sélecteur de dates. Les métriques sont collectées toutes les minutes. Vous pouvez également obtenir les dernières métriques en cliquant sur le bouton Actualiser. Pour plus d’informations, consultez Afficher les métriques de cluster en direct et historiques.

Métriques Ganglia

Notes

Les métriques Ganglia sont disponibles uniquement pour Databricks Runtime 12.2 et ses versions antérieures.

Pour accéder à l’interface utilisateur Ganglia, accédez à l’onglet Métriques sur la page Détails du cluster. Les métriques de l’UC sont disponibles dans l’interface utilisateur Ganglia pour tous les runtimes Databricks. Les métriques GPU sont disponibles pour les clusters compatibles GPU.

Pour afficher les métriques en temps réel, cliquez sur le lien de l’interface utilisateur Ganglia.

Pour afficher l’historique des métriques, cliquez sur un fichier de capture instantanée. La capture instantanée contient des métriques agrégées pour l’heure précédant l’heure sélectionnée.

Notes

Ganglia n’est pas prise en charge avec les conteneurs Docker. Les métriques Ganglia ne sont pas disponibles si vous utilisez un conteneur Docker avec votre cluster.

Configurer la collecte de métriques Ganglia

Par défaut, Azure Databricks collecte les métriques Ganglia toutes les 15 minutes. Pour configurer la période de collecte, définissez la variable d’environnement DATABRICKS_GANGLIA_SNAPSHOT_PERIOD_MINUTES à l’aide d’un script d’initialisation ou dans le champ spark_env_vars de l’API Création d’un nouveau cluster.

Azure Monitor

Vous pouvez configurer un cluster Azure Databricks pour envoyer des métriques à un espace de travail Log Analytics dans Azure Monitor, la plateforme de monitoring pour Azure. Pour obtenir des instructions complètes, consultez Monitoring de Azure Databricks.

Notes

Si vous avez déployé l’espace de travail Azure Databricks dans votre propre réseau virtuel et que vous avez configuré des groupes de sécurité réseau (NSG) pour refuser tout le trafic sortant qui n’est pas requis par Azure Databricks, vous devez configurer une règle de trafic sortant supplémentaire pour l’étiquette de service « AzureMonitor ».

Exemple de Notebook : Métriques Datadog

Datadog metrics

Vous pouvez installer des agents Datadog sur des nœuds de cluster pour envoyer des métriques Datadog à votre compte Datadog. Le notebook suivant montre comment installer un agent Datadog sur un cluster à l’aide d’un script d’initialisation à l’échelle du cluster.

Pour installer l’agent Datadog sur tous les clusters, gérez le script d’initialisation de l’étendue du cluster à l’aide d’une stratégie de cluster.

Installer le notebook de script d’initialisation de l’agent Datadog

Obtenir le notebook

Désactiver des instances Spot

Étant donné que les instances Spot peuvent réduire les coûts, la création de clusters à l’aide d’instances Spot plutôt que d’instances à la demande est un moyen courant d’exécuter des travaux. Toutefois, les instances Spot peuvent être reportées par les mécanismes de planification du fournisseur de Cloud. La report des instances Spot peut entraîner des problèmes avec les travaux en cours d’exécution, notamment :

  • Des défaillances de récupération (fetch) de données de lecture aléatoire
  • La perte de données de lecture aléatoire
  • La perte de données RDD
  • Échecs des travaux

Vous pouvez activer la mise hors service pour aider à résoudre ces problèmes. La mise hors service tire parti de la notification que le fournisseur de Cloud envoie généralement avant qu’une instance Spot soit retirée. Lorsqu’une instance Spot contenant un exécuteur reçoit une notification de report, le processus de mise hors service tente de migrer les données de lecture aléatoire et RDD vers des exécuteurs sains. La durée avant le report final est généralement de 30 secondes à 2 minutes en fonction du fournisseur de Cloud.

Databricks recommande l’activation de la migration des données lorsque la mise hors service est également activée. En règle générale, le risque d’erreurs diminue au fur et à mesure que les données sont migrées, y compris les défaillances de récupération (fetch) de données de lecture aléatoire, la perte de données de lecture aléatoire et la perte de données RDD. La migration des données peut également entraîner moins de recalcul et réduire les coûts.

Notes

La désaffectation est le meilleur effort et elle ne garantit pas que toutes les données peuvent être migrées avant une préemption finale. La mise hors service ne peut pas garantir l’arrêt des défaillances de récupération (fetch) de données de lecture aléatoire lorsque des tâches en cours d’exécution récupèrent des données aléatoires à partir de l’exécuteur.

Lorsque la mise hors service est activée, les échecs de tâches dus au report d’une instance Spot ne sont pas ajoutés au nombre total de tentatives ayant échoué. Les échecs de tâches provoqués par le report ne sont pas comptabilisés comme des tentatives ayant échoué, car la cause de l’échec est externe à la tâche et n’entraîne pas d’échec de la tâche.

Activer la désaffectation

Pour activer la désaffectation sur un cluster, saisissez les propriétés suivantes dans l’onglet Spark sous Options avancées dans l’IU de configuration du cluster. Pour plus d’informations sur ces propriétés, consultez configuration Spark.

  • Pour activer la désaffectation pour les applications, saisissez cette propriété dans le champ de configuration Spark :

    spark.decommission.enabled true

  • Pour activer la migration aléatoire des données pendant la désaffectation, saisissez cette propriété dans le champ de configuration Spark :

    spark.storage.decommission.enabled true
spark.storage.decommission.shuffleBlocks.enabled true

  • Pour activer la migration des données de cache RDD pendant la désaffectation, saisissez cette propriété dans le champ de configuration Spark :

    spark.storage.decommission.enabled true
spark.storage.decommission.rddBlocks.enabled true

    Notes

    Lorsque la réplication RDD StorageLevel est définie sur une valeur supérieure à 1, Databricks ne recommande pas l’activation de la migration des données RDD puisque les réplicas garantissent que les RDD ne perdront pas de données.

  • Pour activer la désaffectation des workers, saisissez cette propriété dans le champ Variables d’environnement :

    SPARK_WORKER_OPTS="-Dspark.decommission.enabled=true"

Afficher l’état de désaffectation et la raison de la perte dans l’IU

Pour accéder à l’état de désaffectation d’un worker depuis l’IU, accédez à l’onglet IU du cluster Spark - Master :

Une fois la désaffectation terminée, vous pouvez afficher la raison de la perte de l’exécuteur dans l’onglet Exécuteurs de > l’IU Spark sur la page des détails du cluster.