Partage via

Continuité d’activité et reprise d’activité pour Azure Logic Apps

  • Article

Pour réduire l’impact et les effets des événements imprévisibles sur votre entreprise et vos clients, assurez-vous de disposer d’une solution de reprise d’activité (DR) afin de pouvoir protéger les données, restaurer rapidement les ressources qui prennent en charge les fonctions métier critiques et maintenir l’exécution des opérations afin de préserver la continuité d’activité (BC). Par exemple, les interruptions peuvent inclure des pannes, des pertes de l’infrastructure sous-jacente ou des composants tels que les ressources de stockage, réseau ou de calcul, des défaillances d’application irrécupérables ou même une perte complète du centre de ressources. En disposant d’une solution de continuité d’activité et de reprise d’activité (BCDR), votre entreprise ou organisation peut faire face plus rapidement aux interruptions, planifiées ou non, et réduire les temps d’arrêt affectant vos clients.

Cet article fournit des conseils et des stratégies BCDR que vous pouvez appliquer lorsque vous créez des flux de travail automatisés à l’aide d’Azure Logic Apps. Les flux de travail d’application logique vous aident à intégrer et orchestrer plus facilement les données entre les applications, les services cloud et les systèmes locaux en réduisant la quantité de code que vous devez écrire. Quand vous planifiez d’utiliser une solution BCDR, veillez à ne pas prendre en compte que vos applications logiques, mais également ces ressources Azure que vous utilisez avec vos applications logiques :

Emplacements principal et secondaire

Chaque application logique doit spécifier l’emplacement que vous souhaitez utiliser pour le déploiement, par exemple une région Azure telle que « USA Ouest ». Cette stratégie de reprise d’activité est axée sur la configuration de votre application logique principale afin qu’elle bascule vers une application logique de secours ou de sauvegarde dans un autre emplacement où Azure Logic Apps est également disponible. Ainsi, si l’application logique principale subit des pertes, des interruptions ou des défaillances, l’application logique secondaire peut prendre le relais. Cette stratégie exige que votre application logique secondaire et les ressources dépendantes soient déjà déployées et prêtes dans l’emplacement secondaire.

Remarque

Si votre application logique fonctionne également avec des artefacts B2B, comme des partenaires commerciaux, des contrats, des schémas, des cartes et des certificats, qui sont stockés dans un compte d’intégration, ce dernier et vos applications logiques doivent utiliser le même emplacement.

Si vous suivez les bonnes pratiques DevOps, vous utilisez déjà des modèles Azure Resource Manager pour définir et déployer vos applications logiques et leurs ressources dépendantes. Les modèles Resource Manager vous permettent d’utiliser une seule définition de déploiement, puis d’utiliser les fichiers de paramètres pour fournir les valeurs de configuration à utiliser pour chaque destination de déploiement. Cela signifie que vous pouvez déployer la même application logique dans différents environnements, par exemple, de développement, de test et de production. Vous pouvez également déployer la même application logique, qui prend en charge les stratégies de récupération d’urgence utilisant des régions appairées, dans plusieurs régions Azure.

Pour la stratégie de basculement, vos applications logiques et emplacements doivent respecter les conditions suivantes :

  • L’instance de l’application logique secondaire a accès aux mêmes applications, services et systèmes que l’instance de l’application logique principale.

  • Les deux instances de l’application logique ont le même type d’hôte. Par conséquent, les deux instances sont déployées dans des régions dans Azure Logic Apps multilocataire global ou des régions dans Azure Logic Apps monolocataire. Pour connaître les bonnes pratiques et obtenir plus d’informations sur les régions appairées pour la continuité d’activité et la reprise d’activité (BCDR), consultez Réplication inter-région dans Azure : continuité d’activité et reprise d’activité.

Exemple : Azure multilocataire

