Récupération d'urgence

La récupération d’urgence pour Azure Databricks réplique les espaces de travail, les données et les configurations dans les régions cloud afin que vos équipes continuent de travailler quand une panne régionale met votre déploiement principal hors connexion. Un plan complet de reprise après sinistre couvre non seulement Azure Databricks, mais aussi les sources de données, les outils d’ingestion, les outils décisionnels et les planificateurs auxquels il se connecte.

Cette page présente les concepts, les stratégies, les outils et les procédures de test dont vous avez besoin pour concevoir et mettre en œuvre une solution de reprise après sinistre inter-régions.

Vous débutez avec le plan de reprise après sinistre ? Commencez par la terminologie du secteur de la récupération d’urgence pour les définitions du RPO et du RTO.

Importante

Utilisez la récupération d’urgence managée. Azure Databricks recommande la reprise après sinistre managée pour la reprise après sinistre inter-région sur AWS et Azure. Il réplique de façon continue les métadonnées de Unity Catalog, les données des tables gérées et les ressources de l’espace de travail, fournit une URL stable qui reste valable après un basculement, et vous permet de déclencher le basculement depuis la console du compte. Aucun script de réplication à écrire ou à gérer. Utilisez le guide DIY de cette page uniquement pour les ressources que la reprise après sinistre gérée ne réplique pas, ou si vous avez besoin de topologies active-active, d’une réplication intercloud ou d’un contrôle précis du pipeline de réplication.

Garanties de haute disponibilité intrarégion

Le reste de cette page traite de la reprise après sinistre interrégionale, mais Azure Databricks offre également une haute disponibilité (HA) au sein d’une même région. Comprenez d’abord ces garanties. Ils déterminent si vous avez besoin d’une stratégie de récupération d’urgence distincte.

La haute disponibilité et la reprise après sinistre résolvent différents problèmes :

HA utilise la redondance interzones de disponibilité (AZ) au sein d’une région. Si une zone tombe en panne, les services continuent de fonctionner dans les autres zones.
DR utilise la réplication interrégion. Vous exécutez des espaces de travail Azure Databricks secondaires dans une autre région et y répliquez les données et les configurations, puis effectuez le basculement lors d’une panne dans la région.

Si vous n’avez pas besoin d’une reprise après sinistre multirégions, la haute disponibilité d’Azure Databricks peut suffire. La haute disponibilité évite la complexité entre régions, mais ne protège pas contre une panne touchant toute une région. Si vous vous appuyez uniquement sur la HA pour la reprise après sinistre, vérifiez la séparation et la redondance de votre région de cloud.

Les garanties de haute disponibilité intrarégion couvrent le plan de contrôle et le plan de calcul.

Disponibilité du plan de contrôle Azure Databricks

Le plan de contrôle Azure Databricks est résilient aux défaillances de zone et récupère automatiquement dans un délai d’environ 15 minutes d’une défaillance de zone. Des tests réguliers de défaillance de zone le confirment.

Tous les services du plan de contrôle sans état peuvent perdre des machines virtuelles individuelles, voire toutes les machines virtuelles individuelles d’une zone entière, sans interrompre le service. Les données d’espace de travail sont stockées dans les bases de données répliquées entre les 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, et toutes les régions ont des comptes de stockage secondaires qui prennent le relais lorsque le serveur principal est arrêté.

Remarque

Les garanties du plan de contrôle ci-dessus s’appliquent à l’infrastructure gérée par Azure Databricks. Vous êtes responsable de la redondance interzone du plan de calcul, notamment en choisissant un stockage redondant entre zones pour le compartiment racine de l’espace de travail et en utilisant des pools d’instances s’étendant sur plusieurs zones de disponibilité.

Certaines régions Azure utilisent un plan de contrôle déployé dans une région jumelée. Consultez les régions Azure Databricks.

La tolérance aux pannes de zone permet qu’au plus une seule zone soit indisponible et n’est disponible que dans les régions Azure qui prennent en charge plusieurs zones.

Disponibilité du plan de calcul

La disponibilité de l’espace de travail dépend de la disponibilité du plan de contrôle.

Les données racines DBFS ne sont pas affectées si le compte de stockage est configuré avec le stockage redondant interzone (ZRS) ou le stockage géoredondant interzone (GZRS). La valeur par défaut est le stockage géoredondant (GRS).

Les nœuds de cluster sont extraits de différentes zones de disponibilité en demandant des nœuds du fournisseur de calcul Azure, en supposant une capacité suffisante dans les zones restantes. Si un nœud est perdu, le gestionnaire de cluster demande des nœuds de remplacement au fournisseur de calcul Azure, qui les tire des zones de disponibilité accessibles. L’exception se produit lorsque le nœud pilote est perdu. Dans ce cas, le gestionnaire de cluster redémarre le travail et le cluster.

