Delen via

Betrouwbaarheid in Azure Functions

Azure Functions is een gebeurtenisgestuurde rekenservice waarmee u kleine codeblokken (functies) kunt uitvoeren zonder expliciet infrastructuur in te richten of te beheren. Functies kunnen reageren op gebeurtenissen zoals HTTP-aanvragen, timers, wachtrijberichten en wijzigingen in andere Azure-services, waardoor deze goed geschikt zijn voor het verwerken van gegevens, het integreren van systemen en het uitvoeren van 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 Azure Functions bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, fouten in beschikbaarheidszones en regiobrede fouten. Ook wordt belangrijke informatie over de Service Level Agreement (SLA) van Azure Functions uitgelicht.

Aanbevelingen voor productie-implementatie

Het Azure Well-Architected Framework biedt aanbevelingen voor betrouwbaarheid, prestaties, beveiliging, kosten en bewerkingen. Als u wilt weten hoe deze gebieden elkaar beïnvloeden en bijdragen aan een betrouwbare Azure Functions-oplossing, raadpleegt u best practices voor Architectuur voor Azure Functions.

Overzicht van betrouwbaarheidsarchitectuur

Wanneer u Azure Functions implementeert, is het belangrijk dat u bekend bent met verschillende 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 wordt gebruikt voor het beheren van aspecten van de interne bewerkingen van de functie-app, waaronder opslag van functiecode, logboekregistratie en gelijktijdigheidsbeheer (zoals blob-leases voor bepaalde triggertypen).

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

    Belangrijk

    De opslagaccounts zijn essentiële onderdelen van uw Azure Functions-betrouwbaarheidsarchitectuur en u moet deze configureren om te voldoen aan de tolerantievereisten van uw functie-app.

  • Triggers en bindingen: hiermee kan uw functie reageren op gebeurtenissen, ontvangen en schrijven van andere services.

  • Durable Functions: Duurzame functies zijn stateful functies, waaronder langlopende indelingen en stateful entiteiten.

    Wanneer u Durable Functions gebruikt, configureert u een opslagprovider, waarin de status wordt opgeslagen. U moet de betrouwbaarheidskenmerken van het door u gekozen statusarchief evalueren en configureren 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 Azure Functions-platform bevat ingebouwde tijdelijke foutafhandeling voor veel triggers en bindingen. Wanneer er 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 helpt ervoor te zorgen dat tijdelijke verbindingsproblemen of service-blip's niet verhinderen dat uw functie wordt uitgevoerd. Zie Azure Functions-foutafhandeling en nieuwe pogingen voor meer informatie.

    Deze beveiliging omvat echter alleen tijdelijke fouten. Permanente fouten, zoals een onjuist geconfigureerde verbindingsreeks of een verwijderde resource, worden niet opnieuw geprobeerd.

    Permanente fouten en herhaalde tijdelijke fouten worden behandeld als fouten en u kunt logboekregistratie configureren om informatie over fouten bij de uitvoering van functies vast te leggen. Zie De bewaking configureren voor Azure Functions voor meer informatie.

  • Uw functiecode: Binnen de hoofdtekst van uw functie bent u verantwoordelijk voor het afhandelen van tijdelijke fouten wanneer u aanroepen doet naar externe services. U moet logica voor nieuwe pogingen, time-outs en circuitonderbrekerpatronen implementeren, indien van toepassing op eventuele externe service-aanroepen in uw functiecode. Ontwerp waar mogelijk uw functies als idempotent, zodat nieuwe pogingen geen dubbele bijwerkingen veroorzaken.

  • Clients: Clienttoepassingen die synchroon verbinding maken met functies, zoals met behulp van 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 typen Flex Consumption-abonnementen, Premium-abonnementen of Toegewezen (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 ook zone-redundante opslag (ZRS) inschakelen in het hostopslagaccount, waardoor het ook bestand is tegen zonestoringen.

Diagram met een zone-redundant Azure Functions-plan met drie exemplaren verspreid over drie zones en een zone-redundant opslagaccount.

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 Betrouwbaarheid in Azure App Service voor meer informatie over hoe App Service zoneredundantie verwerkt.

Als u zoneredundantie niet inschakelt, is uw plan niet-zonegebonden of regionaal, wat betekent dat planexemplaren mogelijk in een beschikbaarheidszone binnen de regio of binnen dezelfde zone worden geplaatst en dat ze niet bestand zijn tegen storingen in de beschikbaarheidszone. Uw plan kan downtime ondervinden tijdens een storing in elke zone in de regio.

Requirements

  • Regioondersteuning: Zone-redundante Flex Consumption-abonnementen kunnen worden geïmplementeerd 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: Zone-redundante Premium-abonnementen kunnen worden geïmplementeerd 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

  • Besturingssystemen: Zowel Windows- als Linux-abonnementen worden ondersteund.

  • Minimumaantal exemplaren: Er zijn minimaal twee altijd gereede exemplaren vereist wanneer zoneredundantie is ingeschakeld voor Premium-abonnementen.

  • Opslagaccount voor implementatiecontainer: Als u een afzonderlijk opslagaccount gebruikt voor de implementatiecontainer van de app, moet u deze ook bijwerken naar zone-redundant.

Overwegingen

Zoneredundantie garandeert alleen een continue uptime voor geïmplementeerde toepassingen. Een storing in de beschikbaarheidszone kan van invloed zijn op bepaalde aspecten van Azure Functions, ook al blijft de toepassing verkeer leveren. 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 tussen 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 op round robin-wijze.

    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. Alle exemplaren die door het platform worden gemaakt, worden door het platform beheerd, gefactureerd als altijd gereede exemplaren en wijzigen de altijd gereede configuratie-instellingen niet.

  • On-demand instanties worden gemaakt als gevolg van volumes van gebeurtenisbronnen, als de app verder opschaalt dan het aantal altijd beschikbare instanties. Exemplaren op aanvraag worden gedistribueerd tussen beschikbaarheidszones op basis van best effort. Snellere uitschaling krijgt prioriteit boven gelijkmatige verdeling tussen zones. Het platform streeft ernaar om de verdeling in de tijd te egaliseren.

Wanneer u Premium elastische functie-app-abonnementen configureert om zone-redundant te zijn, verspreidt het platform exemplaren van het plan 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 de exemplaren gelijkmatig verdeeld wanneer de capaciteit een veelvoud is van het aantal zones.
  • Voor een capaciteitswaarde die groter is dan aantal zones * Aantal exemplaren, worden extra exemplaren verdeeld over de resterende zones.

Wanneer Functions exemplaren toewijst aan een zoneredundant Premium-abonnement, wordt gebruikgemaakt van best-effort zonebalancering, die de onderliggende Azure Virtual Machine Scale Sets biedt. Een Premium-abonnement wordt als evenwichtig beschouwd wanneer elke zone hetzelfde aantal virtuele machines heeft in alle andere zones die worden gebruikt door het Premium-abonnement, plus-of-min-één virtuele machine.

Cost

Er zijn geen extra kosten verbonden aan het inschakelen van zoneredundantie. Prijzen voor een zone-redundant plan zijn hetzelfde als een abonnement met één zone.

Wanneer u echter beschikbaarheidszones inschakelt in een app met een altijd gereed exemplaarconfiguratie van minder dan twee exemplaren voor elke functie voor schaalaanpassing 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 echter beschikbaarheidszones inschakelt voor een plan 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 Azure Functions voor volledige prijsinformatie.

Ondersteuning voor beschikbaarheidszones configureren

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

  • 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. U moet uw app in plaats daarvan migreren door een parallelle implementatie te maken op een nieuwe app met 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 een storing ondervinden.

Tijdens een zonestoring detecteert Azure Functions verloren exemplaren en probeert automatisch vervangingsexemplaren te vinden of te maken in de zones die in orde zijn. Dit proces wordt op basis van best effort uitgevoerd en wordt niet gegarandeerd. Als uw workload een bepaald aantal instanties moet hebben om uw verwachte serviceniveau te behouden, kunt u overwegen om het aantal altijd gereed instanties over te voorzien. Met deze aanpak kan de oplossing enige capaciteitsverlies tolereren en blijven werken zonder verslechterde 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 een plan zone-redundant is, het hostopslagaccount ZRS gebruikt en alle beschikbaarheidszones operationeel zijn.

  • Bewerking tussen zones: Wanneer u zoneredundantie configureert in Azure Functions, 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: Azure Functions is een stateless compute-service, dus er zijn geen klantgegevens 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.

    Voor Durable Functions controleert u uw opslagprovider om te begrijpen hoe gegevens in verschillende zones worden gerepliceerd.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een plan zone-redundant is, het hostopslagaccount gebruikmaakt van ZRS en er een storing in de beschikbaarheidszone is.

  • Detectie en reactie: Het Azure Functions-platform 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 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 alle aanvragen die worden uitgevoerd die zijn verbonden 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: Er wordt niet verwacht dat zonefouten gegevensverlies veroorzaken omdat Azure Functions een staatloze service is.

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

    Raadpleeg voor Durable Functions uw opslagprovider om te begrijpen 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: Azure Functions detecteert de verloren exemplaren uit die zone en probeert nieuwe vervangingsexemplaren te vinden. Nadat Azure Functions vervangingen heeft gevonden, wordt verkeer naar behoefte verdeeld over de nieuwe exemplaren.

    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 over-inrichten.

  • 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 herstelt, herstelt Azure Functions automatisch de exemplaren in de beschikbaarheidszone, verwijdert de tijdelijke exemplaren die in de andere beschikbaarheidszones zijn gemaakt, en leidt het verkeer tussen uw exemplaren weer normaal om.

Testen op zonefouten

Het Azure Functions-platform beheert verkeersroutering, failover en zoneherstel voor zone-redundante resources. U hoeft niets te initiëren. Omdat deze functie volledig wordt beheerd, hoeft u de foutprocessen van de beschikbaarheidszone niet te valideren.

Tolerantie voor storingen in de hele regio

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

Aangepaste oplossingen voor meerdere regio's voor veerkracht

Om verlies van uitvoering tijdens storingen te voorkomen, kunt u dezelfde functies redundant implementeren in 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, zijn er twee veelgebruikte patronen die u kunt overwegen: actief-actief en actief-passief. De volgende secties bevatten een korte inleiding tot deze patronen, maar bieden geen gedetailleerde richtlijnen of configuratiestappen.

Actief-actief patroon voor HTTP-triggerfuncties

Met een actief-actief patroon worden functies in beide regio's actief uitgevoerd en verwerken ze gebeurtenissen, hetzij op een dubbele manier, hetzij in rotatie. U moet een actief-actief patroon gebruiken in combinatie met Azure Front Door voor uw kritieke HTTP-geactiveerde functies, die HTTP-aanvragen kunnen routeren en in een round-robin verdelen tussen functies die in meerdere regio's worden uitgevoerd. Azure Front Door kan ook periodiek de status van elk eindpunt controleren. Als een functie in één regio niet meer reageert op statuscontroles, haalt Azure Front Door deze uit roulatie en stuurt het verkeer alleen door naar de resterende gezonde functies.

Diagram van een voorbeeld van een actief-actief-architectuur met Azure Front Door-routering tussen Azure Functions-apps in verschillende regio's, elk met hun eigen database.

Actief-passief patroon voor niet-HTTP-triggerfuncties

Gebruik een actief-passief patroon voor niet-HTTP-geactiveerde functies, zoals functies die geactiveerd worden door Service Bus en Event Hubs. 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 voor het verwerken van elk bericht, wat belangrijk is voor het onderhouden van gegevensconsistentie, terwijl ook een mechanisme wordt geboden voor een failover naar de secundaire regio in een noodgeval, zoals een storing in een regio.

De failover van de Function App moet worden overwogen samen met het failover-gedrag van andere services, zoals:

Bekijk een voorbeeldtopologie met behulp van een Azure Event Hubs-trigger, waarbij uw Event Hubs-naamruimte is geconfigureerd voor herstel na geografische noodgevallen. In dit geval vereist het actief-passieve patroon de volgende onderdelen:

  • Azure Event Hubs geïmplementeerd in zowel een primaire als een secundaire regio.
  • Geo-noodherstel is 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 de Event Hubs-naamruimte en over te schakelen van primair naar secundair zonder de verbindingsgegevens te wijzigen.
  • Functie-apps die zijn geïmplementeerd in zowel de primaire als de secundaire regio (failover), waarbij de app in de secundaire regio inactief is omdat er geen berichten worden verzonden.
  • Functie-app activeert de directe verbindingsreeks (niet-alias) voor de bijbehorende Event Hubs-naamruimte.
  • Uitgevers die publiceren naar de Event Hubs-naamruimte moeten naar de alias-verbindingsreeks publiceren.

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

Voordat een failover wordt uitgevoerd, verzenden uitgevers via 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 begint zich automatisch te activeren. 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.

Duurzame functies

Zie Herstel na noodgevallen en geografische distributie in Azure Durable Functions voor herstel na noodgevallen voor meerdere regio's voor Durable Functions.

Tolerantie voor serviceonderhoud

Azure 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-applicatie 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, wordt er een extra tolerantielaag toegevoegd als een exemplaar of zone beschadigd raakt tijdens een upgrade.

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 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 wilt valideren, schakelt u handmatige upgrades in. Met deze methode kunt u validatie en tests uitvoeren op een niet-productie-exemplaar voordat u deze 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 moet voorbereid zijn om een update terug te draaien als deze problemen veroorzaakt. U moet ook bepalen hoe updates worden geïmplementeerd om onderbrekingen van het opnieuw opstarten van toepassingen te minimaliseren.

Flex Consumption-abonnementen bieden ondersteuning voor site-updatestrategieën, die meerdere manieren bieden om uw app-updates te implementeren, inclusief rolling updates voor implementaties zonder downtime.

Azure Functions-implementatiesites maken implementaties van uw functie-apps zonder downtime mogelijk. 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 een tijdelijke fout.

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.

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

Verwante inhoud

  • Last updated on