Partager via

Fiabilité dans Azure Databricks

Azure Databricks est une plateforme d’IA et de données apache Spark collaborative optimisée pour Microsoft Azure. Il fournit un environnement unifié pour les charges de travail Big Data et IA et combine le meilleur de Databricks et Azure pour simplifier l’ingénierie des données, la science des données et le Machine Learning.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment Azure Databricks gère la résilience contre diverses pannes et problèmes potentiels et comment vous pouvez configurer la résilience pour répondre à vos besoins. Les instructions couvrent les pannes temporaires, les pannes de zone de disponibilité, les pannes de région et la maintenance des services. Cet article explique également comment utiliser des sauvegardes pour récupérer à partir d’autres problèmes et met en évidence des informations clés sur le contrat de niveau de service Azure Databricks (SLA).

Recommandations concernant le déploiement de production

Pour savoir comment déployer Azure Databricks pour prendre en charge les exigences de fiabilité de votre solution et comment la fiabilité affecte d’autres aspects de votre architecture, consultez les meilleures pratiques d’architecture pour Azure Databricks.

Vue d’ensemble de l’architecture de fiabilité

Vous devez comprendre la fiabilité de chaque composant principal dans Azure Databricks :

  • Le plan de contrôle est une collection de services sans état qui gère les métadonnées de l’espace de travail, l’accès utilisateur, la planification des travaux et la gestion des clusters. Ces services sont soutenus par des bases de données répliquées entre les zones de disponibilité dans les régions prises en charge.

  • La racine du système de fichiers Databricks (DBFS) est un compte de stockage que Azure Databricks provisionne automatiquement lorsque vous créez un espace de travail Azure Databricks dans votre compte cloud. Nous vous recommandons de ne pas stocker de données sur la racine DBFS et de désactiver ce compte de stockage si possible.

  • Le stockage catalogue Unity inclut un ou plusieurs comptes de stockage qui stockent vos données Unity Catalog dans votre compte cloud. Pour plus d’informations, consultez vue d’ensemble du catalogue Unity.

  • Le plan de calcul exécute des charges de travail de traitement des données à l’aide de clusters de machines virtuelles. Le plan de calcul gère les erreurs temporaires et remplace automatiquement les nœuds ayant échoué sans intervention de l’utilisateur. Vous pouvez choisir parmi plusieurs types de ressources de calcul. Pour plus d’informations, consultez Calcul.

    La disponibilité de l’espace de travail dépend de la disponibilité du plan de contrôle, mais les clusters de calcul peuvent continuer à traiter des travaux même pendant les interruptions du plan de contrôle.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Vous pouvez gérer les nouvelles tentatives pour les tâches dans Lakeflow Jobs, ce qui simplifie la récupération après des erreurs transitoires.

Pour les applications qui s’exécutent sur Azure Databricks, implémentez une logique de nouvelle tentative avec interruption exponentielle lorsque vous vous connectez à des services externes ou à des services Azure, tels que Stockage, Azure SQL Database ou Azure Event Hubs. Databricks Runtime inclut une résilience intégrée pour de nombreux services Azure, mais votre code d’application doit gérer les défaillances temporaires spécifiques au service.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Azure Databricks prend en charge la redondance de zone pour chaque composant :

  • Plan de contrôle : Dans les régions qui prennent en charge les zones de disponibilité, le plan de contrôle s’exécute dans plusieurs zones de disponibilité. Le plan de contrôle gère automatiquement les défaillances de zone, avec un impact minimal et aucune intervention de l’utilisateur n’est requise.

    Les données de l’espace de travail du plan de contrôle sont stockées dans des bases de données. Dans les régions qui prennent en charge les zones de disponibilité, les bases de données sont répliquées sur plusieurs zones de la région. Les comptes de stockage qui servent des images Databricks Runtime sont également redondants à l’intérieur de la région. Toutes les régions disposent de comptes de stockage secondaires, utilisés lorsque le compte de stockage principal est hors service.

  • Racine DBFS : Dans les régions qui prennent en charge les zones de disponibilité, vous pouvez configurer le compte de stockage pour la racine DBFS afin d’utiliser le stockage redondant interzone (ZRS). Dans les régions jumelées qui prennent en charge les zones de disponibilité, vous pouvez éventuellement utiliser le stockage redondant par zones géographiques (GZRS).

  • Plan de calcul : Databricks prend en charge la distribution automatique de zones pour les ressources de calcul, ce qui signifie que vos ressources sont distribuées entre plusieurs zones de disponibilité. Cette distribution vous aide à rendre vos charges de travail de production plus résilientes face aux pannes de zone.

    Lorsque vous utilisez le calcul serverless, vous ne sélectionnez pas explicitement de zones pour votre calcul. Databricks gère la sélection des zones pour les machines virtuelles ainsi que le remplacement des machines virtuelles susceptibles d’être perdues en raison de pannes de zone.

Spécifications

