Bedrijfscontinuïteit en herstel na noodgevallen voor Azure Logic Apps

  • Artikel

Om de impact en effecten van onvoorspelbare gebeurtenissen op uw bedrijf en klanten te verminderen, moet u ervoor zorgen dat u beschikt over een oplossing voor herstel na noodgevallen , zodat u gegevens kunt beveiligen, de resources die kritieke bedrijfsfuncties ondersteunen, snel kunt herstellen en bewerkingen kunt 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 datacentrumverlies omvatten. Door een BCDR-oplossing (business continuity and disaster recovery) gereed te hebben, kan uw onderneming of organisatie sneller reageren op onderbrekingen, geplande of ongeplande onderbrekingen 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 indelen tussen apps, cloudservices en on-premises systemen door minder code te schrijven. Wanneer u BCDR plant, moet u niet alleen rekening houden met uw logische apps, maar ook met 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 de implementatie. Deze locatie is een openbare regio in azure met meerdere tenants, zoals VS - west, of een integratieserviceomgeving (ISE) 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 wereldwijde 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-up logische app op een alternatieve locatie waar Azure Logic Apps ook beschikbaar is. Op die manier kan de secundaire instantie het werk overnemen als de primaire afdeling verlies, onderbrekingen of storingen ondervindt. Deze strategie vereist dat uw secundaire logische app en afhankelijke resources al zijn geïmplementeerd en gereed zijn op de alternatieve locatie.

Als u de goede DevOps-procedures volgt, gebruikt u al Azure Resource Manager-sjablonen om uw logische apps en de afhankelijke resources ervan 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 moeten worden gebruikt voor elke implementatiebestemming. Deze mogelijkheid betekent dat u dezelfde logische app kunt implementeren in verschillende omgevingen, bijvoorbeeld voor 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 secundaire exemplaar van de 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 wereldwijde Azure met meerdere tenants, of beide exemplaren worden geïmplementeerd in ISE's, waardoor 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 aanbevolen procedures en meer informatie over gekoppelde regio's voor BCDR.

    De primaire en secundaire locatie moeten bijvoorbeeld ISE's zijn wanneer de primaire logische app wordt uitgevoerd in een ISE en connectors met ISE-versie, HTTP-acties gebruikt om resources in het virtuele Azure-netwerk aan te roepen, 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 als locaties combineren. Zorg er echter voor dat u rekening houdt met en begrijpt wat de verschillen zijn tussen de wijze waarop logische apps worden uitgevoerd in een ISE en azure met meerdere tenants.

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

Voorbeeld: Multitenant Azure

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

Instanties van primaire en secundaire logische apps op afzonderlijke locaties

Voorbeeld: Integratieserviceomgeving

In dit voorbeeld ziet u de vorige instanties van de primaire en secundaire logische app, maar die zijn geïmplementeerd in afzonderlijke ISE's. Eén Resource Manager sjabloon definieert zowel instanties van logische apps, de afhankelijke resources die voor deze logische apps zijn vereist, als de ISE's 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, services, systemen en andere resources kan gebruiken, zoals Azure Storage-accounts, SQL Server databases, werk- of school-e-mailaccounts, enzovoort. Als uw logische app toegang tot deze resources nodig heeft, maakt u verbindingen waarmee de toegang tot deze resources wordt geverifieerd. Elke verbinding is een afzonderlijke Azure-resource die zich op een specifieke locatie bevindt en niet kan worden gebruikt door resources op andere locaties.

