Delen via

Implementaties in meerdere regio's voor herstel na noodgevallen in Azure Logic Apps

  • Artikel

Dit artikel bevat richtlijnen en strategieën voor het instellen van een implementatie in meerdere regio's voor uw werkstromen voor logische apps in Azure Logic Apps. Met een implementatie met meerdere regio's kunt u gegevens beschermen, snel herstellen tegen rampen en andere verstorende gebeurtenissen, resources herstellen die vereist zijn voor kritieke bedrijfsfuncties en bedrijfscontinuïteit behouden.

Zie Betrouwbaarheid in Azure Logic Apps voor meer informatie over de betrouwbaarheidsfuncties in Azure Logic Apps, waaronder tolerantie binnen regio's via beschikbaarheidszones.

Overwegingen

Met werkstromen voor logische apps kunt u eenvoudiger gegevens integreren en organiseren tussen apps, cloudservices en on-premises systemen door te beperken hoeveel code u moet schrijven. Wanneer u redundantie voor meerdere regio's plant, moet u rekening houden met niet alleen uw logische apps, maar ook met deze Azure-resources die u met uw logische apps gebruikt:

Zie Betrouwbaarheid in Azure Logic Apps voor meer informatie over betrouwbaarheid in Azure Logic Apps, waaronder tolerantie binnen regio's via beschikbaarheidszones en implementaties in meerdere regio's.

Primaire en secundaire implementatie

Een implementatie met meerdere regio's bestaat uit een primaire en een secundaire logische app. De primaire logische app is geconfigureerd voor een failover naar de secundaire logische app in een andere regio waar Azure Logic Apps ook beschikbaar is. Op die manier kan de secundaire instantie het werk overnemen als de primaire schade, onderbrekingen of storingen lijdt. Deze implementatiestrategie vereist dat uw secundaire logische app en afhankelijke resources al zijn geïmplementeerd en gereed zijn in de secundaire regio.

Notitie

Als uw logische app ook werkt met B2B-artefacten, zoals handelspartners, overeenkomsten, schema's, kaarten en certificaten, die zijn opgeslagen in een integratieaccount, moeten zowel uw integratieaccount als logische apps dezelfde locatie gebruiken.

Als u goede DevOps-procedures volgt, gebruikt u al Bicep - of Azure Resource Manager-sjablonen om uw logische apps en hun afhankelijke resources te definiëren en te implementeren. Bicep- en Resource Manager-sjablonen bieden u de mogelijkheid om één implementatiedefinitie te gebruiken en vervolgens parameterbestanden te gebruiken om de configuratiewaarden op te geven die voor elke implementatiebestemming moeten worden gebruikt. Deze mogelijkheid betekent dat u dezelfde logische app kunt implementeren in verschillende omgevingen, bijvoorbeeld ontwikkeling, testen en productie. U kunt dezelfde logische app ook implementeren in verschillende Azure-regio's, die ondersteuning bieden voor implementaties in meerdere regio's, zoals voor strategieën voor herstel na noodgevallen.

Voor een geslaagde failover moeten uw logische apps en locaties voldoen aan deze vereisten:

Voorbeeld: Multitenant Azure

In dit voorbeeld ziet u primaire en secundaire instanties van logische apps, die zijn geïmplementeerd in afzonderlijke regio's in de globale multitenant Azure. Eén Resource Manager-sjabloon definieert zowel exemplaren van logische apps als de afhankelijke resources die vereist zijn voor deze logische apps. Afzonderlijke parameterbestanden geven de configuratiewaarden op die voor elke implementatielocatie moeten worden gebruikt:

Primaire en secundaire logische app-exemplaren op afzonderlijke locaties

Verbindingen met resources

Azure Logic Apps biedt bewerkingen voor meer dan 1000 connectors die uw werkstroom voor logische apps kan gebruiken om te werken met andere apps, services, systemen en andere resources, zoals Azure Storage-accounts, SQL Server-databases, werk- of school-e-mailaccounts, enzovoort. Als uw logische app toegang nodig heeft tot deze resources, maakt u verbindingen die toegang tot deze resources verifiëren. Elke verbinding is een afzonderlijke Azure-resource die op een specifieke locatie bestaat en niet kan worden gebruikt door resources op andere locaties.

