Betrouwbaarheid in Azure Functions
In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure Functions beschreven en wordt zowel binnen regionale tolerantie behandeld als beschikbaarheidszones en herstel in meerdere regio's en bedrijfscontinuïteit. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheidsprincipes in Azure.
Ondersteuning voor beschikbaarheidszones voor Azure Functions is beschikbaar voor zowel Premium-abonnementen (Elastic Premium) als Toegewezen (App Service). Dit artikel is gericht op ondersteuning voor zoneredundantie voor Premium-abonnementen. Zie App Service migreren naar ondersteuning voor beschikbaarheidszones voor zoneredundantie voor toegewezen plannen.
Ondersteuning voor beschikbaarheidszone
Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.
Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.
Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.
Azure Functions ondersteunt een zone-redundante implementatie.
Wanneer u Functions configureert als zone-redundant, verspreidt het platform automatisch de exemplaren van de functie-app over drie zones in de geselecteerde regio.
Het verspreiden van exemplaren met een zone-redundante implementatie wordt bepaald binnen de volgende regels, zelfs als de app wordt ingeschaald en uitgeschaald:
- Het minimale aantal exemplaren van de functie-app is drie.
- Wanneer u een capaciteit opgeeft die groter is dan drie, worden de exemplaren gelijkmatig verdeeld wanneer de capaciteit een veelvoud van 3 is.
- Voor een capaciteitswaarde van meer dan 3*N worden extra exemplaren verdeeld over de resterende of twee zones.
Belangrijk
Azure Functions kan worden uitgevoerd op het Azure-app Service-platform. In het App Service-platform worden plannen die functie-apps voor Premium-abonnementen hosten aangeduid als Elastic Premium-abonnementen, met SKU-namen zoals EP1. Als u ervoor kiest om uw functie-app uit te voeren op een Premium-abonnement, moet u een plan maken met een SKU-naam die begint met 'E', zoals EP1. SKU-namen van App Service-plannen die beginnen met 'P', zoals P1V2 (Premium V2 Small-abonnement), zijn eigenlijk Toegewezen hostingabonnementen. Omdat ze Toegewezen en niet Elastic Premium zijn, worden abonnementen met SKU-namen die beginnen met 'P' niet dynamisch geschaald en kunnen uw kosten worden verhoogd.
Regionale beschikbaarheid
Zone-redundante Premium-abonnementen zijn beschikbaar in de volgende regio's:
| Noord- en Zuid-Amerika | Europa | Midden-Oosten | Afrika | Azië en Stille Oceaan |
|---|---|---|---|---|
| Brazilië - zuid | Frankrijk - centraal | Israël - centraal | Zuid-Afrika - noord | Australië - oost |
| Canada - midden | Duitsland - west-centraal | Qatar - centraal | India - centraal | |
| Central US | Italië - noord | VAE - noord | China - noord 3 | |
| VS - oost | Europa - noord | Azië - oost | ||
| VS - oost 2 | Noorwegen - oost | Japan East | ||
| VS - zuid-centraal | Zweden - centraal | Azië - zuidoost | ||
| VS - west 2 | Zwitserland - noord | |||
| US - west 3 | Verenigd Koninkrijk Zuid | |||
| Europa -west |
Vereisten
Ondersteuning voor beschikbaarheidszones is een eigenschap van het Premium-abonnement. Hier volgen de huidige vereisten/beperkingen voor het inschakelen van beschikbaarheidszones:
- U kunt beschikbaarheidszones alleen inschakelen bij het maken van een Premium-abonnement voor uw functie-app. U kunt een bestaand Premium-abonnement niet converteren om beschikbaarheidszones te gebruiken.
- U moet een zone-redundant opslagaccount (ZRS) gebruiken voor het opslagaccount van uw functie-app. Als u een ander type opslagaccount gebruikt, kan Functions onverwacht gedrag vertonen tijdens een zonegebonden storing.
- Zowel Windows als Linux worden ondersteund.
- Moet worden gehost op een Elastic Premium - of Dedicated-hostingabonnement. Zie App Service migreren naar ondersteuning voor beschikbaarheidszones voor meer informatie over het gebruik van zoneredundantie met een toegewezen plan.
- Ondersteuning voor beschikbaarheidszones is momenteel niet beschikbaar voor functie-apps in verbruiksabonnementen .
- Functie-apps die worden gehost in een Premium-abonnement, moeten minimaal drie exemplaren hebben die altijd gereed zijn.
- Het platform dwingt dit minimumaantal achter de schermen af als u minder dan drie exemplaren opgeeft.
- Als u geen Premium-abonnement of een schaaleenheid gebruikt die beschikbaarheidszones ondersteunt, zich in een niet-ondersteunde regio bevindt of niet zeker weet, raadpleegt u de migratierichtlijnen.
Prijzen
Er zijn geen extra kosten verbonden aan het inschakelen van beschikbaarheidszones. Prijzen voor een zoneredundant Premium App Service-plan zijn hetzelfde als een Premium-abonnement met één zone. Voor elk App Service-plan dat u gebruikt, worden er kosten in rekening gebracht op basis van de SKU die u kiest, de capaciteit die u opgeeft en alle instanties die u schaalt op basis van uw criteria voor automatische schaalaanpassing. Als u beschikbaarheidszones inschakelt, maar een capaciteit opgeeft die kleiner is dan drie voor een App Service-plan, dwingt het platform een minimumaantal exemplaren van drie af voor dat App Service-plan en worden er kosten in rekening gebracht voor deze drie exemplaren.
Een zone-redundant Premium-plan en -functie-app maken
Er zijn momenteel twee manieren om een zone-redundant Premium-abonnement en functie-app te implementeren. U kunt Azure Portal of een ARM-sjabloon gebruiken.
Open Azure Portal en navigeer naar de pagina Functie-app maken. Hier vindt u informatie over het maken van een functie-app in de portal.
Vul op de pagina Basisinformatie de velden voor uw functie-app in. Let vooral op de velden in de onderstaande tabel (ook gemarkeerd in de onderstaande schermafbeelding), met specifieke vereisten voor zoneredundantie.
Instelling Voorgestelde waarde Opmerkingen voor zoneredundantie Regio Voorkeursregio Het abonnement waarmee deze nieuwe functie-app is gemaakt. U moet een regio kiezen waarvoor een beschikbaarheidszone is ingeschakeld in de bovenstaande lijst. 
Vul op de pagina Hosting de velden in voor het hostingabonnement van uw functie-app. Let vooral op de velden in de onderstaande tabel (ook gemarkeerd in de onderstaande schermafbeelding), met specifieke vereisten voor zoneredundantie.
Instelling Voorgestelde waarde Opmerkingen voor zoneredundantie Opslagaccount Een zone-redundant opslagaccount Zoals hierboven vermeld in de sectie Vereisten , raden we u ten zeerste aan een zone-redundant opslagaccount te gebruiken voor uw zone-redundante functie-app. Abonnemtsype Functions Premium In dit artikel wordt beschreven hoe u een zoneredundante app maakt in een Premium-abonnement. Zoneredundantie is momenteel niet beschikbaar in verbruiksabonnementen. In dit artikel vindt u informatie over zoneredundantie in App Service-plannen. Zoneredundantie Ingeschakeld In dit veld wordt de vlag ingevuld die bepaalt of uw app zone-redundant is of niet. U kunt deze optie alleen selecteren Enabledals u een regio hebt gekozen die zoneredundantie ondersteunt, zoals vermeld in stap 2.
Voor de rest van het proces voor het maken van de functie-app maakt u uw functie-app als normaal. Er zijn geen velden in de rest van het aanmaakproces die van invloed zijn op zoneredundantie.
Nadat het zone-redundante plan is gemaakt en geïmplementeerd, wordt elke functie-app die wordt gehost in uw nieuwe plan beschouwd als zone-redundant.
Migratie van beschikbaarheidszone
Azure Function Apps biedt momenteel geen ondersteuning voor in-place migratie van bestaande functie-apps-exemplaren. Zie App Service migreren naar ondersteuning voor beschikbaarheidszones voor informatie over het migreren van het openbare Premium-abonnement met meerdere tenants van een niet-beschikbaarheidszone naar ondersteuning voor beschikbaarheidszones.
Zone-down-ervaring
Alle beschikbare functie-app-exemplaren van zone-redundante functie-apps zijn ingeschakeld en verwerken gebeurtenissen. Wanneer een zone uitvalt, detecteert Functions verloren exemplaren en probeert functies automatisch nieuwe vervangende exemplaren te vinden, indien nodig. Gedrag van elastische schaal is nog steeds van toepassing. In een zone-down scenario is er echter geen garantie dat aanvragen voor extra exemplaren kunnen slagen, omdat verloren exemplaren opnieuw worden ingevuld op basis van best effort. Toepassingen die zijn geïmplementeerd in een Premium-abonnement voor een beschikbaarheidszone, blijven actief, zelfs wanneer er in andere zones in dezelfde regio een storing optreedt. Het is echter mogelijk dat niet-runtimegedrag nog steeds wordt beïnvloed door een storing in andere beschikbaarheidszones. Dit beïnvloede gedrag kan bestaan uit het schalen van Premium-abonnementen, het maken van toepassingen, het configureren van toepassingen en het publiceren van toepassingen. Zoneredundantie voor Premium-abonnementen garandeert alleen een continue uptime voor geïmplementeerde toepassingen.
Wanneer Functions exemplaren toewijst aan een zoneredundant Premium-abonnement, wordt gebruikgemaakt van zoneverdeling met de beste inspanningszone die wordt aangeboden door de onderliggende Virtuele-machineschaalsets van Azure. Een Premium-abonnement wordt als evenwichtig beschouwd wanneer elke zone hetzelfde aantal VIRTUELE machines (± 1 VM) heeft in alle andere zones die door het Premium-abonnement worden gebruikt.
Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's
Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.
Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.
In deze sectie worden enkele strategieën beschreven die u kunt gebruiken om Functies te implementeren om herstel na noodgevallen mogelijk te maken.
Herstel na noodgevallen voor meerdere regio's
Omdat er geen ingebouwde redundantie beschikbaar is, worden functies uitgevoerd in een functie-app in een specifieke Azure-regio. Om verlies van uitvoering tijdens storingen te voorkomen, kunt u dezelfde functies redundant implementeren in functie-apps in meerdere regio's. Zie de richtlijnen in de webtoepassing met hoge beschikbaarheid voor meerdere regio's voor meer informatie over implementaties in meerdere regio's.
Wanneer u dezelfde functiecode uitvoert in meerdere regio's, zijn er twee patronen om rekening mee te houden, actief-actief en actief-passief.
Actief-actief patroon voor HTTP-triggerfuncties
Met een actief-actief patroon worden functies in beide regio's actief uitgevoerd en verwerkt ze op een dubbele manier of in rotatie. Het is raadzaam om een actief-actief patroon te gebruiken in combinatie met Azure Front Door voor uw kritieke door HTTP geactiveerde functies, die HTTP-aanvragen kunnen routeren en round robin-AANVRAGEN tussen functies die in meerdere regio's worden uitgevoerd. Front door kan ook periodiek de status van elk eindpunt controleren. Wanneer een functie in één regio niet meer reageert op statuscontroles, haalt Azure Front Door deze uit de rotatie en stuurt het verkeer alleen door naar de resterende gezonde functies.
Belangrijk
Hoewel het raadzaam is om het actief-passieve patroon te gebruiken voor niet-HTTPS-triggerfuncties. U kunt actief-actieve implementaties maken voor niet-HTTP-geactiveerde functies. U moet echter overwegen hoe de twee actieve regio's met elkaar communiceren of coördineren. Wanneer u dezelfde functie-app implementeert in twee regio's waarbij elke app wordt geactiveerd in dezelfde Service Bus-wachtrij, fungeren ze als concurrerende consumenten bij het ongedaan maken van de wachtrij. Dit betekent dat elk bericht slechts door een van de exemplaren wordt verwerkt, maar dat betekent ook dat er nog steeds een single point of failure is op het enkele Service Bus-exemplaar.
U kunt in plaats daarvan twee Service Bus-wachtrijen implementeren, met één in een primaire regio, één in een secundaire regio. In dit geval kunt u twee functie-apps hebben, waarbij elk ervan wees naar de Service Bus-wachtrij die actief is in hun regio. De uitdaging met deze topologie is hoe de wachtrijberichten worden verdeeld tussen de twee regio's. Dit betekent vaak dat elke uitgever probeert een bericht naar beide regio's te publiceren en dat elk bericht wordt verwerkt door beide actieve functie-apps. Hoewel hiermee het gewenste actieve/actieve patroon wordt gemaakt, ontstaan er ook andere uitdagingen met betrekking tot duplicatie van rekenkracht en wanneer of hoe gegevens worden geconsolideerd.
Actief-passief patroon voor niet-HTTPS-triggerfuncties
Het wordt aanbevolen om een actief-passief patroon te gebruiken voor uw gebeurtenisgestuurde, niet-HTTP-geactiveerde functies, zoals door Service Bus en Event Hubs geactiveerde functies.
Als u redundantie wilt maken voor niet-HTTP-triggerfuncties, gebruikt u een actief-passief patroon. Met een actief-passief patroon worden functies actief uitgevoerd in de regio die gebeurtenissen ontvangt; terwijl dezelfde functies in een tweede regio inactief blijven. Het actief-passieve patroon biedt een manier voor slechts één functie om elk bericht te verwerken en tegelijkertijd een mechanisme te bieden voor een failover naar de secundaire regio in een noodgeval. Functie-apps werken met het failovergedrag van de partnerservices, zoals Azure Service Bus geo-herstel en Azure Event Hubs geo-herstel.
Bekijk een voorbeeldtopologie met behulp van een Azure Event Hubs-trigger. In dit geval vereist het actieve/passieve patroon de volgende onderdelen:
- Azure Event Hubs geïmplementeerd in zowel een primaire als een secundaire regio.
- Geo-noodgeval ingeschakeld om de primaire en secundaire Event Hubs te koppelen. Hiermee maakt u ook een alias die u kunt gebruiken om verbinding te maken met Event Hubs en over te schakelen van primair naar secundair zonder de verbindingsgegevens te wijzigen.
- Functie-apps worden geïmplementeerd in zowel de primaire als de secundaire regio (failover), waarbij de app in de secundaire regio in feite niet actief is omdat er geen berichten worden verzonden.
- Functie-app-triggers op de directe (niet-alias) verbindingsreeks voor de respectieve Event Hub.
- Uitgevers naar de Event Hub moeten publiceren naar de alias verbindingsreeks.
Voordat een failover wordt uitgevoerd, 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 de failover is gestart, worden uitgevers die naar de gedeelde alias verzenden, doorgestuurd naar de secundaire Event Hub. De secundaire functie-app wordt nu actief en wordt automatisch geactiveerd. Effectieve failover naar een secundaire regio kan volledig worden aangestuurd vanuit de Event Hub, waarbij de functies alleen actief worden wanneer de respectieve Event Hub actief is.
Lees meer over informatie en overwegingen voor failover met Service Bus en Event Hubs.