Betrouwbaarheid in Azure Functions

Azure Functions is een gebeurtenisgestuurde rekenservice waarmee kleine codeblokken worden uitgevoerd, of functies, zonder expliciete infrastructuurinrichting of -beheer. Functies kunnen reageren op gebeurtenissen zoals HTTP-aanvragen, timers, wachtrijberichten en wijzigingen in andere Azure-services. Deze mogelijkheid maakt Functions geschikt voor gegevensverwerking, systeemintegratie en achtergrondtaken.

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 Functions bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, fouten in de beschikbaarheidszone en regiobrede fouten. Er wordt ook belangrijke informatie over de service-level agreement (SLA) voor Functions uitgelicht.

Aanbevelingen voor productie-implementatie

Het Azure Well-Architected Framework biedt aanbevelingen voor betrouwbaarheid, beveiliging, kosten, bewerkingen en prestaties. Als u wilt weten hoe deze gebieden van invloed zijn op elkaar en bijdragen aan een betrouwbare Functions-oplossing, raadpleegt u best practices voor architecturen voor Functions.

Overzicht van betrouwbaarheidsarchitectuur

Wanneer u Functions implementeert, is het belangrijk om vertrouwd te raken met deze concepten:

  • Hostingabonnementen: Plannen vertegenwoordigen de hostingomgeving voor uw functie-apps. Het plan bepaalt de beschikbare rekenresources, het prijsmodel en het schaalgedrag.

  • Opslagaccounts: Wanneer u een functie-app maakt, moet u een hostopslagaccount opgeven. Het opslagaccount beheert aspecten van interne bewerkingen van de functie-app, waaronder opslag van functiecode, logboeken en gelijktijdigheidsbeheer (zoals blob-leases voor specifieke triggertypen).

    U kunt ook een opslagaccount gebruiken voor implementatie. Dit opslagaccount is mogelijk hetzelfde als uw hostopslagaccount of een ander opslagaccount.

    Belangrijk

    Opslagaccounts vormen een essentieel onderdeel van de betrouwbaarheidsarchitectuur van Functions. Configureer deze om te voldoen aan de tolerantievereisten van uw functie-app.

  • Triggers en bindingen: Met triggers en bindingen kan uw functie reageren op gebeurtenissen, gegevens van andere services ontvangen en gegevens naar andere services schrijven.

  • Duurzame functies: Durable Functions is een functie van Functions. Het biedt stateful functies zoals langdurige orkestraties en stateful entiteiten.

    Wanneer u duurzame functies gebruikt, configureert u een opslagprovider waarin de status wordt opgeslagen. Evalueer de betrouwbaarheidskenmerken van het statusarchief dat u kiest en configureer deze om te voldoen aan uw tolerantievereisten.

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 cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Bekijk de volgende aanbevelingen voor het afhandelen van tijdelijke fouten in uw functie-apps:

  • Triggers en bindingen: Het Functions-platform bevat ingebouwde tijdelijke foutafhandeling voor triggers en bindingen. Wanneer een tijdelijke fout optreedt terwijl een ondersteunde trigger wordt geactiveerd of een ondersteunde binding gegevens leest of schrijft, kan het platform de bewerking automatisch opnieuw proberen. Dit ingebouwde gedrag voor opnieuw proberen zorgt ervoor dat tijdelijke verbindingsproblemen of serviceonderbrekingen niet verhinderen dat uw functie wordt uitgevoerd. Zie functies voor foutafhandeling en nieuwe pogingen voor meer informatie.

    Deze beveiliging omvat alleen tijdelijke fouten. Het platform probeert geen permanente fouten opnieuw uit te voeren, zoals een onjuist geconfigureerde verbindingsreeks of een verwijderde resource.

    Het platform behandelt permanente fouten en herhaalde tijdelijke fouten als fouten. Configureer logboekregistratie om informatie over fouten bij het uitvoeren van functies vast te leggen. Zie Bewaking voor Functies configureren voor meer informatie.

  • Uw functiecode: In uw functiecode bent u verantwoordelijk voor het afhandelen van tijdelijke fouten wanneer uw functie externe services aanroept. Implementeer logica voor opnieuw proberen, time-outs en, indien van toepassing, circuit breaker-patronen voor externe service-aanroepen in uw functiecode. Ontwerp uw functies zo mogelijk dat deze idempotent zijn, zodat nieuwe pogingen geen dubbele bijwerkingen veroorzaken.

  • Clients: Clienttoepassingen die synchroon verbinding maken met functies, zoals via een HTTP-verbinding, moeten bestand zijn tegen tijdelijke fouten.

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.