Houd voor uw strategie voor herstel na noodgevallen rekening met de locaties waar afhankelijke resources bestaan ten opzichte van de instanties van uw logische app:

  • Uw primaire exemplaar en afhankelijke resources bevinden zich op verschillende locaties. In dit geval kan uw secundaire exemplaar verbinding maken met dezelfde afhankelijke resources of eindpunten. U moet echter verbindingen maken die specifiek zijn voor uw secundaire exemplaar. Op die manier worden de verbindingen van uw secundaire locatie niet beïnvloed als uw primaire locatie niet beschikbaar is.

    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 afhankelijke resources bevinden zich op dezelfde locatie. In dit geval moeten afhankelijke resources back-ups of gerepliceerde versies op een andere locatie hebben, zodat uw secundaire exemplaar nog steeds toegang heeft tot deze resources.

    Stel dat uw primaire logische app verbinding maakt met een service die zich in dezelfde locatie of regio bevindt, bijvoorbeeld Azure SQL Database. Als deze hele regio niet meer 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 database 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 op een lokale computer installeren. Vervolgens kunt u een gegevensgatewayresource maken in de 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 als uw logische app-resource. Zorg er in uw strategie voor herstel na noodgevallen voor dat de gegevensgateway beschikbaar blijft voor gebruik door uw logische app. U kunt hoge beschikbaarheid voor uw gateway inschakelen wanneer u meerdere gateway-installaties hebt.

Notitie

Als uw logische app wordt uitgevoerd in een Integratieserviceomgeving (ISE) en alleen connectors met ISE-versie 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 connector met ISE-versie 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 Azure met meerdere tenants, niet in uw ISE. Voor deze verbinding is echter de on-premises gegevensgateway vereist.

Actief-actief versus actief-passief-rollen

U kunt uw primaire en secundaire locaties zo instellen dat de instanties van uw logische app op deze locaties de volgende rollen kunnen spelen:

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

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

- Concurrerende consumenten: u kunt beide exemplaren als concurrerende consumenten laten fungeren, zodat de exemplaren concurreren om 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 actief de volledige workload, terwijl het secundaire exemplaar passief is (uitgeschakeld of inactief). De secundaire instantie wacht op een signaal dat de primaire server niet beschikbaar is of niet werkt vanwege een onderbreking of storing en neemt de workload over als het actieve exemplaar.
Combinatie Sommige logische apps spelen een actief-actief-rol, terwijl andere logische apps een actief-passieve rol spelen.

Voorbeelden van actief-actief

Deze voorbeelden tonen de actief-actief-installatie waarbij beide instanties van de logische app aanvragen of berichten actief verwerken. Een ander systeem of een andere service distribueert de aanvragen of berichten tussen exemplaren, bijvoorbeeld een van deze 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 binnenkomend verkeer moet worden verdeeld. U kunt ook een service gebruiken die ondersteuning biedt voor het bijhouden van statussen, 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:

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

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

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

Voorbeelden van actief/passief

In dit voorbeeld ziet u de instelling actief-passief waarbij het primaire logische app-exemplaar actief is op de ene locatie, terwijl het secundaire exemplaar inactief blijft op een andere locatie. Als de primaire instantie een onderbreking of storing ondervindt, kunt u een operator een script laten uitvoeren dat de secundaire taak activeert om de workload over te nemen.

'Actief-passief'-instelling die gebruikmaakt van 'concurrerende consumenten'

Combinatie met actief-actief en actief-passief

In dit voorbeeld ziet u een gecombineerde installatie waarbij de primaire locatie beide actieve logische app-exemplaren heeft, terwijl de secundaire locatie exemplaren van de logische app actief-passief 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 op e-mailberichten controleert met behulp van een Office 365 Outlook polling-trigger.

  • Op de secundaire locatie werkt een actieve logische app met de logische app op de primaire locatie door te luisteren naar en te concurreren om 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 meer beschikbaar is, maar is uitgeschakeld om te voorkomen dat e-mailberichten opnieuw worden gelezen.

De combinatie 'Actief-passief' en 'actief-passief' die gebruikmaakt van terugkeerpatroontriggers

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 is deze niet overdraagbaar naar een andere locatie. Als er een fout of onderbreking optreedt, worden alle actieve werkstroomexemplaren afgestaan. Wanneer u een primaire en secundaire locatie hebt ingesteld, worden nieuwe werkstroomexemplaren uitgevoerd op de secundaire locatie.

Het verminderen van afgeslagen exemplaren die worden uitgevoerd

U kunt kiezen uit verschillende berichtpatronen die u kunt implementeren om het aantal verlaten actieve werkstroomexemplaren te minimaliseren, bijvoorbeeld:

Toegang tot trigger- en uitvoeringsgeschiedenis