Pour confirmer la prise en charge multi-AZ, consultez la liste des régions Azure. Pour la résilience multi-AZ du plan de calcul, utilisez le stockage redondant entre zones.

Terminologie

Utilisez ces définitions de manière cohérente lors de la discussion sur la récupération d’urgence avec votre équipe.

Terminologie régionale

Terminologie des régions

Cette page utilise les définitions de région suivantes :

Région principale : région où les utilisateurs exécutent des charges de travail d’analytique de données interactives et automatisées quotidiennes.
Région secondaire : région où les équipes informatiques déplacent temporairement des charges de travail pendant une panne de région primaire.
Stockage géoredondant : réplication asynchrone entre régions du stockage persistant. Consultez la documentation de votre cloud :

Stockage géoredondant entre les régions (Azure).

Importante

Ne vous appuyez pas sur le stockage géo-redondant pour dupliquer le stockage racine d’Azure Databricks (tel qu’ADLS (pour les espaces de travail créés avant le 6 mars 2023, Stockage Blob Azure) qu’Azure Databricks crée pour chaque espace de travail) entre les régions. Pour répliquer des données de table managées, utilisez Delta Deep Clone et, pour les données non delta, convertissez d’abord en Delta, dans la cas où cela est possible.

Terminologie de l’état du déploiement

Cette page utilise les définitions d’état de déploiement suivantes :

Déploiement actif (parfois appelé déploiement à chaud) : les utilisateurs se connectent à celui-ci et exécutent des charges de travail. Les travaux et les flux de données s’exécutent ici selon la planification.
Déploiement passif (parfois appelé déploiement à froid) : aucun processus n’est exécuté ici. Les équipes informatiques la tiennent prête en automatisant le déploiement de code, de configuration et d’autres objets Azure Databricks. Un déploiement passif devient actif uniquement lorsque le déploiement actif tombe en panne.

Importante

Un projet peut inclure plusieurs déploiements passifs dans différentes régions pour une résilience supplémentaire.

La plupart des équipes exécutent un déploiement actif à la fois, la stratégie active-passive . La stratégie active-active moins courante repose sur deux déploiements actifs simultanés.

Terminologie du secteur de la récupération d’urgence

Terminologie du secteur d’activité de récupération d’urgence

Définissez ces deux termes du secteur avec votre équipe :

Objectif de point de récupération (RPO) : la période maximale de perte de données que votre service peut tolérer pendant un incident majeur. Voir RPO.

Azure Databricks ne stocke pas vos données client principales. Cela réside dans ADLS (pour les espaces de travail créés avant le 6 mars 2023, Stockage Blob Azure) ou d’autres systèmes que vous contrôlez. Le plan de contrôle Azure Databricks stocke certains objets (tels que les travaux et les notebooks), de sorte que le Azure Databricks RPO est la période maximale pendant laquelle les modifications apportées à ces objets peuvent être perdues. Vous êtes responsable de la définition du RPO pour vos données client dans ADLS (pour les espaces de travail créés avant le 6 mars 2023, Stockage Blob Azure) et d'autres sources de données que vous contrôlez.
Objectif de temps de récupération (RTO) : durée maximale pendant laquelle un processus métier doit être restauré après un sinistre. Voir RTO.

Récupération d’urgence et altération des données

Récupération d’urgence et corruption des données

Une solution de récupération d’urgence n’atténue pas l’altération des données. Les données endommagées dans la région primaire sont répliquées dans la région secondaire et endommagées dans les deux régions. Pour atténuer ce type d’échec, utilisez les déplacements temporels Delta, des outils similaires ou des outils de sauvegarde de données.

Flux de travail de récupération standard

Un scénario de récupération d’urgence Azure Databricks s’exécute généralement comme suit :

