Fiabilité dans Azure Data Factory

Azure Data Factory vous permet de créer des pipelines de données flexibles et puissants pour l’intégration et la transformation des données serverless. En tant que service Azure, Data Factory fournit une gamme de fonctionnalités pour prendre en charge vos exigences de fiabilité.

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

Cet article explique comment rendre Data Factory résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence certaines informations clés sur le contrat de niveau de service Data Factory (SLA).

Note

Lorsque vous envisagez la fiabilité de votre fabrique de données, vous devez également prendre en compte la fiabilité des magasins de données auxquels il se connecte. L'amélioration de la résilience de l'usine de données à elle seule pourrait avoir un impact limité si les magasins de données ne sont pas également résilients. Selon vos besoins de résilience, vous devrez peut-être apporter des modifications de configuration dans plusieurs domaines. Pour vous assurer que les magasins de données répondent à vos exigences de continuité d’activité, consultez la documentation et les conseils de fiabilité de leur produit.

Vue d’ensemble de l’architecture de fiabilité

Data Factory se compose de plusieurs composants d’infrastructure. Chaque composant prend en charge la fiabilité de l’infrastructure de différentes façons.

Les composants de Data Factory sont les suivants :

• Le service Data Factory principal, qui gère les déclencheurs de pipeline et supervise la coordination des activités de pipeline. Le service principal gère également les métadonnées pour chaque composant de la fabrique de données. Microsoft gère le service principal.

• Runtimes d’intégration ,qui se connectent aux magasins de données et effectuent des activités définies dans votre pipeline. Il existe différents types d’IR.

  • Les IR gérés par Microsoft, y compris l'IR Azure et l'IR des Services d'Intégration de Serveur Azure-SQL (Azure-SSIS). Microsoft gère les composants qui composent ces runtimes. Dans certains scénarios, vous configurez les paramètres qui affectent la résilience de vos E/S.

  • Runtimes d’intégration auto-gérés (SHIR) Microsoft fournit des logiciels que vous pouvez exécuter sur votre propre infrastructure de calcul pour effectuer certaines parties de vos pipelines Data Factory. Vous êtes responsable du déploiement et de la gestion des ressources de calcul et de la résilience de ces ressources de calcul.

Résilience aux erreurs temporaires

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

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

Lorsque vous utilisez Data Factory, il est important de préparer les erreurs temporaires, en particulier lorsque vous concevez des pipelines et des activités.

Idempotence

Vos activités de pipeline doivent être idempotentes, ce qui signifie que vous pouvez les réexécuter plusieurs fois sans provoquer d’effets indésirables. Si une erreur temporaire comme une défaillance réseau ou une panne de zone de disponibilité se produit, Data Factory peut réexécuter les activités de pipeline. Cette réexécution peut créer des enregistrements en double.

Pour empêcher l’insertion d’enregistrements en double en raison d’une erreur temporaire, implémentez les meilleures pratiques suivantes :

• Utilisez des identificateurs uniques pour chaque enregistrement avant d’écrire dans la base de données. Cette approche peut vous aider à trouver et à éliminer les enregistrements en double.

• Utilisez la stratégie d’upsert pour les connecteurs qui prennent en charge l’upsert. Avant d’insérer des enregistrements en double, utilisez cette approche pour vérifier si un enregistrement existe déjà. S’il existe, mettez-le à jour. S’il n’existe pas, insérez-le. Par exemple, les commandes SQL telles que MERGE ou ON DUPLICATE KEY UPDATE utilisent cette approche upsert.

• Utilisez des stratégies d’actions de copie. Pour plus d’informations, consultez vérification de cohérence des données dans l’activité de copie.

Stratégies de nouvelle tentative

Vous pouvez utiliser des stratégies de nouvelle tentative pour configurer des parties de votre pipeline pour réessayer en cas de problème, comme des erreurs temporaires dans les ressources connectées. Dans Data Factory, vous pouvez configurer des stratégies de nouvelle tentative sur les types d’objets de pipeline suivants :

• Déclencheurs de fenêtre bascule
• Activités d’exécution

Pour découvrir plus d’informations sur la modification ou la désactivation des stratégies de nouvelle tentative pour vos déclencheurs et activités de fabrique de données, consultez Exécution et déclencheurs de pipeline.

Résilience aux échecs de zone de disponibilité

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

Data Factory prend en charge la redondance des zones, ce qui assure la résilience aux défaillances dans les zones de disponibilité.

Chaque partie de Data Factory prend en charge la redondance de zone :