Houd voor uw redundantiestrategie voor meerdere regio's rekening met de locaties waar afhankelijke resources bestaan ten opzichte van uw logische app-exemplaren:

  • Uw primaire exemplaar en afhankelijke resources bestaan op verschillende locaties. In dit geval kan uw secundaire exemplaar verbinding maken met dezelfde afhankelijke resources of eindpunten. U moet echter specifiek verbindingen maken voor uw secundaire exemplaar. Als uw primaire locatie niet beschikbaar is, worden de verbindingen van uw secundaire locatie niet beïnvloed.

    Stel dat uw primaire logische app verbinding maakt met een externe service, zoals Salesforce. Meestal zijn de beschikbaarheid en locatie van de externe service onafhankelijk van de beschikbaarheid van uw logische app. In dit geval kan uw secundaire exemplaar verbinding maken met dezelfde service, maar moet deze een eigen verbinding hebben in uw secundaire regio.

  • Zowel uw primaire exemplaar als de afhankelijke resources bevinden zich op dezelfde locatie. In dit geval moeten afhankelijke resources back-ups of gerepliceerde versies hebben op een andere locatie, zodat uw secundaire exemplaar nog steeds toegang heeft tot deze resources.

    Stel dat uw primaire logische app verbinding maakt met een service die zich op dezelfde locatie of regio bevindt, bijvoorbeeld Azure SQL Database. Als deze hele regio niet beschikbaar is, is de Azure SQL Database-service in die regio waarschijnlijk ook niet beschikbaar. In dit geval wilt u dat uw secundaire exemplaar een gerepliceerde of back-updatabase in de secundaire regio gebruikt, samen met een afzonderlijke verbinding met die database die zich ook in de secundaire regio bevindt.

On-premises gegevensgateways

Als uw logische app wordt uitgevoerd in Azure met meerdere tenants en toegang nodig heeft tot on-premises resources zoals SQL Server-databases, moet u de on-premises gegevensgateway installeren op een lokale computer. U kunt vervolgens een gegevensgatewayresource maken in Azure Portal, zodat uw logische app de gateway kan gebruiken wanneer u een verbinding met de resource maakt.

De gegevensgatewayresource is gekoppeld aan een locatie of Azure-regio, net zoals uw logische app-resource. Zorg ervoor dat in uw redundantiestrategie voor meerdere regio's de gegevensgateway beschikbaar blijft voor gebruik van uw logische app. U kunt hoge beschikbaarheid voor uw gateway inschakelen wanneer u meerdere gatewayinstallaties hebt.

Actief-actief versus actief-passieve rollen

U kunt uw primaire en secundaire locaties instellen, zodat uw exemplaren van de logische app op deze locaties deze rollen kunnen spelen:

Primaire secundaire rol Beschrijving
Actief-actief De primaire en secundaire instanties van logische apps op beide locaties verwerken aanvragen actief door een van deze patronen te volgen:

- Taakverdeling: u kunt beide exemplaren naar een eindpunt laten luisteren en zo nodig verkeer naar elk exemplaar laten verdelen.

- Concurrerende consumenten: u kunt beide exemplaren als concurrerende consumenten laten fungeren, zodat de exemplaren concurreren voor berichten uit een wachtrij. Als het ene exemplaar mislukt, neemt het andere exemplaar de workload over.
Actief-passief Het primaire exemplaar van de logische app verwerkt de hele workload actief, terwijl het secundaire exemplaar passief is (uitgeschakeld of inactief). De secundaire wacht op een signaal dat de primaire niet beschikbaar is of niet werkt vanwege onderbreking of storing en neemt de workload over als het actieve exemplaar.
Combinatie Sommige logische apps spelen een actieve-actieve rol, terwijl andere logische apps een actief-passieve rol spelen.

