Phase 10 : Conception de la haute disponibilité et de la reprise après sinistre

Dans cette phase, vous concevez des stratégies de haute disponibilité (HA) et de reprise après sinistre (DR) pour assurer la continuité des activités et la résilience.

La haute disponibilité (HA) et la reprise après sinistre (DR) sont des aspects importants de Databricks, et de nombreuses organisations les mettent en œuvre pour industrialiser des cas d'utilisation critiques sur Databricks.

Concevez une stratégie de haute disponibilité

La haute disponibilité est la capacité à se remettre d'une panne affectant une seule zone de cloud, avec un impact minimal et de manière transparente pour les utilisateurs. Elle est mesurée comme une disponibilité constante ou un pourcentage de disponibilité (SLA), avec une récupération généralement en secondes ou en minutes.

Haute disponibilité du plan de contrôle

Le plan de contrôle Databricks se compose de dizaines de services, de l'hébergement frontal et de l'authentification à la gestion des clusters et au déploiement des Endpoint. À partir de début 2025, les services essentiels du plan de contrôle sont multi-zonaux, ce qui signifie que si une seule zone au sein d'une région cloud tombe en panne, le plan de contrôle peut récupérer ces services dans une autre zone et continuer à fonctionner.

Caractéristiques HA du plan de contrôle

• Basculement automatique : les services basculent automatiquement vers les zones saines.
• **RTO de 15 minutes** : Le basculement s'effectue généralement en 15 minutes.
• 0 RPO : aucune perte de données en cas de défaillances zonales.
• Couverture multi-zones : Fonctionne pour les régions cloud avec plusieurs zones de disponibilité.

remarque

Ceci ne s'applique pas aux régions cloud à zone unique. Dans les régions à zone unique, une panne zonale est équivalente à une panne régionale.

Haute disponibilité du plan de compute

Haute disponibilité du compute classique

• Déployez les sous-réseaux du workspace dans au moins 2 zones de disponibilité (recommandé : 3).

• Databricks distribue automatiquement les nœuds de cluster entre les zones de disponibilité.

• Configurez les nouvelles tentatives de Job avec une interruption exponentielle pour les défaillances temporaires.

• Surveiller la santé de la zone de disponibilité et redistribuer les charges de travail pendant la dégradation de la zone.

Haute disponibilité du compute Serverless

• Le compute Serverless assure automatiquement le basculement multizone.
• Aucune configuration supplémentaire requise.
• Redistribue automatiquement les charges de travail en cas de défaillance de zone.

Bonnes pratiques pour la haute disponibilité du compute

• Utilisez le compute serverless pour le basculement automatique multizone.
• Pour le compute classique, assurez-vous que les sous-réseaux couvrent plusieurs zones de disponibilité.
• Configurez les nouvelles tentatives automatiques de Job en cas de pannes transitoires.
• Testez régulièrement les procédures de basculement pour valider les configurations HA.
• Surveillez les métriques d'intégrité de la zone et ajustez la planification de la capacité en conséquence.

Concevoir une stratégie de reprise après sinistre

La reprise après sinistre est la capacité de récupérer d'une panne affectant une région cloud entière et de poursuivre les opérations commerciales dans une région secondaire. Elle est mesurée par le temps d'arrêt acceptable (RTO) et la perte de données (RPO), généralement en heures.

Considérations relatives à la DR par couche

Les considérations relatives à la DR doivent être prises en compte à toutes les couches d'une plateforme de données :

Clients

• Les clients devraient pouvoir passer aux URL de workspace de basculement.
• Mettez à jour les configurations DNS ou d'équilibrage de charge pour le basculement automatique.

Code et objets Workspace

• Utilisez IaC/Terraform pour déployer l'infrastructure de la plateforme.
• Utilisez le contrôle de version pour tout le code, tel que les notebooks.
• Déployer sur les deux sites à l'aide de CI/CD.
• Automatisez le déploiement vers la région secondaire.

Identités

• Utilisateurs, Service Principals, groupes.
• Utilisez la synchronisation SCIM au niveau du compte.
• La fédération d'identité assure un accès cohérent entre les régions.

Unity Catalog

• Terraform ou scripts pour déployer ou copier l'infrastructure Unity Catalog.
• Terraform ou scripts pour copier les métadonnées (définitions de table, ACL, etc.).
• Terraform ou scripts pour copier la configuration OpenSharing.
• Déployez des metastores dans les régions principales et secondaires.

Données

• Données externes et gérées : Réplication géoredondante (par exemple, données brutes, sources de données).
• Tables Delta : Delta Deep Clone pour la réplication de tables entre les régions.
• Zones d'atterrissage : Répliquez les données de la zone d'atterrissage vers la région secondaire.

Streaming Endpoint

• Les informations de point de contrôle doivent être synchronisées entre les régions.
• Configurez les écritures doubles ou la réplication des points de contrôle.

Modèles de conception DR