Cet exemple montre des instances d’application logique principale et secondaire, qui sont déployées dans des régions distinctes d’Azure multilocataire mondial pour ce scénario. Un seul modèle Resource Manager définit les deux instances d’application logique et les ressources dépendantes requises par ces applications logiques. Des fichiers de paramètres distincts spécifient les valeurs de configuration à utiliser pour chaque emplacement de déploiement :

Instances d’application logique principale et secondaire dans des emplacements distincts

Connexions aux ressources

Azure Logic Apps fournit des plusieurs centaines d’opérations de connecteurs que le flux de travail de votre application logique peut utiliser pour fonctionner avec d’autres applications, services, systèmes et autres ressources, comme les comptes de stockage Azure, les bases de données SQL Server, les comptes e-mail professionnels ou scolaires, etc. Si votre application logique a besoin d’accéder à ces ressources, vous créez des connexions qui authentifient l’accès à ces ressources. Chaque connexion est une ressource Azure distincte qui existe dans un emplacement spécifique et qui ne peut pas être utilisée par des ressources situées dans d’autres emplacements.

Pour votre stratégie de reprise d’activité, prenez en compte les emplacements où des ressources dépendantes existent par rapport à vos instances d’application logique :

  • Votre instance principale et les ressources dépendantes existent dans des emplacements différents. Dans ce cas, votre instance secondaire peut se connecter aux mêmes ressources dépendantes ou points de terminaison. Toutefois, vous devez créer des connexions spécifiques pour votre instance secondaire. De cette façon, si votre emplacement principal devient indisponible, les connexions de l’emplacement secondaire ne sont pas affectées.

    Supposons, par exemple, que votre application logique principale se connecte à un service externe tel que Salesforce. En règle générale, la disponibilité et l’emplacement du service externe sont indépendants de la disponibilité de votre application logique. Dans ce cas, votre instance secondaire peut se connecter au même service, mais doit avoir sa propre connexion.

  • Votre instance principale et les ressources dépendantes existent dans le même emplacement. Dans ce cas, les ressources dépendantes doivent avoir des sauvegardes ou des versions répliquées dans un autre emplacement afin que votre instance secondaire puisse toujours accéder à ces ressources.

    Supposons, par exemple, que votre application logique principale se connecte à un service qui se trouve dans le même emplacement ou la même région, par exemple, Azure SQL Database. Si toute cette région n’est plus disponible, le service Azure SQL Database de cette région est aussi probablement indisponible. Dans ce cas, il faudra que votre instance secondaire utilise une base de données répliquée ou de sauvegarde avec une connexion distincte à cette base de données.

Passerelles de données locales

Si votre application logique s’exécute dans Azure multilocataire et a besoin d’accéder à des ressources locales telles que des bases de données SQL Server, vous devez installer la passerelle de données locale sur un ordinateur local. Vous pouvez ensuite créer une ressource de passerelle de données dans le portail Azure afin que votre application logique puisse utiliser la passerelle lorsque vous créez une connexion à la ressource.

La ressource de passerelle de données est associée à un emplacement ou à une région Azure, tout comme la ressource de votre application logique. Dans votre stratégie de reprise d’activité, assurez-vous que la passerelle de données reste disponible pour que votre application logique puisse l’utiliser. Vous pouvez activer la haute disponibilité pour votre passerelle lorsque vous avez plusieurs installations de passerelle.

Rôles actif/actif et actif/passif

Vous pouvez configurer vos emplacements principal et secondaire de manière à ce que les instances de votre application logique dans ces emplacements puissent jouer ces rôles :

Rôle principal/secondaire Description
Actif/actif Les instances d’application logique principale et secondaire dans les deux emplacements gèrent activement les demandes en suivant l’un de ces modèles :

- Équilibrage de charge : Vous pouvez faire en sorte que les deux instances écoutent un point de terminaison et équilibrent la charge du trafic vers chaque instance selon les besoins.

