Gérer des clusters

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 des clusters

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

La page Calcul affiche les clusters sous deux onglets : les Clusters à usage général et lesClusters de travail.

all-purpose clusters

job clusters

Pour chaque cluster, cette page affiche :

  • Nom du cluster
  • State
  • Nombre de nœuds
  • Version de Databricks Runtime
  • Type de nœuds pilote et nœuds Worker
  • Créateur de cluster ou propriétaire de l’exécution travail

En plus des informations générales sur les clusters, l’onglet Clusters à usage général affiche le nombre de notebooks Attached Notebooks attachés au cluster. Au-dessus de la liste se trouve le nombre de clusters épinglés.

Une icône à gauche d’un nom de cluster à usage général indique si le cluster est épinglé, si le cluster est un cluster à concurrence élevée et si le contrôle d’accès à la table est activé :

  • Épinglé Pinned
  • Démarrage Starting, Arrêt Terminating
  • Cluster standard
    • En cours d’exécution Running
    • Arrêté Terminated
  • Cluster à fort accès concurrentiel
    • En cours d’exécution Serverless
    • Arrêté Serverless Terminated
  • accès refusé
    • En cours d’exécution Locked
    • Arrêté Locked Terminated
  • ACL de table activées
    • En cours d’exécution Table ACLs
    • Arrêté Table ACLs Terminated

Les boutons situés à l’extrême droite d’un cluster à usage général permettent d’accéder aux actions arrêter, redémarrer, cloner, autorisationset supprimer.

Interactive cluster actions

Les boutons situés à l’extrême droite d’un cluster de travail permettent d’accéder aux actions arrêter, redémarreret cloner.

Job cluster actions

Filtrer la liste des clusters

Vous pouvez filtrer les listes de clusters à l’aide des boutons et du champ Filtrer en haut à droite :

Filter clusters

  • Pour afficher uniquement les clusters que vous avez créés, cliquez sur Créé par moi.
  • Pour afficher uniquement les clusters qui vous sont accessibles (si le contrôle d’accès au cluster est activé), cliquez sur Accessible par moi.
  • Pour filtrer par une chaîne qui apparaît dans n’importe quel champ, tapez la chaîne dans la zone de texte Filtrer.

Épingler un cluster

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

Vous pouvez épingler un cluster à partir de la liste des clusters ou de la page Détails du cluster :

Épingler un cluster à partir d’une liste de clusters

Pour épingler ou détacher un cluster, cliquez sur l’icône d’épingle à gauche du nom du cluster.

Pin cluster in cluster list

Épingler un cluster à partir de la page Détails du cluster

Pour épingler ou détacher un cluster, cliquez sur l’icône d’épingle à droite du nom du cluster.

Pin cluster in cluster detail

Vous pouvez également appeler le point de terminaison de l’API Pin pour épingler un cluster par programmation.

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 2.0. Lorsque vous affichez un cluster existant, accédez simplement à l’onglet Configuration, cliquez sur JSON en haut à droite de l’onglet, copiez le JSON, puis collez-le dans votre appel d’API. La vue JSON est en lecture seule.

Cluster configuration JSON

Modifier un cluster

Vous modifiez une configuration de cluster à partir de la page Détails du cluster. Pour afficher la page Détails du cluster, cliquez sur le nom du cluster dans la page Calcul.

Cluster detail

Vous pouvez également appeler le point de terminaison de l’API Edit pour modifier le cluster par programmation.

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 ne pouvez modifier que les clusters en cours d’exécution ou arrêtés. Toutefois, vous pouvez mettre à jour les autorisations pour les clusters qui ne se trouvent pas dans ces états sur la page Détails du cluster.

Pour plus d’informations sur les propriétés de configuration de cluster que vous pouvez modifier, consultez Configurer des clusters.

Cloner un cluster

Vous pouvez créer un nouveau cluster en clonant un cluster existant.

  • Liste de clusters

    Clone cluster in cluster list

  • Page Détails du cluster

    Clone cluster in cluster detail