• Service principal : Microsoft gère les composants du service Data Factory principal et les répartit entre les zones de disponibilité.

  Toutefois, après une défaillance de zone, Microsoft n’assure pas l’état des déclencheurs de fenêtre bascule.

• Irs: La prise en charge de la redondance de zone dépend du type d’ir que vous utilisez.

  • Azure IR prend en charge la redondance de zone, et Microsoft gère cette fonctionnalité.

    

  • Une instance Azure-SSIS IR vous oblige à déployer au moins deux nœuds. Ces nœuds sont alloués automatiquement dans différentes zones de disponibilité.

    Le diagramme suivant illustre un pipeline redondant interzone et un runtime d’intégration Azure-SSIS avec deux nœuds déployés dans différentes zones :

    

  • Un SHIR vous donne la responsabilité de déployer l’infrastructure de calcul pour héberger le runtime. Vous pouvez déployer plusieurs nœuds, tels que des machines virtuelles individuelles, et les configurer pour une haute disponibilité. Vous pouvez ensuite distribuer ces nœuds entre plusieurs zones de disponibilité. Pour plus d’informations, consultez Haute disponibilité et scalabilité.

Spécifications

Les ressources Data Factory redondantes interzone peuvent être déployées dans n’importe quelle région qui prend en charge les zones de disponibilité.

Coût

• Service principal : Aucun coût supplémentaire ne s’applique à la redondance de zone.

• Irs: Le coût de la redondance de zone varie en fonction du type d’ir que vous utilisez.

  • Un runtime d’intégration Azure inclut la redondance de zone sans frais supplémentaires.

  • Un runtime d’intégration Azure-SSIS vous oblige à déployer au moins deux nœuds pour atteindre une redondance de zone. Pour plus d’informations sur la facturation de chaque nœud, consultez l'exemple de calcul tarifaire : Exécution des packages SSIS sur un environnement d’exécution Azure-SSIS.

  • Un SHIR vous oblige à déployer et à gérer l’infrastructure de calcul. Pour obtenir une résilience de zone, vous devez répartir vos ressources de calcul entre plusieurs zones. En fonction du nombre de nœuds que vous déployez et de la façon dont vous les configurez, vous pouvez entraîner des coûts supplémentaires à partir des services de calcul sous-jacents et d’autres services de prise en charge. Il n’existe aucun frais supplémentaire pour exécuter le SHIR sur plusieurs nœuds.

Configurez la prise en charge des zones de disponibilité

• Service principal : Aucune configuration requise. Le service principal Data Factory prend automatiquement en charge la redondance de zone.

• Irs:

  • Azure IR : Aucune configuration requise. Azure IR active automatiquement la redondance de zone.

  • Un Azure-SSIS IR : aucune configuration n’est requise. Un runtime d’intégration Azure-SSIS active automatiquement la redondance de zone lorsqu’il est déployé avec au moins deux nœuds.

  • Un SHIR vous oblige à configurer votre propre résilience, ce qui inclut la répartition de vos nœuds entre plusieurs zones de disponibilité.

Planification de capacité et gestion

• Service principal : Le service de base Data Factory est mis à l’échelle automatiquement en fonction de la demande et vous n’avez pas besoin de planifier ou de gérer la capacité.

• Irs:

  • Un runtime d’intégration Azure est mis à l’échelle automatiquement en fonction de la demande et vous n’avez pas besoin de planifier ou de gérer la capacité.

  • Un IR Azure-SSIS vous oblige à configurer spécifiquement le nombre de nœuds que vous utilisez. Pour vous préparer à un échec de zone de disponibilité, envisagez de surapprovisionner la capacité de votre runtime d’intégration. Le surapprovisionnement permet à la solution de tolérer un certain degré de perte de capacité et de continuer à fonctionner sans dégradation des performances. Pour plus d’informations, consultez Gérer la capacité en surprovisionnant.

  • Un SHIR nécessite que vous configuriez votre propre capacité et scalabilité. Envisagez le surapprovisionnement lorsque vous déployez un SHIR.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque les ressources Data Factory sont configurées pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

• Routage du trafic entre les zones : Pendant les opérations normales, Data Factory distribue automatiquement les activités de pipeline, les déclencheurs et d’autres tâches entre des instances saines dans chaque zone de disponibilité.

• Réplication des données entre les zones : En général, Data Factory est un service sans état. Il n’est donc pas nécessaire de répliquer l’état entre les zones.

  Toutefois, les déclencheurs de fenêtres bascules contiennent un état qui n’est peut-être pas entièrement répliqué entre les zones.