- Consommateurs concurrents : Vous pouvez faire en sorte que les deux instances agissent comme des consommateurs concurrents afin qu’elles soient en concurrence pour les messages provenant d’une file d’attente. Si une instance échoue, l’autre instance prend la charge de travail.
Actif/passif L’instance d’application logique principale gère activement l’intégralité de la charge de travail, tandis que l’instance secondaire est passive (désactivée ou inactive). L’instance secondaire attend un signal indiquant que l’instance principale n’est pas disponible ou ne fonctionne pas en raison d’une interruption ou d’un échec, et prend la charge de travail en tant qu’instance active.
Combinaison Certaines applications logiques jouent un rôle actif/actif, tandis que d’autres applications logiques jouent un rôle actif/passif.

Exemples actif/actif

Ces exemples illustrent la configuration actif/actif dans laquelle les deux instances de l’application logique gèrent activement les requêtes ou les messages. Un autre système ou service distribue les demandes ou les messages entre les instances, par exemple, l’une de ces options :

  • Un équilibreur de charge « physique », comme du matériel qui achemine le trafic

  • Un équilibreur de charge « logiciel », comme Azure Load Balancer ou Gestion des API Azure. Avec Gestion des API, vous pouvez spécifier des stratégies qui déterminent comment équilibrer la charge du trafic entrant. Vous pouvez également utiliser un service qui prend en charge le suivi de l’état, par exemple, Azure Service Bus.

    Bien que cet exemple illustre principalement Azure Load Balancer, vous pouvez utiliser l’option qui répond le mieux aux besoins de votre scénario :

    Configuration « actif/actif » qui utilise un équilibrage de charge ou un service avec état

  • Chaque instance d’application logique agit comme un consommateur et les deux instances sont en concurrence pour les messages provenant d’une file d’attente :

    Configuration « actif/actif » qui utilise des « consommateurs concurrents »

Exemples actif/passif

Cet exemple montre la configuration actif/passif dans laquelle l’instance d’application logique principale est active à un emplacement, tandis que l’instance secondaire reste inactive à un autre emplacement. Si l’instance principale subit une interruption ou une défaillance, vous pouvez faire en sorte qu’un opérateur exécute un script qui active l’instance secondaire pour qu’elle prenne en charge la charge de travail.

Configuration « actif/passif » qui utilise des « consommateurs concurrents »

Combinaison de configuration actif/actif et actif/passif

Cet exemple montre une configuration combinée dans laquelle l’emplacement principal contient les deux instances d’application logique actives, tandis que l’emplacement secondaire contient des instances d’application logique actives/passives. Si l’emplacement principal subit une interruption ou une défaillance, l’application logique active dans l’emplacement secondaire, qui se charge déjà d’une charge de travail partielle, peut se charger de la charge de travail dans son intégralité.

  • Dans l’emplacement principal, une application logique active écoute les messages dans une file d’attente Azure Service Bus, tandis qu’une autre application logique active vérifie les e-mails à l’aide d’un déclencheur d’interrogation Office 365 Outlook.

  • Dans l’emplacement secondaire, une application logique active fonctionne avec l’application logique dans l’emplacement principal en écoutant les messages dans la même file d’attente Service Bus et en entrant en concurrence pour ceux-ci. Pendant ce temps, une application logique inactive passive attend, en mode veille, pour vérifier les e-mails lorsque l’emplacement principal devient indisponible, mais elle est désactivée pour éviter de relire les mêmes e-mails.

Combinaison « actif/passif » et « actif/passif » qui utilise des déclencheurs de périodicité

État et historique de l’application logique

Lorsque votre application logique est déclenchée et commence à s’exécuter, l’état de l’application est stocké à l’emplacement où l’application a démarré et n’est pas transférable vers un autre emplacement. En cas de défaillance ou d’interruption, toutes les instances de flux de travail en cours sont abandonnées. Lorsque vous avez configuré un emplacement principal et un emplacement secondaire, les nouvelles instances de flux de travail commencent à s’exécuter à l’emplacement secondaire.

