Azure Functions geo-noodherstel
Wanneer hele Azure-regio's of datacenters te maken krijgen met downtime, moet uw bedrijfskritische code in een andere regio blijven verwerken. In dit artikel worden enkele van de strategieën beschreven die u kunt gebruiken om functies te implementeren om herstel na nood gevallen mogelijk te maken.
Basisbegrippen
Azure Functions uitgevoerd in een functie-app in een specifieke regio. Er is geen ingebouwde redundantie beschikbaar. Om verlies van uitvoering tijdens uitval te voorkomen, kunt u dezelfde functies redundant implementeren voor functie-apps in meerdere regio's.
Wanneer u dezelfde functiecode in meerdere regio's gebruikt, zijn er twee patronen om rekening mee te houden:
| Patroon | Beschrijving |
|---|---|
| Actief/actief | Functies in beide regio's worden actief uitgevoerd en verwerken gebeurtenissen, ofwel op een dubbele manier of in rotatie. We raden u aan een actief/actief-patroon te gebruiken in combinatie met Azure Front Door voor uw kritieke http-geactiveerde functies. |
| Actief/passief | Functies worden actief uitgevoerd in regio's die gebeurtenissen ontvangen, terwijl dezelfde functies in een tweede regio inactief blijven. Wanneer failover is vereist, wordt de tweede regio geactiveerd en wordt de verwerking overgenomen. We raden dit patroon aan voor uw gebeurtenisgestuurde, niet door HTTP geactiveerde functies, zoals Service Bus en door Event Hub geactiveerde functies. |
Zie de richtlijnen in Uiterst beschikbare webtoepassing voor meerdere regio's voor meer informatie over implementaties in meerdere regio's.
Redundantie voor HTTP-triggerfuncties
Het actief/actief-patroon is het beste implementatiemodel voor HTTP-triggerfuncties. In dit geval moet u een Azure Front Door aanvragen tussen beide regio's te coördineren. Azure Front Door kunt HTTP-aanvragen routeer- en round robin-aanvragen uitvoeren tussen functies die in meerdere regio's worden uitgevoerd. Ook wordt periodiek de status van elk eindpunt gecontroleerd. Wanneer een functie in één regio niet meer reageert op statuscontroles, Azure Front Door de functie uit de roulatie en wordt alleen verkeer doorgestuurd naar de resterende functies in orde.
Redundantie voor niet-HTTP-triggerfuncties
Redundantie voor functies die gebeurtenissen van andere services gebruiken, vereist een ander patroon, dat werkt met het failoverpatroon van de gerelateerde services.
Actieve/passieve redundantie voor niet-HTTP-triggerfuncties
Actief/passief biedt een manier voor slechts één functie om elk bericht te verwerken, maar biedt een mechanisme om in geval van een noodgeval een fail over te brengen naar een secundaire regio. Functie-apps werken met het failovergedrag van de partnerservices, zoals Azure Service Bus geo-herstel en Azure Event Hubs geo-herstel. De secundaire functie-app wordt als passief beschouwd omdat de failoverservice waarmee deze is verbonden momenteel niet actief is, waardoor de functie-app in feite inactief is.
Neem een voorbeeldtopologie met behulp van een Azure Event Hubs trigger. In dit geval vereist het actief/passief-patroon de volgende onderdelen:
- Azure Event Hub geïmplementeerd in zowel een primaire als een secundaire regio.
- Geo-noodval ingeschakeld om de primaire en secundaire Event Hub te koppelen. Hiermee maakt u ook een alias die u kunt gebruiken om verbinding te maken met Event Hubs en over te schakelen van de primaire naar de secundaire zonder de verbindingsgegevens te wijzigen.
- Functie-apps worden geïmplementeerd in zowel de primaire als de secundaire regio (failover), met de app in de secundaire regio in feite inactief omdat er geen berichten worden verzonden.
- Functie-app wordt op de directe (niet-alias) connection string voor de respectieve Event Hub.
- Uitgevers naar de Event Hub moeten publiceren naar de alias connection string.
Vóór de failover verzenden uitgevers naar de gedeelde aliasroute naar de primaire Event Hub. De primaire functie-app luistert uitsluitend naar de primaire Event Hub. De secundaire functie-app is passief en inactief. Zodra failover is gestart, worden uitgevers die naar de gedeelde alias verzenden, doorgeleid naar de secundaire Event Hub. De secundaire functie-app wordt nu actief en wordt automatisch actief. Effectieve failover naar een secundaire regio kan volledig worden aangestuurd vanuit de Event Hub, met de functies alleen actief wanneer de respectieve Event Hub actief is.
Lees meer over informatie en overwegingen voor failover met Service Bus en Event Hubs.
Actieve/actieve redundantie voor niet-HTTP-triggerfuncties
U kunt nog steeds actieve/actieve implementaties uitvoeren voor niet-HTTP-geactiveerde functies. U moet echter wel overwegen hoe de twee actieve regio's met elkaar communiceren of met elkaar samenwerken. Wanneer u dezelfde functie-app implementeert in twee regio's met elke trigger in dezelfde Service Bus-wachtrij, fungeren ze als concurrerende consumenten bij het uit de wachtrij verwijderen van die wachtrij. Hoewel dit betekent dat elk bericht alleen wordt verwerkt door een van de exemplaren, betekent dit ook dat er nog steeds één storingspunt is op de Service Bus instantie.
U kunt in plaats daarvan twee Service Bus implementeren, met één in een primaire regio, één in een secundaire regio. In dit geval kunt u twee functie-apps hebben, met elk naar de Service Bus wachtrij actief in hun regio. De uitdaging van deze topologie is hoe de wachtrijberichten worden verdeeld over de twee regio's. Dit betekent vaak dat elke uitgever een bericht probeert te publiceren naar beide regio's en dat elk bericht wordt verwerkt door beide actieve functie-apps. Hoewel hiermee het gewenste actief/actief-patroon wordt gemaakt, ontstaan er ook andere uitdagingen met het duplicatie van rekenkracht en wanneer of hoe gegevens worden geconsolideerd. Vanwege deze uitdagingen raden we u aan het actieve/passieve patroon te gebruiken voor niet-HTTPS-triggerfuncties.