Affidabilità in Funzioni di Azure
Questo articolo descrive il supporto per l'affidabilità in Funzioni di Azure e illustra sia la resilienza all'interno dell'area con 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 delle zone di disponibilità per Funzioni di Azure è disponibile in entrambi i 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 del Servizio app al supporto della zona di disponibilità.
Supporto della zona di disponibilità
Le zone di disponibilità di Azure sono costituite da almeno tre gruppi fisicamente separati di data center all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di alimentazione, raffreddamento e infrastruttura di rete indipendenti. Le zone di disponibilità sono progettate in modo che, in caso di errore in una zona locale, i servizi regionali, la capacità e la disponibilità elevata della zona interessata siano supportati dalle altre due zone.
Gli errori possono essere di tipo hardware o software oppure correlati a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene conseguita mediante la ridondanza e l'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à sono progettati per fornire il livello adeguato di affidabilità e flessibilità. Tali servizi possono essere configurati in due modi. Possono essere con ridondanza della zona, che prevede la replica automatica tra le zone, o a zona, con istanze aggiunte in una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sulle architetture a zona e con ridondanza della zona, vedere Raccomandazioni per l'uso delle zone e delle 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 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 P1V2 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.
Disponibilità a livello di area
I piani Premium con ridondanza della zona sono disponibili nelle aree seguenti:
| Americhe | 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 (ZRS) 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 del 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 di servizio app Premium con ridondanza della zona corrispondono a un piano Premium a zona singola. Per ogni piano di servizio app 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 pari a tre per il piano di servizio app e addebita 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 ARM.
Nel portale di Azure andare alla pagina Crea app per le funzioni. Per altre informazioni sulla creazione di un'app per le funzioni nel portale, vedere Creare un'app per le funzioni.
Selezionare Funzioni Premium quindi selezionare il pulsante Seleziona. Questo articolo descrive come creare un'app con ridondanza della zona in un piano Premium. La ridondanza della zona non è attualmente disponibile nei piani A consumo. Per informazioni sulla ridondanza della zona nei piani di servizio app, vedere Affidabilità nel Servizio app di Azure.
Nella pagina Crea app per le funzioni (Funzioni Premium) immettere le impostazioni per l'app per le funzioni nella scheda Dati principali. Prestare particolare attenzione alle impostazioni nella tabella seguente (evidenziata anche nello screenshot seguente), che presentano requisiti specifici per la ridondanza della zona.
Impostazione Valore suggerito Note sulla ridondanza della zona Area Area supportata preferita Area in cui viene creata la nuova app per le funzioni. È necessario scegliere un'area che supporta le zone di disponibilità. Vedere l'elenco di disponibilità dell'area. Piano tariffario Uno dei piani Elastic Premium. Per altre informazioni, vedere SKU di istanza disponibili. Questo articolo descrive come creare un'app con ridondanza della zona in un piano Premium. La ridondanza della zona non è attualmente disponibile nei piani A consumo. Per informazioni sulla ridondanza della zona nei piani di servizio app, vedere Affidabilità nel Servizio app di Azure. Ridondanza della zona Attivata Questa impostazione specifica se l'app è con ridondanza della zona. Non sarà possibile selezionare Enableda meno che non sia stata scelta un'area che supporta la ridondanza della zona, come descritto in precedenza.
Nella scheda Archiviazione immettere le impostazioni per l'account di archiviazione dell'app per le funzioni. Prestare particolare attenzione all'impostazione nella tabella seguente, che presenta 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 descritto nella sezione prerequisiti, è consigliabile usare un account di archiviazione con ridondanza della zona per l'app per le funzioni con ridondanza della zona. Per il resto del processo di creazione dell'app per le funzioni, creare l'app per le funzioni come di consueto. Non sono presenti impostazioni nel resto del processo di creazione che influiscono 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.
Migrazione della zona di disponibilità
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 del servizio app al supporto della zona di disponibilità.
Esperienza di inattività 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 dai set di scalabilità di macchine virtuali di Azure sottostanti. 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 e continuità aziendale tra aree
Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri 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 a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per tali servizi, l'utente ha la responsabilità di configurare un piano di ripristino di emergenza che funzioni per i propri carichi di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il piano di ripristino di emergenza.
Questa sezione illustra alcune delle strategie che è possibile usare per distribuire Funzioni per consentire il ripristino di emergenza.
Per il ripristino di emergenza per Durable Functions, vedere Ripristino di emergenza e distribuzione geografica in Durable Functions di Azure.
Ripristino di emergenza multi-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 criteri 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 criterio 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 del bus di servizio, questi vengono usati come consumer concorrenti per annullare la coda. Anche se questo significa che ogni messaggio viene elaborato solo da una delle istanze, significa anche che c'è ancora un singolo punto di errore nella singola istanza del bus di servizio.
È invece possibile distribuire due code del bus di servizio, una in un'area primaria, una in un'area secondaria. In questo caso, è possibile avere due app per le funzioni, ognuna delle quali punta alla coda del 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 il 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 il ripristino geografico del Bus di servizio di Azure e il ripristino geografico di Hub eventi di Azure.
Si consideri una topologia di esempio usando un trigger di Hub eventi di Azure. In questo caso, il modello attivo/passivo richiede i componenti seguenti:
- Hub eventi di Azure distribuito 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 nella stringa di connessione diretta (non alias) per il rispettivo hub eventi.
- I server di pubblicazione nell'hub eventi devono pubblicare nella stringa di connessione alias.
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 il Bus di servizio e Hub eventi.