Le formulaire de création de cluster est ouvert prérempli avec la configuration de cluster. Les attributs suivants du cluster existant 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 Console d’administration permet aux administrateurs et aux utilisateurs délégués 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 peuvent choisir les utilisateurs autorisés à créer des clusters.

    Cluster create permission

  • Autorisations au niveau du cluster : Un utilisateur disposant de l’autorisation Peut gérer pour un cluster peut configurer si d’autres utilisateurs peuvent attacher à, redémarrer, redimensionner et gérer ce cluster en cliquant sur l'icône Permissions Icon dans les actions de cluster.

    Cluster permissions

Pour savoir comment configurer le contrôle d’accès au cluster et les autorisations au niveau du cluster, consultez Contrôle d’accès au cluster.

Démarrer un cluster

Outre la création d’un nouveau cluster, vous pouvez également démarrer un cluster précédemment arrêté. Cela vous permet de recréer un cluster précédemment arrêté avec sa configuration d’origine.

Vous pouvez démarrer un cluster à partir de la liste des clusters, de la page Détails du cluster ou d’un notebook.

  • Liste de clusters

    Start cluster from cluster list

  • Page Détails du cluster

    Start cluster from cluster detail

  • Notebook Notebook Attach cluster attach drop-down

    Start cluster from notebook attach drop-down

Vous pouvez également appeler le point de terminaison de l’API Start pour épingler un cluster par programmation.

Azure Databricks identifie un cluster avec un ID de cluster unique. Lorsque vous démarrez un cluster arrêté, Databricks recrée le cluster avec le même ID, 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.

Démarrage automatique de cluster pour les travaux

Lorsqu’un travail attribué à un cluster arrêté existant est planifié pour s’exécuter ou que vous vous connectez à un cluster arrêté à 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 cluster vous permet de configurer des clusters pour qu’ils s’arrêtent automatiquement, sans nécessiter une intervention manuelle pour redémarrer les clusters pour les tâches planifiées. 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.

Arrêter un cluster

Pour enregistrer des ressources de cluster, vous pouvez arrêter un cluster. Un cluster arrêté ne peut pas exécuter de notebooks ou de travaux, mais sa configuration est stockée afin qu’il puisse être réutilisé (ou, dans le cas de certains types de travaux, redémarré automatiquement) ultérieurement. Vous pouvez arrêter un cluster manuellement ou le configurer pour qu’il s’arrête automatiquement après une période d’inactivité spécifiée. Azure Databricks enregistre les informations chaque fois qu’un cluster est arrêté. 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é, il est définitivement et automatiquement supprimé 30 jours après son arrêt.

Termination reason

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 arrêter manuellement un cluster à partir de la liste des clusters ou de la page Détails du cluster.

  • Liste de clusters

    Terminate cluster in cluster list

  • Page Détails du cluster

    Terminate cluster in cluster detail

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é alors qu’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, un cluster peut être arrêté 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 configurez l’arrêt automatique dans le champ Arrêt automatique de la zone Options Autopilot de la page de création du cluster :

Auto termination

Important

La valeur par défaut du paramètre d’arrêt automatique varie selon que vous choisissez de créer un cluster de concurrence standard ou élevée :

  • Les clusters standard sont configurés pour s’arrêter automatiquement après 120 minutes.
  • Les clusters à concurrence élevée sont configurés pour ne pas s’arrêter automatiquement.

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 inattendue

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.

Avertissement

Vous ne pouvez pas annuler cette action.

Vous ne pouvez pas supprimer un cluster épinglé. Pour supprimer un cluster épinglé, celui-ci doit d’abord être détaché par un administrateur.

Pour supprimer un cluster, cliquez sur l’icône Delete Icon dans les actions du cluster, dans l’onglet Clusters de travail ou Clusters à usage général.

Delete cluster

Vous pouvez également appeler le point de terminaison d’API Permanent delete pour supprimer un cluster par programmation.

Afficher des informations de cluster dans l’interface utilisateur Apache Spark

