Herstel na noodgevallen en geo-distributie in Durable Functions

Microsoft streeft ernaar om ervoor te zorgen dat Azure-services altijd beschikbaar zijn. Er kunnen echter niet-geplande servicestoringen optreden. Wanneer uw toepassing tolerantie vereist, moet u uw app configureren voor georedundantie.

U moet ook een noodherstelplan hebben voor het afhandelen van een regionale servicestoring. Een belangrijk onderdeel van een plan voor herstel na noodgevallen is dat er een failover naar de secundaire replica's van uw app en uw opslagaccount wordt uitgevoerd wanneer de primaire replica's niet beschikbaar zijn.

In dit artikel worden voorbeeldscenario's beschreven voor het configureren van herstel na noodgevallen en geo-distributie met behulp van de Durable Functions-functie van Azure Functions.

Achtergrond

In Durable Functions wordt standaard alle status behouden in Azure Storage. Een taakhub is een logische container voor Azure Storage-resources die worden gebruikt voor indelingen en entiteiten. Orchestrator-, activiteits- en entiteitsfuncties kunnen alleen met elkaar communiceren wanneer ze deel uitmaken van dezelfde taakhub. Dit artikel verwijst naar taakhubs bij het beschrijven van scenario's voor het maximaal beschikbaar houden van deze Azure Storage-resources.

Indelingen en entiteiten kunnen worden geactiveerd via clientfuncties die zelf worden geactiveerd via HTTP of een van de andere ondersteunde Azure Functions-triggertypen. Indelingen en entiteiten kunnen ook worden geactiveerd via ingebouwde HTTP-API's. Ter vereenvoudiging is dit artikel gericht op scenario's waarbij Azure Storage- en HTTP-functietriggers betrokken zijn, samen met opties voor het verhogen van de beschikbaarheid en het minimaliseren van downtime tijdens herstel na noodgevallen. In dit artikel worden niet expliciet andere triggertypen behandeld, zoals Azure Service Bus- of Azure Cosmos DB-triggers.

De scenario's in dit artikel zijn gebaseerd op actieve/passieve configuraties, die het beste het gebruik van Azure Storage ondersteunen. Dit patroon bestaat uit het implementeren van een back-upfunctie-app (passief) in een andere regio. Azure Traffic Manager bewaakt de primaire (actieve) functie-app voor HTTP-beschikbaarheid. Er wordt een failover uitgevoerd naar de back-upfunctie-app wanneer de primaire app mislukt. Zie de methode Prioriteit voor verkeersroutering voor meer informatie.

Algemene overwegingen

Houd rekening met deze overwegingen bij het configureren van een actieve/passieve failoverconfiguratie voor Durable Functions:

• In de richtlijnen in dit artikel wordt ervan uitgegaan dat u de standaard Azure Storage-provider gebruikt voor het opslaan van de Durable Functions-runtimestatus. U kunt ook alternatieve opslagproviders configureren die de status elders opslaan, zoals in een SQL Server-database. Alternatieve opslagproviders vereisen mogelijk verschillende strategieën voor herstel na noodgevallen en geo-distributie. Zie Durable Functions-opslagproviders voor meer informatie.
• De voorgestelde actieve/passieve configuratie zorgt ervoor dat een client altijd nieuwe indelingen kan activeren via HTTP. Wanneer twee functie-apps echter dezelfde taakhub in de opslag delen, kunnen sommige achtergrondopslagtransacties tussen de apps worden gedistribueerd. Als gevolg van deze distributie kan deze configuratie leiden tot extra uitgaande kosten voor de secundaire functie-app.
• Het onderliggende opslagaccount en de taakhub worden beide gemaakt in de primaire regio. De functie-apps delen dit opslagaccount en taakhub.
• Alle functie-apps die redundant zijn geïmplementeerd, moeten dezelfde functietoegangssleutels delen wanneer ze via HTTP worden geactiveerd. De Azure Functions-runtime maakt een beheer-API beschikbaar die u kunt gebruiken om functiesleutels programmatisch toe te voegen, te verwijderen en bij te werken. U kunt sleutels ook beheren met behulp van Azure Resource Manager-API's.