Verbruiksabonnementen bieden geen ondersteuning voor beschikbaarheidszones. Als zoneredundantie een vereiste is voor uw workload, kunt u overwegen om in plaats daarvan de abonnementen Flex Consumption, Premium of Dedicated (Azure App Service) te gebruiken.

Flex Consumption-abonnementen ondersteunen zone-redundante implementaties.

Premium-abonnementen bieden ondersteuning voor zone-redundante implementaties.

Wanneer zoneredundantie is ingeschakeld, verspreidt het platform uw planexemplaren automatisch over alle beschikbaarheidszones in de geselecteerde regio. Als er een beschikbaarheidszone in de regio een probleem heeft, blijven uw functies worden uitgevoerd met behulp van exemplaren in gezonde zones.

U moet zone-redundante opslag (ZRS) inschakelen in het hostopslagaccount, waardoor het ook bestand is tegen zonestoringen.

Diagram met een zone-redundant Functions-plan met drie exemplaren verdeeld over drie zones en een ZRS-account.

Het Dedicated (App Service)-plan ondersteunt zone-redundante implementaties. Wanneer zoneredundantie is ingeschakeld, verspreidt het platform uw exemplaren automatisch over alle beschikbaarheidszones in de geselecteerde regio. U configureert zoneredundantie op het plan. Zie Reliability in App Service voor meer informatie over hoe Azure App Service zoneredundantie verwerkt.

Uw plan is niet-zonegebonden of regionaal wanneer u zoneredundantie niet inschakelt. Het platform kan planinstanties plaatsen in elke beschikbaarheidszone in de regio of in dezelfde zone. Planexemplaren zijn niet bestand tegen fouten in de beschikbaarheidszone. Uw plan kan downtime ondervinden tijdens een storing in elke zone in de regio.

Requirements

  • Regioondersteuning: U kunt zone-redundante Flex Consumption-abonnementen implementeren in een specifieke set regio's. U kunt de huidige lijst met ondersteunde regio's ophalen met behulp van de Azure CLI. Zie Regio's weergeven die beschikbaarheidszones ondersteunen voor meer informatie.

  • Regioondersteuning: U kunt zone-redundante Premium-abonnementen implementeren in de volgende regio's.

    Americas Europa Midden-Oosten Africa Asia Pacific
    Brazilië Zuid Centraal Frankrijk Israël Centraal Zuid-Afrika - noord Australia East
    Canada Central West-Centraal Duitsland Qatar Central Centraal-India
    Central US Italy North VAE Noord China - noord 3
    East US Europa - noord Oost-Azië
    Oostelijke Verenigde Staten 2 Norway East Oost-Japan
    Zuid-Centraal Verenigde Staten Zweden - centraal Zuidoost-Azië
    Westelijke Verenigde Staten 2 Switzerland North
    Westelijke VS 3 UK South
    West Europe

  • Operating systems: Het platform ondersteunt het implementeren van zone-redundante Windows- en Linux-abonnementen.

  • Minimumaantal exemplaren: Zoneredundantie voor Premium-abonnementen vereist minimaal twee altijd gereede exemplaren.

  • Hostopslagaccount: U moet het standaardhostopslagaccount van uw functie-app configureren voor het gebruik van ZRS. Als u een hostopslagaccount gebruikt dat niet is geconfigureerd voor ZRS, gedraagt uw app zich mogelijk onverwacht tijdens een storing in een zone.
  • Opslagaccount voor implementatiecontainer: Als u een afzonderlijk opslagaccount gebruikt voor de implementatiecontainer van de app, moet u deze ook bijwerken naar zone-redundant.

Overwegingen

Niet-runtime gedrag: Zone-redundantie garandeert alleen een continue uptime voor geïmplementeerde toepassingen. Een storing in de beschikbaarheidszone kan van invloed zijn op aspecten van Functions, ook al blijft de toepassing verkeer bedienen. Dit gedrag omvat het plannen van schalen, het maken van toepassingen, het configureren van toepassingen en het publiceren van toepassingen.

Exemplaardistributie tussen zones

