Delen via

Betrouwbaarheid in Azure Logic Apps

Met Azure Logic 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 Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u werkstromen van logische apps tolerant maakt voor een verscheidenheid aan mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. Ook worden enkele belangrijke informatiepunten over de Service Level Agreement (SLA) van Azure Logic Apps uitgelicht.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voor productiewerkzaamheden raden we u aan het volgende te doen:

  • Voor zakelijke en veilige werkstromen met isolatie- of netwerkbeveiligingsvereisten maakt en voert u Standard-werkstromen uit in Azure Logic Apps met één tenant in plaats van verbruikswerkstromen in multitenant Azure Logic Apps. Zie Maken en implementeren in verschillende omgevingen voor meer informatie.
  • Voor productie-implementaties met Azure Logic Apps met één tenant kunt u zoneredundantie inschakelen om uw logische app-resources over meerdere beschikbaarheidszones te verdelen.

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

De primaire resource die u implementeert, is een logische app. Logische apps voor verbruik hebben slechts één werkstroom, terwijl Standaard logische apps meer dan één werkstroom kunnen hebben. De meeste werkstromen gebruiken een of meer verbindingen voor toegang tot andere apps, services en systemen.

Als u toegang hebt tot gegevens in on-premises systemen, kunt u een on-premises gegevensgateway implementeren. Elke gatewayresource vertegenwoordigt een afzonderlijke installatie van een gegevensgateway op een lokale computer. U kunt een on-premises gegevensgateway configureren voor hoge beschikbaarheid met behulp van meerdere computers. Zie Ondersteuning voor hoge beschikbaarheid voor meer informatie.

Wanneer u Azure Logic Apps gebruikt voor bedrijfs-naar-business-integratiescenario's (B2B), kunt u integratieaccounts implementeren waarin u de artefacten definieert en opslaat die door logische app-werkstromen worden gebruikt.

Fysieke architectuur