Scenario 1: Berekening met gelijke taakverdeling met gedeelde opslag

Om de kans op downtime te beperken als uw functie-app-resources niet beschikbaar zijn, gebruikt dit scenario twee functie-apps die zijn geïmplementeerd in verschillende regio's. We raden dit scenario aan als een oplossing voor failovers.

Traffic Manager is geconfigureerd om problemen in de primaire functie-app te detecteren en verkeer automatisch om te leiden naar de functie-app in de secundaire regio. Deze functie-app deelt hetzelfde Azure Storage-account en dezelfde taakhub. De status van de functie-apps gaat niet verloren en het werk kan normaal worden hervat. Nadat de status is hersteld naar de primaire regio, start Azure Traffic Manager automatisch routeringsaanvragen naar die functie-app.

Er zijn verschillende voordelen voor het gebruik van dit implementatiescenario:

• Als de rekeninfrastructuur mislukt, kan het werk worden hervat in de failoverregio zonder gegevensverlies.
• Traffic Manager zorgt voor de automatische failover naar de goede functie-app.
• Traffic Manager brengt automatisch opnieuw verkeer naar de primaire functie-app tot stand nadat de storing is beëindigd.

Scenariospecifieke overwegingen

• Als u de functie-app implementeert met behulp van een toegewezen Azure App Service-plan, verhoogt het repliceren van de rekeninfrastructuur in het failover-datacenter de kosten.

• In dit scenario worden storingen in de rekeninfrastructuur behandeld, maar het opslagaccount blijft het single point of failure voor de functie-app. Als er een Azure Storage-storing optreedt, lijdt de toepassing aan downtime.

• Als de functie-app een failover heeft uitgevoerd, neemt de latentie toe omdat de app toegang heeft tot het opslagaccount in verschillende regio's.

• Wanneer de functie-app zich in failover bevindt, krijgt deze toegang tot de opslagservice in de oorspronkelijke regio. Het uitgaand netwerkverkeer kan leiden tot hogere kosten.

• Dit scenario is afhankelijk van Traffic Manager. Het kan enige tijd duren voordat een clienttoepassing het adres van de functie-app opnieuw moet aanvragen bij Traffic Manager. Zie Hoe Traffic Manager werkt voor meer informatie.

• Vanaf versie 2.3.0 van de Durable Functions-extensie kunt u veilig twee functie-apps tegelijk uitvoeren met hetzelfde opslagaccount en taakhubconfiguratie. De eerste app die moet worden gestart, verkrijgt een blob-lease op toepassingsniveau die voorkomt dat andere apps berichten uit de wachtrijen van de taakhub stelen. Als deze eerste app niet meer wordt uitgevoerd, verloopt de lease ervan. Een tweede app kan de lease verkrijgen en beginnen met het verwerken van taakhub-berichten.

  Voor extensieversies vóór 2.3.0 zijn functie-apps die zijn geconfigureerd voor het gebruik van hetzelfde opslagaccount berichten verwerken en opslagartefacten gelijktijdig bijwerken. Deze gelijktijdige activiteit resulteert in hogere totale latentie en uitgaande kosten. Als voor de primaire en replica-apps ooit verschillende code is geïmplementeerd, zelfs tijdelijk, kunnen indelingen ook niet correct worden uitgevoerd vanwege inconsistenties in de orchestratorfunctie in de twee apps.

  Alle apps waarvoor geodistributie is vereist voor herstel na noodgevallen, moeten versie 2.3.0 of hoger van de Durable Functions-extensie gebruiken.

Scenario 2: Taakverdeling berekenen met regionale opslag of een regionale duurzame taakplanner