Une défaillance atteint un service critique dans votre région primaire : une source de données, un réseau ou une autre dépendance sur laquelle repose le déploiement Azure Databricks.
Vous enquêtez avec votre fournisseur de services cloud.
Si l’attente est inacceptable, vous décidez de basculer vers votre région secondaire.
Vérifiez que le même problème n’affecte pas votre région secondaire.
Basculement (pour plus d’informations, consultez Test de basculement) :
1. Arrêtez toutes les activités de l’espace de travail. Les utilisateurs arrêtent les charges de travail et sauvegardent les modifications récentes dans la mesure du possible. Les tâches s’arrêtent (si la panne ne les a pas déjà fait échouer).
2. Exécutez la procédure de récupération de région secondaire pour mettre à jour le routage et rediriger les connexions et le trafic réseau.
3. Redirigez les systèmes en aval (outils décisionnels, planificateurs, intégrations tierces) vers l’espace de travail secondaire et rétablissez leurs connexions.
4. Après le test, déclarez la région secondaire opérationnelle. Les utilisateurs se connectent au déploiement désormais actif, et vous relancez les tâches planifiées ou différées.
Une fois le problème de région primaire atténué, confirmez le correctif.
Restauration automatique (pour plus d’informations, consultez Restauration de test (restauration automatique)) :
1. Arrêtez tout le travail dans la région secondaire.
2. Exécutez la procédure de récupération de région primaire pour rediriger le routage retour.
3. Répliquez les nouvelles données dans la région primaire. Réduisez ce qui doit être répliqué. Par exemple, les tâches en lecture seule s’exécutant dans le déploiement secondaire peuvent ne pas nécessiter de réécriture.
4. Testez le déploiement dans la région principale.
5. Définissez la région principale comme active et reprenez les charges de travail de production.

Importante

Certaines pertes de données peuvent se produire pendant ces étapes. Définissez la quantité de perte acceptable pour votre organisation et la façon dont vous l’atténuez.

Étape 1 : comprendre les besoins de votre entreprise

Identifiez les services de données critiques et définissez leur RPO cible et leur RTO. Recherchez la tolérance réelle de chaque système.

La reprise après sinistre, le basculement et la restauration automatique entraînent des coûts et des risques bien réels, notamment la corruption des données, la duplication des données (écriture au mauvais emplacement de stockage) et les modifications effectuées par les utilisateurs dans la mauvaise région.

Mappez chaque Azure Databricks point d’intégration qui affecte votre entreprise, puis choisissez les outils et les canaux de communication utilisés par votre plan.

Points d’intégration à mapper

Votre solution de reprise après sinistre doit-elle prendre en charge les processus interactifs, les processus automatisés ou les deux ?
Quels services de données utilisez-vous ? Certains peuvent être sur site.
Comment les données d’entrée sont-elles dans le Cloud ?
Qui utilise-t-il ces données ? Quels sont les processus qui le consomment en aval ?
Existe-t-il des intégrations tierces qui doivent être conscientes des modifications de la reprise après sinistre ?

Outils et communication à planifier

Pouvez-vous prédéfinir votre configuration et la rendre modulaire pour prendre en charge les solutions de récupération d’urgence de manière naturelle et gérable ?
Quels sont les outils de communication et les canaux qui informeront les équipes internes et les tiers (intégrations, consommateurs en aval) du basculement de reprise après sinistre et des changements de restauration automatique ? Comment confirmez-vous leur accusé de réception ?
Quels services, le cas échéant, arrêtez-vous jusqu’à ce que la récupération complète soit en place ?

Étape 2 : choisir un processus qui répond aux besoins de votre entreprise

Valeur par défaut pour la reprise après sinistre gérée. Il gère la réplication de l’espace de travail, les métadonnées d’Unity Catalog, les données des tables gérées et l’orchestration du basculement sans scripts personnalisés. Utilisez le guide DIY ci-dessous uniquement si vous vous trouvez en dehors de son étendue, par exemple, pour les ressources gérées par la reprise après sinistre qui ne répliquent pas, les topologies active-active, la réplication intercloud ou le contrôle précis sur le pipeline de réplication.

Une solution DIY doit répliquer les bonnes données sur le plan de contrôle, le plan de calcul et les sources de données. Les espaces de travail redondants sont mappés à différents plans de contrôle dans différentes régions. Vous les conservez donc synchronisés avec une solution basée sur un script, soit un outil de synchronisation, soit un flux de travail CI/CD. Pour les données proprement dites, la plupart des équipes utilisent des travaux Azure Databricks (souvent planifiés) ou delta Deep Clone pour copier des tables entre les régions. Vous n’avez pas besoin de synchroniser les données depuis le plan de calcul (par exemple, à partir de Databricks Runtime Workers).

Si vous utilisez la fonctionnalité d’injection de réseau virtuel (non disponible avec tous les types d’abonnement et de déploiement), déployez des réseaux de manière cohérente dans les deux régions à l’aide d’outils basés sur des modèles comme Terraform.

Répliquez vos sources de données entre les régions en fonction des besoins.