Comportement lors d’une défaillance de zone

Cette section décrit ce qui doit être attendu lorsque les ressources Data Factory sont configurées pour la redondance de zone et qu’il existe une panne de zone de disponibilité.

• Détection et réponse : La plateforme Data Factory est chargée de détecter un échec dans une zone de disponibilité et de répondre. Vous n’avez rien à faire pour lancer un basculement de zone dans vos pipelines ou dans d’autres composants.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Demandes actives : tous les pipelines et déclencheurs en cours continuent de s’exécuter et aucune interruption immédiate ne survient en raison d’une défaillance de zone. Toutefois, les activités en cours pendant une défaillance de zone peuvent échouer et être redémarrées. Il est important de concevoir des activités pour qu’elles soient idempotentes, ce qui les aide à récupérer suite à des défaillances de zone, ainsi qu’à d’autres types de défauts. Pour plus d’informations, consultez Résilience aux erreurs temporaires.

• Temps d’arrêt attendu : Aucun temps d’arrêt n’est attendu lors d’une défaillance de zone.

• Perte de données attendue : Dans l’ensemble, Data Factory est un service sans état, donc aucune perte de données n’est attendue lors d’une défaillance de zone.

  Toutefois, si vous utilisez un déclencheur de fenêtre bascule, il est possible que l’état du déclencheur soit perdu après une défaillance de zone. Vous devez redémarrer ou réexécuter les déclenchements qui s'exécutaient au moment de l’échec de la zone.

Récupération de la zone

Lorsque la zone de disponibilité récupère, Data Factory bascule automatiquement vers la zone d’origine. Vous n’avez rien à faire pour lancer une restauration automatique de zone dans vos pipelines ou dans d’autres composants.

Toutefois, si vous utilisez un SHIR, vous devrez peut-être redémarrer vos ressources de calcul si elles ont été arrêtées.

Tester les pannes de zone

Pour le service principal, ainsi que pour les runtimes d’intégration Azure et Azure-SSIS, Data Factory gère le routage du trafic, le basculement et la restauration automatique pour les ressources redondantes interzones. Cette fonctionnalité étant complètement managée, vous n’avez pas besoin de lancer ou de valider les processus de défaillance de zone de disponibilité.

Pour les shirs, vous pouvez utiliser Azure Chaos Studio pour simuler une défaillance de zone de disponibilité sur une machine virtuelle Azure.

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

Les ressources Data Factory sont déployées dans une seule région Azure. Si la région devient indisponible, votre usine de données devient également indisponible. Toutefois, il existe des approches que vous pouvez utiliser pour garantir la résilience aux pannes de région. Ces approches varient selon que la fabrique de données se trouve dans une région jumelée ou non associée et selon vos exigences et configuration spécifiques.

Basculement managé par Microsoft vers une région couplée

Data Factory prend en charge le basculement géré par Microsoft pour les fabriques de données dans des régions couplées, à l’exception de Brésil Sud et Asie Sud-Est. Dans le cas peu probable d'une défaillance prolongée de la région, Microsoft pourrait initier un basculement régional de votre instance Data Factory.

En raison des exigences de résidence des données dans le Brésil Sud et Asie Sud-Est, les données Data Factory sont stockées uniquement dans la région locale à l’aide du stockage redondant interzone Azure. Pour l’Asie sud-est, toutes les données sont stockées à Singapour. Pour le Brésil Sud, toutes les données sont stockées au Brésil.

Pour les fabriques de données dans des régions non couplées ou dans Brésil Sud ou Asie Sud-Est, Microsoft n’effectue pas de basculement régional à votre place.

Important

Microsoft déclenche le basculement géré par Microsoft. Il est probable qu’il se produise après un retard important et qu’il soit effectué en fonction des meilleures possibilités. Il existe également des exceptions à ce processus. Vous risquez de perdre des métadonnées de l'usine de données. Le basculement des ressources de Data Factory peut se produire à un moment différent de celui du basculement des autres services Azure.

Si vous devez être résilient aux pannes de région, envisagez d’utiliser l’une des solutions multirégions personnalisées pour la résilience.

Basculement des runtimes d’intégration

Pour préparer un basculement, il est possible qu’il y ait des considérations supplémentaires, selon le runtime d’intégration que vous utilisez.