In het voorgaande scenario worden alleen fouten behandeld die beperkt zijn tot de rekeninfrastructuur. Een storing in de functie-app kan ook optreden wanneer de opslagservice of de duurzame taakplanner mislukt.

Om continue werking van Durable Functions te garanderen, implementeert het tweede scenario een toegewezen opslagaccount of een duurzame taakplanner in elke regio waar functie-apps worden gehost. We raden deze aanpak voor herstel na noodgevallen momenteel aan wanneer u een duurzame taakplanner gebruikt.

Met deze aanpak worden verbeteringen aan het vorige scenario toegevoegd:

• Regionale statusisolatie: elke functie-app is gekoppeld aan een eigen regionaal opslagaccount of een duurzame taakplanner. Als de functie-app mislukt, leidt Traffic Manager verkeer om naar de secundaire regio. Omdat de functie-app in elke regio gebruikmaakt van de lokale opslag of duurzame taakplanner, kan Durable Functions blijven verwerken met behulp van de lokale status.
• Er is geen extra latentie toegevoegd voor failover: tijdens een failover worden een functie-app en statusprovider (opslagaccount of durable task scheduler) geplaatst, zodat er geen extra latentie is in de failoverregio.
• Tolerantie voor fouten bij statusbacking: Als het opslagaccount of de duurzame taakplanner in één regio uitvalt, mislukt Durable Functions in die regio. Het mislukken van Durable Functions activeert omleiding naar de secundaire regio. Omdat zowel de reken- als de app-status per regio zijn geïsoleerd, blijft Durable Functions in de failoverregio operationeel.

Scenariospecifieke overwegingen

• Als u de functie-app implementeert met behulp van een toegewezen App Service-plan, verhoogt het repliceren van de rekeninfrastructuur in het failover-datacenter de kosten.
• De huidige status is niet mislukt. Bestaande indelingen en entiteiten worden effectief onderbroken en niet beschikbaar totdat de primaire regio wordt hersteld. Of dit compromis om latentie te behouden en de kosten voor uitgaand verkeer te minimaliseren acceptabel is, is afhankelijk van de vereisten van de toepassing.

Scenario 3: Berekening met gelijke taakverdeling met gedeelde GRS

Dit scenario is een wijziging van het eerste scenario (het implementeren van een gedeeld opslagaccount). Het belangrijkste verschil is dat het opslagaccount wordt gemaakt met geo-replicatie ingeschakeld.

Dit scenario biedt dezelfde functionele voordelen als het eerste scenario, maar biedt ook andere voordelen voor gegevensherstel:

• Geografisch redundante opslag (GRS) en GRS (leestoegang) (RA-GRS) maximaliseren de beschikbaarheid voor uw opslagaccount.
• Als er sprake is van een regionale storing in de Azure Storage-service, kunt u handmatig een failover naar de secundaire replica initiëren. In extreme omstandigheden waarin een regio verloren gaat vanwege een noodgeval, kan Microsoft een regionale failover initiëren. In dit geval hoeft u geen actie te ondernemen.
• Wanneer er een failover plaatsvindt, blijft de status van Durable Functions behouden tot de laatste replicatie van het opslagaccount. De replicatie vindt doorgaans om de paar minuten plaats.

Zie planning en failover voor herstel na noodgevallen van Azure Storage voor meer informatie.

Scenariospecifieke overwegingen

• Een failover naar de replica kan enige tijd duren. Totdat de failover is voltooid en Dns-records van Azure Storage zijn bijgewerkt, blijft de functie-app ontoegankelijk.
• Er zijn hogere kosten verbonden aan het gebruik van geografisch gerepliceerde opslagaccounts.
• GRS-replicatie kopieert uw gegevens asynchroon. Sommige van de meest recente transacties gaan mogelijk verloren vanwege de latentie van het replicatieproces.
• Zoals beschreven voor het eerste scenario, raden we u aan om functie-apps die in deze strategie zijn geïmplementeerd, versie 2.3.0 of hoger van de Durable Functions-extensie te gebruiken.

Volgende stap