Voorbeelden van actief-actief

In deze voorbeelden ziet u de actief-actieve installatie waarbij beide exemplaren van logische apps aanvragen of berichten actief verwerken. Een ander systeem of andere service distribueert de aanvragen of berichten tussen exemplaren, bijvoorbeeld een van de volgende opties:

  • Een 'fysieke' load balancer, zoals een stuk hardware waarmee verkeer wordt gerouteerd

  • Een 'zachte' load balancer, zoals Azure Load Balancer of Azure API Management. Met API Management kunt u beleidsregels opgeven die bepalen hoe inkomend verkeer moet worden verdeeld. U kunt ook een service gebruiken die ondersteuning biedt voor statustracking, bijvoorbeeld Azure Service Bus.

    Hoewel in dit voorbeeld voornamelijk Azure Load Balancer wordt weergegeven, kunt u de optie gebruiken die het beste past bij de behoeften van uw scenario:

    Setup 'Actief-actief' die gebruikmaakt van een load balancer of stateful service

  • Elk exemplaar van een logische app fungeert als consument en beide instanties concurreren voor berichten uit een wachtrij:

    Setup 'Actief-actief' die gebruikmaakt van 'concurrerende consumenten'

Actief-passieve voorbeelden

In dit voorbeeld ziet u de actief-passieve installatie waarbij het primaire exemplaar van de logische app actief is op één locatie, terwijl het secundaire exemplaar inactief blijft op een andere locatie. Als de primaire fout een onderbreking of storing ondervindt, kunt u een operator een script laten uitvoeren waarmee de secundaire bewerking wordt geactiveerd om de workload op te nemen.

Combinatie met actief-actief en actief-passief

In dit voorbeeld ziet u een gecombineerde installatie waarbij de primaire locatie beide actieve exemplaren van logische apps heeft, terwijl de secundaire locatie actief-passieve logische app-exemplaren heeft. Als de primaire locatie een onderbreking of storing ondervindt, kan de actieve logische app op de secundaire locatie, die al een gedeeltelijke workload verwerkt, de hele workload overnemen.

  • Op de primaire locatie luistert een actieve logische app naar een Azure Service Bus-wachtrij voor berichten, terwijl een andere actieve logische app controleert op e-mailberichten met behulp van een Polling-trigger van Office 365 Outlook.

  • Op de secundaire locatie werkt een actieve logische app met de logische app op de primaire locatie door te luisteren naar en te concurreren voor berichten uit dezelfde Service Bus-wachtrij. Ondertussen wacht een passieve inactieve logische app op stand-by om te controleren op e-mailberichten wanneer de primaire locatie niet beschikbaar is, maar is uitgeschakeld om te voorkomen dat e-mailberichten opnieuw worden gelezen.

Status en geschiedenis van logische app

Wanneer uw logische app wordt geactiveerd en wordt uitgevoerd, wordt de status van de app opgeslagen op dezelfde locatie waar de app is gestart en niet overdraagbaar is naar een andere locatie. Als er een fout of onderbreking optreedt, worden alle actieve werkstroomexemplaren afgetrokken. Wanneer u een primaire en secundaire locatie hebt ingesteld, worden nieuwe werkstroomexemplaren uitgevoerd op de secundaire locatie.

Afgeslagen instanties in uitvoering verminderen