Les solutions de reprise après sinistre impliquent généralement deux espaces de travail (ou plus). Choisissez parmi les stratégies suivantes selon la durée de perturbation que vous pouvez tolérer, l’effort opérationnel requis et le coût du retour vers la région principale.

Bonnes pratiques générales

Les meilleures pratiques générales pour un plan de récupération d’urgence réussie sont les suivantes :

Comprendre quels processus sont essentiels aux activités et doivent fonctionner en reprise après sinistre.
Identifiez clairement les services impliqués, les données en cours de traitement, le flux de données et l’emplacement où elles sont stockées.
Isolez autant que possible les services et les données. Par exemple, créez un conteneur de stockage cloud spécial pour les données de récupération d’urgence ou déplacez des objets Azure Databricks nécessaires lors d’un sinistre vers un espace de travail distinct.
Vous êtes responsable de la maintenance de l’intégrité entre les déploiements principaux et secondaires pour les objets non stockés dans le plan de contrôle Azure Databricks.
Pour les sources de données, utilisez les outils Azure natifs pour répliquer les données vers vos régions de reprise d’activité lorsque cela est possible.

Avertissement

Ne stockez pas de données dans l'ADLS racine (pour les espaces de travail créés avant le 6 mars 2023, Stockage Blob Azure) utilisés pour l'accès racine DBFS. Le stockage racine DBFS n’est pas pris en charge pour les données client de production. Azure Databricks recommande également de ne pas stocker de bibliothèques, de fichiers de configuration ou de scripts d’initialisation à cet emplacement.

Stratégie de solution active-passive

Cette section se concentre sur la stratégie active-passive, car elle est la plus courante, la plus simple et la plus rentable. Une solution active-passive synchronise les données et les modifications d’objet de votre déploiement actif vers un déploiement passif dans une région secondaire. Pendant un événement de récupération d’urgence, le déploiement passif devient actif.

Deux variantes courantes :

Unifié (à l’échelle de l’entreprise) : un ensemble de déploiements actifs et passifs prend en charge l’ensemble de l’organisation.
Par département ou projet : chaque domaine gère sa propre solution de reprise après sinistre avec des régions primaires et secondaires adaptées à ses besoins.

Vous pouvez également utiliser un déploiement passif pour les charges de travail en lecture seule, telles que les requêtes utilisateur, qui ne modifient pas les données ni les objets Azure Databricks.

Stratégie de solution en mode actif-actif

Stratégie de solution active-active

Dans une solution active-active, tous les processus de données s’exécutent dans les deux régions en parallèle à tout moment. Votre équipe d’exploitation doit marquer chaque tâche comme terminée uniquement après sa réussite dans les deux régions. Les objets ne peuvent pas être modifiés en production et doivent suivre une promotion CI/CD stricte entre le développement/la préproduction et la mise en production.

La stratégie active-active est la plus complexe et coûte plus cher, car les travaux s’exécutent dans les deux régions, mais elle offre les RTO et RPO les plus faibles.

Vous pouvez mettre en œuvre une architecture active-active à l’échelle de toute l’entreprise ou par service. Vous n’avez pas besoin d’un espace de travail en double pour chaque charge de travail. Par exemple, les espaces de travail de développement ou intermédiaires sont souvent plus faciles à reconstruire à partir d’un pipeline de développement que de maintenir la synchronisation.

Choisir vos outils

Il existe deux approches principales pour maintenir la synchronisation des données entre les espaces de travail dans vos régions primaires et secondaires :

Client de synchronisation qui copie de principal à secondaire: un client de synchronisation pousse les données de production et les ressources de la région primaire vers la région secondaire. En règle générale, cela s’exécute sur une base planifiée et la fréquence de planification dépend de votre RTO et de votre RPO cibles.
Outils CI/CD pour le déploiement parallèle: pour le code et les ressources de production, utilisez les outils CICD qui poussent les modifications des systèmes de production simultanément dans les deux régions. Par exemple, lors du passage de code et de ressources de l'environnement intermédiaire/développement à la production, un système CI/CD les rend disponibles dans les deux régions en même temps. L’idée principale est de traiter tous les artefacts dans un espace de travail Azure Databricks en tant qu’infrastructure-comme-code. La plupart des artefacts pourraient être déployés conjointement dans les espaces de travail principal et secondaire, tandis que certains artefacts ne devraient être déployés qu’après un événement de reprise après sinistre. Pour obtenir des outils, consultez scripts d’automatisation, exemples et prototypes.

Selon vos besoins, vous pouvez combiner les approches. Par exemple, utilisez CI/CD pour le code source du notebook, mais utilisez la synchronisation pour la configuration comme les pools et les contrôles d’accès.

