Opzioni di hosting di Funzioni di Azure
Quando si crea un'app per le funzioni in Azure, è necessario scegliere un piano di hosting per l'app. Sono disponibili tre piani di hosting di base per Funzioni di Azure: piano a consumo, piano Premium e piano dedicato (servizio app). Tutti i piani di hosting sono disponibili generalmente su macchine virtuali sia Linux che Windows.
Il piano di hosting scelto determina i comportamenti seguenti:
- Come viene ridimensionata l'app per le funzioni.
- Le risorse disponibili per ogni istanza dell'app per le funzioni.
- Il supporto per funzionalità avanzate, ad esempio la connettività della rete virtuale di Azure.
Questo articolo fornisce un confronto dettagliato tra i vari piani di hosting, insieme all'hosting basato su Kubernetes.
Nota
Se si sceglie di ospitare le funzioni in un cluster Kubernetes, è consigliabile usare un cluster Kubernetes abilitato per Azure Arc. L'hosting in un cluster Kubernetes abilitato per Azure Arc è attualmente in anteprima. Per altre informazioni, vedere servizio app, Funzioni e App per la logica in Azure Arc.
Panoramica dei piani
Di seguito è riportato un riepilogo dei vantaggi offerti dai tre piani di hosting principali per Funzioni:
| Piano | Vantaggi |
|---|---|
| Piano a consumo | Ridimensionare automaticamente e pagare solo per le risorse di calcolo quando le funzioni sono in esecuzione. Nel piano a consumo le istanze dell'host di Funzioni vengono aggiunte e rimosse in modo dinamico in base al numero di eventi in ingresso. ✔ Piano di hosting predefinito. ✔ Pagare solo quando le funzioni sono in esecuzione. ✔ Ridimensiona automaticamente, anche durante periodi di carico elevato. |
| Piano Premium | Consente di dimensionare automaticamente in base alla domanda usando ruoli di lavoro preriscaldati che eseguono le applicazioni senza ritardi dopo l'inattività, di usare istanze più potenti per l'esecuzione e di connettersi alle reti virtuali. Si consideri il piano Funzioni di Azure Premium nelle situazioni seguenti: ✔ Le app per le funzioni vengono eseguite in modo continuo o quasi continuo. ✔ Si dispone di un numero elevato di esecuzioni di piccole dimensioni e di una fattura di esecuzione elevata, ma bassi GB secondi nel piano a consumo. ✔ Sono necessarie più opzioni di CPU o memoria rispetto a quelle fornite dal piano a consumo. ✔ Il codice deve essere eseguito più a lungo del tempo di esecuzione massimo consentito nel piano a consumo. ✔ Sono necessarie funzionalità non disponibili nel piano a consumo, ad esempio la connettività di rete virtuale. ✔ Si vuole fornire un'immagine Linux personalizzata in cui eseguire le funzioni. |
| Piano dedicato | Eseguire le funzioni all'interno di un piano di servizio app a tariffe regolari dei piani di servizio app. Ideale per scenari a esecuzione prolungata in cui non è possibile usare Durable Functions. Si consideri un piano servizio app nelle situazioni seguenti: ✔ Sono presenti macchine virtuali sottoutilizzate che eseguono già altre istanze di servizio app. ✔ Sono necessari il ridimensionamento predittivo e i costi. |
Le tabelle di confronto in questo articolo includono anche le opzioni di hosting seguenti, che forniscono la quantità più elevata di controllo e isolamento in cui eseguire le app per le funzioni.
| Opzione Hosting | Dettagli |
|---|---|
| ASE | L'ambiente del servizio app di Azure è una funzionalità del servizio app di Azure che offre un ambiente completamente isolato e dedicato per l'esecuzione sicura delle app del servizio app su larga scala. Gli ambiente del servizio app sono appropriati per i carichi di lavoro dell'applicazione che richiedono: ✔ Scala molto elevata. ✔ Isolamento di calcolo completo e accesso sicuro alla rete. ✔ Utilizzo elevato della memoria. |
| Kubernetes (Diretto o Azure Arc) |
Kubernetes offre un ambiente completamente isolato e dedicato in esecuzione nella piattaforma Kubernetes. Kubernetes è appropriato per i carichi di lavoro dell'applicazione che richiedono: ✔ Requisiti hardware personalizzati. ✔ Isolamento e accesso sicuro alla rete. ✔ Possibilità di essere eseguita in un ambiente ibrido o multi-cloud. ✔ Eseguire insieme ad applicazioni e servizi Kubernetes esistenti. |
Le tabelle rimanenti di questo articolo confrontano i piani relativi a varie funzionalità e comportamenti. Per un confronto dei costi tra piani di hosting dinamici (Consumo e Premium), vedere la pagina dei prezzi Funzioni di Azure. Per i prezzi delle varie opzioni di piano dedicato, vedere la pagina dei prezzi servizio app.
Sistema operativo/runtime
La tabella seguente illustra il supporto del sistema operativo e della lingua per i piani di hosting.
| Linux1,2 solo codice |
Solo codice Di Windows | Linux1,2,3 Contenitore Docker |
|
|---|---|---|---|
| Piano a consumo | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
Nessun supporto |
| Piano Premium | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Piano dedicato | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| ASE | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Kubernetes (diretto) | n/d | n/d | C# JavaScript Java PowerShell Core Python TypeScript |
| Azure Arc (anteprima) | C# JavaScript Java Python TypeScript |
n/d | C# JavaScript Java PowerShell Core Python TypeScript |
1 Linux è l'unico sistema operativo supportato per lo stack di runtime Python.
2 Il supporto di PowerShell in Linux è attualmente in anteprima.
3 Linux è l'unico sistema operativo supportato per i contenitori Docker.
Durata del timeout di un'app per le funzioni
La durata del timeout per le funzioni in un'app per le funzioni è definita dalla functionTimeout proprietà nel file di progetto host.json . Questa proprietà si applica in modo specifico alle esecuzioni di funzioni. Dopo l'avvio dell'esecuzione della funzione, la funzione deve restituire/rispondere entro la durata del timeout. Per altre informazioni, vedere Migliorare le prestazioni e l'affidabilità dei Funzioni di Azure.
La tabella seguente mostra i valori predefiniti e massimi (in minuti) per piani specifici:
| Piano | Predefinito | Massimo1 |
|---|---|---|
| Piano a consumo | 5 | 10 |
| Piano Premium | 302 | Nessuna limitazione |
| Piano dedicato | 302 | Nessuna limitazione |
1 Indipendentemente dall'impostazione del timeout dell'app per le funzioni, 230 secondi è il tempo massimo che una funzione attivata HTTP può richiedere per rispondere a una richiesta. Il motivo è legato al timeout di inattività predefinito di Azure Load Balancer. Per tempi di elaborazione più lunghi, provare a usare lo schema asincrono di Durable Functions oppure rinviare il processo effettivo e restituire una risposta immediata.
2 Il timeout predefinito per la versione 1.x del runtime di Funzioni è illimitato.
Scalabilità
La tabella seguente confronta i comportamenti di ridimensionamento dei vari piani di hosting.
Le istanze massime vengono fornite in base a un'app per ogni funzione (consumo) o per piano (Premium/Dedicato), a meno che non sia indicato diversamente.
| Piano | Aumentare il numero di istanze | Numero massimo di istanze # |
|---|---|---|
| Piano a consumo | Guidata dall'evento. Aumento automatico del numero di istanze anche in periodo di carico elevato. Funzioni di Azure infrastruttura ridimensiona le risorse CPU e memoria aggiungendo istanze aggiuntive dell'host Funzioni, in base al numero di eventi trigger in ingresso. | Windows: 200 Linux: 1001 |
| Piano Premium | Guidata dall'evento. Aumento automatico del numero di istanze anche in periodo di carico elevato. Funzioni di Azure le risorse di CPU e memoria vengono ridimensionate aggiungendo istanze aggiuntive dell'host funzioni, in base al numero di eventi attivati dalle funzioni. | Windows: 100 Linux: 20-1002 |
| Piano dedicato3 | Scalabilità manuale/automatica | 10-30 |
| Ambiente del servizioapp 3 | Scalabilità manuale/automatica | 100 |
| Kubernetes | Scalabilità automatica basata su eventi per i cluster Kubernetes tramite KEDA. | Varia in base al cluster |
1 Durante la scalabilità orizzontale, è attualmente previsto un limite di 500 istanze per ogni sottoscrizione per ogni ora per le app Linux in un piano a consumo.
2 In alcune aree, le app Linux in un piano Premium possono essere ridimensionate a 100 istanze. Per altre informazioni, vedere l'articolo Piano Premium.
3 Per limiti specifici per le varie opzioni di piano di servizio app, vedere i limiti del piano di servizio app.
Comportamento di avvio a freddo
| Piano | Dettagli |
|---|---|
| Piano a consumo | Le app possono essere ridimensionate a zero quando sono inattive, vale a dire che alcune richieste potrebbero avere una latenza aggiuntiva all'avvio. Il piano a consumo include alcune ottimizzazioni per ridurre l'ora di inizio a freddo, incluso il pull da funzioni segnaposto pre-riscaldamento che hanno già l'host della funzione e i processi del linguaggio in esecuzione. |
| Piano Premium | Istanze con riscaldamento perpetuo per evitare qualsiasi avvio a freddo. |
| Piano dedicato | Quando si esegue in un piano dedicato, l'host funzioni può essere eseguito in modo continuo, il che significa che l'avvio a freddo non è un problema. |
| ASE | Quando si esegue in un piano dedicato, l'host funzioni può essere eseguito in modo continuo, il che significa che l'avvio a freddo non è un problema. |
| Kubernetes | A seconda della configurazione KEDA, le app possono essere configurate per evitare un avvio a freddo. Se configurato per la scalabilità su zero, viene rilevato un avvio a freddo per i nuovi eventi. |
Limiti del servizio
| Risorsa | Piano a consumo | Piano Premium | Piano dedicato | ASE | Kubernetes |
|---|---|---|---|---|---|
| Durata del timeout predefinita (min) | 5 | 30 | 301 | 30 | 30 |
| Durata del timeout massima (min) | 10 | Senza limiti7 | Senza limiti2 | unbounded | unbounded |
| Numero massimo di connessioni in uscita (per istanza) | 600 attive (1200 totali) | unbounded | unbounded | unbounded | unbounded |
| Dimensioni massime della richiesta (MB)3 | 100 | 100 | 100 | 100 | Dipende dal cluster |
| Lunghezza massima della stringa di query3 | 4096 | 4096 | 4096 | 4096 | Dipende dal cluster |
| Lunghezza massima dell'URL della richiesta3 | 8192 | 8192 | 8192 | 8192 | Dipende dal cluster |
| Unità di calcolo di Azure per istanza | 100 | 210-840 | 100-840 | 210-2508 | Prezzi del servizio Azure Kubernetes |
| Dimensioni massime della memoria (GB per istanza) | 1.5 | 3,5-14 | 1,75-14 | 3,5-14 | Qualsiasi nodo è supportato |
| Numero massimo di istanze (Windows/Linux) | 200/100 | 100/20 | varia in base alla SKU9 | 1009 | Dipende dal cluster |
| App per le funzioni per piano | 100 | 100 | Senza limiti4 | unbounded | unbounded |
| Piani del servizio app | 100 per area | 100 per gruppo di risorse | 100 per gruppo di risorse | - | - |
| Slot di distribuzione per app10 | 2 | 3 | 1-209 | 20 | n/d |
| Archiviazione5 | 5 TB | 250 GB | 50-1000 GB | 1 TB | n/d |
| Domini personalizzati per applicazione | 5006 | 500 | 500 | 500 | n/d |
| Supporto per il dominio personalizzato SSL | Connessione SNI SSL senza limiti inclusa | Connessioni SNI SSL senza limiti e 1 connessione IP SSL incluse | Connessioni SNI SSL senza limiti e 1 connessione IP SSL incluse | Connessioni SNI SSL senza limiti e 1 connessione IP SSL incluse | n/d |
1 Per impostazione predefinita, il timeout per il runtime di Funzioni 1.x in un piano di servizio app non prevede limiti.
2 Richiede l'impostazione del piano di servizio app su Always On. Pagamento con tariffe standard.
3 Questi limiti vengono impostati nell'host.
4 Il numero effettivo di app per le funzioni che è possibile ospitare dipende dall'attività delle app, dalle dimensioni delle istanze del computer e dall'uso delle risorse corrispondente.
5 Il limite di archiviazione corrisponde alle dimensioni totali del contenuto nello spazio di archiviazione temporanea in tutte le app nello stesso piano di servizio app. Il piano a consumo usa File di Azure per l'archiviazione temporanea.
6 Quando l'app per le funzioni è ospitata in un piano a consumo, è supportata solo l'opzione CNAME. Per le app per le funzioni in un piano Premium o in un piano di servizio app, è possibile eseguire il mapping di un dominio personalizzato usando un record CNAME o A.
7 Garantito per un massimo di 60 minuti.
8 I ruoli di lavoro ospitano app di clienti. e sono disponibili in tre dimensioni fisse: Una vCPU/3,5 GB di RAM, due vCPU/7 GB di RAM oppure quattro vCPU/14 GB di RAM.
9 Per informazioni dettagliate, vedere limiti di servizio app.
10 Incluso lo slot di produzione.
Limitazioni per la creazione di nuove app per le funzioni in un gruppo di risorse esistente
In alcuni casi, quando si tenta di creare un nuovo piano di hosting per l'app per le funzioni in un gruppo di risorse esistente, è possibile che venga visualizzato uno degli errori seguenti:
- Il piano tariffario non è consentito in questo gruppo di risorse
- <SKU_name i ruoli di> lavoro non sono disponibili nel gruppo <di risorse resource_group_name>
Ciò può verificarsi quando vengono soddisfatte le condizioni seguenti:
- Si crea un'app per le funzioni in un gruppo di risorse esistente che contiene un'altra app per le funzioni o un'altra app Web.
- La nuova app per le funzioni viene creata nella stessa area dell'app precedente.
- L'app precedente è in qualche modo incompatibile con la nuova app. Ciò può verificarsi tra SKU, sistemi operativi o a causa di altre funzionalità a livello di piattaforma, ad esempio il supporto della zona di disponibilità.
Il motivo è dovuto al mapping dei piani dell'app per le funzioni e delle app Web a pool di risorse diversi al momento della creazione. Sku diversi richiedono un set diverso di funzionalità dell'infrastruttura. Quando si crea un'app in un gruppo di risorse, tale gruppo di risorse viene mappato e assegnato a un pool specifico di risorse. Se si tenta di creare un altro piano in tale gruppo di risorse e il pool mappato non dispone delle risorse necessarie, si verificherà questo errore.
Quando si verifica questo errore, creare invece l'app per le funzioni e il piano di hosting in un nuovo gruppo di risorse.
Funzionalità di rete
| Funzionalità | Piano a consumo | Piano Premium | Piano dedicato | ASE |
|---|---|---|---|---|
| Restrizioni IP in ingresso | ✅Sì | ✅Sì | ✅Sì | ✅Sì |
| Endpoint privati in ingresso | ❌No | ✅Sì | ✅Sì | ✅Sì |
| Integrazione della rete virtuale | ❌No | ✅Sì (Regionale) | ✅Sì (Regional e Gateway) | ✅Sì |
| Trigger della rete virtuale (non HTTP) | ❌No | ✅Sì | ✅Sì | ✅Sì |
| Connessioni ibride (solo Windows) | ❌No | ✅Sì | ✅Sì | ✅Sì |
| Restrizioni IP in uscita | ❌No | ✅Sì | ✅Sì | ✅Sì |
Fatturazione
| Piano | Dettagli |
|---|---|
| Piano a consumo | Pagare solo per il momento in cui vengono eseguite le funzioni. La fatturazione si basa sul numero di esecuzioni, il tempo di esecuzione e la memoria usata. |
| Piano Premium | Il piano Premium si basa sul numero di secondi di core e memoria usati tra le istanze necessarie e pre-riscaldamento. Almeno un'istanza per piano deve essere sempre mantenuta a caldo. Questo piano offre i prezzi più prevedibili. |
| Piano dedicato | Si paga lo stesso per le app per le funzioni in un piano servizio app come per altre risorse servizio app, ad esempio le app Web. |
| Ambiente del servizio app | Esiste una tariffa mensile fissa per un ambiente del servizio app che paga l'infrastruttura e non cambia con le dimensioni dell'ambiente del servizio app. È previsto anche un costo per servizio app piano vCPU. Tutte le app ospitate in un ambiente del servizio app fanno parte di uno SKU di prezzi isolato. |
| Kubernetes | Si pagano solo i costi del cluster Kubernetes; nessuna fatturazione aggiuntiva per Funzioni. L'app per le funzioni viene eseguita come carico di lavoro dell'applicazione all'inizio del cluster, proprio come una normale app. |