Als u het aantal verlaten werkstroomexemplaren in uitvoering wilt minimaliseren, kunt u kiezen uit verschillende berichtpatronen die u kunt implementeren, bijvoorbeeld:

  • Vast patroon routeringsslip

    Dit bedrijfsberichtpatroon dat een bedrijfsproces splitst in kleinere fasen. Voor elke fase stelt u een logische app in waarmee de workload voor die fase wordt verwerkt. Uw logische apps gebruiken een asynchroon berichtenprotocol zoals Azure Service Bus-wachtrijen of onderwerpen om met elkaar te communiceren. Wanneer u een proces onderverdeelt in kleinere fasen, vermindert u het aantal bedrijfsprocessen dat vastloopt op een mislukt exemplaar van een logische app. Zie Enterprise-integratiepatronen - Routelijst voor meer algemene informatie over dit patroon.

    In dit voorbeeld ziet u een routelijstpatroon waarbij elke logische app een fase vertegenwoordigt en een Service Bus-wachtrij gebruikt om te communiceren met de volgende logische app in het proces.

    Een bedrijfsproces splitsen in fasen die worden vertegenwoordigd door logische apps, die met elkaar communiceren met behulp van Azure Service Bus-wachtrijen

    Als zowel primaire als secundaire logische app-exemplaren hetzelfde patroon voor routeringsslip op hun locaties volgen, kunt u het patroon concurrerende consumenten implementeren door actieve-actieve rollen in te stellen voor deze exemplaren.

  • Procesbeheerpatroon (broker)

  • Peek-lock zonder time-outpatroon

Toegang tot trigger- en uitvoeringsgeschiedenis

Als u meer informatie wilt over de eerdere werkstroomuitvoeringen van uw logische app, kunt u de trigger en uitvoeringsgeschiedenis van de app bekijken. De uitvoeringsgeschiedenis van een logische app wordt opgeslagen op dezelfde locatie of regio waar die logische app is uitgevoerd. Dit betekent dat u deze geschiedenis niet naar een andere locatie kunt migreren. Als uw primaire exemplaar een failover naar een secundair exemplaar uitvoert, hebt u alleen toegang tot de trigger van elk exemplaar en wordt de geschiedenis uitgevoerd op de respectieve locaties waar deze exemplaren zijn uitgevoerd. U kunt echter locatie-agnostische informatie over de geschiedenis van uw logische app ophalen door uw logische apps in te stellen om diagnostische gebeurtenissen naar een Azure Log Analytics-werkruimte te verzenden. Vervolgens kunt u de status en geschiedenis bekijken van logische apps die op meerdere locaties worden uitgevoerd.

Richtlijnen voor triggertypen

Het triggertype dat u in uw logische apps gebruikt, bepaalt uw opties voor het instellen van logische apps op verschillende locaties in een strategie voor herstel na noodgevallen. Hier volgen de beschikbare triggertypen die u kunt gebruiken in werkstromen voor logische apps:

Trigger met terugkeerpatroon

De terugkeertrigger is onafhankelijk van een specifieke service of eindpunt en wordt uitsluitend gebaseerd op een opgegeven planning en geen andere criteria, bijvoorbeeld:

  • Een vaste frequentie en interval, zoals elke 10 minuten
  • Een geavanceerder schema, zoals de laatste maandag van elke maand om 17:00 uur

Wanneer uw logische app begint met een terugkeerpatroontrigger, moet u uw primaire en secundaire instanties van logische apps instellen met de actief-passieve rollen. Als u de beoogde hersteltijd (RTO) wilt verminderen, die verwijst naar de doelduur voor het herstellen van een bedrijfsproces na een onderbreking of noodgeval, kunt u uw instanties van logische apps instellen met een combinatie van actief-passieve rollen en passief-actieve rollen. In deze installatie splitst u de planning op verschillende locaties.

Stel dat u een logische app hebt die elke 10 minuten moet worden uitgevoerd. U kunt uw logische apps en locaties zo instellen dat als de primaire locatie niet beschikbaar is, de secundaire locatie het werk kan overnemen:

Combinatie 'Actief-passief' en 'passief-actief' die gebruikmaakt van terugkeerpatroontriggers

  • Stel op de primaire locatie actief-passieve rollen in voor deze logische apps:

    • Stel voor de actieve ingeschakelde logische app de trigger Terugkeerpatroon in om boven aan het uur te beginnen en herhaal elke 20 minuten, bijvoorbeeld 9:00, 9:20 uur, enzovoort.

    • Stel voor de passieve uitgeschakelde logische app de trigger Terugkeerpatroon in op hetzelfde schema, maar begin bij 10 minuten na het uur en herhaal elke 20 minuten, bijvoorbeeld 9:10, 9:30 uur, enzovoort.

  • Stel op de secundaire locatie passief-actief in voor deze logische apps:

    • Voor de passieve uitgeschakelde logische app stelt u de trigger Terugkeerpatroon in op hetzelfde schema als de actieve logische app op de primaire locatie, die zich boven aan het uur bevindt en elke 20 minuten herhaalt, bijvoorbeeld 9:00 uur, 9:10 uur, enzovoort.

    • Voor de actieve logische app stelt u de trigger Terugkeerpatroon in op dezelfde planning als de passieve logische app op de primaire locatie. Dit is om 10 minuten na het uur te beginnen en elke 20 minuten te herhalen, bijvoorbeeld 9:10, 9:20 uur, enzovoort.

Als er nu een verstorende gebeurtenis op de primaire locatie plaatsvindt, activeert u de passieve logische app op de alternatieve locatie. Als het vinden van de fout tijd kost, beperkt deze instelling het aantal gemiste terugkeerpatronen tijdens die vertraging.

Poll-trigger

Als u regelmatig wilt controleren of nieuwe gegevens voor verwerking beschikbaar zijn via een specifieke service of een specifiek eindpunt, kan uw logische app een polling-trigger gebruiken die herhaaldelijk de service of het eindpunt aanroept op basis van een vast terugkeerschema. De gegevens die de service of het eindpunt biedt, kunnen een van de volgende typen hebben:

  • Statische gegevens, waarin gegevens worden beschreven die altijd beschikbaar zijn voor lezen
  • Vluchtige gegevens, waarin gegevens worden beschreven die niet meer beschikbaar zijn na het lezen

Om te voorkomen dat dezelfde gegevens herhaaldelijk worden gelezen, moet uw logische app onthouden welke gegevens eerder zijn gelezen door de status aan de clientzijde of op de server, service of systeemzijde te behouden.

  • Logische apps die werken met status aan de clientzijde maken gebruik van triggers die de status kunnen behouden.

    Een trigger die bijvoorbeeld een nieuw bericht uit een Postvak IN leest, vereist dat de trigger het laatst gelezen bericht kan onthouden. Op die manier wordt de logische app alleen gestart wanneer het volgende ongelezen bericht binnenkomt.

  • Logische apps die werken met de status server, service of systeem, gebruiken eigenschapswaarden of instellingen die zich op de server, service of systeemzijde bevinden.

    Een op query's gebaseerde trigger die bijvoorbeeld een rij uit een database leest, vereist dat de rij een isRead kolom heeft die is ingesteld op FALSE. Telkens wanneer de trigger een rij leest, wordt die rij bijgewerkt door de isRead kolom te wijzigen van FALSE in TRUE.

    Deze benadering aan de serverzijde werkt op dezelfde manier voor Service Bus-wachtrijen of onderwerpen die semantiek in de wachtrij hebben, waarbij een trigger een bericht kan lezen en vergrendelen terwijl de logische app het bericht verwerkt. Wanneer de logische app klaar is met verwerken, wordt het bericht verwijderd uit de wachtrij of het onderwerp.