Le tableau suivant décrit comment gérer chaque type de données avec chaque option d’outils.

Descriptif	Comment gérer avec les outils d’intégration continue/de CD	Comment gérer avec l’outil de synchronisation
Code source : exportations du code source du notebook et code source pour les bibliothèques packagées	Co-déployez à la fois sur le serveur principal et le serveur secondaire.	Synchronisez le code source du serveur principal vers le serveur secondaire.
Utilisateurs et groupes	Gérez les métadonnées en tant que configuration dans Git. Vous pouvez également utiliser le même fournisseur d’identité (IdP) pour les deux espaces de travail. Co-déployez des données d’utilisateur et de groupe dans des déploiements principaux et secondaires.	Utilisez SCIM ou une autre automatisation pour les deux régions. La création manuelle n’est pas recommandée, mais si elle est utilisée, elle doit être effectuée pour les deux en même temps. Si vous utilisez une configuration manuelle, créez un processus automatisé planifié pour comparer la liste des utilisateurs et des groupes entre les deux déploiements.
Configurations de pool	Il peut s’agir de modèles dans Git. Co-déployez à la fois sur le serveur principal et le serveur secondaire. Toutefois, `min_idle_instances` en secondaire doit être nul jusqu’à l’événement DR.	Pools créés avec n’importe lequel `min_idle_instances` lorsqu’ils sont synchronisés avec l’espace de travail secondaire à l’aide de l’API ou de l’interface CLI.
Configurations du travail	Utilisez databricks Asset Bundles avec des cibles par environnement (par exemple, `prod` et `dr`) pour déployer la même définition de travail dans les deux régions. Pour le déploiement secondaire, réglez la concurrence à zéro afin que la tâche soit mise en attente sans être exécutée. Modifiez la valeur de concurrence après que le déploiement secondaire est devenu actif.	Si, pour une quelconque raison, les travaux s'exécutent sur des clusters existants `<interactive>`, le client de synchronisation doit effectuer un mappage vers le `cluster_id` correspondant dans l'espace de travail secondaire.
Listes de contrôle d'accès (ACL)	Il peut s’agir de modèles dans Git. Effectuez un co-déploiement sur les déploiements principaux et secondaires pour les blocs-notes, les dossiers et les clusters. Toutefois, conservez les données des travaux jusqu’à l’événement de reprise après sinistre.	L’API Permissions peut définir des contrôles d’accès pour les clusters, les travaux, les pools, les notebooks et les dossiers. Un client de synchronisation doit mapper à des ID d’objet correspondants pour chaque objet dans l’espace de travail secondaire. Databricks recommande de créer une carte d’ID d’objet de l’espace de travail principal vers l’espace de travail secondaire tout en synchronisant ces objets avant de répliquer les contrôles d’accès.
Bibliothèques	Inclure dans le code source et les modèles de cluster/tâches.	Synchroniser les bibliothèques personnalisées à partir de référentiels centralisés, DBFS ou le stockage cloud (peut être monté).
Scripts d’initialisation de cluster	Incluez dans le code source si vous préférez.	Pour une synchronisation plus simple, stockez les scripts init dans l’espace de travail principal dans un dossier commun ou dans un petit ensemble de dossiers, si possible.
Points de montage	Inclure dans le code source s’il est créé uniquement par le biais de travaux basés sur un bloc-notes ou d’une API de commande.	Utilisez des travaux, qui peuvent être exécutés en tant qu’activités Azure Data Factory (ADF). Notez que les points de terminaison de stockage peuvent changer, étant donné que les espaces de travail se trouvent dans des régions différentes. Cela dépend également de la stratégie de reprise après sinistre de vos données.
Métadonnées de table	Pour les objets catalogue Unity (catalogues, schémas, tables, volumes et subventions), co-déployez avec le fournisseur Databricks Terraform ou databricks Asset Bundles. Pour les tables du metastore Hive hérité, incluez les instructions de création de table dans le code source lorsqu’elles sont créées via des travaux basées sur des notebooks ou l’API de commande.	Pour les objets d’Unity Catalog, lisez les métadonnées source à partir des tables système ou de `information_schema`, et répliquez-les vers l’espace de travail secondaire à l’aide du Databricks SDK. Pour les tables du metastore Hive hérité, comparez les définitions de métadonnées entre les metastores à l’aide de l’API du catalogue Spark ou `SHOW CREATE TABLE` via un notebook ou des scripts. Les chemins de stockage sous-jacents peuvent être basés sur une région et peuvent différer entre les instances de metastore.
Secrets	Inclure dans le code source s’il est créé uniquement par le biais de l' API de commande. Notez que certains contenus secrets peuvent être amenés à changer entre le serveur principal et le serveur secondaire.	Les secrets sont créés dans les deux espaces de travail par le biais de l’API. Notez que certains contenus secrets peuvent être amenés à changer entre le serveur principal et le serveur secondaire.
Configurations de cluster	Il peut s’agir de modèles dans Git. Co-déployez sur des déploiements principaux et secondaires, bien que ceux qui se trouvent dans le déploiement secondaire doivent être terminés jusqu’à l’événement de reprise après sinistre.	Les clusters sont créés une fois qu’ils sont synchronisés avec l’espace de travail secondaire à l’aide de l’API ou de l’interface CLI. Celles-ci peuvent être arrêtées explicitement si vous le souhaitez, en fonction des paramètres de terminaison automatique.
Autorisations pour le bloc-notes, le travail et le dossier	Il peut s’agir de modèles dans Git. Co-déploiement vers les déploiements primaires et secondaires.	Réplication à l’aide de l’API Permissions.