Reprise après sinistre active-passive

• La région principale gère tout le trafic de production.
• Région secondaire en attente de basculement.
• Données répliquées périodiquement (par exemple, horaires, quotidiennes).
• Basculement manuel ou automatisé en cas de défaillance de la région principale.

DR actif-actif

• Les deux régions traitent le trafic de production.
• Données répliquées en continu ou quasi en temps réel.
• Équilibré en charge sur les régions.
• Coût plus élevé mais de meilleures performances et RTO.

Sauvegarde et restauration

• Sauvegardes régulières vers la région secondaire.
• Processus de restauration manuel en cas de défaillance de la région primaire.
• Coût le plus bas mais RTO et RPO les plus élevés.
• Convient aux charges de travail non critiques.

Définir les exigences RTO et RPO

Objectif de temps de récupération (RTO)

• Combien de temps l'entreprise peut-elle tolérer les temps d'arrêt ?
• Détermine les exigences d'automatisation du basculement.
• Influence l'investissement dans l'infrastructure.

Objectif de point de récupération (RPO)

• Quelle quantité de perte de données est acceptable ?
• Détermine la fréquence de réplication.
• Influence la stratégie de sauvegarde et de réplication.

Exigences RTO/RPO

• Charges de travail critiques : RTO < 1 heure, RPO < 15 minutes (actif-actif ou actif-passif avec réplication continue).
• Charges de travail importantes : RTO < 4 heures, RPO < 1 heure (actif-passif avec réplication horaire).
• Charges de travail standard : RTO < 24 heures, RPO < 24 heures (sauvegarde et restauration).

Concevoir une stratégie de test de reprise après sinistre (DR)

Les procédures de DR doivent être testées régulièrement afin de s'assurer qu'elles fonctionnent en cas de besoin. Concevez une stratégie de test de reprise après sinistre adaptée à vos exigences RTO/RPO.

Modèles de test DR

• Tests trimestriels de reprise après sinistre : Basculement complet vers la région secondaire, validation de tous les systèmes.
• Validation mensuelle du runbook : Examinez et mettez à jour les procédures de DR.
• Tests automatisés continus : testez régulièrement les composants individuels.
• Exercices sur table : simulez des scénarios de reprise après sinistre avec les parties prenantes.

Bonnes pratiques de test de DR

• Documentez les runbooks détaillés de reprise après sinistre avec des procédures étape par étape.
• Testez les procédures de reprise après sinistre pendant les heures creuses.
• Validez l'intégrité des données après le basculement.
• Mesurez le RTO et le RPO réels au cours des tests.
• Mettre à jour les procédures en fonction des résultats des tests.
• Former les équipes des opérations sur les procédures de reprise après sinistre.

Recommandations HA et DR

Recommandations

• Utilisez l'IaC (Terraform) pour déployer l'infrastructure dans les régions primaire et secondaire.
• Déployez le compute classique sur plusieurs zones de disponibilité pour HA.
• Utilisez le compute serverless pour le basculement automatique multizone.
• Mettre en œuvre la réplication géoredondante pour les données brutes et les sources de données.
• Utilisez Delta Deep Clone pour répliquer les tables critiques entre les régions.
• Utilisez la synchronisation SCIM pour une gestion cohérente des identités entre les régions.
• Documenter les exigences RTO et RPO pour toutes les charges de travail critiques.
• Automatisez les procédures de basculement DR lorsque cela est possible.
• Testez régulièrement les procédures de reprise après sinistre (DR) (au moins tous les trimestres).
• Documentez les runbooks détaillés de reprise après sinistre.

Evaluer en fonction des exigences

• Évaluez la reprise après sinistre (DR) actif-actif pour les charges de travail stratégiques avec des exigences RTO strictes.
• Conciliez l'investissement en reprise après sinistre (DR) avec la criticité commerciale et les exigences de RTO/RPO.
• Envisagez une DR multi-cloud pour une résilience maximale (mais une complexité et un coût plus élevés).

Résultats de la phase 10

Une fois la Phase 10 terminée, vous devriez avoir :

• Stratégie de haute disponibilité conçue (déploiement multi-zone pour le compute classique).
• Caractéristiques HA du plan de contrôle comprises (RTO de 15 minutes, RPO de 0).
• Stratégie de récupération après sinistre conçue (active-passive, active-active, ou sauvegarde/restauration).
• Exigences RTO et RPO définies pour les charges de travail critiques.
• Modèles de conception DR sélectionnés en fonction des exigences.
• Stratégie de test DR définie avec un calendrier de tests régulier.
• Approche IaC définie pour le déploiement vers des régions principales et secondaires.
• Stratégie de réplication des données conçue (par exemple, stockage géoredondant, Delta Deep Clone).
• Stratégie de gestion des identités conçue (synchronisation SCIM).
• Manuels de procédures DR documentés avec des procédures détaillées.

Vous avez terminé toutes les phases du guide de déploiement Databricks.