Wanneer u vanuit het perspectief van herstel na noodgevallen de primaire en secundaire instanties van uw logische app instelt, moet u ervoor zorgen dat u rekening houdt met dit gedrag op basis van of de logische app de status aan de clientzijde of aan de serverzijde bijhoudt:

  • Voor een logische app die werkt met de status clientzijde, moet u ervoor zorgen dat uw logische app niet meer dan één keer hetzelfde bericht leest. Slechts één locatie kan op elk gewenst moment een actief exemplaar van een logische app hebben. Zorg ervoor dat het exemplaar van de logische app op de alternatieve locatie inactief of uitgeschakeld is totdat het primaire exemplaar een failover naar de alternatieve locatie uitvoert.

    De Office 365 Outlook-trigger behoudt bijvoorbeeld de status aan de clientzijde en houdt de tijdstempel voor de recentste e-mail bij om te voorkomen dat er een duplicaat wordt gelezen.

  • Voor een logische app die werkt met de status aan de serverzijde, kunt u uw exemplaren van de logische app instellen om actieve-actieve rollen te spelen waarbij ze werken als concurrerende consumenten of actief-passieve rollen waarbij het alternatieve exemplaar wacht totdat het primaire exemplaar een failover naar de alternatieve locatie uitvoert.

    Als u bijvoorbeeld leest vanuit een berichtenwachtrij, zoals een Azure Service Bus-wachtrij, wordt de status aan de serverzijde gebruikt omdat de wachtrijservice vergrendelingen op berichten onderhoudt om te voorkomen dat andere clients dezelfde berichten lezen.

    Notitie

    Als uw logische app berichten in een specifieke volgorde moet lezen, bijvoorbeeld vanuit een Service Bus-wachtrij, kunt u het concurrerende consumentenpatroon gebruiken, maar alleen in combinatie met Service Bus-sessies. Dit wordt ook wel het sequentiële convoypatroon genoemd. Anders moet u uw exemplaren van de logische app instellen met de actief-passieve rollen.

Aanvraagtrigger

De aanvraagtrigger maakt uw logische app aanroepbaar vanuit andere apps, services en systemen en wordt doorgaans gebruikt om deze mogelijkheden te bieden:

  • Een directe REST API voor uw logische app die anderen kunnen aanroepen

    Gebruik bijvoorbeeld de aanvraagtrigger om uw logische app te starten, zodat andere logische apps de trigger kunnen aanroepen met behulp van de actie Oproepwerkstroom - Logic Apps .

  • Een webhook of callback-mechanisme voor uw logische app

  • Een manier waarop u handmatig gebruikersbewerkingen of routines kunt uitvoeren om uw logische app aan te roepen, bijvoorbeeld met behulp van een PowerShell-script waarmee een specifieke taak wordt uitgevoerd

Vanuit het perspectief van herstel na noodgevallen is de aanvraagtrigger een passieve ontvanger omdat de logische app geen werk doet en wacht totdat een andere service of systeem de trigger expliciet aanroept. Als passief eindpunt kunt u uw primaire en secundaire exemplaren op deze manieren instellen:

  • Actief-actief: beide exemplaren verwerken aanvragen of aanroepen actief. De beller of router verdeelt verkeer tussen deze exemplaren of distribueert het verkeer.

  • Actief-passief: alleen het primaire exemplaar is actief en verwerkt al het werk, terwijl de secundaire instantie wacht totdat de primaire storing of storing optreedt. De beller of router bepaalt wanneer het secundaire exemplaar moet worden aangeroepen.

Als aanbevolen architectuur kunt u Azure API Management gebruiken als proxy voor de logische apps die gebruikmaken van aanvraagtriggers. API Management biedt ingebouwde tolerantie in meerdere regio's en de mogelijkheid om verkeer over meerdere eindpunten te routeren.

Webhooktrigger

Een webhooktrigger biedt de mogelijkheid voor uw logische app om zich te abonneren op een service door een callback-URL door te geven aan die service. Uw logische app kan vervolgens luisteren en wachten tot er een specifieke gebeurtenis op dat service-eindpunt plaatsvindt. Wanneer de gebeurtenis plaatsvindt, roept de service de webhooktrigger aan met behulp van de callback-URL, die vervolgens de logische app uitvoert. Wanneer deze optie is ingeschakeld, abonneert de webhooktrigger zich op de service. Wanneer deze functie is uitgeschakeld, wordt de trigger afgemeld voor de service.

Stel vanuit het perspectief van herstel na noodgevallen primaire en secundaire exemplaren in die gebruikmaken van webhooktriggers om actief-passieve rollen te spelen, omdat slechts één exemplaar gebeurtenissen of berichten van het geabonneerde eindpunt moet ontvangen.

De status van het primaire exemplaar evalueren