Choisir des régions et plusieurs espaces de travail secondaires

Vous contrôlez quand DR se déclenche et vers quelle région secondaire vous basculez. Vous êtes également responsable de la stabilisation de l’environnement de reprise après sinistre avant de reprendre les opérations normales. Cela signifie généralement qu’il faut créer plusieurs espaces de travail Azure Databricks de production et de reprise après sinistre, puis choisir une région secondaire de basculement.

Avant de sélectionner votre région secondaire, vérifiez que toutes les ressources et services dont vous dépendez (types de calcul, produits, intégrations) sont disponibles. Certains services Azure Databricks sont disponibles uniquement dans des régions spécifiques.

Vérifiez également la réplication des données et la disponibilité des types de machine virtuelle.

Étape 3 : préparer les espaces de travail et effectuer une copie unique

Tout d’abord, déployez un espace de travail Azure Databricks secondaire (ou plusieurs espaces de travail) ainsi que le metastore associé dans la région secondaire de votre choix. L’espace de travail secondaire doit mettre en miroir le compte, la région et la configuration d’identité du principal avant de pouvoir répliquer des données ou des ressources.

Si vous utilisez la reprise après sinistre gérée, Azure Databricks prend en charge l’amorçage initial des catalogues concernés et des ressources de l’espace de travail lorsque vous créez un groupe de basculement. Vous n’avez pas besoin d’effectuer une copie unique pour ces ressources. Continuez avec le reste de cette section pour toutes les sources de données ou ressources que la reprise après sinistre gérée ne réplique pas.

Pour un espace de travail de production fonctionnant hors du périmètre de la reprise après sinistre gérée, exécutez une copie unique pour synchroniser le déploiement passif avec le déploiement actif. Cette fonctionnalité de copie prend en charge :

Réplication des données : utilisez une solution de réplication cloud ou delta Deep Clone.
Génération de jeton : Automatisez la réplication et les charges de travail futures avec des jetons générés.
Réplication de l’espace de travail : répliquer à l’aide des méthodes de l’étape 4 : préparer vos sources de données. Pour obtenir des conseils complets sur l’exportation de ressources d’espace de travail, de données et d’IA/ML, consultez Exporter les données de l’espace de travail.
Validation de l’espace de travail : testez l’espace de travail et le processus pour confirmer qu’ils s’exécutent correctement et produisent les résultats attendus.

Les synchronisations suivantes s’exécutent plus rapidement que la copie initiale, et vos journaux d’outils enregistrent ce qui a changé et quand.

Étape 4 : préparer vos sources de données

Azure Databricks pouvez traiter une grande variété de sources de données à l’aide du traitement par lots ou des flux de données.

Traitement par lots à partir de sources de données

Les données batch résident généralement dans une source que vous pouvez répliquer ou remettre dans une autre région.

Par exemple, les données sont souvent chargées dans le stockage cloud selon une planification. En mode reprise après sinistre, pointez ces chargements sur votre stockage de région secondaire et mettez à jour les charges de travail pour lire et écrire dans ce stockage.

Flux de données

Le traitement d’un flux de données est un défi plus important. Les données de streaming peuvent être ingérées à partir de différentes sources, traitées et envoyées à une solution de diffusion en continu :

File d’attente de messages telle que Kafka
Flux de capture des modifications de la base de données
Traitement continu basé sur les fichiers
Traitement planifié basé sur des fichiers, parfois appelé "déclenchement une fois"

Dans tous ces cas, vous devez configurer vos sources de données pour gérer le mode de reprise après sinistre et utiliser votre déploiement secondaire dans votre région secondaire.

