Share via

Bedrijfscontinuïteit en herstel na noodgevallen voor Azure Logic Apps

  • Artikel

Om de impact en effecten te verminderen die onvoorspelbare gebeurtenissen hebben op uw bedrijf en klanten, moet u ervoor zorgen dat u een noodhersteloplossing (DR) hebt, zodat u gegevens kunt beveiligen, snel de resources kunt herstellen die kritieke bedrijfsfuncties ondersteunen en operationele activiteiten uitvoeren om bedrijfscontinuïteit (BC) te behouden. Onderbrekingen kunnen bijvoorbeeld storingen, verliezen in onderliggende infrastructuur of onderdelen, zoals opslag, netwerk of rekenresources, onherstelbare toepassingsfouten of zelfs een volledig datacenterverlies omvatten. Door een BCDR-oplossing (bedrijfscontinuïteit en herstel na noodgevallen) gereed te maken, kan uw bedrijf of organisatie sneller reageren op onderbrekingen, gepland of ongepland en downtime voor uw klanten verminderen.

Dit artikel bevat BCDR-richtlijnen en -strategieën die u kunt toepassen wanneer u geautomatiseerde werkstromen bouwt met behulp van Azure Logic Apps. 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 BCDR plant, moet u rekening houden met niet alleen uw logische apps, maar ook deze Azure-resources die u met uw logische apps gebruikt:

Primaire en secundaire locaties

Elke logische app moet de locatie opgeven die u wilt gebruiken voor implementatie. Deze locatie is een openbare regio in globale Azure met meerdere tenants, zoals VS - west of een ISE (Integration Service Environment) die u eerder hebt gemaakt en geïmplementeerd in een virtueel Azure-netwerk. Het uitvoeren van logische apps in een ISE is vergelijkbaar met het uitvoeren van logische apps in een globale Azure-regio, wat betekent dat uw strategie voor herstel na noodgevallen kan worden toegepast op beide scenario's. ISE's hebben echter andere overwegingen, zoals het configureren van toegang tot resources die alleen beschikbaar zijn voor ISE's.

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 opgeven.

Deze strategie voor herstel na noodgevallen is gericht op het instellen van uw primaire logische app voor failover naar een stand-by- of back-uplogica-app op een andere locatie 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 strategie vereist dat uw secundaire logische app en afhankelijke resources al zijn geïmplementeerd en gereed zijn op de alternatieve locatie.

Als u goede DevOps-procedures volgt, gebruikt u al Azure Resource Manager-sjablonen om uw logische apps en hun afhankelijke resources te definiëren en te implementeren. 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 of ISE's, die ondersteuning bieden voor strategieën voor herstel na noodgevallen die gebruikmaken van gekoppelde regio's.

Voor de failoverstrategie moeten uw logische apps en locaties voldoen aan deze vereisten:

  • Het exemplaar van de secundaire logische app heeft toegang tot dezelfde apps, services en systemen als het primaire exemplaar van de logische app.

  • Beide exemplaren van logische apps hebben hetzelfde hosttype. Beide exemplaren worden dus geïmplementeerd in regio's in globale azure met meerdere tenants of beide exemplaren worden geïmplementeerd in ISE's, zodat uw logische apps rechtstreeks toegang hebben tot resources in een virtueel Azure-netwerk. Zie replicatie tussen regio's in Azure: Bedrijfscontinuïteit en herstel na noodgevallen voor meer informatie over gekoppelde regio's voor BCDR.

    De primaire en secundaire locaties moeten bijvoorbeeld ISE's zijn wanneer de primaire logische app wordt uitgevoerd in een ISE en gebruikmaakt van ise-versieconnectors, HTTP-acties voor het aanroepen van resources in het virtuele Azure-netwerk of beide. In dit scenario moet uw secundaire logische app ook een vergelijkbare installatie hebben op de secundaire locatie als de primaire logische app.

    Notitie

    Voor geavanceerdere scenario's kunt u zowel Azure met meerdere tenants als een ISE combineren als locaties. Zorg er echter voor dat u rekening houdt met de verschillen tussen de manier waarop logische apps worden uitgevoerd in een ISE versus azure met meerdere tenants.

  • Als u ISE's gebruikt, moet u ervoor zorgen dat ze zijn uitgeschaald of voldoende capaciteit hebben om de belasting te verwerken.

Voorbeeld: Multitenant Azure

In dit voorbeeld ziet u primaire en secundaire instanties van logische apps, die voor dit scenario worden geïmplementeerd in afzonderlijke regio's in azure met meerdere tenants. 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

Voorbeeld: Integratieserviceomgeving

In dit voorbeeld ziet u de vorige exemplaren van de primaire en secundaire logische app, maar geïmplementeerd voor afzonderlijke ISE's. Eén Resource Manager-sjabloon definieert zowel exemplaren van logische apps, de afhankelijke resources die vereist zijn voor deze logische apps als de implementatielocaties. Afzonderlijke parameterbestanden definiëren de configuratiewaarden die moeten worden gebruikt voor implementatie op elke locatie:

Primaire en secundaire logische apps op verschillende locaties

Verbindingen met resources

Azure Logic Apps biedt vele honderden connectorbewerkingen 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.

Voor uw strategie voor herstel na noodgevallen moet u rekening houden met de locaties waar afhankelijke resources bestaan ten opzichte van uw exemplaren van uw logische app:

  • 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.

  • 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 gebruikt, samen met een afzonderlijke verbinding met die database.

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 strategie voor herstel na noodgevallen de gegevensgateway beschikbaar blijft voor gebruik van uw logische app. U kunt hoge beschikbaarheid voor uw gateway inschakelen wanneer u meerdere gatewayinstallaties hebt.

Notitie

Als uw logische app wordt uitgevoerd in een ISE -omgeving (Integration Service Environment) en alleen ISE-versie van connectors gebruikt voor on-premises gegevensbronnen, hebt u de gegevensgateway niet nodig omdat ISE-connectors directe toegang bieden tot de on-premises resource.

Als er geen ise-versieconnector beschikbaar is voor de on-premises resource die u wilt gebruiken, kan uw logische app de verbinding nog steeds maken met behulp van een niet-ISE-connector, die wordt uitgevoerd in de globale multitenant Azure, niet uw ISE. Voor deze verbinding is echter de on-premises gegevensgateway vereist.

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 uw strategie voor herstel na noodgevallen. Hier volgen de beschikbare triggertypen die u kunt gebruiken in 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

Om uw strategie voor herstel na noodgevallen te laten werken, heeft uw oplossing manieren nodig 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.

Zoneredundantie met beschikbaarheidszones

In elke Azure-regio zijn beschikbaarheidszones fysiek gescheiden locaties die tolerant zijn voor lokale fouten. Dergelijke fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Deze zones bereiken tolerantie door de redundantie en logische isolatie van Azure-services.

Om tolerantie en gedistribueerde beschikbaarheid te bieden, bestaan er ten minste drie afzonderlijke beschikbaarheidszones in elke Azure-regio die zoneredundantie ondersteunt en mogelijk maakt. Het Azure Logic Apps-platform distribueert deze zones en workloads van logische apps over deze zones. Deze mogelijkheid is een belangrijke vereiste voor het inschakelen van flexibele architecturen en het bieden van hoge beschikbaarheid als datacenterfouten in een regio optreden.

Momenteel is deze mogelijkheid preview en beschikbaar voor nieuwe logische apps voor verbruik in specifieke regio's. Voor meer informatie raadpleegt u de volgende documentatie:

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