Réduire les instances en cours abandonnées

Pour réduire le nombre d’instances de flux de travail en cours abandonnées, vous pouvez choisir parmi différents modèles de messages que vous pouvez implémenter, par exemple :

Accéder à l’historique du déclencheur et des exécutions

Pour obtenir plus d’informations sur les exécutions passées de flux de travail de votre application logique, vous pouvez examiner l’historique du déclencheur et des exécutions de l’application. L’historique d’exécution d’une application logique est stocké dans l’emplacement ou la région où l’application logique a été exécutée, ce qui signifie que vous ne pouvez pas migrer cet historique vers un autre emplacement. Si votre instance principale bascule vers une instance secondaire, vous ne pouvez accéder à l’historique du déclencheur et des exécutions de chaque instance que dans les emplacements respectifs où ces instances ont été exécutées. Toutefois, vous pouvez obtenir des informations indépendantes de l’emplacement sur l’historique de votre application logique en configurant vos applications logiques pour qu’elles envoient des événements de diagnostic à un espace de travail Azure Log Analytics. Vous pouvez ensuite passer en revue l’intégrité et l’historique des applications logiques qui s’exécutent à plusieurs emplacements.

Aide sur le type de déclencheur

Le type de déclencheur que vous utilisez dans vos applications logiques détermine les options de configuration des applications logiques entre les différents emplacements dans votre stratégie de reprise d’activité. Voici les types de déclencheurs disponibles que vous pouvez utiliser dans des applications logiques :

Déclencheur recurrence

Le déclencheur de périodicité Recurrence est indépendant de tout service ou point de terminaison spécifique, et se déclenche uniquement en fonction d’une planification spécifiée et d’aucun autre critère, par exemple :

  • Une fréquence et un intervalle fixes, par exemple toutes les 10 minutes
  • Une planification plus avancée, comme le dernier lundi de chaque mois à 17h

Lorsque votre application logique démarre avec un déclencheur Recurrence, vous devez configurer vos instances d’application logique principale et secondaire avec les rôles actifs/passifs. Pour réduire l’objectif de délai de récupération (RTO), qui fait référence à la durée cible de restauration d’un processus métier après une interruption ou un incident, vous pouvez configurer vos instances d’application logique avec une combinaison de rôles actifs/passifs et de rôles passifs/actifs. Dans cette configuration, vous fractionnez la planification entre les différents emplacements.

Supposons, par exemple, que vous ayez une application logique qui doit s’exécuter toutes les 10 minutes. Vous pouvez configurer vos applications logiques et emplacements de sorte que si l’emplacement principal devient indisponible, l’emplacement secondaire peut se charger du travail :

Combinaison « actif/passif » et « passif/actif » qui utilise des déclencheurs de périodicité

  • Dans l’emplacement principal, configurez des rôles actifs/passifs pour ces applications logiques :

    • Pour l’application logique active activée, définissez le déclencheur de périodicité afin qu’il démarre sur l’heure et se répète toutes les 20 minutes, par exemple, 9h, 9h20, et ainsi de suite.

    • Pour l’application logique passive désactivée, définissez le déclencheur de périodicité sur le même horaire mais avec un démarrage 10 minutes après l’heure et une répétition toutes les 20 minutes, par exemple, 9h10, 9h30, et ainsi de suite.

  • Dans l’emplacement secondaire, configurez passif/actif pour ces applications logiques :

    • Pour l’application logique passive désactivée, définissez le déclencheur de périodicité sur le même horaire que l’application logique active dans l’emplacement principal, c’est-à-dire un démarrage sur l’heure et une répétition toutes les 20 minutes, par exemple, 9h, 9h20, et ainsi de suite.

    • Pour l’application logique active activée, définissez le déclencheur de périodicité sur le même horaire que l’application logique passive dans l’emplacement principal, c’est-à-dire un démarrage 10 minutes après l’heure et une répétition toutes les 20 minutes, par exemple, 9h10, 9h30, et ainsi de suite.

