Piano Premium di Funzioni di Azure
Il piano Elastic Premium di Funzioni di Azure è un'opzione di hosting a scalabilità dinamica per le app per le funzioni. Per altre opzioni del piano di hosting, vedere l'articolo relativo al piano di hosting.
Importante
Funzioni di Azure può essere eseguito nella piattaforma del servizio app di Azure. Nella piattaforma del servizio app, i piani che ospitano app per le funzioni del piano Premium vengono definiti piani Elastic Premium, con nomi di SKU come EP1. Se si sceglie di eseguire l'app per le funzioni in un piano Premium, assicurarsi di creare un piano con un nome SKU che inizia per "E", ad esempio EP1. I nomi degli SKU del piano di servizio app che iniziano per "P", ad esempio P1V2 (piano Premium V2 Small), sono in realtà piani di hosting dedicati. Poiché sono Dedicati e non Elastic Premium, i piani con nomi SKU che iniziano per "P" non vengono ridimensionati in modo dinamico e potrebbero comportare un aumento dei costi.
L'hosting di piani Premium offre i vantaggi seguenti alle funzioni:
- Evitare l'avvio a freddo con le istanze riscaldate.
- Connettività di rete virtuale.
- Supporta durate di runtime più lunghe.
- Scelta tra diverse dimensioni dell'istanza Premium.
- Prezzi più prevedibili rispetto al piano a consumo.
- Allocazione app ad alta densità per piani con più app per le funzioni.
- Supporta le distribuzioni di contenitori Linux.
Quando si usa il piano Premium, le istanze dell'host di Funzioni di Azure vengono aggiunte e rimosse in base al numero di eventi in ingresso, come per il Piano a consumo. È possibile distribuire più app per le funzioni nello stesso piano Premium ed esso consente di configurare le dimensioni dell'istanza di calcolo, le dimensioni di base e le dimensioni massime del piano.
Fatturazione
La fatturazione per il piano Premium è basata sul numero di secondi di core e sulla memoria allocata nelle istanze. Questa fatturazione è diversa dal piano a consumo, che viene fatturato in base all'utilizzo e alle esecuzioni delle risorse al secondo. Con il piano Premium, non sono previsti addebiti per l'esecuzione. Questa fatturazione comporta un costo mensile minimo per ogni piano attivo, indipendentemente dal fatto che la funzione sia attiva o inattiva. Tenere presente che tutte le app per le funzioni in un piano Premium condividono istanze allocate. Per ulteriori informazioni, vedere la pagina prezzi di Funzioni di Azure.
Nota
Ogni piano Premium ha sempre almeno un'istanza attiva (fatturata).
Creare un piano Premium
Quando si crea un'app per le funzioni nel portale di Azure, il piano a consumo è l'impostazione predefinita. Per creare un'app per le funzioni eseguita in un piano Premium, è necessario creare o scegliere esplicitamente un piano di hosting Premium di Funzioni di Azure usando uno degli SKU Elastic Premium. L'app per le funzioni creata viene quindi ospitata in questo piano. Il portale di Azure semplifica la creazione in contemporanea del piano Premium e dell'app per le funzioni. È possibile eseguire più app per le funzioni nello stesso piano Premium, ma devono essere eseguite nello stesso sistema operativo (Windows o Linux).
Gli articoli seguenti illustrano come creare un'app per le funzioni a livello di codice con un piano Premium:
Eliminare gli avviamenti a freddo
Quando non si verificano eventi o esecuzioni nel piano a consumo, l'app potrebbe effettuare il ridimensionamento a zero istanze. All’arrivo di nuovi eventi, una nuova istanza con l'app in esecuzione deve essere specializzata. La specializzazione di nuove istanze può richiedere molto tempo, a seconda dell'app. Questa latenza aggiuntiva nella prima chiamata viene spesso chiamata avviamento a freddo dell'app.
Il piano Premium offre due funzionalità che collaborano per eliminare efficacemente gli avviamenti a freddo nelle funzioni: istanze sempre pronte e istanze preriscaldate. Le istanze sempre pronte sono una categoria di istanze preallocate non interessate dal ridimensionamento e quelle preriscaldate sono un buffer durante il ridimensionamento a causa di eventi HTTP.
Quando gli eventi cominciano ad attivare l'app, vengono prima indirizzati alle istanze sempre pronte. Quando la funzione diventa attiva a causa di eventi HTTP, altre istanze vengono riscaldate come buffer. Queste istanze memorizzate nel buffer sono denominate istanze preriscaldate. Questo buffer riduce l'avvio a freddo per le nuove istanze necessarie durante il ridimensionamento.
Istanze sempre pronte
Nel piano Premium, l’app può essere sempre pronta con un numero specifico di istanze. In tali istanze, l’app è continuamente in esecuzione, indipendentemente dal carico. Se il carico supera quanto le istanze sempre pronte possono gestire, vengono aggiunte più istanze in base alle esigenze, fino al numero massimo specificato.
Questa impostazione a livello di app controlla anche le istanze minime del piano. Si consideri ad esempio la presenza di tre app per le funzioni nello stesso piano Premium. Quando due delle app hanno il numero di istanze sempre pronte impostato su uno e una terza istanza lo ha impostato su cinque, il numero minimo per l'intero piano è cinque. Questo riflette anche il numero minimo di istanze per cui viene fatturato il piano. Il numero massimo di istanze sempre pronte supportate per ogni app è 20.
È possibile configurare il numero di istanze sempre pronte nel portale di Azure selezionando l'app per le funzioni, passando alla scheda Funzionalità della piattaforma e selezionando le opzioni Scale Out. Nella finestra di modifica dell'app per le funzioni, le istanze sempre pronte sono specifiche all'app.
Istanze preriscaldate
L'impostazione del numero di istanze preriscaldate fornisce istanze preriscaldate come buffer durante gli eventi di scalabilità e attivazione HTTP. Le istanze preriscaldate continuano a fungere da buffer fino a quando non viene raggiunto il limite massimo di scale-out. Il numero di istanze preriscaldate predefinito è 1 e, nella maggior parte degli scenari, questo valore deve rimanere 1.
Si consideri uno scenario più raro, ad esempio un'app in esecuzione in un contenitore personalizzato. Poiché i contenitori personalizzati hanno un tempo di riscaldamento lungo, si potrebbe voler aumentare il buffer di istanze preriscaldate. Un'istanza preriscaldata diventa attiva solo dopo che tutte le istanze attive sono in uso.
È anche possibile definire un trigger di riscaldamento che venga eseguito durante il processo di preriscaldamento. È possibile usare un trigger di riscaldamento per precaricare dipendenze personalizzate durante il processo di preriscaldamento in modo che le funzioni siano pronte per avviare immediatamente l'elaborazione delle richieste. Per ulteriori informazioni, vedere Trigger di riscaldamento di Funzioni di Azure.
Si consideri questo esempio di interazione tra istanze sempre pronte e le istanze preriscaldate. Un'app per le funzioni Premium ha due istanze sempre pronte configurate e un’istanza preriscaldata per impostazione predefinita.
- Quando l'app è inattiva e non ci sono trigger di eventi, il provisioning e l'esecuzione dell'app sono effettuati con due istanze. In questo momento, le due istanze sempre pronte vengono fatturate, ma non un'istanza preriscaldata, poiché nessuna istanza preriscaldata è stata allocata.
- Quando l'applicazione inizia a ricevere traffico HTTP, le richieste vengono bilanciate tra le due istanze sempre pronte. Non appena queste due istanze avviano l'elaborazione degli eventi, viene aggiunta un'istanza per riempire il buffer preriscaldato. L'app è ora in esecuzione con tre istanze con provisioning: le due istanze sempre pronte e il terzo buffer preriscaldato e inattivo. Vengono fatturate le tre istanze.
- Con l'aumentare del carico, l'app richiede più istanze per gestire il traffico HTTP e l’istanza preriscaldata viene scambiata con un'istanza attiva. Il caricamento HTTP viene ora indirizzato a tutte e tre le istanze e viene eseguito immediatamente il provisioning di una quarta istanza per riempire il buffer preriscaldato.
- Questa sequenza di ridimensionamento e preriscaldamento continua fino a quando non viene raggiunto il numero massimo di istanze per l'app o il carico diminuisce causando la riduzione della piattaforma dopo un certo periodo di tempo. Nessuna istanza viene preriscaldata o attivata una volta superato il valore massimo.
Non è possibile modificare l'impostazione del numero di istanze preriscaldate nel portale. Sarà invece necessario usare l'interfaccia della riga di comando di Azure o Azure PowerShell.
Numero massimo di istanze dell'app per le funzioni
Oltre al numero massimo di burst del piano, è possibile configurare un valore massimo per app. Il valore massimo dell'app può essere configurato usando il limite di scalabilità dell’app. Il limite massimo del numero di istanze che è possibile aggiungere all'app non può superare quello massimo di istanze burst del piano.
Connettività di rete privata
Le app per le funzioni distribuite in un piano Premium possono sfruttare l'integrazione della rete virtuale per le app Web. Se configurata, l'app può comunicare con le risorse all'interno della rete virtuale o protette tramite endpoint di servizio. Le restrizioni IP sono disponibili anche nell'app per limitare il traffico in ingresso.
Quando si assegna una subnet all'app per le funzioni in un piano Premium, è necessaria una subnet con indirizzi IP sufficienti per ogni potenziale istanza. È necessario un blocco IP con almeno 100 indirizzi disponibili.
Per ulteriori informazioni, vedere integrare l'app per le funzioni con una rete virtuale.
Scalabilità elastica rapida
Più istanze di calcolo vengono aggiunte automaticamente per l'app usando la stessa logica di ridimensionamento rapido del piano a consumo. Le app nello stesso piano di servizio app effettuano il ridimensionamento indipendentemente l'una dall'altra, in base alle esigenze individuali dell’app. Tuttavia, le app per le funzioni nello stesso piano di servizio app condividono le risorse della macchina virtuale per ridurre i costi, quando possibile. Il numero di app associate a una macchina virtuale dipende dal footprint di ogni app e dalle dimensioni della macchina virtuale.
Per ulteriori informazioni sul funzionamento del ridimensionamento, vedere Ridimensionamento causato da eventi in Funzioni di Azure.
Durata dell'esecuzione più lunga
Le funzioni in un piano a consumo sono limitate a 10 minuti per una singola esecuzione. Nel piano Premium, la durata dell'esecuzione per impostazione predefinita è di 30 minuti, per evitare esecuzioni incontrollate. Tuttavia, è possibile modificare la configurazione host.json per rendere la durata senza limitazioni per le app del piano Premium, fatta eccezione per le limitazioni seguenti:
- Gli aggiornamenti della piattaforma possono attivare un arresto gestito e interrompere l'esecuzione della funzione.
- Le interruzioni della piattaforma possono causare un arresto non gestito e interrompere l'esecuzione della funzione.
- È presente un timer di inattività che arresta il ruolo di lavoro dopo 60 minuti senza nuove esecuzioni.
- Il comportamento di riduzione può causare l'arresto del ruolo di lavoro dopo 60 minuti.
- Gli scambi di slot possono terminare le esecuzioni negli slot di origine e di destinazione durante lo scambio.
Migrazione
Se si dispone di un'app per le funzioni esistente, è possibile usare i comandi dell'interfaccia della riga di comando di Azure per eseguire la migrazione dell'app tra un piano a consumo e un piano Premium in Windows. I comandi specifici dipendono dalla direzione della migrazione. Per altre informazioni, vedere Pianificare la migrazione.
Questa migrazione non è supportata in Linux.
Impostazioni del piano Premium
Quando si crea il piano, sono disponibili due impostazioni relative alle dimensioni del piano: il numero minimo di istanze (o le dimensioni del piano) e il limite massimo di burst.
Se l'app richiede istanze oltre a quelle sempre pronte, può continuare ad aumentarne il numero fino a quando questo non raggiunge il limite massimo di burst del piano o il limite massimo di ridimensionamento dell’app, se configurato. Le istanze vengono fatturate solo mentre sono in esecuzione e allocate all'utente, in base al numero di istanze al secondo. La piattaforma si impegna il più possibile per permettere all’app di effettuare il ridimensionamento ai limiti massimi definiti.
È possibile configurare le dimensioni e i valori massimi del piano nel portale di Azure selezionando le opzioni Scale Out in Impostazioni di un'app per le funzioni distribuita in tale piano.
Il numero minimo per ogni piano Premium è di almeno un'istanza. Il numero minimo effettivo di istanze viene determinato automaticamente in base alle istanze sempre pronte richieste dalle app nel piano. Ad esempio, se l'app A richiede cinque istanze sempre pronte e l'app B richiede due istanze sempre pronte nello stesso piano, la dimensione minima del piano viene calcolata come cinque. L'app A è in esecuzione su tutte e cinque e l'app B è in esecuzione solo su 2.
Importante
Vengono addebitati i costi per ogni istanza allocata nel numero minimo di istanze indipendentemente dal fatto che le funzioni siano in esecuzione o meno.
Nella maggior parte dei casi, questo valore minimo calcolato automaticamente è sufficiente. Tuttavia, il ridimensionamento oltre il minimo si verifica con la massima diligenza possibile. È possibile, anche se improbabile, che in un momento specifico il ridimensionamento debba essere posticipato se altre istanze non dovessero essere disponibili. Impostando un valore minimo superiore al minimo calcolato automaticamente, si riservano istanze in anticipo in vista di scale-out.
È possibile configurare le istanze minime nel portale di Azure selezionando le opzioni Scale Out in Impostazioni di un'app per le funzioni distribuita in tale piano.
SKU di istanza disponibili
Quando crei o dimensioni il piano, puoi scegliere tra tre dimensioni di istanza. Viene addebitato il numero totale di core e memoria di cui è stato effettuato il provisioning, per ogni secondo in cui un’istanza è allocata. L'app può aumentare automaticamente il numero di istanze in base alla necessità.
| SKU | Core | Memoria | Storage |
|---|---|---|---|
| EP1 | 1 | 3,5 GB | 250 GB |
| EP2 | 2 | 7 GB | 250 GB |
| EP3 | 4 | 14 GB | 250 GB |
Considerazioni sull'utilizzo della memoria
L'esecuzione in un computer con più memoria non comporta sempre l’uso di tutta la memoria disponibile da parte dell'app per le funzioni.
Ad esempio, un'app per le funzioni JavaScript è vincolata dal limite di memoria predefinito in Node.js. Per aumentare questo limite fisso di memoria, aggiungere l'impostazione languageWorkers:node:arguments dell'app con valore --max-old-space-size=<max memory in MB>.
Per i piani con più di 4 GB di memoria, assicurarsi che l'impostazione Bitness Platform sia impostata su 64 Bit in Impostazioni generali.
Aumento del numero massimo di istanze dell'area
Questi sono i valori massimi di scale-out attualmente supportati per un singolo piano in ogni area e configurazione del sistema operativo:
| Paese | Windows | Linux |
|---|---|---|
| Australia centrale | 100 | 20 |
| Australia centrale 2 | 100 | Non disponibile |
| Australia orientale | 100 | 40 |
| Australia sud-orientale | 100 | 20 |
| Brasile meridionale | 100 | 20 |
| Canada centrale | 100 | 100 |
| India centrale | 100 | 20 |
| Stati Uniti centrali | 100 | 100 |
| Cina orientale 2 | 100 | 20 |
| Cina settentrionale 2 | 100 | 20 |
| Asia orientale | 100 | 20 |
| Stati Uniti orientali | 100 | 100 |
| Stati Uniti orientali 2 | 100 | 100 |
| Francia centrale | 100 | 60 |
| Germania centro-occidentale | 100 | 20 |
| Israele centrale | 100 | 20 |
| Italia settentrionale | 100 | 20 |
| Giappone orientale | 100 | 20 |
| Giappone occidentale | 100 | 20 |
| India occidentale Jio | 100 | 20 |
| Corea centrale | 100 | 20 |
| Corea meridionale | 40 | 20 |
| Stati Uniti centro-settentrionali | 100 | 20 |
| Europa settentrionale | 100 | 100 |
| Norvegia orientale | 100 | 20 |
| Sudafrica settentrionale | 100 | 20 |
| Sudafrica occidentale | 20 | 20 |
| Stati Uniti centro-meridionali | 100 | 100 |
| India meridionale | 100 | Non disponibile |
| Asia sud-orientale | 100 | 20 |
| Svizzera settentrionale | 100 | 20 |
| Svizzera occidentale | 100 | 20 |
| Emirati Arabi Uniti settentrionali | 100 | 20 |
| Regno Unito meridionale | 100 | 100 |
| Regno Unito occidentale | 100 | 20 |
| USGov Arizona | 100 | 20 |
| USGov Texas | 100 | Non disponibile |
| USGov Virginia | 100 | 20 |
| Stati Uniti centro-occidentali | 100 | 20 |
| Europa occidentale | 100 | 100 |
| India occidentale | 100 | 20 |
| Stati Uniti occidentali | 100 | 100 |
| Stati Uniti occidentali 2 | 100 | 20 |
| Stati Uniti occidentali 3 | 100 | 20 |
Per altre informazioni, vedere la disponibilità completa a livello di area di Funzioni di Azure.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per