Affidabilità in Funzioni di Azure
Questo articolo descrive il supporto dell'affidabilità in Funzioni di Azure e illustra sia la resilienza all'interno dell'area con le zone di disponibilità che il ripristino tra aree e la continuità aziendale. Per una panoramica più dettagliata dei principi di affidabilità in Azure, vedere Affidabilità di Azure.
Il supporto della zona di disponibilità per Funzioni di Azure è disponibile nei piani Premium (Elastic Premium) e Dedicato (servizio app). Questo articolo è incentrato sul supporto della ridondanza della zona per i piani Premium. Per la ridondanza della zona nei piani dedicati, vedere Eseguire la migrazione di servizio app al supporto della zona di disponibilità.
Supporto della zona di disponibilità
Le zone di disponibilità di Azure sono almeno tre gruppi di data center separati fisicamente all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di energia, raffreddamento e infrastruttura di rete indipendenti. In caso di errore della zona locale, le zone di disponibilità sono progettate in modo che se l'unica zona è interessata, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle due zone rimanenti.
Gli errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori si ottiene con ridondanza e isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.
I servizi abilitati per le zone di disponibilità di Azure sono progettati per offrire il giusto livello di affidabilità e flessibilità. Possono essere configurati in due modi. Possono essere ridondanti della zona, con replica automatica tra zone o zone, con istanze aggiunte a una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sull'architettura zonale e con ridondanza della zona, vedere Consigli per l'uso di zone e aree di disponibilità.
Funzioni di Azure supporta una distribuzione con ridondanza della zona.
Quando si configura Funzioni come ridondanza della zona, la piattaforma distribuisce automaticamente le istanze dell'app per le funzioni in tre zone nell'area selezionata.
La distribuzione di istanze con una distribuzione con ridondanza della zona viene determinata all'interno delle regole seguenti, anche quando l'app viene ridimensionata in ingresso e in uscita:
- Il numero minimo di istanze dell'app per le funzioni è tre.
- Quando si specifica una capacità maggiore di tre, le istanze vengono distribuite in modo uniforme solo quando la capacità è un multiplo di 3.
- Per un valore di capacità superiore a 3*N, le istanze aggiuntive vengono distribuite tra una o due zone rimanenti.
Importante
Funzioni di Azure può essere eseguito nella piattaforma del servizio app Azure. Nella piattaforma 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 con "E", ad esempio EP1. servizio app nomi di SKU del piano che iniziano con "P", ad esempio P1V2 (piano Premium V2 small), sono effettivamente Piani di hosting dedicati. Poiché sono Dedicati e non Elastic Premium, i piani con nomi sku che iniziano con "P" non vengono ridimensionati in modo dinamico e possono aumentare i costi.
Disponibilità a livello di area
I piani Premium con ridondanza della zona sono disponibili nelle aree seguenti:
| America | Europa | Medio Oriente | Africa | Asia Pacifico |
|---|---|---|---|---|
| Brasile meridionale | Francia centrale | Israele centrale | Sudafrica settentrionale | Australia orientale |
| Canada centrale | Germania centro-occidentale | Qatar centrale | India centrale | |
| Stati Uniti centrali | Italia settentrionale | Emirati Arabi Uniti settentrionali | Cina settentrionale 3 | |
| Stati Uniti orientali | Europa settentrionale | Asia orientale | ||
| Stati Uniti orientali 2 | Norvegia orientale | Giappone orientale | ||
| Stati Uniti centro-meridionali | Svezia centrale | Asia sud-orientale | ||
| West US 2 | Svizzera settentrionale | |||
| Stati Uniti occidentali 3 | Regno Unito meridionale | |||
| Europa occidentale |
Prerequisiti
Il supporto della zona di disponibilità è una proprietà del piano Premium. Di seguito sono riportati i requisiti/limitazioni correnti per l'abilitazione delle zone di disponibilità:
- È possibile abilitare le zone di disponibilità solo quando si crea un piano Premium per l'app per le funzioni. Non è possibile convertire un piano Premium esistente per usare le zone di disponibilità.
- È necessario usare un account di archiviazione con ridondanza della zona per l'account di archiviazione dell'app per le funzioni. Se si usa un tipo diverso di account di archiviazione, Funzioni può mostrare un comportamento imprevisto durante un'interruzione di zona.
- Sono supportati sia Windows che Linux.
- Deve essere ospitato in un piano di hosting Elastic Premium o Dedicato. Per informazioni su come usare la ridondanza della zona con un piano dedicato, vedere Eseguire la migrazione di servizio app al supporto della zona di disponibilità.
- Il supporto della zona di disponibilità non è attualmente disponibile per le app per le funzioni nei piani a consumo .
- Le app per le funzioni ospitate in un piano Premium devono avere un numero minimo di istanze sempre pronte di tre.
- La piattaforma applica questo conteggio minimo in background se si specifica un numero di istanze inferiore a tre.
- Se non si usa un piano Premium o un'unità di scala che supporta le zone di disponibilità, si trovano in un'area non supportata o non sono sicuri, vedere le indicazioni sulla migrazione.
Prezzi
Non sono previsti costi aggiuntivi associati all'abilitazione delle zone di disponibilità. I prezzi per un piano Premium servizio app con ridondanza della zona corrispondono a un piano Premium a zona singola. Per ogni servizio app piano usato, vengono addebitati i costi in base allo SKU scelto, alla capacità specificata e alle istanze a cui si esegue il ridimensionamento in base ai criteri di scalabilità automatica. Se si abilitano le zone di disponibilità ma si specifica una capacità inferiore a tre per un piano di servizio app, la piattaforma applica un numero minimo di istanze di tre per il piano servizio app e viene addebitato l'utente per tali tre istanze.
Creare un piano Premium con ridondanza della zona e un'app per le funzioni
Esistono attualmente due modi per distribuire un piano Premium con ridondanza della zona e un'app per le funzioni. È possibile usare il portale di Azure o un modello di Resource Manager.
Aprire il portale di Azure e passare alla pagina Crea app per le funzioni. Le informazioni sulla creazione di un'app per le funzioni nel portale sono disponibili qui.
Nella pagina Informazioni di base compilare i campi per l'app per le funzioni. Prestare particolare attenzione ai campi nella tabella seguente (evidenziati anche nello screenshot seguente), che presentano requisiti specifici per la ridondanza della zona.
Impostazione Valore suggerito Note sulla ridondanza della zona Area Area preferita Sottoscrizione in cui viene creata questa nuova app per le funzioni. È necessario selezionare un'area abilitata nell'elenco precedente. 
Nella pagina Hosting compilare i campi per il piano di hosting dell'app per le funzioni. Prestare particolare attenzione ai campi nella tabella seguente (evidenziati anche nello screenshot seguente), che presentano requisiti specifici per la ridondanza della zona.
Impostazione Valore suggerito Note sulla ridondanza della zona Account di archiviazione Un account di archiviazione con ridondanza della zona Come accennato in precedenza nella sezione dei prerequisiti , è consigliabile usare un account di archiviazione con ridondanza della zona per l'app per le funzioni con ridondanza della zona. Tipo di piano Funzioni Premium Questo articolo illustra in dettaglio come creare un'app con ridondanza della zona in un piano Premium. La ridondanza della zona non è attualmente disponibile nei piani a consumo. Informazioni sulla ridondanza della zona nei piani di servizio app sono disponibili in questo articolo. Ridondanza della zona Attivata Questo campo popola il flag che determina se l'app è con ridondanza della zona o meno. Non sarà possibile selezionare Enableda meno che non sia stata scelta un'area che supporta la ridondanza della zona, come indicato nel passaggio 2.
Per il resto del processo di creazione dell'app per le funzioni, creare l'app per le funzioni come di consueto. Nessun campo nel resto del processo di creazione che influisce sulla ridondanza della zona.
Dopo aver creato e distribuito il piano con ridondanza della zona, qualsiasi app per le funzioni ospitata nel nuovo piano viene considerata ridondante dalla zona.
Eseguire la migrazione dell'app per le funzioni a un piano con ridondanza della zona
App per le funzioni di Azure attualmente non supporta la migrazione sul posto delle istanze di app per le funzioni esistenti. Per informazioni su come eseguire la migrazione del piano Premium multi-tenant pubblico dalla zona non di disponibilità al supporto della zona di disponibilità, vedere Eseguire la migrazione di servizio app al supporto della zona di disponibilità.
Esperienza di riduzione della zona
Tutte le istanze dell'app per le funzioni disponibili delle app per le funzioni con ridondanza della zona sono abilitate ed elaborano eventi. Quando una zona diventa inattiva, Funzioni rileva le istanze perse e tenta automaticamente di trovare nuove istanze di sostituzione, se necessario. Si applica comunque il comportamento della scalabilità elastica. Tuttavia, in uno scenario di zona verso il basso non esiste alcuna garanzia che le richieste per istanze aggiuntive possano avere esito positivo, poiché il back-riempimento delle istanze perse si verifica in modo ottimale. Le applicazioni distribuite in un piano Premium abilitato per la zona di disponibilità continuano a essere eseguite anche quando altre zone nella stessa area subiscono un'interruzione. Tuttavia, è possibile che i comportamenti non di runtime possano comunque essere interessati da un'interruzione in altre zone di disponibilità. Questi comportamenti interessati possono includere il ridimensionamento del piano Premium, la creazione di applicazioni, la configurazione dell'applicazione e la pubblicazione di applicazioni. La ridondanza della zona per i piani Premium garantisce solo un tempo di attività continuo per le applicazioni distribuite.
Quando Funzioni alloca le istanze a un piano Premium con ridondanza della zona, usa il bilanciamento della zona consigliato offerto dal set di scalabilità di macchine virtuali di Azure sottostante. Un piano Premium viene considerato bilanciato quando ogni zona ha lo stesso numero di macchine virtuali (± 1 VM) in tutte le altre zone usate dal piano Premium.
Ripristino di emergenza tra aree e continuità aziendale
Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.
Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.
Questa sezione illustra alcune delle strategie che è possibile usare per distribuire Funzioni per consentire il ripristino di emergenza.
Ripristino di emergenza in più aree
Poiché non è disponibile alcuna ridondanza predefinita, le funzioni vengono eseguite in un'app per le funzioni in un'area di Azure specifica. Per evitare la perdita di esecuzione durante le interruzioni, è possibile distribuire in modo ridondante le stesse funzioni nelle app per le funzioni in più aree. Per altre informazioni sulle distribuzioni in più aree, vedere le linee guida in Applicazione Web multiarea a disponibilità elevata.
Quando si esegue lo stesso codice di funzione in più aree, esistono due modelli da considerare, attivo-attivo e attivo-passivo.
Modello attivo-attivo per le funzioni trigger HTTP
Con un modello attivo-attivo, le funzioni in entrambe le aree eseguono attivamente ed elaborano eventi, in modo duplicato o in rotazione. È consigliabile usare un modello attivo-attivo in combinazione con Frontdoor di Azure per le funzioni attivate da HTTP critiche, che possono instradare e instradare le richieste HTTP round robin tra le funzioni in esecuzione in più aree. Frontdoor può anche controllare periodicamente l'integrità di ogni endpoint. Quando una funzione in un'area smette di rispondere ai controlli di integrità, Frontdoor di Azure lo rimuove dalla rotazione e inoltra solo il traffico alle funzioni integre rimanenti.
Importante
Sebbene sia consigliabile usare il modello attivo-passivo per le funzioni trigger non HTTPS. È possibile creare distribuzioni attive-attive per le funzioni attivate non HTTP. Tuttavia, è necessario considerare il modo in cui le due aree attive interagiscono o coordinano tra loro. Quando si distribuisce la stessa app per le funzioni in due aree con ogni trigger nella stessa coda di bus di servizio, fungerebbero da consumer concorrenti per il de-accodamento di tale coda. Anche se questo significa che ogni messaggio viene elaborato solo da una delle istanze, significa anche che è ancora presente un singolo punto di errore nella singola istanza di bus di servizio.
È invece possibile distribuire due code bus di servizio, una in un'area primaria, una in un'area secondaria. In questo caso, è possibile avere due app per le funzioni, ognuna a cui punta la coda bus di servizio attiva nella propria area. La sfida con questa topologia è il modo in cui i messaggi della coda vengono distribuiti tra le due aree. Spesso, ciò significa che ogni editore tenta di pubblicare un messaggio in entrambe le aree e ogni messaggio viene elaborato da entrambe le app per le funzioni attive. Anche se crea il modello attivo/attivo desiderato, crea anche altre sfide per la duplicazione del calcolo e quando o come vengono consolidati i dati.
Modello attivo-passivo per le funzioni trigger non HTTPS
È consigliabile usare il modello attivo-passivo per le funzioni attivate da eventi, non HTTP, ad esempio bus di servizio e le funzioni attivate da Hub eventi.
Per creare ridondanza per le funzioni trigger non HTTP, usare un modello attivo-passivo. Con un modello attivo-passivo, le funzioni vengono eseguite attivamente nell'area che riceve gli eventi; mentre le stesse funzioni in una seconda area rimangono inattive. Il modello attivo-passivo consente a una sola funzione di elaborare ogni messaggio fornendo un meccanismo per eseguire il failover nell'area secondaria in un'emergenza. Le app per le funzioni funzionano con i comportamenti di failover dei servizi partner, ad esempio bus di servizio di Azure il ripristino geografico e il ripristino geografico Hub eventi di Azure.
Si consideri una topologia di esempio usando un trigger Hub eventi di Azure. In questo caso, il modello attivo/passivo richiede i componenti seguenti:
- Hub eventi di Azure distribuita in un'area primaria e secondaria.
- Emergenza geografica abilitata per associare gli hub eventi primari e secondari. Viene inoltre creato un alias che è possibile usare per connettersi agli hub eventi e passare da primario a secondario senza modificare le informazioni di connessione.
- Le app per le funzioni vengono distribuite nell'area primaria e secondaria (failover), con l'app nell'area secondaria essenzialmente inattiva perché i messaggi non vengono inviati.
- L'app per le funzioni viene attivata nel stringa di connessione diretto (non alias) per il rispettivo hub eventi.
- I server di pubblicazione nell'hub eventi devono pubblicare nell'alias stringa di connessione.
Prima del failover, i server di pubblicazione che inviano alla route alias condivisa all'hub eventi primario. L'app per le funzioni primaria è in ascolto esclusivamente dell'hub eventi primario. L'app per le funzioni secondaria è passiva e inattiva. Non appena viene avviato il failover, i server di pubblicazione che inviano all'alias condiviso vengono indirizzati all'hub eventi secondario. L'app per le funzioni secondaria diventa ora attiva e avvia automaticamente l'attivazione. Un failover efficace in un'area secondaria può essere guidato interamente dall'hub eventi, con le funzioni che diventano attive solo quando il rispettivo hub eventi è attivo.
Altre informazioni e considerazioni sul failover con bus di servizio e Hub eventi.