Een failoverstrategie voor meerdere regio's werkt alleen als uw oplossing manieren nodig heeft om deze taken uit te voeren:

In deze sectie wordt één oplossing beschreven die u rechtop of als basis voor uw eigen ontwerp kunt gebruiken. Hier volgt een visueel overzicht op hoog niveau voor deze oplossing:

Een watchdog-logische app maken die een logische app voor statuscontrole controleert op de primaire locatie

Beschikbaarheid van primaire exemplaren controleren

Als u wilt bepalen of het primaire exemplaar beschikbaar is, wordt uitgevoerd en kan werken, kunt u een logische app voor statuscontrole maken die zich op dezelfde locatie bevindt als het primaire exemplaar. U kunt deze statuscontrole-app vervolgens aanroepen vanaf een alternatieve locatie. Als de statuscontrole-app reageert, is de onderliggende infrastructuur voor de Azure Logic Apps-service in die regio beschikbaar en werkt deze. Als de statuscontrole-app niet reageert, kunt u ervan uitgaan dat de locatie niet meer in orde is.

Voor deze taak maakt u een eenvoudige logische app voor statuscontrole waarmee deze taken worden uitgevoerd:

  1. Ontvangt een oproep van de watchdog-app met behulp van de aanvraagtrigger.

  2. Reageer met een status die aangeeft of de ingeschakelde logische app nog steeds werkt met behulp van de actie Antwoord.

    Belangrijk

    De logische app voor statuscontrole moet een reactieactie gebruiken, zodat de app synchroon reageert, niet asynchroon.

  3. Als u verder wilt bepalen of de primaire locatie in orde is, kunt u rekening houden met de status van andere services die op deze locatie communiceren met de doellogica-app. Vouw de logische app voor statuscontrole uit om ook de status voor deze andere services te beoordelen.

Een logische watchdog-app maken

Als u de status van het primaire exemplaar wilt bewaken en de logische app voor statuscontrole wilt aanroepen, maakt u een logische app 'watchdog' op een alternatieve locatie. U kunt bijvoorbeeld de logische watchdog-app zo instellen dat als het aanroepen van de logica voor statuscontrole mislukt, de watchdog een waarschuwing naar uw operations-team kan verzenden, zodat ze de fout kunnen onderzoeken en waarom het primaire exemplaar niet reageert.

Belangrijk

Zorg ervoor dat de logische watchdog-app zich op een locatie bevindt die verschilt van de primaire locatie. Als Azure Logic Apps op de primaire locatie problemen ondervindt, wordt uw werkstroom voor logische apps mogelijk niet uitgevoerd.

Voor deze taak maakt u op de secundaire locatie een logische watchdog-app waarmee deze taken worden uitgevoerd:

  1. Uitvoeren op basis van een vast of gepland terugkeerpatroon met behulp van de trigger Terugkeerpatroon.

    U kunt het terugkeerpatroon instellen op een waarde die lager is dan het tolerantieniveau voor uw beoogde hersteltijd (RTO).

  2. Roep de werkstroom van de logische app voor statuscontrole aan op de primaire locatie met behulp van de HTTP-actie.

U kunt ook een geavanceerdere watchdog logische app maken, die na een aantal fouten een andere logische app aanroept die automatisch overschakelt naar de secundaire locatie wanneer de primaire mislukt.

Uw secundaire exemplaar activeren

Als u het secundaire exemplaar automatisch wilt activeren, kunt u een logische app maken die de beheer-API aanroept, zoals de Azure Resource Manager-connector , om de juiste logische apps op de secundaire locatie te activeren. U kunt uw watchdog-app uitbreiden om deze logische activerings-app aan te roepen nadat een specifiek aantal fouten is opgetreden.

Diagnostische gegevens verzamelen

U kunt logboekregistratie voor uw logische app-uitvoeringen instellen en de resulterende diagnostische gegevens verzenden naar services zoals Azure Storage, Azure Event Hubs en Azure Log Analytics voor verdere verwerking en verwerking.

Volgende stappen