Si un événement perturbateur se produit dans l’emplacement principal, activez l’application logique passive à l’emplacement secondaire. Ainsi, si la détection de la défaillance prend du temps, cette configuration limite le nombre de récurrences manquées durant ce délai.

Déclencheur d’interrogation

Pour vérifier régulièrement si de nouvelles données pour le traitement sont disponibles à partir d’un service ou d’un point de terminaison spécifique, votre application logique peut utiliser un déclencheur d’interrogation qui appelle de façon répétée le service ou le point de terminaison en fonction d’une planification de périodicité fixe. Les données que le service ou le point de terminaison fournit peuvent avoir l’un des types suivants :

  • Données statiques, qui décrivent les données qui sont toujours disponibles pour la lecture
  • Données volatiles, qui décrivent les données qui ne sont plus disponibles après la lecture

Pour éviter de lire les mêmes données de façon répétée, votre application logique doit mémoriser les données qui ont été lues précédemment en conservant l’état côté client ou côté serveur, service ou système.

  • Les applications logiques qui fonctionnent avec l’état côté client utilisent des déclencheurs qui peuvent conserver l’état.

    Par exemple, un déclencheur qui lit un nouveau message à partir d’une boîte de réception de courrier électronique nécessite que le déclencheur mémorise le dernier message lu. De cette façon, le déclencheur ne démarre l’application logique que lorsque le message non lu suivant arrive.

  • Les applications logiques qui fonctionnent avec l’état côté serveur, service ou système utilisent des paramètres ou valeurs de propriété qui se trouvent côté serveur, service ou système.

    Par exemple, un déclencheur basé sur requête qui lit une ligne d’une base de données nécessite que la ligne ait une colonne isRead définie sur FALSE. Chaque fois que le déclencheur lit une ligne, l’application logique met à jour cette ligne en modifiant la colonne isRead de FALSE à TRUE.

    Cette approche côté serveur fonctionne de la même façon pour les files d’attente ou les rubriques Service Bus qui disposent d’une sémantique de mise en file d’attente où un déclencheur peut lire et verrouiller un message pendant que l’application logique traite le message. À la fin du traitement par l’application logique, le déclencheur supprime le message de la file d’attente ou de la rubrique.

Du point de vue de la reprise d’activité, quand vous configurez les instances principale et secondaire de votre application logique, assurez-vous de prendre en compte ces comportements selon que votre application logique effectue le suivi de l’état côté client ou côté serveur :

  • Pour une application logique qui fonctionne avec l’état côté client, assurez-vous que votre application logique ne lit pas le même message plusieurs fois. Un seul emplacement peut avoir une application logique active à tout moment donné. Vérifiez que l’instance d’application logique à l’emplacement secondaire est inactive ou désactivée jusqu’au basculement de l’instance principale vers l’emplacement secondaire.

    Par exemple, le déclencheur Office 365 Outlook conserve l’état côté client et effectue le suivi de l’horodatage du dernier e-mail lu afin d’éviter de lire un doublon.

  • Pour une application logique qui fonctionne avec l’état côté serveur, vous pouvez configurer vos instances d’application logique pour qu’elles jouent des rôles actifs/actifs où elles fonctionnent comme des consommateurs concurrents ou des rôles actifs/passifs où l’instance de remplacement attend que l’instance principale bascule vers l’emplacement secondaire.

    Par exemple, la lecture à partir d’une file d’attente de messages, comme une file d’attente Azure Service Bus, utilise l’état côté serveur, car le service de mise en file d’attente maintient des verrous sur les messages pour empêcher d’autres clients de lire les mêmes messages.

    Notes

    Si votre application logique doit lire les messages dans un ordre spécifique, par exemple, à partir d’une file d’attente Service Bus, vous pouvez utiliser le modèle de consommateurs concurrents, mais uniquement en association avec des sessions Service Bus, ce qui est également appelé modèle de convoi séquentiel. Dans le cas contraire, vous devez configurer vos instances d’application logique avec des rôles actifs/passifs.