Voor meer informatie 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 in dezelfde locatie of regio waar die logische app werd uitgevoerd. Dit betekent dat u deze geschiedenis niet naar een andere locatie kunt migreren. Als uw primaire exemplaar een failover uitvoert naar een secundair exemplaar, hebt u alleen toegang tot de trigger van elk exemplaar en voert u de geschiedenis uit op de respectieve locaties waar deze exemplaren zijn uitgevoerd. U kunt echter locatie-agnostische informatie over de geschiedenis van uw logische app verkrijgen door uw logische apps in te stellen voor het verzenden van diagnostische gebeurtenissen naar een Azure Log Analytics-werkruimte. Vervolgens kunt u de status en geschiedenis bekijken van logische apps die op meerdere locaties worden uitgevoerd.

Richtlijnen voor triggertype

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. Dit zijn de beschikbare triggertypen die u in logische apps kunt gebruiken:

Trigger terugkeerpatroon

De trigger Terugkeerpatroon is onafhankelijk van een specifieke service of eindpunt en wordt alleen geactiveerd op basis van een opgegeven planning en geen andere criteria, bijvoorbeeld:

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

Wanneer uw logische app begint met een terugkeerpatroontrigger, moet u de primaire en secundaire instanties van de logische app instellen met de actief-passieve rollen. Als u de beoogde hersteltijd (RTO) wilt verminderen, die verwijst naar de beoogde duur voor het herstellen van een bedrijfsproces na een onderbreking of noodgeval, kunt u uw logische app-exemplaren instellen met een combinatie van actief-passieve rollen en passief-actieve rollen. In deze installatie splitst u de planning over 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 meer beschikbaar is, de secundaire locatie het werk kan overnemen:

De combinatie 'Actief-passief' en 'passief-actief' die gebruikmaakt van terugkeerpatroontriggers

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

    • Voor de actieve logische app stelt u de trigger Terugkeerpatroon in op het begin van het uur en herhaalt u deze elke 20 minuten, bijvoorbeeld 9:00 uur, 9:20 uur, enzovoort.

    • Voor de passieve uitgeschakelde logische app stelt u de trigger Terugkeerpatroon in op hetzelfde schema, maar begint u 10 minuten na het uur en herhaalt u deze elke 20 minuten, bijvoorbeeld 9:10 uur, 9:30 uur, enzovoort.

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

    • Stel voor de passieve uitgeschakelde logische app de trigger Terugkeerpatroon in op hetzelfde schema als de actieve logische app op de primaire locatie, die zich bovenaan het uur bevindt en herhaal deze elke 20 minuten, bijvoorbeeld 9:00 uur, 9:10 uur, enzovoort.

    • Stel voor de actieve ingeschakelde logische app de trigger Terugkeerpatroon in op hetzelfde schema 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 uur, 9:20 uur, enzovoort.

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

Polling-trigger

Als u regelmatig wilt controleren of nieuwe gegevens voor verwerking beschikbaar zijn vanaf een specifieke service of specifiek eindpunt, kan uw logische app een polling-trigger gebruiken die de service of het eindpunt herhaaldelijk 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, die gegevens beschrijven die altijd beschikbaar zijn om te worden gelezen
  • 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 aan de server-, service- of systeemzijde te behouden.

  • Logische apps die werken met de status aan de clientzijde, gebruiken 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 start de trigger de logische app alleen wanneer het volgende ongelezen bericht binnenkomt.

  • Logische apps die werken met server-, service- of systeemstatus gebruiken eigenschapswaarden of -instellingen die zich aan de server-, service- of systeemzijde bevinden.

    Een trigger op basis van een query die bijvoorbeeld een rij uit een database leest, vereist dat de rij een isRead kolom bevat die is ingesteld op FALSE. Telkens wanneer de trigger een rij leest, werkt de logische app die rij bij door de isRead kolom van FALSE te wijzigen in TRUE.

    Deze benadering aan de serverzijde werkt op dezelfde manier voor Service Bus-wachtrijen of onderwerpen met semantiek in de wachtrij, waarbij een trigger een bericht kan lezen en vergrendelen terwijl de logische app het bericht verwerkt. Wanneer de verwerking van de logische app is voltooid, verwijdert de trigger het bericht uit de wachtrij of het onderwerp.