Un writer de flux stocke un point de contrôle avec des informations sur les données qui ont été traitées. Ce point de contrôle peut contenir un emplacement de données (généralement le stockage cloud) qui doit être modifié vers un nouvel emplacement pour garantir le redémarrage réussi du flux. Par exemple, le sous-dossier source sous le point de contrôle peut stocker le dossier du Cloud basé sur des fichiers.

Ce point de contrôle doit être répliqué en temps opportun. Envisagez de synchroniser l’intervalle de point de contrôle avec toute nouvelle solution de réplication Cloud.

La mise à jour du point de contrôle est une fonction du writer et s’applique donc à l’ingestion du flux de données ou au traitement et au stockage sur une autre source de streaming.

Pour les charges de travail de diffusion en continu, assurez-vous que les points de contrôle sont configurés dans le stockage géré par le client afin qu’ils puissent être répliqués dans la région secondaire pour la reprise de la charge de travail à partir du point de dernier échec. Vous pouvez également choisir d’exécuter le processus de diffusion en continu secondaire en parallèle au processus principal.

Étape 5 : implémenter et tester votre solution

Si vous utilisez la reprise après sinistre gérée, vous pouvez déclencher un basculement planifié depuis la console du compte pour vérifier que votre configuration fonctionne de bout en bout. La même procédure s’applique à la fois aux tests de reprise après sinistre et aux pannes réelles. Consultez Basculement et restauration automatique.

Testez régulièrement votre configuration de reprise après sinistre. Un plan de reprise après sinistre non testé échoue souvent lorsque vous en avez besoin. Certaines équipes changent de régions actives tous les quelques mois selon une planification pour valider les hypothèses, les processus d’exercice et garder l’équipe familiarisée avec le runbook.

Importante

Testez votre solution de reprise après sinistre dans des conditions réelles à intervalles réguliers.

Si un test révèle un objet ou un modèle manquant, mettez à jour votre plan : supprimez la dépendance, répliquez-la dans l’espace de travail secondaire ou mettez-la à disposition d’une autre façon.

Testez également les modifications d’organisation et de configuration. Votre plan de reprise après sinistre a une incidence sur votre pipeline de déploiement ; l’équipe doit donc savoir quels éléments maintenir synchronisés. Après avoir configuré des espaces de travail de reprise après sinistre, vérifiez que votre infrastructure, vos tâches, vos notebooks, vos bibliothèques et les autres objets de l’espace de travail sont disponibles dans la région secondaire.

Développez vos processus de travail standard et vos pipelines de configuration pour déployer des modifications dans tous les espaces de travail. Gérez les identités utilisateur entre les espaces de travail et configurez l’automatisation et la surveillance des travaux pour les nouveaux espaces de travail.

Planifiez et testez les modifications apportées à vos outils de configuration.

Modifications de configuration pour planifier et tester

Pour chacune des hypothèses suivantes, préparez un plan de basculement et testez toutes les hypothèses :

Ingestion : comprendre où se trouvent vos sources de données et où ces sources obtiennent leurs données. Si possible, paramétrez la source et utilisez un modèle de configuration distinct pour le déploiement et la région secondaires.
Modifications d’exécution : si vous avez un planificateur pour déclencher des travaux ou d’autres actions, vous aurez peut-être besoin d’un planificateur distinct qui fonctionne avec le déploiement secondaire ou ses sources de données.
Connectivité interactive : réfléchissez à la façon dont la configuration, l’authentification et les connexions réseau peuvent être affectées par des interruptions régionales pour toute utilisation d’API REST, d’outils CLI ou d’autres services tels que JDBC/ODBC.
Modifications de l’automatisation : pour tous les outils d’automatisation.
Sorties : pour tous les outils qui génèrent des données de sortie ou des journaux d’activité.
Modifications en aval : pour les outils décisionnels, les tableaux de bord, les planificateurs et les intégrations tierces qui lisent ou écrivent dans Azure Databricks, planifiez la façon de les repointer dans l’espace de travail secondaire et de notifier leurs propriétaires.

Tester le basculement

Test de basculement

De nombreux scénarios peuvent déclencher la récupération d’urgence : une panne inattendue dans le réseau cloud, le stockage cloud ou un autre service principal où vous ne pouvez pas arrêter correctement ; un arrêt ou une panne planifié ; ou même un basculement périodique entre les régions dans le cadre de votre cycle de test.

Pour tester le basculement, connectez-vous au système et exécutez un processus d’arrêt. Vérifiez que tous les travaux sont terminés et que les clusters sont arrêtés.