Déclencheur de requête

Le déclencheur de requête Request fait en sorte que votre application logique puisse être appelée à partir d’autres applications, services et systèmes, et est généralement utilisé pour fournir les fonctionnalités suivantes :

  • Une API REST directe pour votre application logique que les autres peuvent appeler

    Par exemple, utilisez le déclencheur de requête pour démarrer votre application logique afin que d’autres applications logiques puissent appeler le déclencheur à l’aide de l’action Appeler le flux de travail - Logic Apps.

  • Un webhook ou un mécanisme de rappel pour votre application logique

  • Une façon dont vous pouvez exécuter manuellement des opérations ou routines utilisateur pour appeler votre application logique, par exemple, à l’aide d’un script PowerShell qui effectue une tâche spécifique

Du point de vue de la reprise d’activité, le déclencheur de requête est un récepteur passif, car l’application logique n’effectue aucun travail et attend qu’un autre service ou système appelle le déclencheur de manière explicite. En tant que point de terminaison passif, vous pouvez configurer vos instances principale et secondaire de l’une des manières suivantes :

  • Actif/actif : Les deux instances gèrent activement les requêtes ou les appels. L’appelant ou le routeur équilibre ou distribue le trafic entre ces instances.

  • Actif/passif : Seule l’instance principale est active et gère l’ensemble du travail, tandis que l’instance secondaire attend que l’instance principale subisse une interruption ou une défaillance. L’appelant ou le routeur détermine quand appeler l’instance secondaire.

En tant qu’architecture recommandée, vous pouvez utiliser Gestion des API Azure comme proxy pour les applications logiques qui utilisent des déclencheurs de requête. Gestion des API offre une résilience intégrée entre les régions et la capacité à acheminer le trafic entre plusieurs points de terminaison.

Déclencheur de webhook

Un déclencheur webhook permet à votre application logique de s’abonner à un service en passant une URL de rappel à ce service. Votre application logique peut ensuite écouter et attendre qu’un événement spécifique se produise au niveau de ce point de terminaison de service. Lorsque l’événement se produit, le service appelle le déclencheur webhook à l’aide de l’URL de rappel, qui exécute ensuite l’application logique. Lorsqu’il est activé, le déclencheur webhook s’abonne au service. Lorsqu’il est désactivé, le déclencheur se désabonne du service.

Du point de vue de la reprise d’activité, configurez des instances principale et secondaire utilisant des déclencheurs webhook pour jouer des rôles actifs/passifs, car une seule instance doit recevoir des événements ou des messages du point de terminaison abonné.

Évaluer l’intégrité de l’instance principale

Pour que votre stratégie de reprise d’activité fonctionne, votre solution nécessite des moyens d’effectuer les tâches suivantes :

Cette section décrit une solution que vous pouvez utiliser en mode autonome ou en tant que base de votre propre conception. Voici une vue d’ensemble visuelle de haut niveau pour cette solution :

Créer une application logique de surveillance qui surveille une application logique de contrôle d’intégrité dans l’emplacement principal

Vérifier la disponibilité de l’instance principale

Pour déterminer si l’instance principale est disponible, en cours d’exécution et en mesure de fonctionner, vous pouvez créer une application logique de « contrôle d’intégrité » qui se trouve dans le même emplacement que l’instance principale. Vous pouvez ensuite appeler cette application de contrôle d’intégrité à partir d’un autre emplacement. Si l’application de contrôle d’intégrité répond correctement, l’infrastructure sous-jacente du service Azure Logic Apps de cette région est disponible et opérationnelle. Si l’application de contrôle d’intégrité ne répond pas, vous pouvez supposer que l’emplacement n’est plus sain.

