Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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 Opzioni di hosting di Funzioni di Azure.
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 del piano Premium offre i seguenti vantaggi per le tue funzioni:
- Istanze sempre pronte e già riscaldate per evitare l'avvio a freddo
- Connettività di rete virtuale
- Supporto per durate di runtime più lunghe
- Scelta delle dimensioni dell'istanza Premium
- Prezzi più prevedibili rispetto al piano di consumo
- Allocazione di app ad alta densità per piani con più app per le funzioni
- Supporto per 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, proprio come il piano Flex Consumption e il piano 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 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 altre informazioni, vedere 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 avvio a freddo.
Il piano Premium offre due funzionalità che interagiscono per eliminare efficacemente gli avvii a freddo nelle funzioni: istanze sempre pronte e istanze preavvise. 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 un numero di istanze sempre pronto impostato su uno e la terza app è impostata 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 always-ready 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 lungo tempo di riscaldamento, puoi prendere in considerazione l'aumento del buffer di istanze pre-riscaldate. Un'istanza preriscaldata diventa attiva solo dopo che tutte le istanze attive sono in uso.
È anche possibile definire un trigger di riscaldamento che viene eseguito durante la fase 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 che mostra come interagiscono le istanze sempre pronte e le istanze preavvise. 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. Al momento, vengono fatturate le due istanze sempre pronte, ma non vengono fatturate per un'istanza preavvisa perché non viene allocata alcuna istanza preavvisa.
- 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 preavviso nel portale. È 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 di scalabilità orizzontale delle app non può superare le istanze massime di 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 altre informazioni, vedere Integrare Funzioni di Azure 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 con un periodo di tolleranza di 10 minuti.
- È 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 le istanze sempre pronte, può continuare a aumentare le istanze fino a quando il numero di istanze raggiunge il limite massimo di burst del piano o il limite massimo di scalabilità orizzontale 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 se le funzioni siano in esecuzione.
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à.
Codice articolo (SKU) | Core | Memoria | Immagazzinamento |
---|---|---|---|
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
La tabella seguente elenca attualmente i valori massimi di scalabilità orizzontale 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 | 20 | 20 |
Cina settentrionale 2 | 20 | 20 |
Cina settentrionale 3 | 20 | 20 |
Asia orientale | 100 | 20 |
Stati Uniti orientali | 100 | 100 |
Stati Uniti orientali 2 | 80 | 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 |
Messico centrale | 20 | 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 |
Spagna centrale | 20 | 20 |
Svizzera settentrionale | 100 | 20 |
Svizzera occidentale | 100 | 20 |
Emirati Arabi Uniti settentrionali | 100 | 100 |
Regno Unito meridionale | 100 | 100 |
Regno Unito occidentale | 100 | 20 |
USGov Arizona | 20 | 20 |
USGov Texas | 20 | Non disponibile |
Governo degli Stati Uniti Virginia | 80 | 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 Prodotti disponibili in base all'area.