Reprise après sinistre
La reprise après sinistre (DR) pour Databricks réplique les Workspaces, les données et les configurations entre les régions cloud afin que vos équipes continuent à travailler lorsqu'une panne régionale met votre déploiement principal hors ligne. Un plan de DR complet couvre non seulement Databricks, mais aussi les sources de données, les outils d'ingestion, les outils de BI et les planificateurs auxquels il se connecte.
Cette page couvre les concepts, les stratégies, les outils et les procédures de test dont vous avez besoin pour concevoir et exécuter une solution de DR interrégionale.
Vous débutez en planification de reprise après sinistre ? Start with terminologie du secteur de la reprise après sinistre pour les définitions du RPO et du RTO.
Utilisez la reprise après sinistre gérée. Databricks recommande la récupération d’urgence gérée pour la reprise après sinistre interrégionale sur AWS et Azure. Il réplique les métadonnées de Unity Catalog, les données des tables gérées et les Workspace assets selon un calendrier continu, fournit une URL stable qui survit au basculement et vous permet de trigger un basculement depuis la console du compte. Aucun script de réplication à écrire ou à maintenir. Utilisez les conseils DIY de cette page uniquement pour les ressources gérées que la reprise d'activité ne réplique pas, ou si vous avez besoin de topologies actif-actif, de réplication inter-cloud ou d'un contrôle précis sur le pipeline de réplication.
Garanties de haute disponibilité intra-région
Le reste de cette page couvre la DR interrégionale, mais Databricks fournit également une haute disponibilité (HA) au sein d'une seule région. Comprenez d'abord ces garanties. Ils déterminent si vous avez besoin d'une stratégie de DR distincte.
La HA et la DR résolvent différents problèmes :
- Le HA utilise la redondance de zone de disponibilité (AZ) au sein d'une région. Si une zone échoue, les services continuent de s’exécuter dans les autres.
- DR utilise la réplication inter-régions. Vous exécutez des workspaces Databricks secondaires dans une autre région et y répliquez les données et les configurations, puis basculez en cas de panne régionale.
Si vous n’avez pas besoin de reprise d’activité multirégion, la haute disponibilité Databricks peut être suffisante. La haute disponibilité évite la complexité interrégionale, mais elle ne protège pas contre une panne régionale complète. Si vous comptez uniquement sur la HA pour la reprise après sinistre, vérifiez la séparation et la redondance de vos régions cloud.
Les garanties de haute disponibilité intra-région couvrent le plan de contrôle et le plan de compute.
Disponibilité du plan de contrôle Databricks
Disponibilité du plan de contrôle Databricks
Le plan de contrôle Databricks est résilient aux défaillances de zone et se rétablit automatiquement dans les 15 minutes environ suivant une défaillance de zone. Des tests réguliers de défaillance de zone valident ceci.
Tous les services du plan de contrôle sans état peuvent perdre des VM individuelles, ou toutes les VM d'une zone entière, sans interrompre le service. Les données du Workspace sont stockées dans des bases de données répliquées sur plusieurs zones de la région. Les comptes de stockage qui fournissent des images Databricks Runtime sont également redondants au sein de la région, et toutes les régions disposent de comptes de stockage secondaires qui prennent le relais lorsque le compte principal est hors service.
The control plane guarantees above apply to Databricks-managed infrastructure. You are responsible for compute-plane zone redundancy, for example, choosing zone-redundant storage for the workspace root bucket and using instance pools that span availability zones.
La résilience aux défaillances de zone prend en charge qu'une seule zone soit hors service au maximum dans une région.
Disponibilité du plan de compute
Disponibilité du plan de compute
La disponibilité du Workspace dépend de la disponibilité du plan de contrôle.
Les données racine de DBFS ne sont pas affectées sauf si le compte de stockage est configuré dans une variante à une zone. Les données Amazon S3 sont régionales par default, avec une redondance des données entre les zones.
Les nœuds de cluster sont alloués dans une seule zone de disponibilité (AZ) du fournisseur de compute AWS. Si un nœud est perdu, le gestionnaire de cluster demande des nœuds de remplacement au fournisseur de compute AWS dans la même AZ. L'exception se produit lorsque le nœud driver est perdu. Dans ce cas, le gestionnaire de cluster redémarre le Job et le cluster. Si l'AZ contenant le cluster subit une panne de zone, le gestionnaire de cluster redémarre le Job et le cluster dans une autre AZ.
Terminologie
Utilisez ces définitions de manière cohérente lorsque vous discutez de DR avec votre équipe.
Terminologie de la région
Terminologie de la région
Cette page utilise les définitions de région suivantes :
-
**Région principale** : La région où les utilisateurs exécutent les charges de travail d'analytique des données interactives et automatisées quotidiennes.
-
Région secondaire : Région où les équipes IT déplacent temporairement les charges de travail lors d'une panne de la région principale.
-
Stockage géoredondant : réplication asynchrone interrégionale du stockage persistant. Consultez la documentation de votre cloud :
Do not rely on geo-redundant storage to duplicate Databricks root storage (such as the Amazon S3 bucket Databricks creates for each workspace) across regions. To replicate managed table data, use Delta Deep Clone, and for non-Delta data, convert to Delta first where possible.
Terminologie de l'état du déploiement
Terminologie de l'état du déploiement
Cette page utilise les définitions suivantes de l'état de déploiement :
-
Déploiement actif (parfois appelé déploiement à chaud ) : les utilisateurs s'y connectent et exécutent des charges de travail. Les jobs et les Stream de données s'exécutent ici selon un calendrier.
-
**Déploiement passif** (parfois appelé *déploiement à froid*) : Aucun processus ne s'exécute ici. Les équipes IT le maintiennent prêtes en automatisant le déploiement de code, de configuration et d'autres objets Databricks. Un déploiement passif devient actif uniquement lorsque le déploiement actif tombe en panne.
Un projet peut inclure plusieurs déploiements passifs dans différentes régions pour une résilience accrue.
La plupart des équipes exécutent un seul déploiement actif à la fois, la stratégie actif-passif. La stratégie moins courante active-active exécute deux déploiements actifs simultanés.
Terminologie des secteurs d'activité de la reprise après sinistre
Terminologie du secteur de la reprise après sinistre
Définissez ces deux termes des secteurs d'activité avec votre équipe :
-
Recovery point objective (RPO) : la période maximale de perte de données que votre service peut tolérer lors d'un incident majeur. Voir RPO.
Databricks ne stocke pas vos données client principales. Qui réside dans Amazon S3 ou d'autres systèmes que vous contrôlez. Le plan de contrôle Databricks stocke certains objets (tels que des Jobs et des Notebooks), de sorte que le RPO Databricks correspond à 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 Amazon S3 et les autres sources de données que vous contrôlez.
-
Objectif de temps de récupération (RTO) : le temps maximal dans lequel un processus métier doit être restauré après un sinistre. Voir RTO.
Reprise après sinistre et corruption des données
Récupération après sinistre et corruption de données
Une solution de reprise après sinistre n'atténue pas la corruption des données. Les données corrompues dans la région primaire sont répliquées vers la région secondaire et sont corrompues dans les deux régions. Pour atténuer ce type de défaillance, utilisez Delta time travel, des outils similaires ou des outils de sauvegarde des données.
Workflow de récupération standard
Un scénario de reprise après sinistre (DR) Databricks se déroule généralement comme suit :
-
Une défaillance touche un service critique dans votre région principale : une source de données, un réseau ou une autre dépendance sur laquelle repose le déploiement Databricks.
-
Vous enquêtez avec votre fournisseur cloud.
-
Si l'attente est inacceptable, vous décidez de basculer vers votre région secondaire.
-
Confirmez que le même problème n'affecte pas votre région secondaire.
-
Basculement (pour connaître les étapes détaillées, consultez Test de basculement) :
- Arrêtez toute l'activité du Workspace. Les utilisateurs arrêtent les workloads et sauvegardent les modifications récentes dans la mesure du possible. Les Jobs s'arrêtent (si la panne ne les a pas déjà fait échouer).
- Exécutez la procédure de récupération de la région secondaire pour mettre à jour le routage et rediriger les connexions et le trafic réseau.
- Redirigez les systèmes en aval (outils de BI, planificateurs, intégrations tierces) vers le Workspace secondaire et rétablissez leurs connexions.
- Après les tests, déclarez la région secondaire opérationnelle. Les utilisateurs se connectent au déploiement désormais actif, et vous redéclenchez les jobs planifiés ou retardés.
-
Une fois le problème de la région principale atténué, confirmez le correctif.
-
Restauration (pour plus de détails, consultez Test de restauration (restauration)) :
- Arrêtez tout travail dans la région secondaire.
- Exécutez la procédure de récupération de la région principale pour rediriger le routage.
- Répliquez toutes les nouvelles données vers la région principale. Minimisez ce qui doit être répliqué. Par exemple, les Jobs en lecture seule exécutés dans le déploiement secondaire peuvent ne pas nécessiter de réécriture.
- Testez le déploiement dans la région primaire.
- Déclarez la région principale active et reprenez les workloads de production.
Des pertes de données peuvent survenir au cours de ces étapes. Définissez le niveau de perte acceptable pour votre organisation, et la manière dont vous l'atténuez.
Étape 1 : comprendre les besoins de votre entreprise
Identifiez les Data Services critiques et définissez leurs RPO et RTO cibles. Recherchez la tolérance réelle de chaque système.
La reprise après sinistre, le basculement et le retour arrière comportent des coûts et des risques réels, notamment la corruption des données, la duplication des données (écriture à un emplacement de stockage incorrect) et des utilisateurs apportant des modifications dans la mauvaise région.
Mappez chaque point d'intégration Databricks qui affecte votre entreprise, et choisissez les outils et les Canal de distribution que votre plan utilise.
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 Data Services utilisez-vous ? Certains pourraient être on-premise.
- Comment les données d'entrée arrivent-elles dans le cloud ?
- Qui consomme ces données ? Quels processus le consomment en aval ?
- Existe-t-il des intégrations tierces qui doivent être informées des changements de DR ?
Outils et communication pour planifier
- Pouvez-vous prédéfinir votre configuration et la rendre modulaire pour s'adapter aux Solutions de DR de manière naturelle et maintenable ?
- Quels outils et canaux de communication avertissent les équipes internes et les tiers (intégrations, consommateurs en aval) des modifications de basculement et de récupération d'urgence ? Comment confirmez-vous leur prise en compte ?
- Quels services, le cas échéant, arrêtez-vous jusqu'à ce que la récupération complète soit en place ?
Étape 2 : Choisissez un processus qui répond à vos besoins métier
Default to récupération après sinistre gérée. Il gère la réplication de Workspace, les métadonnées d'Unity Catalog, les données de table gérée et l'orchestration de basculement sans scripts personnalisés. Utilisez les instructions de bricolage ci-dessous uniquement si vous sortez de son champ d'application, par exemple, la DR gérée par les ressources ne se réplique pas, les topologies actives-actives, la réplication inter-cloud ou un contrôle granulaire sur le pipeline de réplication.
Une solution DIY doit répliquer les données correctes sur le plan de contrôle, le plan de calcul et les sources de données. Des workspaces redondants sont associés à des plans de contrôle différents dans des régions différentes, vous les maintenez donc synchronisés avec une solution basée sur des scripts, soit un outil de synchronisation ou un workflow CI/CD. Pour les données elles-mêmes, la plupart des équipes utilisent des jobs 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 à partir du plan de compute (par exemple, à partir des Worker Databricks Runtime).
Si vous utilisez la fonctionnalité Virtual Private Cloud (VPC) gérée par le client (non disponible avec tous les types d'abonnement et de déploiement), déployez les réseaux de manière cohérente dans les deux régions à l'aide d'outils basés sur des template comme Terraform.
Répliquez vos sources de données dans les régions selon les besoins.
Les solutions DR impliquent généralement deux (ou plusieurs) workspaces. Choisissez parmi les stratégies suivantes en fonction de la durée de la disruption que vous devez tolérer, de l'effort opérationnel et du coût du retour à la région principale.
Bonnes pratiques générales
Bonnes pratiques générales
Les bonnes pratiques générales pour un plan de reprise d'activité (DR) réussi incluent :
- Comprendre quels processus sont essentiels pour l'entreprise et doivent s'exécuter en cas de reprise après sinistre.
- Identifiez clairement les services impliqués, les données traitées, le flux de données et l'emplacement de leur stockage.
- Isolez les services et les données autant que possible. Par exemple, créez un conteneur de stockage cloud spécial pour les données DR ou déplacez les objets Databricks nécessaires en cas de sinistre vers un Workspace distinct.
- Vous êtes responsable de maintenir l'intégrité entre les déploiements primaires et secondaires pour les objets non stockés dans le plan de contrôle Databricks.
- Pour les sources de données, utilisez les outils AWS natifs pour répliquer les données vers vos régions DR, si possible.
Don't store data in the root Amazon S3 bucket used for DBFS root access. DBFS root storage is unsupported for production customer data. Databricks also recommends against storing libraries, configuration files, or init scripts there.
Stratégie de solution active-passive
Stratégie de solution active-passive
Cette section se concentre sur la stratégie actif-passif, car elle est la plus courante, la plus simple et la plus rentable. Une solution actif-passif synchronise les données et les modifications d'objets de votre déploiement actif vers un déploiement passif dans une région secondaire. Lors d'un événement de reprise après sinistre, 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 service ou projet : chaque domaine maintient sa propre solution de DR avec des régions primaires et secondaires adaptées à ses besoins.
Vous pouvez également utiliser un déploiement passif pour des charges de travail en lecture seule, telles que les requêtes utilisateur, qui ne modifient pas les données ou les objets Databricks.
Stratégie de solution actif-actif
Stratégie de solution actif-actif
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 des opérations doit marquer chaque job comme terminé seulement *après* qu'il ait réussi dans les deux régions. Les objets ne peuvent pas être modifiés en production et doivent respecter une promotion CI/CD stricte du développement/préproduction à la production.
L'actif-actif est la stratégie la plus complexe et la plus coûteuse, car les Jobs s'exécutent dans les deux régions, mais elle offre les RTO et RPO les plus bas.
Vous pouvez implémenter la configuration actif-actif à l'échelle de l'entreprise ou par service. Vous n'avez pas besoin d'un workspace en double pour chaque charge de travail. Par exemple, les Workspace de développement ou de staging sont souvent plus faciles à reconstruire à partir d'un pipeline de développement qu'à maintenir synchronisés.
Choisissez vos outils
Choisissez vos outils
Il existe deux approches principales pour synchroniser les données entre les Workspace dans vos régions primaire et secondaire :
- Client de synchronisation qui copie du principal au secondaire : un client de synchronisation envoie les données de production et les assets de la région principale vers la région secondaire. Généralement, cela s'exécute de manière planifiée, et la fréquence de la planification dépend de vos objectifs RTO et RPO.
- Outils CI/CD pour le déploiement parallèle : pour le code de production et les assets, utilisez les outils CI/CD qui déploient simultanément les changements vers les systèmes de production dans les deux régions. Par exemple, lors de la publication de code et d'assets de l'environnement de staging/développement vers la production, un système CI/CD les rend disponibles dans les deux régions simultanément. L'idée fondamentale est de traiter tous les artefacts d'un Databricks Workspace comme de l'Infrastructure-as-Code. La plupart des artefacts pourraient être déployés conjointement dans les workspaces principaux et secondaires, tandis que certains artefacts pourraient ne devoir être déployés qu'après un événement de reprise après sinistre. Pour les outils, consultez Scripts, exemples et prototypes d'automatisation.
Selon vos besoins, vous pouvez combiner les approches. Par exemple, utilisez le CI/CD pour le code source de 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 outil.
Description | How to handle with CI/CD tooling | How to handle with sync tool |
|---|---|---|
Source code: notebook source exports and source code for packaged libraries | Co-deploy both to primary and secondary. | Synchronize source code from primary to secondary. |
Users and groups | Manage metadata as config in Git. Alternatively, use the same identity provider (IdP) for both workspaces. Co-deploy user and group data to primary and secondary deployments. | Use SCIM or other automation for both regions. Manual creation is not recommended, but if used must be done for both at the same time. If you use a manual setup, create a scheduled automated process to compare the list of users and groups between the two deployments. |
Pool configurations | Can be templates in Git. Co-deploy to primary and secondary. However, | Pools created with any |
Job configurations | Use Databricks Asset Bundles with per-environment targets (for example, | If the jobs run on existing |
Access control lists (ACLs) | Can be templates in Git. Co-deploy to primary and secondary deployments for notebooks, folders, and clusters. However, hold the data for jobs until the DR event. | The Permissions API can set access controls for clusters, jobs, pools, notebooks, and folders. A sync client needs to map to corresponding object IDs for each object in the secondary workspace. Databricks recommends creating a map of object IDs from primary to secondary workspace while syncing those objects before replicating the access controls. |
Libraries | Include in source code and cluster/job templates. | Sync custom libraries from centralized repositories, DBFS, or cloud storage (can be mounted). |
Include in the source code if you prefer. | For simpler synchronization, store init scripts in the primary workspace in a common folder or in a small set of folders if possible. | |
Mount points | Include in source code if created only through notebook-based jobs or Command API. | Use jobs. Note that the storage endpoints might change, given that workspaces would be in different regions. This depends a lot on your data DR strategy as well. |
Table metadata | For Unity Catalog objects (catalogs, schemas, tables, volumes, and grants), co-deploy with the Databricks Terraform provider or Databricks Asset Bundles. For legacy Hive metastore tables, include create-table statements with source code if created through notebook-based jobs or the Command API. | For Unity Catalog objects, read source metadata from system tables or |
Secrets | Include in source code if created only through Command API. Note that some secrets content might need to change between the primary and secondary. | Secrets are created in both workspaces via the API. Note that some secrets content might need to change between the primary and secondary. |
Cluster configurations | Can be templates in Git. Co-deploy to primary and secondary deployments, although the ones in secondary deployment should be terminated until the DR event. | Clusters are created after they are synced to the secondary workspace using the API or CLI. Those can be explicitly terminated if you want, depending on auto-termination settings. |
Notebook, job, and folder permissions | Can be templates in Git. Co-deploy to primary and secondary deployments. | Replicate using the Permissions API. |
Choisir les régions et plusieurs Workspaces secondaires
Choisissez des régions et plusieurs workspaces secondaires
Vous contrôlez quand la reprise après sinistre Trigger 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 implique généralement de créer plusieurs Databricks Workspace pour la production et la reprise après sinistre, puis de choisir une région de basculement secondaire.
Avant de sélectionner votre région secondaire, confirmez que toutes les ressources et services dont vous dépendez (types de compute, produits, intégrations) y sont disponibles. Certains services Databricks sont disponibles uniquement dans des régions spécifiques.
Étape 3 : Préparer les workspaces et effectuer une copie unique
Tout d'abord, mettez en place un Workspace Databricks secondaire (ou des Workspaces) et son métastore de support dans la région secondaire de votre choix. Le Workspace secondaire doit refléter la configuration du compte, de la région et de l'identité du primaire avant que vous puissiez y répliquer des données ou des assets.
Si vous utilisez la reprise après sinistre gérée, Databricks gère l'amorçage initial des catalogues inclus dans le périmètre et des assets de workspace lorsque vous créez un groupe de basculement. Vous n'avez pas besoin d'effectuer une copie unique pour ces ressources. Poursuivez cette section pour les sources de données ou les assets que la DR gérée ne réplique pas.
Pour un workspace de production exécutant en dehors du périmètre de DR géré, exécutez une copie unique pour synchroniser le déploiement passif avec le déploiement actif. Cette copie gère :
- Réplication des données : utilisez une solution de réplication cloud ou Delta Deep Clone.
- Génération de jetons : Automatisez la réplication et les futures charges de travail avec les jetons générés.
- Réplication de Workspace : répliquez à l'aide des méthodes de l'article Étape 4 : Préparez vos sources de données. Pour des conseils complets sur l'exportation de la configuration du workspace, des données et des assets d'IA/ML, consultez Exportation des données du workspace.
- Validation du Workspace : Testez le workspace et le processus pour confirmer qu’ils s’exécutent avec succès et produisent les résultats attendus.
Les synchronisations ultérieures s'exécutent plus rapidement que la copie initiale, et les logs de vos outils enregistrent les modifications et leur date.
Étape 4 : Préparez vos sources de données
Databricks peut traiter une grande variété de sources de données en utilisant le traitement par batch ou des Stream de données.
Traitement par batch à partir de sources de données
Traitement par batch à partir de sources de données
Les données batch résident généralement dans une source que vous pouvez répliquer ou livrer à une autre région.
Par exemple, les données sont souvent upload vers le stockage cloud selon un calendrier. En mode reprise après sinistre, dirigez ces téléchargements vers votre stockage de région secondaire et mettez à jour les charges de travail pour lire et écrire dans ce stockage.
Flux de données
Data Stream
Le traitement d'un data Stream est un plus grand défi. Les données de streaming peuvent être ingérées depuis diverses sources, traitées et envoyées à une solution de streaming :
- File d'attente de messages comme Kafka
- Stream de capture des modifications de données de base de données
- Traitement continu basé sur les fichiers
- Traitement programmé basé sur les fichiers, également connu sous le nom de Trigger unique
Dans tous ces cas, vous devez configurer vos sources de données pour gérer le mode DR et pour utiliser votre déploiement secondaire dans votre région secondaire.
Un enregistreur de stream 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 un stockage cloud) qui doit être modifié vers un nouvel emplacement pour assurer un redémarrage réussi du stream. Par exemple, le sous-dossier source sous le checkpoint pourrait stocker le dossier cloud basé sur des fichiers.
Ce point de contrôle doit être répliqué en temps voulu. Envisagez la synchronisation de 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 de l'enregistreur et s'applique donc à l'ingestion ou au traitement de flux de données et au stockage sur une autre source de streaming.
Pour les workloads de streaming, assurez-vous que les points de contrôle sont configurés dans un stockage géré par le client afin qu'ils puissent être répliqués vers la région secondaire pour la reprise des workloads à partir du point de défaillance précédent. Vous pouvez également choisir d'exécuter le processus de streaming secondaire en parallèle du processus principal.
Étape 5 : Implémenter et tester votre solution
Si vous utilisez la reprise après sinistre gérée, vous pouvez Trigger un basculement planifié depuis la console du compte pour valider que votre configuration fonctionne de bout en bout. La même procédure couvre les tests de reprise après sinistre et les pannes réelles. Voir Basculement et rétablissement.
Testez régulièrement votre configuration de reprise après sinistre (DR). Un plan de reprise après sinistre non testé échoue souvent au moment où vous en avez besoin. Certaines équipes changent de régions actives tous les quelques mois selon un calendrier pour valider les hypothèses, exercer les processus et familiariser l'équipe avec le plan d'exécution.
Testez votre solution DR dans des conditions réelles, selon une planification régulière.
Si un test révèle un objet ou un Template manquant, mettez à jour votre plan : supprimez la dépendance, répliquez-la vers le Workspace secondaire ou rendez-la disponible d'une autre manière.
Testez également les modifications d'organisation et de configuration. Votre plan de reprise après sinistre affecte votre pipeline de déploiement, l'équipe doit donc savoir ce qu'il faut synchroniser. Une fois que vous avez configuré les Workspace de reprise après sinistre, confirmez que votre infrastructure, vos Job, vos notebooks, vos bibliothèques et d'autres objets de Workspace sont disponibles dans la région secondaire.
Étendez vos processus de travail standard et vos pipelines de configuration pour déployer les modifications dans tous les workspaces. Gérez les identités des utilisateurs à travers les workspaces, et configurez l'automatisation des Jobs et le monitoring pour les nouveaux workspaces.
Planifiez et testez les modifications apportées à votre outillage de configuration.
Modifications de configuration à planifier et à tester
Pour chacun des éléments suivants, préparez un plan de basculement et testez toutes les hypothèses :
- **Ingestion** : comprenez où se trouvent vos sources de données et d'où ces sources tirent leurs données. Lorsque cela est possible, paramétrez la source et utilisez un Template de configuration distinct pour le déploiement secondaire et la région.
- Modifications d'exécution : Si vous disposez d'un planificateur pour Trigger des Jobs ou d'autres actions, vous pourriez avoir besoin d'un planificateur distinct qui fonctionne avec le déploiement secondaire ou ses sources de données.
- Connectivité interactive : Examinez comment la configuration, l’authentification et les connexions réseau pourraient être affectées par des disruptions régionales pour toute utilisation des APIs REST, des outils CLI ou d’autres services comme JDBC/ODBC.
- Changements d'automatisation : Pour tous les outils d'automatisation.
- Sorties : Pour tout outil qui génère des données ou des Logs de sortie.
- Modifications en aval : pour les outils de BI, les tableaux de bord, les planificateurs et les intégrations tierces qui lisent ou écrivent dans Databricks, planifiez la manière de les rediriger vers le Workspace secondaire et d'en informer leurs propriétaires.
Tester le basculement
Test de basculement
De nombreux scénarios peuvent Trigger un plan de reprise après sinistre : une panne inattendue dans le cloud network, le stockage cloud ou un autre service essentiel où vous ne pouvez pas arrêter en douceur ; un arrêt ou une panne planifiée ; 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 lancez un arrêt. Confirmez que tous les Jobs sont terminés et que les clusters se sont arrêtés.
Un client de synchronisation (ou outil CI/CD) réplique les objets et ressources Databricks pertinents vers le workspace secondaire. Pour activer le Workspace secondaire, votre processus pourrait inclure tout ou partie des éléments suivants :
- Exécuter des tests pour confirmer que la plateforme est à jour.
- Désactivez les pools et les clusters dans la région principale afin que, si le service en échec redevient opérationnel, la région principale ne start pas à traiter de nouvelles données.
- Exécutez le processus de récupération pour vos sources de données (voir ci-dessous).
- Start les Pools pertinents (ou augmentez le
min_idle_instancesà un nombre pertinent). - Start les clusters pertinents (s'ils ne sont pas arrêtés).
- Modifiez l'exécution concurrente pour les jobs et exécutez les jobs pertinents. Il peut s'agir d'exécutions uniques ou d'exécutions périodiques.
- Pour tout outil externe qui utilise une URL ou un nom de domaine pour votre Databricks Workspace, mettez à jour les configurations pour tenir compte du nouveau plan de contrôle. Par exemple, mettez à jour les URL pour les APIs REST et les connexions JDBC/ODBC. L'URL destinée aux clients de l'application web Databricks change lorsque le plan de contrôle change, veuillez donc informer les utilisateurs de votre organisation de la nouvelle URL.
Détails du processus de récupération
- Vérifiez la date des données synchronisées les plus récentes. Voir terminologie du secteur de la reprise après sinistre. Les détails de cette étape varient selon la manière dont vous synchronisez les données et vos besoins uniques de l’entreprise.
- Stabilisez vos sources de données et assurez-vous qu'elles sont toutes disponibles. Incluez toutes les sources de données externes, telles que AWS RDS, et vos fichiers Delta Lake, Parquet ou autres.
- Trouvez votre point de récupération de streaming. Mettez en place 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 tâche).
- Terminez le processus de flux de données et informez les utilisateurs.
Test de restauration (reprise après échec)
Test de restauration (reprise après incident)
Le failback est plus facile à contrôler et peut être effectué dans une fenêtre de maintenance. Planifiez tout ou partie des étapes suivantes :
- Obtenez la confirmation que la région principale est restaurée.
- Désactivez les pools et les clusters sur la région secondaire afin qu'elle ne start pas à traiter de nouvelles données.
- Synchronisez tous les nouveaux ou modifiés assets dans le workspace secondaire vers le déploiement principal. Selon la conception de vos scripts de basculement, vous pourriez exécuter les mêmes scripts pour synchroniser les objets de la région secondaire (DR) vers la région principale (production).
- Synchronisez toutes les nouvelles mises à jour de données avec le déploiement principal. Vous pouvez utiliser les pistes d'audit des logs et des tables Delta pour garantir aucune perte de données.
- Arrêtez toutes les charges de travail dans la région DR.
- Changez l'URL des Jobs et des utilisateurs vers la région principale, et redirigez les connexions en aval (outils de BI, planificateurs, intégrations tierces) vers celle-ci.
- Exécuter des tests pour confirmer que la plateforme est à jour.
- Start les Pools pertinents (ou augmentez le
min_idle_instancesà un nombre pertinent). - Start les clusters pertinents (s'ils ne sont pas arrêtés).
- Modifiez l'exécution concurrente des Jobs et exécutez les Jobs pertinents. Il peut s'agir d'exécutions uniques ou d'exécutions périodiques.
- Au besoin, configurez à nouveau votre région secondaire pour une future reprise après sinistre.
Scripts d'automatisation, exemples et prototypes
Pour AWS et Azure, la récupération d'urgence gérée gère la réplication du workspace et des tables gérées sans automatisation personnalisée. Les références ci-dessous s'appliquent uniquement si vous construisez une solution DIY en dehors du champ d'application de DR géré.
Pour les pipelines de DR en mode auto-service, utilisez le fournisseur Databricks Terraform pour gérer les assets de workspace en tant que code et les co-déployer dans les régions primaires et secondaires.