Pour cette tâche, créez une application logique de contrôle d’intégrité de base qui effectue les tâches suivantes :

  1. Reçoit un appel de l’application de surveillance à l’aide du déclencheur de requête.

  2. Répond à l’aide d’un état indiquant si l’application logique vérifiée fonctionne toujours à l’aide de l’action de réponse.

    Important

    L’application logique de contrôle d’intégrité doit utiliser une action de réponse pour que l’application réponde de façon synchrone, et non asynchrone.

  3. Pour déterminer plus précisément si l’emplacement principal est sain, vous pouvez éventuellement prendre en compte l’intégrité de tous les autres services qui interagissent avec l’application logique cible à cet emplacement. Développez simplement l’application logique de contrôle d’intégrité pour évaluer aussi l’intégrité de ces autres services.

Créer une application logique de surveillance

Pour surveiller l’intégrité de l’instance principale et appeler l’application logique de contrôle d’intégrité, créez une application logique de « surveillance » dans un autre emplacement. Par exemple, vous pouvez configurer l’application logique de surveillance de sorte que si l’appel de l’application logique de contrôle d’intégrité échoue, l’application logique de surveillance peut envoyer une alerte à votre équipe des opérations pour qu’elle examine l’échec et la raison pour laquelle l’instance principale ne répond pas.

Important

Assurez-vous que votre application logique de surveillance se trouve dans un emplacement qui diffère de l’emplacement principal. Si le service Azure Logic Apps dans l’emplacement principal rencontre des problèmes, il est possible que votre application logique de surveillance ne s’exécute pas.

Pour cette tâche, dans l’emplacement secondaire, créez une application logique de surveillance qui effectue les tâches suivantes :

  1. Exécution basée sur une périodicité fixe ou planifiée à l’aide du déclencheur de périodicité.

    Vous pouvez définir la périodicité sur une valeur qui se trouve sous le niveau de tolérance pour votre objectif de délai de récupération (RTO).

  2. Appelez le workflow de l’application logique de contrôle d’intégrité dans l’emplacement principal en utilisant l’action HTTP.

Vous pouvez également créer une application logique de surveillance plus sophistiquée, qui, après un certain nombre d’échecs, appelle une autre application logique qui gère automatiquement le basculement vers l’emplacement secondaire en cas d’échec du serveur principal.

Activer votre instance secondaire

Pour activer automatiquement l’instance secondaire, vous pouvez créer une application logique qui appelle l’API de gestion, par exemple le connecteur Azure Resource Manager pour activer les applications logiques appropriées dans l’emplacement secondaire. Vous pouvez développer votre application de surveillance pour appeler cette application logique d’activation après un nombre spécifique d’échecs.

Redondance de zone avec des zones de disponibilité

Dans chaque région Azure, les zones de disponibilité sont des emplacements physiquement séparés qui sont tolérants aux défaillances locales. Ces défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. Ces zones permettent d’atteindre la tolérance via la redondance et l’isolation logique des services Azure.

Pour fournir la résilience et la disponibilité distribuée, au moins trois zones de disponibilité distinctes existent dans les régions Azure prenant en charge et assurant la redondance de zone. La plateforme Azure Logic Apps distribue ces zones et les charges de travail d’application logique entre ces zones. Cette fonctionnalité est une condition essentielle pour obtenir des architectures résilientes et fournir une haute disponibilité si des défaillances de centre de données se produisent dans une région.

Actuellement, cette fonctionnalité est en préversion et disponible pour les nouvelles applications logiques Consommation dans des régions spécifiques. Pour plus d’informations, consultez la documentation suivante :

Collecter des données de diagnostic

Vous pouvez configurer la journalisation des exécutions de votre application logique et envoyer les données de diagnostic obtenues à des services comme Stockage Azure, Azure Event Hubs et Azure Log Analytics pour une gestion et un traitement supplémentaires.

Étapes suivantes