Voor logische apps voor verbruik beheert Azure Logic Apps automatisch de rekeninfrastructuur, statusopslag en andere resources. U hoeft geen virtuele machines (VM's) te configureren of te beheren. Logische apps voor verbruik delen de rekeninfrastructuur tussen veel klanten.

Voor standaard logische apps maakt Azure Logic Apps gebruik van rekenresources, werkstroomserviceplannen of -plannen, die speciaal voor u zijn toegewezen. Elk plan kan meerdere exemplaren hebben, die u desgewenst kunt verdelen over meerdere beschikbaarheidszones. Elk exemplaar wordt ruwweg toegewezen aan een virtuele machine (VM), maar u ziet deze VM's niet en u hoeft ze niet rechtstreeks te configureren of te beheren. Uw workflows draaien op instanties van uw plan.

Voor standaard logische apps moet u opslag configureren om de toestand van stateful werkstromen te behouden. Zie Stateful en stateless werkstromen voor meer informatie.

Standaard logische apps maken gebruik van vergelijkbare onderliggende infrastructuur als Azure Functions en Azure App Service. Er bestaan echter enkele verschillen in de manier waarop u plannen voor logische apps configureert in vergelijking met andere services.

Zie Verschillen tussen standaard logische apps en logische apps voor verbruik voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

In Azure Logic Apps ondersteunen veel werkstroomtriggers en -acties automatisch beleid voor opnieuw proberen, waardoor aanvragen die mislukken automatisch opnieuw worden geprobeerd vanwege tijdelijke fouten. Zie Fouten en uitzonderingen afhandelen in Azure Logic Apps voor meer informatie over het wijzigen of uitschakelen van beleid voor opnieuw proberen.

Als een actie mislukt, kunt u het gedrag van volgende acties aanpassen. U kunt ook scopes maken om gerelateerde acties te groeperen die samen kunnen mislukken of slagen.

Zie Fouten en uitzonderingen verwerken in Azure Logic Apps voor meer informatie.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure Logic Apps ondersteunt zoneredundantie, die rekenresources en statussen verspreidt over meerdere beschikbaarheidszones. Wanneer u workloadresources voor logische apps over beschikbaarheidszones distribueert, verbetert u de veerkracht en betrouwbaarheid van uw logische app-workloads in productie.

Nieuwe en bestaande werkstromen voor logische verbruiks-apps in multitenant Azure Logic Apps schakelen zoneredundantie automatisch in.

Azure Logic Apps ondersteunt zoneredundantie, die rekenresources verspreidt over meerdere beschikbaarheidszones. U kunt eventueel zoneredundantie configureren voor de status van de werkstromen van uw logische app. Wanneer u workloadresources voor logische apps over beschikbaarheidszones distribueert, verbetert u de veerkracht en betrouwbaarheid van uw logische app-workloads in productie.

Voor Standaardwerkstromen met de hostingoptie Workflow Service Plan in Azure Logic Apps met één tenant kunt u eventueel zoneredundantie inschakelen.

Voor Standaardwerkstromen met de hostingoptie App Service Environment v3 kunt u eventueel zoneredundantie inschakelen. Zie Betrouwbaarheid in App Service Environment voor meer informatie over hoe App Service Environment v3 beschikbaarheidszones ondersteunt.

Requirements

  • Regioondersteuning: Logische verbruiksapps die zijn geïmplementeerd in elke regio die beschikbaarheidszones ondersteunt , zijn automatisch zone-redundant. Japan - west is de uitzondering, die momenteel geen zone-redundante logische apps ondersteunt, omdat sommige afhankelijke services nog geen zoneredundantie ondersteunen.
  • Regioondersteuning: U kunt zone-redundante logische standaard-apps implementeren met werkstroomserviceplannen in elke regio die beschikbaarheidszones voor Azure App Service ondersteunt. Japan - west is de uitzondering, die momenteel geen zone-redundante logische apps ondersteunt, omdat sommige afhankelijke services nog geen zoneredundantie ondersteunen. Zie Betrouwbaarheid in Azure-app Service voor meer informatie.
  • Regioondersteuning: Zie Regio's om te zien welke regio's beschikbaarheidszones ondersteunen voor App Service Environment v3.
  • Instance count: U moet ten minste twee instances van de Workflow Service Plan implementeren. Elk exemplaar komt ongeveer overeen met één VM, dus als u deze exemplaren (VM's) over meerdere beschikbaarheidszones wilt distribueren, moet u minimaal twee exemplaren hebben.

Considerations

  • Connectors: Wanneer uw logische app zone-redundant is, zijn ingebouwde connectors automatisch zone-redundant.

  • Integratieaccounts: Premium SKU-integratieaccounts zijn standaard zone-redundant.

Cost

Er zijn geen extra kosten van toepassing op het gebruik van zoneredundantie, die automatisch wordt ingeschakeld voor nieuwe en bestaande logische apps voor verbruik in multitenant Azure Logic Apps.

Wanneer u standaardlogica-apps hebt met het Workflow Service-plan in Azure Logic Apps met één tenant, zijn er geen extra kosten van toepassing op het inschakelen van beschikbaarheidszones als u twee of meer planexemplaren hebt. Er worden kosten in rekening gebracht op basis van uw plan-SKU, de opgegeven capaciteit en eventuele instanties die u omhoog of omlaag schaalt, op basis van uw criteria voor automatische schaalaanpassing. Als u beschikbaarheidszones inschakelt, maar minder dan twee instanties opgeeft, dwingt het platform tot het minimum van twee instanties en brengt kosten in rekening voor deze twee instanties.

App Service Environment v3 heeft een specifiek prijsmodel voor zoneredundantie. Zie Prijzen voor prijsinformatie voor App Service Environment v3.

Ondersteuning voor beschikbaarheidszones configureren

Werkstromen van logische apps voor verbruik ondersteunen automatisch zoneredundantie, dus er is geen configuratie vereist.

  • Een nieuwe zone-redundante logische app maken: als u zoneredundantie wilt inschakelen voor standaard logische apps, raadpleegt u Zoneredundantie inschakelen voor uw logische app.

  • Zoneredundantie inschakelen voor een bestaande logische app: u kunt zoneredundantie niet inschakelen nadat u een serviceplan hebt gemaakt. In plaats daarvan moet u een nieuw plan maken met zoneredundantie ingeschakeld en de oude verwijderen.

  • Zoneredundantie uitschakelen: u kunt zoneredundantie niet uitschakelen nadat u een workflowserviceplan hebt gemaakt. In plaats daarvan moet u een nieuw plan maken waarbij zoneredundantie is uitgeschakeld en het oude plan verwijderen.

Capaciteitsplanning en -beheer

Als u zich wilt voorbereiden op een fout in de beschikbaarheidszone, kunt u overwegen om de capaciteit van uw plan te over-inrichten . Met overinrichting kan de oplossing enige mate van capaciteitsverlies tolereren en toch blijven functioneren zonder verminderde prestaties. Zie Capaciteit beheren met overinrichting voor meer informatie.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer logische app-resources zijn geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.

  • Verkeersroutering tussen zones: tijdens normale bewerkingen kunnen werkstroomoproepen rekenresources gebruiken vanuit elke beschikbaarheidszone in de regio.

  • Gegevensreplicatie tussen zones: Voor stateful werkstromen wordt de werkstroomstatus synchroon gerepliceerd tussen beschikbaarheidszones met behulp van zone-redundante opslag (ZRS).

  • Verkeersroutering tussen zones: tijdens normale bewerkingen worden werkstroomoproepen verspreid over al uw beschikbare planexemplaren in alle beschikbaarheidszones.

  • Gegevensreplicatie tussen zones: Voor stateful werkstromen wordt de werkstroomstatus opgeslagen op basis van de statusopslag die u hebt geconfigureerd. Wanneer u Azure Storage als uw externe opslagsysteem gebruikt, moet u zone-redundante opslag (ZRS) gebruiken, waarmee de werkstroomstatus tussen beschikbaarheidszones synchroon wordt gerepliceerd.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer er een storing in de beschikbaarheidszone optreedt terwijl logische app-resources zijn geconfigureerd voor zoneredundantie.

  • Detectie en reactie: Azure Logic Apps is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone. U hoeft niets te doen om een zonefailover te starten.
  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Als een beschikbaarheidszone niet beschikbaar is, beëindigt Azure Logic Apps alle actieve werkstroomuitvoeringen die worden uitgevoerd op een VIRTUELE machine in de defecte beschikbaarheidszone. Het platform hervat de werkstroom automatisch op een andere VIRTUELE machine in een andere beschikbaarheidszone. Vanwege dit gedrag kunnen actieve werkstromen tijdelijke fouten of een hogere latentie ervaren, omdat nieuwe VM's worden toegevoegd aan de resterende beschikbaarheidszones.

  • Verwachte downtime: er wordt geen downtime verwacht in Azure Logic Apps. Als er echter afhankelijkheden bestaan voor andere services die downtime ondervinden, kan uw logische app ook worden beïnvloed.

  • Verwachte gegevensverlies: Er wordt geen gegevensverlies verwacht.

  • Verkeer omleiden: binnenkomend verkeer wordt automatisch gedistribueerd naar infrastructuur in gezonde zones.
  • Niet-runtimegedrag: werkstromen van logische apps in een zone-redundant plan blijven actief, zelfs als een beschikbaarheidszone een storing ondervindt. Gedragingen buiten de runtime kunnen echter worden beïnvloed tijdens een storing in de beschikbaarheidszone. Zie betrouwbaarheid in Azure App Service: gedrag tijdens een zonefout voor meer informatie en een lijst met deze gedragingen.
  • Niet-runtimegedrag: werkstromen van logische apps in een zone-redundant plan blijven actief, zelfs als een beschikbaarheidszone een storing ondervindt. Gedragingen buiten de runtime kunnen echter worden beïnvloed tijdens een storing in de beschikbaarheidszone. Zie betrouwbaarheid in Azure App Service Environment - Gedrag tijdens een zonefout voor meer informatie en een lijst met deze gedragingen.

Zoneherstel

Wanneer de beschikbaarheidszone wordt hersteld, herstelt Azure Logic Apps automatisch de instanties in de beschikbaarheidszone, verwijdert tijdelijke instanties die zijn aangemaakt in de andere beschikbaarheidszones en routeert het verkeer tussen uw instanties zoals gebruikelijk.

Testen op zonefouten

Azure Logic Apps beheert verkeersroutering, failover en failback voor zone-redundante logische app-resources. U hoeft niets te initiëren. Deze functie wordt volledig beheerd, dus u hoeft de foutprocessen van de beschikbaarheidszone niet te valideren.

Tolerantie voor storingen in de hele regio

Elke logische app wordt geïmplementeerd in één Azure-regio. Als de regio niet beschikbaar is, is uw logische app ook niet beschikbaar.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

Voor een hogere tolerantie kunt u een logische app voor stand-by of back-up implementeren in een secundaire regio en een failover naar die andere regio uitvoeren als de primaire regio niet beschikbaar is. Voer de volgende taken uit om deze mogelijkheid in te schakelen:

  • Implementeer uw logische app in zowel primaire als secundaire regio's.
  • Configureer zo nodig verbindingen met resources opnieuw.
  • Taakverdeling en failoverbeleid configureren.
  • Plan om de gezondheid van de primaire instantie te bewaken en failover te initiëren.

Zie voor meer informatie over implementaties in meerdere regio's voor uw werkstromen voor logische apps:

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Verwante inhoud

  • Last updated on