Wanneer u Flex Consumption-plan-apps configureert als zone-redundant, verspreidt het platform automatisch planexemplaren over meerdere zones in de geselecteerde regio, met verschillende regels voor always-ready versus on-demand exemplaren:

  • Altijd gereede exemplaren worden verdeeld over ten minste twee zones met behulp van round robin-distributie.

    Om zonetolerantie te garanderen, onderhoudt het platform automatisch ten minste twee altijd gereede exemplaren voor elke functie voor schaalaanpassing per functie of groep, ongeacht de altijd gereede configuratie voor de app. Exemplaren die door het platform worden gemaakt, worden beheerd door het platform, gefactureerd als altijd gereede exemplaren en wijzigen de altijd gereede configuratie-instellingen niet.

  • On-demand exemplaren zijn het resultaat van gebeurtenisbronvolumes wanneer de app wordt geschaald buiten het aantal altijd gereede exemplaren. Exemplaren op aanvraag worden gedistribueerd over beschikbaarheidszones op basis van best effort. Het platform geeft prioriteit aan het sneller vergroten van capaciteit boven een evenwichtigere verdeling over zones. Het platform streeft ernaar om de verdeling in de tijd te egaliseren.

Wanneer u elastische Premium-functie-app-abonnementen configureert als zone-redundant, verspreidt het platform planexemplaren automatisch over meerdere zones in de geselecteerde regio. De spreiding van instanties volgt deze regels, zelfs wanneer de app wordt geschaald naar boven en naar beneden:

  • Het minimumaantal exemplaren van de functieapp is twee.

  • Wanneer u een capaciteit opgeeft die groter is dan het aantal zones, worden exemplaren gelijkmatig verdeeld wanneer de capaciteit een veelvoud is van het aantal zones.

  • Voor een capaciteitswaarde die groter is dan het aantal zones vermenigvuldigd met het aantal exemplaren, worden extra exemplaren verdeeld over de resterende zones.