Pour utiliser la prise en charge des zones de disponibilité dans Azure Databricks, vous avez besoin des conditions suivantes :

  • Prise en charge de la région : La prise en charge des zones de disponibilité Azure Databricks est disponible dans toutes les régions Azure qui prennent en charge Azure Databricks et fournissent des zones de disponibilité. Pour obtenir la liste des régions qui prennent en charge Azure Databricks, consultez Produits disponibles par région. Pour obtenir la liste complète des régions qui prennent en charge les zones de disponibilité, consultez les régions Azure qui prennent en charge les zones de disponibilité.

  • Réplication du stockage : Configurez les comptes de stockage d’espace de travail pour utiliser ZRS ou GZRS (le cas échéant).

  • Capacité de calcul : Vérifiez que la capacité de calcul suffisante existe sur plusieurs zones de votre région cible. Azure Databricks distribue automatiquement les nœuds de cluster entre les zones, mais vous devez vérifier que vos types d’instances sélectionnés sont disponibles dans toutes les zones cibles.

Considérations

Azure Databricks distribue automatiquement les nœuds de cluster entre les zones de disponibilité. La distribution dépend de la capacité disponible dans chaque zone. Pendant les périodes à forte demande, les nœuds d’un cluster peuvent être concentrés dans moins de zones. Lorsque vous utilisez le calcul serverless, Azure Databricks gère la sélection des zones pour les machines virtuelles et le remplacement de celles qui pourraient être perdues en cas de pannes de zone.

Coûts

La distribution de zone n’affecte pas les coûts de calcul, car vous payez le même nombre de machines virtuelles, quel que soit leur emplacement de zone de disponibilité. Pour plus d’informations, consultez la tarification des calculs Azure Databricks.

La redondance par défaut pour le compte de stockage managé ou la racine DBFS est un stockage géoredondant (GRS). Le passage à ZRS ou GZRS peut affecter vos coûts de stockage. Pour découvrir plus d’informations, consultez Tarification Stockage Blob Azure.

Configurez la prise en charge des zones de disponibilité

  • Plan de contrôle : Le plan de contrôle prend automatiquement en charge la redondance de zone dans les régions qui ont des zones de disponibilité. Vous n’avez pas besoin de configurer quoi que ce soit.

  • Racine DBFS : Vous pouvez configurer la redondance de zone pour le stockage racine DBFS lorsque vous créez un espace de travail ou modifiez un espace de travail existant :

    • Créez un espace de travail avec stockage racine DBFS redondant interzone : Lorsque vous créez un espace de travail Azure Databricks, vous pouvez éventuellement configurer le compte de stockage associé pour utiliser ZRS ou GZRS au lieu du GRS par défaut. Pour plus d’informations, consultez Modifier les options de redondance du stockage de l’espace de travail.

    • Activez la redondance de zone sur le stockage racine DBFS : Pour les espaces de travail existants, vous pouvez modifier la configuration de redondance du compte de stockage de l’espace de travail en ZRS ou GZRS. Pour plus d’informations sur l’activation de la redondance de zone, consultez Modifier les paramètres de réplication d’un compte de stockage.

  • Plan de calcul : Les nœuds de cluster sont automatiquement distribués entre les zones de disponibilité. Aucune configuration client n’est requise pour la distribution de zone.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsqu’un espace de travail est configuré avec la prise en charge des zones de disponibilité et que toutes les zones de disponibilité sont opérationnelles.

  • Réplication des données entre les zones : La réplication des données pour le stockage d’espace de travail se produit de manière synchrone entre les zones lorsque la racine DBFS utilise un compte ZRS ou GZRS. Cette approche garantit une cohérence forte avec un impact minimal sur les performances.

  • Routage du trafic entre les zones : Azure Databricks distribue automatiquement les nœuds de cluster entre les zones lors de la création du cluster. Le service équilibre la charge de calcul entre les zones tout en conservant la localité des données pour des performances optimales.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsqu’un espace de travail est configuré avec la prise en charge de la zone de disponibilité et qu’il existe une panne de zone de disponibilité.

  • Détection et réponse : Microsoft détecte automatiquement les défaillances de zone et lance des procédures de réponse. Vous n’avez aucune action à entreprendre pour le basculement au niveau de la zone.

  • Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser la page d’état Azure Databricks pour afficher une vue d’ensemble de tous les services Azure Databricks principaux. Vous pouvez également vous abonner aux mises à jour d'état des composants de service individuels et recevoir une alerte lorsque l'état du service auquel vous êtes abonné change.

  • Demandes actives : L’exécution de clusters peut perdre des nœuds dans la zone affectée. Le gestionnaire de cluster demande automatiquement les nœuds de remplacement des zones restantes. Si le nœud pilote est perdu, le cluster et la tâche redémarrent intégralement.

  • Perte de données attendue :

    • Plan de contrôle : Attendez-vous à aucune perte de données lors d’une panne de zone.

    • Racine DBFS : Les données de l’espace de travail restent disponibles si elles utilisent des configurations de stockage ZRS ou GZRS.

    • Plan de calcul : Les données mises en cache sur les machines virtuelles sont éphémères. Toutes les données perdues à partir de machines virtuelles lors d’une défaillance de zone sont récupérées à partir du stockage. Si le nœud pilote est perdu, le travail redémarre et recalcule les résultats.

  • Temps d’arrêt attendu :

    • Plan de contrôle : Le plan de contrôle Databricks effectue un basculement automatique vers des zones saines dans un délai d’environ 15 minutes.

    • Racine DBFS : Aucun temps d'arrêt n'est attendu pour les comptes de stockage qui utilisent ZRS ou GZRS.

    • Plan de calcul : Si les nœuds sont perdus, car leurs machines virtuelles résident dans la zone de disponibilité affectée, le gestionnaire de clusters Azure demande des nœuds de remplacement du fournisseur de calcul Azure. Si les zones saines restantes disposent d’une capacité suffisante pour répondre à la requête, le fournisseur de calcul extrait les nœuds des zones saines pour remplacer les nœuds perdus. Ce processus peut prendre plusieurs minutes.

      Si le nœud pilote est perdu en raison d’une défaillance de zone, l’ensemble du cluster redémarre, ce qui peut entraîner des temps de récupération plus longs que la perte de nœuds Worker. Planifiez ce comportement dans vos stratégies de planification et de supervision des travaux.

      Vous pouvez utiliser des pools serverless ou d’instances pour réduire cette durée.

  • Réacheminement du trafic :

    • Plan de contrôle : Le plan de contrôle Databricks effectue un basculement automatique vers des zones saines dans un délai d’environ 15 minutes.

    • Racine DBFS : Stockage Azure redirige automatiquement les requêtes vers des clusters de stockage situés dans des zones saines.

    • Plan de calcul : Le gestionnaire de cluster bascule automatiquement vers des nœuds dans des zones saines.