Un client de synchronisation (ou outils CI/CD) réplique les objets et ressources Azure Databricks pertinents dans l’espace de travail secondaire. Pour activer l’espace de travail secondaire, votre processus peut inclure une partie ou l’ensemble des éléments suivants :

Exécutez les tests pour confirmer que la plateforme est à jour.
Désactivez les pools et les clusters de la région primaire de sorte que si le service défaillant retourne en ligne, la région primaire ne commence pas à traiter les nouvelles données.
Exécutez le processus de récupération pour vos sources de données (voir ci-dessous).
Démarrez les pools appropriés (ou augmentez le min_idle_instances au nombre correspondant).
Démarrez les clusters appropriés (s’ils ne sont pas arrêtés).
Modifiez l’exécution simultanée des travaux et exécutez les travaux appropriés. Il peut s’agir d’exécutions ponctuelles ou périodiques.
Pour tout outil externe qui utilise une URL ou un nom de domaine pour votre espace de travail Azure Databricks, mettez à jour les configurations pour tenir compte du nouveau plan de contrôle. Par exemple, mettez à jour les URL des API REST et des connexions JDBC/ODBC. L’URL côté client de l’application web Azure Databricks change lorsque le plan de contrôle change, afin d’informer les utilisateurs de votre organisation de la nouvelle URL.

Détails du processus de récupération

Vérifiez la date des dernières données synchronisées. Consultez la terminologie du secteur de la récupération d’urgence. Les détails de cette étape varient selon la façon dont vous synchronisez les données et vos besoins métier uniques.
Stabilisez vos sources de données et assurez-vous qu’elles sont toutes disponibles. Incluez toutes les sources de données externes, telles qu’Azure Cloud SQL, et vos fichiers Delta Lake, Parquet ou d’autres fichiers.
Recherchez votre point de récupération de streaming. Configurez le processus pour redémarrer à partir de là et disposez d’un processus prêt à identifier et à éliminer les doublons potentiels (Delta Lake facilite cette opération).
Terminez le processus de transmission de données et informez les utilisateurs.

Test de restauration (retour arrière)

Restauration de test (retour à la situation initiale)

La restauration automatique est plus facile à contrôler et peut être effectuée dans une fenêtre de maintenance. Planifiez certaines ou toutes les étapes suivantes :

Demandez confirmation que la région primaire est restaurée.
Désactivez les pools et les clusters sur la région secondaire afin qu’ils ne commencent pas à traiter de nouvelles données.
Synchronisez les ressources nouvelles ou modifiées dans l’espace de travail secondaire dans le déploiement principal. Selon la conception de vos scripts de basculement, vous pouvez exécuter les mêmes scripts pour synchroniser les objets de la région secondaire (reprise après sinistre) vers la région principale (production).
Synchronisez toutes les nouvelles mises à jour de données dans le déploiement principal. Vous pouvez utiliser les pistes d’audit des journaux et des tables Delta pour garantir qu'aucune donnée n'est perdue.
Arrêtez toutes les charges de travail dans la région de reprise après sinistre.
Modifiez l’URL des tâches et des utilisateurs pour qu’elle pointe vers la région principale, puis redirigez de nouveau vers celle-ci les connexions en aval (outils décisionnels, planificateurs, intégrations tierces).
Exécutez les tests pour confirmer que la plateforme est à jour.
Démarrez les pools appropriés (ou augmentez le min_idle_instances au nombre correspondant).
Démarrez les clusters appropriés (s’ils ne sont pas arrêtés).
Modifiez l’exécution simultanée des tâches et exécutez les tâches pertinentes. Il peut s’agir d’exécutions ponctuelles ou périodiques.
Si nécessaire, configurez à nouveau votre région secondaire pour une reprise après sinistre ultérieure.

Scripts d’automatisation, exemples et prototypes

Pour AWS et Azure, la récupération d’urgence managée gère l’espace de travail et la réplication de table managée sans automatisation personnalisée. Les références ci-dessous s’appliquent uniquement si vous mettez en place une solution DIY en dehors de l’étendue de la reprise après sinistre gérée.

Pour les pipelines de reprise après sinistre DIY, utilisez le Fournisseur Terraform Databricks pour gérer les ressources de l’espace de travail sous forme de code et les déployer conjointement dans les régions principale et secondaire.

Si vous orchestrez Azure Databricks à partir de Azure Data Factory, répliquez les pipelines ADF pertinents afin qu’ils fassent référence à un service lié mappé à l’espace de travail secondaire.

Ressources supplémentaires

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2026-06-24