Wanneer Functions exemplaren toewijst aan een zone-redundant Premium-plan, maakt het gebruik van best-effort zone balancing, die door de onderliggende Azure-schaalvergrotingssets voor virtuele machines wordt aangeboden. Azure beschouwt een Premium-abonnement balanced wanneer elke zone hetzelfde aantal virtuele machines (VM's) heeft als de andere zones in het plan, plus of min één VM.

Cost

Er worden geen extra kosten in rekening gebracht wanneer u zoneredundantie inschakelt. Prijzen voor een zone-redundant plan zijn hetzelfde als een abonnement met één zone. Het inschakelen van zoneredundantie heeft wel invloed op het minimum aantal instances in uw plan.

Wanneer u beschikbaarheidszones inschakelt in een app met een altijd gereed exemplaarconfiguratie van minder dan twee exemplaren voor elke functie voor schalen per functie of groep, maakt het platform automatisch twee exemplaren van het altijd kant-en-klare type voor elke functie of groep voor schaalaanpassing per functie. Deze nieuwe exemplaren worden ook aangemerkt als altijd gereed exemplaren.

Als u beschikbaarheidszones inschakelt voor een abonnement met minder dan twee exemplaren, dwingt het platform een minimumaantal exemplaren van twee af voor dat abonnement en worden er kosten in rekening gebracht voor beide exemplaren.

Zie De prijzen van Functions voor volledige prijzen.

Ondersteuning voor beschikbaarheidszones configureren

  • Maak een nieuw zone-redundant Functions-plan. U kunt zoneredundantie inschakelen wanneer u een nieuw plan maakt. Zie Een zone-redundante functie-app maken voor meer informatie.

  • Zoneredundantie inschakelen voor een bestaand plan. U kunt beschikbaarheidszones in- of uitschakelen voor bestaande Elastic Premium-abonnementen. Elastische Premium-abonnementen hebben specifiek capaciteitsgedrag dat verschilt van Toegewezen (App Service)-abonnementen en vereist extra configuratiestappen. Zie Zoneredundantie inschakelen voor een bestaand plan voor gedetailleerde stappen.

  • Maak een nieuw zone-redundant Functions-plan. U kunt zoneredundantie inschakelen wanneer u een nieuw plan maakt. Zie Een zone-redundante functie-app maken voor meer informatie.

  • Zoneredundantie inschakelen voor een bestaand plan. Voor Premium-abonnementen kunt u zoneredundantie alleen inschakelen tijdens het maken van een plan. U kunt een bestaand Premium-abonnement niet converteren naar zone-redundant. Migreer in plaats daarvan uw app door een side-by-side-implementatie te maken binnen een Premium-abonnement. Zie Zoneredundantie inschakelen voor een bestaand plan voor meer informatie.

Capaciteitsplanning en -beheer

Zone-redundante functie-apps blijven actief, zelfs wanneer zones in de regio te maken hebben met een storing.

Tijdens een zonestoring detecteert Functions verloren gegane instanties en probeert men automatisch vervangingsexemplaren te vinden of te maken in de gezonde zones. Het platform voert dit proces uit op basis van best effort en garandeert geen succes. Als voor uw workload een specifiek aantal exemplaren is vereist om uw verwachte serviceniveau te behouden, kunt u overwegen om het aantal altijd gereede exemplaren te overprovisioneren . Met overprovisioning kan de oplossing capaciteitsverlies verdragen en zonder verminderde prestaties blijven functioneren. Zie voor meer informatie Capaciteit beheren door overprovisioning.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een plan zone-redundant is, het hostopslagaccount ZRS gebruikt en alle beschikbaarheidszones operationeel zijn.

  • Bewerking tussen zones: Wanneer u zoneredundantie op Functions configureert, worden aanvragen automatisch verspreid over de exemplaren in elke beschikbaarheidszone. Een aanvraag kan naar elke instantie in welke beschikbaarheidszone dan ook komen.

  • Replicatie van gegevens in meerdere zones: Functions is een stateless compute-service, dus er zijn geen gegevens om tussen zones te repliceren. Het platform repliceert de configuratie automatisch tussen zones.

    Als uw hostopslagaccount gebruikmaakt van ZRS, repliceert Azure Storage synchroon de gegevens in meerdere beschikbaarheidszones.

    Raadpleeg uw opslagprovider voor duurzame functies om te leren hoe gegevens in verschillende zones worden gerepliceerd.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een plan zoneredundant is, het hostopslagaccount ZRS gebruikt en er een storing in de beschikbaarheidszone is.

  • Detectie en reactie: Het Functions-platform is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone. U hoeft geen zonefailover te starten.
  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt echter Azure Resource Health gebruiken om de status van een afzonderlijke resource te controleren en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook 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: Wanneer een beschikbaarheidszone niet beschikbaar is, worden aanvragen uitgevoerd die verbinding maken met een exemplaar in de defecte beschikbaarheidszone, beëindigd en moeten ze opnieuw worden geprobeerd. Zorg ervoor dat uw toepassingen zijn voorbereid door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

  • Verwachte gegevensverlies: Zonefouten zullen naar verwachting geen gegevensverlies veroorzaken omdat Functions een staatloze service is.

    Als uw hostopslagaccount gebruikmaakt van ZRS, zorgt Storage ervoor dat er geen gegevens verloren gaan van een zonefout.

    Raadpleeg uw opslagprovider voor duurzame functies om te zien of gegevensverlies mogelijk is tijdens een zonefout.

  • Verwachte downtime: Tijdens zonestoringen kunnen verbindingen korte onderbrekingen ondervinden die doorgaans enkele seconden duren wanneer het verkeer opnieuw wordt gedistribueerd. Zorg ervoor dat uw toepassingen zijn voorbereid door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

  • Verkeer omleiden: Functies detecteert de verloren exemplaren uit die zone en probeert nieuwe vervangingsexemplaren te vinden. Nadat Functions vervangingen heeft gevonden, wordt verkeer, indien nodig, over de nieuwe instanties verdeeld.

    Belangrijk

    Azure garandeert niet dat aanvragen voor meer exemplaren slagen in een zone-down scenario. Het platform probeert verloren gevallen naar beste kunnen opnieuw in te vullen. Als u gegarandeerde capaciteit nodig hebt tijdens een storing in de beschikbaarheidszone, maakt en configureert u uw plannen om rekening te houden met zoneverlies door de capaciteit te overprovisioneren.

  • Niet-uitgevoerd gedrag: Toepassingen in een zoneredundante functie-app-plan blijven actief en verwerken verkeer, zelfs als een beschikbaarheidszone een storing ondervindt. Gedragingen buiten de runtime kunnen echter worden beïnvloed tijdens een storing in de beschikbaarheidszone. Dit gedrag omvat het schalen van functie-apps, het maken van toepassingen, het configureren van toepassingen en het publiceren van toepassingen.

Zoneherstel

Wanneer de beschikbaarheidszone is hersteld, herstelt Functions automatisch de exemplaren in de beschikbaarheidszone, verwijdert de tijdelijke exemplaren die zijn gemaakt in de andere beschikbaarheidszones en leidt het verkeer tussen uw exemplaren weer normaal om.

Testen op zonefouten

Het Functions-platform beheert verkeersroutering, failover en zoneherstel voor zone-redundante resources. U hoeft niets te initiëren. Azure deze functie volledig beheert, hoeft u dus geen foutenprocessen in de beschikbaarheidszone te valideren.

Tolerantie voor storingen in de hele regio

Functions is een service met één regio. Als de regio niet meer beschikbaar is, is uw Functions-resource ook niet beschikbaar.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

Om onderbrekingen van uw service tijdens storingen in de hele regio te voorkomen, kunt u dezelfde functies redundant implementeren voor functie-apps in meerdere regio's.

U bent verantwoordelijk voor:

  • Functie-apps implementeren in meerdere regio's.

  • Verkeersdistributie tussen regio's beheren.

  • Failovermechanismen implementeren.

  • Gegevensconsistentie tussen regio's garanderen (indien van toepassing).

  • Implementaties in meerdere regio's bewaken en beheren.

Wanneer u dezelfde functiecode uitvoert in meerdere regio's, moet u rekening houden met de actief-actief- en actief-passieve patronen. In de volgende secties worden deze patronen geïntroduceerd, maar bieden geen gedetailleerde richtlijnen of configuratiestappen.

Actief-actief patroon voor HTTP-triggerfuncties

In een actief-actief patroon worden functies in beide regio's actief uitgevoerd en worden gebeurtenissen verwerkt, hetzij op een duplicerende manier of in rotatie. Gebruik een actief-actief patroon in combinatie met Azure Front Door voor uw kritieke HTTP-geactiveerde functies. Deze kunnen HTTP-aanvragen routeren en round-robin verdelen tussen functies die in meerdere regio's draaien. Azure Front Door kan ook periodiek de status van elk eindpunt controleren. Als een functie in één regio niet meer reageert op statuscontroles, Azure Front Door deze uit rotatie verwijdert en alleen verkeer doorstuurt naar de resterende gezonde functies.

Diagram met een voorbeeld van een active-active-architectuur. Azure Front Door verzorgt het routen naar Functions-apps in verschillende regio's, die elk hun eigen database hebben.

Actief-passief patroon voor niet-HTTP-triggerfuncties

Gebruik een actief-passief patroon voor gebeurtenisgestuurde, niet-HTTP-geactiveerde functies (zoals Azure Service Bus en Azure Event Hubs triggers). In een actief-passief patroon worden functie-exemplaren uitgevoerd in de regio die gebeurtenissen ontvangt, terwijl de exemplaren in de secundaire regio inactief blijven. Dit patroon zorgt ervoor dat slechts één functie elk bericht verwerkt, waardoor gegevensconsistentie behouden blijft. Het biedt ook een manier om een failover naar de secundaire regio uit te voeren tijdens een noodgeval, zoals een storing in de regio.

Overweeg failover van functie-apps samen met het failovergedrag van andere services die u gebruikt, zoals:

Bekijk een voorbeeldtopologie die gebruikmaakt van een Event Hubs-trigger, waarbij uw Event Hubs-naamruimte is geconfigureerd voor herstel na geo-noodgeval. In dit geval vereist het actief-passieve patroon de volgende onderdelen:

  • Event Hubs-naamruimten die zijn geïmplementeerd in zowel een primaire als een secundaire regio.

  • Geo-noodherstel is ingeschakeld om de primaire en secundaire Event Hubs te koppelen. Met deze configuratie wordt ook een alias gemaakt die u kunt gebruiken om verbinding te maken met de Event Hubs-naamruimte en de alias over te schakelen van de primaire naar de secundaire, zonder dat de verbindingsgegevens worden gewijzigd.

  • Functionaliteitsapps geplaatst in zowel de primaire als de secundaire regio. De app in de secundaire regio blijft inactief omdat er geen berichten worden ontvangen.

  • De triggers van elke functie-app gebruiken de direct (nonalias) verbindingsreeks voor de bijbehorende Event Hubs-naamruimte.

  • Uitgevers voor de Event Hubs-naamruimte publiceren naar de alias verbindingsreeks.

Diagram met een voorbeeld van een actief-passieve architectuur. Event Hubs geo-noodherstel omvat meerdere regio's en afzonderlijke functie-apps en databases in elke regio.

Voordat een failover wordt uitgevoerd, sturen uitgevers die gebeurtenissen verzenden naar de gedeelde alias, het verkeer door naar de primaire event hub. De primaire functie-app luistert uitsluitend naar de primaire Event Hub. De secundaire functie-app blijft passief en inactief.

Wanneer de failover wordt gestart, worden uitgevers die gebeurtenissen naar de gedeelde alias verzenden, doorgestuurd naar de secundaire Event Hub. De secundaire functie-app wordt actief en wordt automatisch geactiveerd. De Event Hub kan het hele failoverproces aandrijven en elke functie-app wordt alleen uitgevoerd wanneer de bijbehorende Event Hub actief is.

Duurzame functies

Zie Disaster recovery and geo-distribution in Azure durable functions voor herstel na noodgevallen voor meerdere regio's voor duurzame functies.

Tolerantie voor serviceonderhoud

Functions voert reguliere service-upgrades en andere onderhoudstaken uit.

  • Tijdelijke fouttolerantie: Tijdens het onderhoud van de service kunnen de exemplaren waarop uw functie-app wordt uitgevoerd, opnieuw worden opgestart of tijdelijke onderbrekingen ondervinden. Zorg ervoor dat clienttoepassingen die communiceren met uw functie-app bestand zijn tegen tijdelijke fouten.
  • Zoneredundantie inschakelen: Wanneer u zoneredundantie voor uw plan inschakelt, verbetert u ook de tolerantie tijdens platformupdates. Door meerdere exemplaren in uw plan te implementeren en zoneredundantie voor uw plan in te schakelen, voegt u een extra tolerantielaag toe als een exemplaar of een zone beschadigd raakt tijdens een upgrade.

  • Extra tijdelijke instanties: Om uw verwachte capaciteit tijdens een upgrade te behouden, voegt het platform automatisch extra exemplaren van het plan toe tijdens het upgradeproces.

  • Zoneredundantie inschakelen: Wanneer u zoneredundantie voor uw plan inschakelt, verbetert u ook de tolerantie tijdens platformupdates. Updatedomeinen bestaan uit verzamelingen vm's die offline gaan tijdens een update en die worden toegewezen aan beschikbaarheidszones. Door meerdere exemplaren in uw plan te implementeren en zoneredundantie voor uw plan in te schakelen, wordt er een extra tolerantielaag toegevoegd als een exemplaar of een zone beschadigd raakt tijdens een upgrade.

  • App Service Environment: Als u uw functie-app host in een App Service Environment, kunt u de upgradecyclus aanpassen. Als u het effect van upgrades op uw workload moet valideren, schakelt u handmatige upgrades in. Gebruik deze methode om een niet-productie-exemplaar te valideren en te testen voordat u de upgrades toepast op uw productie-exemplaar.

    Zie Upgradevoorkeuren voor gepland onderhoud in App Service Environment voor meer informatie over onderhoudsvoorkeuren.

Tolerantie voor toepassingsimplementaties

Toepassingsimplementaties veroorzaken het risico op problemen in een productieomgeving. U kunt een update terugdraaien als deze problemen veroorzaakt. Bepalen hoe updates worden geïmplementeerd om onderbreking van het opnieuw opstarten van toepassingen te verminderen.

Flex Consumption-abonnementen ondersteunen strategieën voor site-updates, die meerdere manieren bieden om uw app-updates te implementeren. Deze strategieën omvatten rolling updates voor implementaties zonder downtime.

Met implementatiesleuven kunt u implementaties van uw functie-apps zonder downtime uitvoeren. Gebruik implementatieslots om het effect van implementaties en configuratiewijzigingen voor uw gebruikers te minimaliseren. Implementatiesites verminderen ook de kans dat uw toepassing opnieuw wordt opgestart. Het opnieuw opstarten van de toepassing veroorzaakt tijdelijke fouten.

Diensteniveau-overeenkomst

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.

Functions biedt afzonderlijke beschikbaarheidS-SLA's voor het verbruiksabonnement en voor andere abonnementstypen.

Verwante inhoud

  • Last updated on