Des informations détaillées sur les travaux Spark s’affichent dans l’interface utilisateur Spark, à laquelle vous pouvez accéder depuis :

  • La liste des clusters : cliquez sur le lien de l'interface utilisateur Spark sur la ligne du cluster.
  • La page Détails du cluster : cliquez sur l’onglet Interface utilisateur Spark.

Spark UI

Vous pouvez obtenir des détails sur les clusters actifs et arrêtés.

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 des journaux de cluster

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

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 Journaux 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 ClusterEventType de l’API REST.

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

  1. Cliquez sur compute iconCalcul dans la barre latérale.

  2. Cliquez sur le nom d’un cluster.

  3. Cliquez sur l’onglet Journal des événements.

    Event log

Pour filtrer les événements, cliquez sur le Menu Dropdown dans le champ Filtrer par type d'événement… et sélectionnez une ou plusieurs cases de type d'événement.

Utilisez Sélectionner tout pour faciliter le filtrage en excluant des types d’événements spécifiques.

Filter event log

Afficher les détails des événements

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

Event details

Journaux des pilotes et des Worker de 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. Ces journaux ont trois sorties :

  • Sortie standard
  • Erreur standard
  • Journaux Log4j

Pour accéder à ces fichiers journaux des pilotes à partir de l’interface utilisateur, accédez à l’onglet Journaux des pilotes sur la page Détails du cluster.

Driver logs

Les fichiers journaux sont régulièrement permutés. Les fichiers journaux plus anciens apparaissent en haut de la page, avec les informations d’horodatage. Vous pouvez télécharger les journaux à des fins de dépannage.

Pour afficher les journaux des Worker Spark, vous pouvez utiliser l’interface utilisateur Spark. Vous pouvez également configurer un emplacement de remise des journaux pour le cluster. Les journaux de Worker et de cluster sont remis à l’emplacement que vous spécifiez.

Surveiller les performances

Pour vous aider à surveiller les performances des clusters Azure Databricks, Azure Databricks permet d’accéder aux métriques Ganglia à partir de la page Détails du cluster.

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 installer des agents Datadog sur des nœuds de cluster pour envoyer des métriques Datadog à votre compte Datadog.

Métriques Ganglia

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.

Ganglia metrics

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.

Configurer la collecte des métriques

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 de 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 ».

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, utilisez un script d’initialisation global après avoir testé le script d’initialisation à l’échelle du cluster.

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

Obtenir le notebook

Désactiver des instances Spot

Notes

Cette fonctionnalité est disponible sur Databricks Runtime 8.0 et versions ultérieures.

É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.

La mise hors service est le meilleur effort et elle ne garantit pas que toutes les données peuvent être migrées avant le report final. 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.

Pour activer la mise hors service, vous devez définir les paramètres de configuration et les variables d’environnement Spark lorsque vous créez un cluster :

  • Pour activer la mise hors service des applications :

    spark.decommission.enabled true
    
  • Pour activer la migration des données de lecture aléatoire pendant la mise hors service :

    spark.storage.decommission.enabled true
    spark.storage.decommission.shuffleBlocks.enabled true
    
  • Pour activer la migration des données de cache RDD pendant la mise hors service :

    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.

    spark.storage.decommission.enabled true
    spark.storage.decommission.rddBlocks.enabled true
    
  • Pour activer la mise hors service pour les Workers :

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

Pour définir ces propriétés de configuration Spark personnalisées :

  1. Dans la page Nouveau cluster, cliquez sur le bouton activer/désactiver Options avancées.

  2. Cliquez sur l’onglet Spark.

    Decommission Config

Pour accéder à l’état de mise hors service d’un Worker depuis l’interface utilisateur, accédez à l’onglet Interface utilisateur du cluster Spark - Master :

Decommission Worker In UI

Une fois la mise hors service terminée, l’exécuteur qui a été mis hors service affiche la raison de la perte dans l’onglet des Exécuteurs de l’interface utilisateur> Spark sur la page Détails du cluster :

Decommission Executor In UI

Decommission Executor In Timeline