Récupération de la zone

Une fois la zone de disponibilité en échec récupérée, Azure Databricks reprend automatiquement les opérations normales dans toutes les zones. Le gestionnaire de cluster peut rééquilibrer la distribution des nœuds pendant les créations de nœuds suivantes, mais les nœuds existants continuent à s’exécuter dans leurs zones actuelles jusqu’à ce qu’ils soient arrêtés.

Vous n’avez aucune action à entreprendre pour les opérations de retour arrière (failback). La distribution de zone normale reprend pour les nouveaux déploiements de cluster.

Tester les pannes de zone

Azure Databricks est un service géré dans lequel Microsoft gère automatiquement le basculement de zone et effectue des tests réguliers de mise hors zone. Vous n’avez pas à évaluer les scénarios de défaillance de zone pour le service lui-même.

Pour vos applications qui s’exécutent sur Azure Databricks, testez la résilience des travaux en simulant des défaillances de nœud de pilote et en surveillant le comportement de redémarrage du cluster. Vérifiez que vos travaux de traitement de données peuvent gérer les redémarrages de cluster et reprendre à partir de points de contrôle appropriés.

Résilience aux défaillances à l’échelle de la région

Azure Databricks est un service à région unique. Si la région n’est pas disponible, votre espace de travail n’est pas disponible également. Si vous avez besoin de déploiements multirégions, consultez la récupération d’urgence d’Azure Databricks.

Solutions multirégions personnalisées pour la résilience

Azure Databricks ne fournit pas de fonctionnalités multirégions intégrées. Pour une protection multirégion complète de vos charges de travail d’analytique, vous devez implémenter votre propre approche.

Les solutions multirégions classiques impliquent deux espaces de travail ou plus. Vous pouvez choisir parmi plusieurs stratégies, notamment les architectures actif-passif et actif-actif.

Pour choisir une architecture, tenez compte des facteurs suivants :

  • Critique de la charge de travail pour votre entreprise
  • Durée potentielle d’une interruption (heures ou éventuellement une journée complète)
  • L’effort nécessaire pour rendre l’espace de travail entièrement opérationnel
  • L’effort nécessaire pour restaurer ou effectuer le retour vers la région principale.

Pour les charges de travail nécessitant une protection multirégion, consultez la récupération d’urgence Azure Databricks.

Sauvegarde et récupération

Azure Databricks sauvegarde automatiquement les bases de données dans le cadre des opérations managées du service. Ce processus inclut le contenu du notebook, les définitions de travaux, les configurations de cluster et les paramètres de contrôle d’accès.

Note

Si une défaillance de zone se produit, Azure Databricks ne s’attend à aucune perte de données.

Nous vous recommandons de stocker vos données sur le stockage du catalogue Unity. Vous pouvez répliquer des données via la réplication de stockage ou le clonage delta.

Les fonctionnalités de sauvegarde et de restauration au niveau de l’espace de travail ne sont pas directement disponibles. Planifiez les procédures de restauration de l'espace de travail qui incluent la remise en place des configurations, des utilisateurs et des contrôles d'accès à partir de vos processus de synchronisation.

Résilience à la maintenance du service

Azure Databricks effectue une maintenance automatique de la plateforme pour appliquer des mises à jour de sécurité, déployer de nouvelles fonctionnalités et améliorer la fiabilité du service. Vous pouvez configurer les fenêtres de maintenance de votre cluster pour réduire la probabilité de maintenance affectant vos charges de travail de production. Pour obtenir plus d’informations, consultez Mise à jour automatique de clusters.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Contenu connexe

  • Last updated on