• Vous pouvez configurer le runtime d’intégration Azure pour résoudre automatiquement la région qu’il utilise. Si la région est définie sur auto resolve et qu’il existe une panne dans la région primaire, Azure IR bascule automatiquement vers la région jumelée. Ce basculement est soumis à des limitations. Pour configurer la région de runtime d’intégration Azure pour l’implémentation ou la distribution de votre activité dans la configuration du runtime d’intégration, définissez la région sur résoudre automatiquement.

• Le basculement de Runtime d’intégration Azure-SSIS est managé séparément du basculement géré par Microsoft de la fabrique de données. Pour plus d’informations, consultez Les solutions multirégions personnalisées pour la résilience.

• Un SHIR s’exécute sur l’infrastructure pour laquelle vous êtes responsable. Par conséquent, un basculement géré par Microsoft ne s’applique pas aux shiRs. Pour plus d’informations, consultez Les solutions multirégions personnalisées pour la résilience.

Reconfiguration après basculement

Une fois le basculement géré par Microsoft terminé, vous pouvez accéder à votre pipeline Data Factory dans la région jumelée. Toutefois, une fois le basculement terminé, vous devrez peut-être effectuer une reconfiguration pour les runtimes d’intégration ou d’autres composants. Ce processus inclut la réécriture de la configuration réseau.

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

Si vous avez besoin que vos pipelines soient résilients aux pannes régionales et que vous avez besoin de contrôler le processus de basculement, envisagez d’utiliser un pipeline piloté par les métadonnées.

• Configurez le contrôle de code source pour Data Factory afin de suivre et d’auditer les modifications apportées à vos métadonnées. Vous pouvez utiliser cette approche pour accéder à vos fichiers JSON de métadonnées pour les pipelines, les jeux de données, les services liés et les déclencheurs. Data Factory prend en charge différents types de référentiels Git, tels qu’Azure DevOps et GitHub. Pour plus d’informations, consultez Contrôle de code source dans Data Factory.

• Utilisez un système d’intégration continue et de livraison continue (CI/CD), tel qu’Azure DevOps, pour gérer vos métadonnées et déploiements de pipeline. Vous pouvez utiliser CI/CD pour restaurer rapidement des opérations sur une instance d’une autre région. Si une région n’est pas disponible, vous pouvez approvisionner une nouvelle fabrique de données manuellement ou via l’automatisation. Après la création de la nouvelle fabrique de données, vous pouvez restaurer vos pipelines, jeux de données et services liés JSON à partir du dépôt Git existant. Pour plus d’informations, consultez continuité d’activité et récupération d’urgence (BCDR) pour les pipelines Data Factory et Azure Synapse Analytics.

Selon l'IR que vous utilisez, il peut y avoir d'autres considérations.

• Un IR Azure-SSIS utilise une base de données stockée dans Azure SQL Database ou Azure SQL Managed Instance. Vous pouvez configurer la géo ou un groupe de basculement pour cette base de données. La base de données Azure-SSIS se trouve dans une région Azure principale disposant d’un accès en lecture-écriture. La base de données est répliquée en continu vers une région secondaire qui dispose d’un accès en lecture seule. Si la région primaire n’est pas disponible, un basculement survient, entraînant l’échange des rôles des bases de données primaires et secondaires.

  Vous pouvez également configurer une paire de runtimes d’intégration Azure SSIS de secours qui fonctionne en synchronisation avec un groupe de basculement Azure SQL Database ou Azure SQL Managed Instance.

  Pour plus d’informations, consultez Configurer un Azure-SSIS IR pour BCDR.

• Un SHIR s’exécute sur l’infrastructure que vous gérez. Si le SHIR est déployé sur une machine virtuelle Azure, vous pouvez utiliser Azure Site Recovery pour déclencher le basculement de machine virtuelle vers une autre région.

Sauvegarde et restauration

Data Factory prend en charge CI/CD via l’intégration du contrôle de code source, afin de pouvoir sauvegarder les métadonnées d’une instance de fabrique de données. Les pipelines CI/CD déploient ces métadonnées en toute transparence dans un nouvel environnement. Pour plus d’informations, consultez CI/CD dans Data Factory.

Contrat de niveau de service

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

Data Factory fournit des contrats SLA de disponibilité distincts pour :

• Taux de réussite des appels d’API que vous effectuez, tels que ceux pour gérer votre fabrique de données.
• Nombre d’exécutions d’activités qui commencent.

Les déroulements des activités peuvent être brièvement retardés, à condition que toutes les dépendances nécessaires à l'exécution du travail soient satisfaites.

Contenu connexe

• Fiabilité dans Azure