Les sinistres peuvent être des défaillances matérielles, des catastrophes naturelles ou des défaillances logicielles. Le processus de préparation et de récupération en cas de sinistre est appelé reprise d’activité. Cet article décrit les pratiques recommandées pour assurer la continuité d’activité et reprise d’activité des pipelines Azure Data Factory et Azure Synapse Analytics.
Les stratégies de continuité d’activité et reprise d’activité incluent la redondance des zones de disponibilité, la récupération automatisée fournie par la reprise d’activité Azure et la récupération gérée par l’utilisateur à l’aide de l’intégration continue/la livraison continue (CI/CD).
Architecture
Téléchargez un fichier Visio de cette architecture.
Workflow
Les pipelines Data Factory et Azure Synapse offrent de la résilience en utilisant des régions Azure et des zones de disponibilité Azure.
- Chaque région Azure a un ensemble de centres de données qui sont déployés dans un périmètre défini par la latence.
- Les zones de disponibilité sont des emplacements physiquement séparés au sein de chaque région Azure qui tolèrent les défaillances locales.
- Toutes les régions et zones de disponibilité Azure sont connectées via un réseau à faible latence, dédié et régional, et par un réseau hautes performances.
- Toutes les régions avec zone de disponibilité ont au moins trois zones de disponibilité distinctes pour garantir la résilience.
Lorsqu’un centre de données, une partie d’un centre de données ou une zone de disponibilité d’une région tombe en panne, le basculement se produit sans temps d’arrêt pour les pipelines Data Factory et Azure Synapse résilients aux zones.
Composants
- Azure Data Factory.
- Pipelines Azure Synapse Analytics et Azure Synapse
- GitHub
- Azure Repos
Détails du scénario
Les pipelines Data Factory et Azure Synapse stockent des artefacts qui incluent les données suivantes :
Métadonnées
- Pipeline
- Groupes de données
- Services liés
- Runtime d’intégration
- Déclencheurs
Données de surveillance
- Pipeline
- Déclencheurs
- Exécutions d’activités
Les sinistres peuvent être de différentes natures : défaillances matérielles, catastrophes naturelles ou défaillances logicielles résultant d’une erreur humaine ou d’une cyberattaque. Selon les types de défaillances, leur impact géographique peut être régional ou international. Lors de la planification d’une stratégie de reprise d’activité, tenez compte à la fois de la nature du sinistre et de son impact géographique.
La continuité d’activité et reprise d’activité dans Azure fonctionne sur un modèle de responsabilité partagée. De nombreux services Azure exigent que les clients configurent explicitement leur stratégie de reprise d’activité, tandis qu’Azure fournit l’infrastructure de base et les services de plateforme en fonction des besoins.
Vous pouvez utiliser les pratiques recommandées suivantes afin d’obtenir la continuité d’activité et reprise d’activité pour les pipelines Data Factory et Azure Synapse dans différents scénarios de défaillance. Pour l’implémentation, consultez Déployer ce scénario.
Récupération automatisée avec la reprise d’activité Azure
Lorsque vous configurez la récupération automatisée fournie par la sauvegarde et reprise d’activité Azure, les pipelines Data Factory ou Azure Synapse basculent automatiquement vers la région jumelée en cas de panne régionale complète d’une région Azure jumelée a une autre région. Les exceptions sont les régions d’Asie du Sud-Est et du Brésil, où les exigences de résidence des données exigent que les données restent dans ces régions.
Dans le cas d’un basculement de reprise d’activité, Data Factory effectue la récupération des pipelines de production. Si vous devez valider vos pipelines récupérés, vous pouvez sauvegarder les modèles Azure Resource Manager pour vos pipelines de production dans un stockage secret et comparer les pipelines récupérés aux sauvegardes.
L’équipe Azure Global effectue des exercices de continuité d’activité et reprise d’activité réguliers, auxquels Azure Data Factory et Azure Synapse Analytics participent. L’exercice de continuité d’activité et reprise d’activité simule une défaillance de région et bascule les services Azure vers une région jumelée sans intervention du client. Pour plus d’informations sur les exercices de continuité d’activité et reprise d’activité, consultez Test des services.
Redondance gérée par l’utilisateur avec CI/CD
Pour obtenir la continuité d’activité et reprise d’activité en cas de défaillance d’une région entière, vous avez besoin d’une fabrique de données ou d’un espace de travail Azure Synapse dans la région secondaire. En cas de suppression accidentelle d’un pipeline Data Factory ou Azure Synapse, de pannes ou d’événements de maintenance interne, vous pouvez utiliser Git et CI/CD pour récupérer les pipelines manuellement.
Si vous le souhaitez, vous pouvez utiliser une implémentation active/passive. La région primaire gère les opérations normales et reste active, tandis que la région de reprise d’activité secondaire nécessite que des étapes planifiées au préalable, en fonction d’une implémentation spécifique, soient promues au niveau principal. Dans ce cas, toutes les configurations nécessaires pour l’infrastructure sont disponibles dans la région secondaire, mais elles ne sont pas provisionnées.
Cas d’usage potentiels
La redondance gérée par l’utilisateur est utile dans plusieurs scénarios, notamment :
- Suppression accidentelle d’artefacts de pipeline en raison d’une erreur humaine.
- Interruptions étendues ou événements de maintenance qui ne déclenchent pas de continuité d’activité et reprise d’activité en raison de l’absence de sinistre signalé.
Vous pouvez rapidement déplacer vos charges de travail de production vers d’autres régions et ne pas être affecté.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.
Les pipelines Data Factory et Azure Synapse sont des services Azure standard qui prennent en charge les zones de disponibilité, et ils sont conçus pour fournir le niveau de résilience et de flexibilité approprié, ainsi qu’une latence ultra-faible.
L’approche de récupération gérée par l’utilisateur vous permet de continuer vos activités en cas d’événements de maintenance, de pannes ou d’erreurs humaines dans la région primaire. À l’aide de CI/CD, les pipelines Data Factory et Azure Synapse peuvent s’intégrer à un dépôt Git et se déployer dans une région secondaire pour une récupération immédiate.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
La récupération gérée par l’utilisateur intègre Data Factory à Git à l’aide de CI/CD et utilise éventuellement une région de reprise d’activité secondaire qui a toutes les configurations d’infrastructure nécessaires en tant que sauvegarde. Ce scénario peut entraîner des coûts supplémentaires. Pour estimer les coûts, utilisez la calculatrice de prix Azure.
Pour obtenir des exemples de tarification de Data Factory et Azure Synapse Analytics, consultez les pages suivantes :
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.
En utilisant l’approche de récupération CI/CD gérée par l’utilisateur, vous pouvez bénéficier d’une intégration à Azure Repos ou GitHub. Pour plus d’informations sur les meilleures pratiques CI/CD, consultez cet article.
Déployer ce scénario
Effectuez les actions suivantes afin de configurer la reprise d’activité automatisée ou gérée par l’utilisateur pour les pipelines Data Factory et Azure Synapse.
Configurer la récupération automatique
Dans Data Factory, vous pouvez définir la région de runtime d’intégration Azure (IR) pour l’exécution ou la répartition de votre activité dans le programme d’installation du runtime d’intégration. Pour activer le basculement automatique en cas de panne régionale complète, définissez Région sur Résolution automatique.
Dans le contexte des runtimes d’intégration, le runtime d’intégration bascule automatiquement vers la région jumelée lorsque vous sélectionnez Résoudre automatiquement comme région de runtime d’intégration. Pour d’autres régions/emplacement spécifiques, vous pouvez créer une fabrique de données secondaire dans une autre région et utiliser CI/CD pour provisionner votre fabrique de données à partir du dépôt Git.
Pour les réseaux virtuels managés, Data Factory bascule également automatiquement vers le runtime d’intégration managé.
Le basculement automatique managé Azure ne s’applique pas au runtime d’intégration auto-hébergé (SHIR), car l’infrastructure est gérée par le client. Pour obtenir des conseils sur la configuration de plusieurs nœuds pour une plus grande disponibilité avec le runtime d'intégration auto-hébergé, consultez Créer et configurer un runtime d’intégration auto-hébergé.
Pour configurer la continuité d’activité et reprise d’activité pour Azure-SSIS IR, consultez Configurer le runtime d’intégration Azure-SSIS pour la continuité d’activité et la reprise d’activité (BCDR).
Les services liés ne sont pas entièrement activés après le basculement, en raison des points de terminaison privés en attente dans le réseau le plus récent de la région. Vous devez configurer des points de terminaison privés dans la région récupérée. Vous pouvez automatiser la création de points de terminaison privés à l’aide de l’API d’approbation.
Configurer la récupération gérée par l’utilisateur via CI/CD
Vous pouvez utiliser Git et CI/CD pour récupérer manuellement des pipelines en cas de suppression ou de panne de pipeline Data Factory ou Azure Synapse.
Pour utiliser les fonctionnalités CI/CD des pipelines Data Factory, consultez Intégration continue et livraison continue dans Azure Data Factory et Contrôle de code source dans Azure Data Factory.
Pour utiliser les fonctionnalités CI/CD des pipelines Azure Synapse, consultez Intégration continue et livraison continue pour un espace de travail Azure Synapse Analytics. Veillez à initialiser d’abord l’espace de travail Azure Synapse. Pour plus d’informations, consultez Contrôle de code source dans Synapse Studio.
Lorsque vous déployez une redondance gérée par l’utilisateur à l’aide de CI/CD, effectuez les actions suivantes :
Désactive les déclencheurs
Désactivez les déclencheurs dans la fabrique de données principale d’origine une fois qu’elle est à nouveau en ligne. Vous pouvez désactiver les déclencheurs manuellement, ou implémenter l’automatisation pour vérifier régulièrement la disponibilité du serveur principal d’origine. Désactivez tous les déclencheurs de la fabrique de données principale d’origine immédiatement après la reprise d’activité de la fabrique.
Pour utiliser Azure PowerShell afin d’activer ou de désactiver des déclencheurs Data Factory, consultez Exemples de script de pré-déploiement et post-déploiement et Améliorations CI/CD relatives au déploiement de déclencheurs de pipeline.
Gérer les écritures en double
La plupart des pipelines d’extraction, de transformation et de chargement (ETL) sont conçus pour gérer les écritures en double, car le remplissage et la restauration en ont besoin. Les récepteurs de données qui prennent en charge le basculement transparent peuvent gérer les écritures en double avec la fusion des enregistrements ou en supprimant et en insérant tous les enregistrements dans l’intervalle de temps spécifique.
Pour les récepteurs de données qui modifient les points de terminaison après le basculement, le stockage principal et secondaire peut avoir des données en double ou partielles. Vous devez fusionner les données manuellement.
Vérifier le témoin et contrôler le flux de pipeline (facultatif)
En général, vous devez concevoir vos pipelines pour inclure des activités, telles que les activités d’échec et de recherche, pour redémarrer les pipelines ayant échoué à partir du point d’intérêt.
Ajoutez un paramètre global dans votre fabrique de données pour indiquer la région, par exemple
region='EastUS'dans la fabrique de données primaire etregion='CentralUS'dans la fabrique de données secondaire.Créez un témoin dans une troisième région. Le témoin peut être un appel REST ou n’importe quel type de stockage. Le témoin retourne la région primaire actuelle, par exemple
'EastUS', par défaut.En cas de sinistre, mettez à jour manuellement le témoin pour retourner la nouvelle région primaire, par exemple
'CentralUS'.Ajoutez une activité dans votre pipeline pour rechercher le témoin et comparer la valeur primaire actuelle au paramètre global.
- Si les paramètres correspondent, ce pipeline est en cours d’exécution sur la région primaire. Continuez avec le travail réel.
- Si les paramètres ne correspondent pas, ce pipeline s’exécute sur la région secondaire. Retournez simplement le résultat.
Notes
Cette approche introduit une dépendance sur la recherche de témoin dans votre pipeline. L’échec de la lecture du témoin interrompt toutes les exécutions de pipeline.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Principaux auteurs :
Krishnakumar Rukmangathan | Responsable de programme senior - équipe Azure Data Factory
Sunil Sabat | Responsable de programme principal - équipe Azure Data Factory
Autres contributeurs :
Mario Zimmermann | Responsable Génie logiciel principal - équipe Azure Data Factory
Wee Hyong Tok | Directeur principal PM - équipe Azure Data Factory
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Gestion de la continuité d’activité dans Azure
- Résilience dans Azure
- Terminologie de la résilience Azure
- Régions et zones de disponibilité
- Réplication interrégionale dans Azure
- Guide de décision concernant les régions Azure
- Services Azure prenant en charge les zones de disponibilité
- Responsabilité partagée dans le cloud
- Redondance des données dans Azure Data Factory
- Runtime d’intégration dans Azure Data Factory
- Pipelines et activités dans Azure Data Factory et Azure Synapse Analytics
- Intégration de données dans Azure Synapse Analytics par rapport à Azure Data Factory