Vanuit het perspectief van herstel na noodgevallen moet u bij het instellen van de primaire en secundaire instanties van uw logische app rekening houden met dit gedrag op basis van het feit of de logische app de status aan de clientzijde of aan de serverzijde bijhoudt:

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

    De Office 365 Outlook-trigger handhaaft bijvoorbeeld de status aan de clientzijde en houdt de tijdstempel bij voor het laatst gelezen e-mailbericht 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 actief-actief-rollen te spelen waarbij ze als concurrerende consumenten werken of actief-passief-rollen waarbij de alternatieve instantie wacht totdat het primaire exemplaar een failover uitvoert naar de alternatieve locatie.

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

    Notitie

    Als uw logische app berichten in een specifieke volgorde moet lezen, bijvoorbeeld uit een Service Bus-wachtrij, kunt u het concurrerende consumentenpatroon gebruiken, maar alleen in combinatie met Service Bus-sessies, ook wel het sequentiële konvooipatroon genoemd. Anders moet u de instanties van uw 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 trigger Aanvraag om uw logische app te starten, zodat andere logische apps de trigger kunnen aanroepen met behulp van de actie Werkstroom aanroepen - 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 tot een andere service of systeem de trigger expliciet aanroept. Als passief eindpunt kunt u uw primaire en secundaire exemplaren op de volgende manieren instellen:

  • Actief-actief: beide instanties verwerken aanvragen of aanroepen actief. De aanroeper of router balanceert of distribueert verkeer tussen deze exemplaren.

  • Actief-passief: alleen het primaire exemplaar is actief en verwerkt al het werk, terwijl het secundaire exemplaar wacht totdat de primaire instantie een onderbreking of storing ondervindt. De aanroeper 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 aanvraagtriggers gebruiken. API Management biedt ingebouwde tolerantie tussen regio's en de mogelijkheid om verkeer te routeren over meerdere eindpunten.

Webhook-trigger

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 plaatsvindt op dat service-eindpunt. 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. Als de trigger is uitgeschakeld, wordt de service afgemeld.

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

De status van het primaire exemplaar evalueren

Uw strategie voor herstel na noodgevallen werkt alleen als uw oplossing manieren nodig heeft om deze taken uit te voeren:

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

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

Beschikbaarheid van primair exemplaar controleren

Als u wilt bepalen of het primaire exemplaar beschikbaar is, wordt uitgevoerd en werkt, 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 logische app voor basisstatuscontrole 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 gecontroleerde 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 en niet asynchroon reageert.

  3. Als u verder wilt bepalen of de primaire locatie in orde is, kunt u desgewenst rekening houden met de status van alle andere services die communiceren met de logische doel-app op deze locatie. Vouw de logische app voor statuscontrole uit om ook de status van 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 app watchdog zo instellen dat als het aanroepen van de statuscontrolelogica mislukt, de watchdog een waarschuwing kan verzenden naar uw operationele team, zodat ze de fout kunnen onderzoeken en waarom het primaire exemplaar niet reageert.

Belangrijk

Zorg ervoor dat de logische app van uw watchdog 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. Voer uit 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 meer geavanceerde logische watchdog-app maken, die na een aantal fouten een andere logische app aanroept die automatisch overschakelt naar de secundaire locatie wanneer de primaire locatie uitvalt.

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 activeringslogica-app aan te roepen nadat een bepaald 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 branden. 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 inschakelt. Het Azure Logic Apps-platform verdeelt deze zones en workloads van logische apps over deze zones. Deze mogelijkheid is een belangrijke vereiste voor het inschakelen van tolerante architecturen en het bieden van hoge beschikbaarheid als er datacenterfouten optreden in een regio.

Deze mogelijkheid is momenteel preview en beschikbaar voor nieuwe logische verbruiksapps in specifieke regio's. Zie de volgende documentatie voor meer informatie:

Diagnostische gegevens verzamelen

U kunt logboekregistratie instellen voor de uitvoeringen van uw logische app 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