Premium-plan voor Azure Functions
Het Azure Functions Elastic Premium-abonnement is een hostingoptie voor dynamische schaal voor functie-apps. Zie het artikel over hostingabonnementen voor andere opties voor hostingabonnementen.
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 hostingplannen. 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.
Hosting van Premium-plannen biedt de volgende voordelen voor uw functies:
- Vermijd koude start met warme exemplaren.
- Virtuele netwerkconnectiviteit.
- Ondersteunt langere runtimeduur.
- Keuze uit Premium-exemplaargrootten.
- Voorspelbarere prijzen, vergeleken met het Verbruiksabonnement.
- High-density-app-toewijzing voor plannen met meerdere functie-apps.
Wanneer u het Premium-abonnement gebruikt, worden exemplaren van de Azure Functions-host toegevoegd en verwijderd op basis van het aantal binnenkomende gebeurtenissen, net zoals het Verbruiksabonnement. Meerdere functie-apps kunnen worden geïmplementeerd in hetzelfde Premium-abonnement en met het plan kunt u de grootte van het rekenproces, de basisplangrootte en de maximale abonnementsgrootte configureren.
Billing
De facturering voor het Premium-plan is gebaseerd op het aantal kernseconden en het toegewezen geheugen binnen exemplaren. Deze facturering verschilt van het verbruiksabonnement, dat wordt gefactureerd op basis van resourceverbruik per seconde en uitvoeringen. Er worden geen uitvoeringskosten in rekening gebracht voor het Premium-abonnement. Deze facturering resulteert in een minimale maandelijkse kosten per actief abonnement, ongeacht of de functie actief of niet actief is. Houd er rekening mee dat alle functie-apps in een Premium-abonnement toegewezen exemplaren delen. Zie de pagina met prijzen voor Azure Functions voor meer informatie.
Notitie
Elk Premium-abonnement heeft ten minste één actief (gefactureerd) exemplaar.
Een Premium-abonnement maken
Wanneer u een functie-app maakt in Azure Portal, is het verbruiksabonnement de standaardinstelling. Als u een functie-app wilt maken die wordt uitgevoerd in een Premium-abonnement, moet u expliciet een Azure Functions Premium-hostingabonnement maken of kiezen met behulp van een van de Elastic Premium-SKU's . De functie-app die u maakt, wordt vervolgens gehost in dit plan. Met Azure Portal kunt u eenvoudig tegelijkertijd zowel het Premium-abonnement als de functie-app maken. U kunt meer dan één functie-app uitvoeren in hetzelfde Premium-abonnement, maar ze moeten beide worden uitgevoerd op hetzelfde besturingssysteem (Windows of Linux).
In de volgende artikelen ziet u hoe u programmatisch een functie-app maakt met een Premium-abonnement:
Koude start elimineren
Wanneer gebeurtenissen of uitvoeringen niet voorkomen in het verbruiksabonnement, kan uw app worden geschaald naar nul exemplaren. Wanneer er nieuwe gebeurtenissen binnenkomen, moet een nieuw exemplaar waarin uw app wordt uitgevoerd, gespecialiseerd zijn. Het specialiseren van nieuwe exemplaren kost tijd, afhankelijk van de app. Deze extra latentie bij de eerste aanroep wordt vaak 'koude start' van de app genoemd.
Premium-abonnement biedt twee functies die samenwerken om koude start in uw functies effectief te voorkomen: altijd gereede exemplaren en voorbewarmde exemplaren. Altijd gereede exemplaren zijn een categorie vooraf toegewezen exemplaren die niet worden beïnvloed door schalen en de vooraf opgewarmde exemplaren zijn een buffer wanneer u schaalt vanwege HTTP-gebeurtenissen.
Wanneer gebeurtenissen beginnen met het activeren van de app, worden ze eerst doorgestuurd naar de altijd gereede exemplaren. Naarmate de functie actief wordt vanwege HTTP-gebeurtenissen, worden andere exemplaren opgewarmd als buffer. Deze gebufferde exemplaren worden voorafwarmde exemplaren genoemd. Deze buffer vermindert de koude start voor nieuwe exemplaren die tijdens de schaal zijn vereist.
Altijd gereede exemplaren
In het Premium-abonnement kunt u ervoor zorgen dat uw app altijd gereed is voor een opgegeven aantal exemplaren. Uw app wordt continu uitgevoerd op deze exemplaren, ongeacht de belasting. Als de belasting groter is dan wat uw altijd gereede exemplaren kunnen verwerken, worden er zo nodig meer exemplaren toegevoegd, tot uw opgegeven maximum.
Deze instelling op app-niveau bepaalt ook de minimale exemplaren van uw plan. Denk bijvoorbeeld aan drie functie-apps in hetzelfde Premium-abonnement. Wanneer twee van uw apps het aantal exemplaren altijd gereed hebben ingesteld op één en in een derde instantie is dit ingesteld op vijf, is het minimumaantal voor uw hele abonnement vijf. Dit weerspiegelt ook het minimale aantal exemplaren waarvoor uw abonnement wordt gefactureerd. Het maximum aantal altijd gereede exemplaren dat per app wordt ondersteund, is 20.
U kunt het aantal altijd gereede exemplaren in Azure Portal configureren door uw functie-app te selecteren, naar het tabblad Platformfuncties te gaan en de opties voor uitschalen te selecteren. In het bewerkingsvenster van de functie-app zijn altijd gereede exemplaren specifiek voor die app.
Vooraf opgewarmde exemplaren
De instelling voor voorafwarmd aantal exemplaren biedt verwarmde exemplaren als buffer tijdens HTTP-schaal- en activeringsgebeurtenissen. Voorbewarmde exemplaren blijven bufferen totdat de maximale uitschaallimiet is bereikt. Het standaardaantal voorbewarmde exemplaren is 1 en voor de meeste scenario's moet deze waarde als 1 blijven.
Overweeg een minder gangbaar scenario, zoals een app die wordt uitgevoerd in een aangepaste container. Omdat aangepaste containers een lange opwarming hebben, kunt u overwegen deze buffer van vooraf verwarmde exemplaren te verhogen. Een voorafwarmd exemplaar wordt pas actief nadat alle actieve exemplaren in gebruik zijn.
U kunt ook een opwarmtrigger definiëren die wordt uitgevoerd tijdens het voorbereidingsproces. U kunt een opwarmtrigger gebruiken om aangepaste afhankelijkheden vooraf te laden tijdens het voorverwarmingsproces, zodat uw functies direct klaar zijn om aanvragen te verwerken. Zie de warmup-trigger van Azure Functions voor meer informatie.
Bekijk dit voorbeeld van hoe instanties die altijd gereed zijn en hoe voorafwarmde exemplaren samenwerken. Een premium-functie-app heeft twee exemplaren die altijd gereed zijn en de standaardinstelling van één voorafwarmd exemplaar.
- Wanneer de app niet actief is en er geen gebeurtenissen worden geactiveerd, wordt de app ingericht en uitgevoerd met twee exemplaren. Op dit moment wordt u gefactureerd voor de twee altijd gereede exemplaren, maar worden ze niet gefactureerd voor een voorafwarmd exemplaar, omdat er geen voorafwarmde instantie wordt toegewezen.
- Wanneer uw toepassing HTTP-verkeer ontvangt, worden aanvragen verdeeld over de twee altijd gereede exemplaren. Zodra deze twee exemplaren beginnen met het verwerken van gebeurtenissen, wordt een exemplaar toegevoegd om de vooraf inwarmde buffer te vullen. De app wordt nu uitgevoerd met drie ingerichte exemplaren: de twee altijd gereede instanties en de derde voorbewarmde en inactieve buffer. U wordt gefactureerd voor de drie instanties.
- Naarmate de belasting toeneemt en uw app meer exemplaren nodig heeft om HTTP-verkeer te verwerken, wordt die vooraf geplaatste instantie omgewisseld naar een actief exemplaar. DE HTTP-belasting wordt nu doorgestuurd naar alle drie de exemplaren en een vierde instantie wordt onmiddellijk ingericht om de vooraf gevulde buffer te vullen.
- Deze reeks schaalaanpassing en voorverwarming gaat door totdat het maximale aantal exemplaren voor de app is bereikt of dat de belasting afneemt, waardoor het platform na een periode weer wordt ingeschaald. Er worden geen exemplaren vooraf of geactiveerd buiten het maximum.
U kunt de instelling voor vooraf opgewarmde exemplaren niet wijzigen in de portal. U moet in plaats daarvan de Azure CLI of Azure PowerShell gebruiken.
Maximum aantal functie-app-exemplaren
Naast het maximale aantal burst-plannen kunt u een maximum per app configureren. Het maximum van de app kan worden geconfigureerd met behulp van de limiet voor app-schaal. De maximale limiet voor uitschalen van apps mag niet groter zijn dan de maximale burst-exemplaren van het plan.
Privénetwerkconnectiviteit
Functie-apps die zijn geïmplementeerd in een Premium-abonnement, kunnen profiteren van de integratie van virtuele netwerken voor web-apps. Wanneer deze is geconfigureerd, kan uw app communiceren met resources binnen uw virtuele netwerk of beveiligd via service-eindpunten. IP-beperkingen zijn ook beschikbaar voor de app om binnenkomend verkeer te beperken.
Wanneer u een subnet toewijst aan uw functie-app in een Premium-abonnement, hebt u een subnet met voldoende IP-adressen nodig voor elk potentieel exemplaar. We hebben een IP-blok met ten minste 100 beschikbare adressen nodig.
Zie Uw functie-app integreren met een virtueel netwerk voor meer informatie.
Snelle elastische schaal
Er worden automatisch meer rekeninstanties toegevoegd voor uw app met behulp van dezelfde snelle schaallogica als het verbruiksabonnement. Apps in hetzelfde App Service-plan worden onafhankelijk van elkaar geschaald op basis van de behoeften van een afzonderlijke app. Functions-apps in hetzelfde App Service-plan delen echter VM-resources om kosten te verlagen, indien mogelijk. Het aantal apps dat aan een VIRTUELE machine is gekoppeld, is afhankelijk van de footprint van elke app en de grootte van de VIRTUELE machine.
Zie Gebeurtenisgestuurd schalen in Azure Functions voor meer informatie over hoe schalen werkt.
Langere duur van uitvoering
Functies in een verbruiksabonnement zijn beperkt tot 10 minuten voor één uitvoering. In het Premium-abonnement wordt de duur van de uitvoering standaard ingesteld op 30 minuten om uitvoeringen van runaway te voorkomen. U kunt echter de host.json-configuratie wijzigen om de duur niet-afhankelijk te maken voor Premium-abonnements-apps, met de volgende beperkingen:
- Platformupgrades kunnen een beheerde afsluiting activeren en de uitvoering van de functie stoppen.
- Platformstoringen kunnen leiden tot een onverwerkt afsluiten en de uitvoering van de functie stoppen.
- Er is een niet-actieve timer die de werkrol na 60 minuten stopt zonder nieuwe uitvoeringen.
- Het gedrag van inschalen kan ertoe leiden dat werkrol na 60 minuten wordt afgesloten.
- Sitewisselingen kunnen uitvoeringen op de bron- en doelsites beëindigen tijdens de wissel.
Migratie
Als u een bestaande functie-app hebt, kunt u Azure CLI-opdrachten gebruiken om uw app te migreren tussen een verbruiksabonnement en een Premium-abonnement in Windows. De specifieke opdrachten zijn afhankelijk van de richting van de migratie. Zie Migratie plannen voor meer informatie.
Deze migratie wordt niet ondersteund in Linux.
Premium-abonnementsinstellingen
Wanneer u het plan maakt, zijn er twee instellingen voor de grootte van het plan: het minimale aantal exemplaren (of de plangrootte) en de maximale burstlimiet.
Als uw app exemplaren nodig heeft buiten de altijd gereede exemplaren, kan deze verder worden geschaald totdat het aantal exemplaren de maximale burstlimiet van het plan bereikt, of de maximale uitschaallimiet van de app als deze is geconfigureerd. U wordt alleen gefactureerd voor exemplaren terwijl ze worden uitgevoerd en aan u worden toegewezen, per seconde. Het platform doet er alles aan om uw app uit te schalen naar de gedefinieerde maximumlimieten.
U kunt de abonnementsgrootte en -maximumgrootten configureren in Azure Portal door de opties voor uitschalen te selecteren onder Instellingen van een functie-app die in dat plan is geïmplementeerd.
Het minimum voor elk Premium-abonnement is ten minste één exemplaar. Het werkelijke minimumaantal exemplaren wordt voor u bepaald op basis van de altijd gereede exemplaren die zijn aangevraagd door apps in het plan. Als app A bijvoorbeeld vijf exemplaren aanvraagt die altijd gereed zijn en app B twee altijd gereede exemplaren in hetzelfde plan aanvraagt, wordt de minimale abonnementsgrootte als vijf bepaald. App A wordt uitgevoerd op alle vijf en app B wordt alleen uitgevoerd op 2.
Belangrijk
Er worden kosten in rekening gebracht voor elk exemplaar dat is toegewezen in het minimumaantal exemplaren, ongeacht of functies worden uitgevoerd of niet.
In de meeste gevallen is dit automatisch berekende minimum voldoende. Het schalen van meer dan het minimum vindt echter plaats op een best effort. Het is mogelijk, hoewel onwaarschijnlijk, dat op een bepaalde tijd uitschalen kan worden vertraagd als andere exemplaren niet beschikbaar zijn. Door een minimum in te stellen dat hoger is dan het automatisch berekende minimum, reserveert u instanties voorafgaand aan uitschalen.
U kunt de minimale exemplaren in Azure Portal configureren door de opties voor uitschalen te selecteren onder Instellingen van een functie-app die in dat plan is geïmplementeerd.
Beschikbare exemplaar-SKU's
Bij het maken of schalen van uw plan kunt u kiezen uit drie exemplaargrootten. U wordt gefactureerd voor het totale aantal kernen en het ingerichte geheugen per seconde dat aan elk exemplaar wordt toegewezen. Uw app kan automatisch worden uitgebreid naar meerdere exemplaren als dat nodig is.
| SKU | Kernen | Geheugen | Storage |
|---|---|---|---|
| EP1 | 1 | 3,5 GB | 250 GB |
| EP2 | 2 | 7 GB | 250 GB |
| EP3 | 4 | 14 GB | 250 GB |
Overwegingen voor geheugengebruik
Als u op een computer met meer geheugen werkt, betekent dit niet altijd dat uw functie-app gebruikmaakt van alle beschikbare geheugen.
Een JavaScript-functie-app wordt bijvoorbeeld beperkt door de standaardgeheugenlimiet in Node.js. Als u deze vaste geheugenlimiet wilt verhogen, voegt u de app-instelling languageWorkers:node:arguments toe met een waarde van --max-old-space-size=<max memory in MB>.
En voor plannen met meer dan 4 GB geheugen moet u ervoor zorgen dat de bitness-platforminstelling is ingesteld 64 Bit op onder Algemeen Instellingen.
Maximale uitschaling van regio
Dit zijn de momenteel ondersteunde maximale uitschaalwaarden voor één plan in elke regio en besturingssysteemconfiguratie:
| Regio | Windows | Linux |
|---|---|---|
| Australië - centraal | 100 | 20 |
| Australië - centraal 2 | 100 | Niet beschikbaar |
| Australië - oost | 100 | 40 |
| Australië - zuidoost | 100 | 20 |
| Brazilië - zuid | 100 | 20 |
| Canada - midden | 100 | 100 |
| India - centraal | 100 | 20 |
| Central US | 100 | 100 |
| China - oost 2 | 100 | 20 |
| China - noord 2 | 100 | 20 |
| Azië - oost | 100 | 20 |
| VS - oost | 100 | 100 |
| VS - oost 2 | 100 | 100 |
| Frankrijk - centraal | 100 | 60 |
| Duitsland - west-centraal | 100 | 20 |
| Israël - centraal | 100 | 20 |
| Italië - noord | 100 | 20 |
| Japan East | 100 | 20 |
| Japan - west | 100 | 20 |
| Jio India West | 100 | 20 |
| Korea - centraal | 100 | 20 |
| Korea - zuid | 40 | 20 |
| VS - noord-centraal | 100 | 20 |
| Europa - noord | 100 | 100 |
| Noorwegen - oost | 100 | 20 |
| Zuid-Afrika - noord | 100 | 20 |
| Zuid-Afrika - west | 20 | 20 |
| VS - zuid-centraal | 100 | 100 |
| India - zuid | 100 | Niet beschikbaar |
| Azië - zuidoost | 100 | 20 |
| Zwitserland - noord | 100 | 20 |
| Zwitserland - west | 100 | 20 |
| VAE - noord | 100 | 20 |
| Verenigd Koninkrijk Zuid | 100 | 100 |
| Verenigd Koninkrijk West | 100 | 20 |
| US Gov - Arizona | 100 | 20 |
| USGov Texas | 100 | Niet beschikbaar |
| USGov Virginia | 100 | 20 |
| VS - west-centraal | 100 | 20 |
| Europa -west | 100 | 100 |
| India - west | 100 | 20 |
| VS - west | 100 | 100 |
| VS - west 2 | 100 | 20 |
| US - west 3 | 100 | 20 |
Zie de volledige regionale beschikbaarheid van Azure Functions voor meer informatie.