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.
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 dipende dal piano di hosting di Funzioni:
| Piano di hosting | Livello di supporto | Per altre informazioni... |
|---|---|---|
| Piano di consumo flessibile | Anteprima | Selezionare Flex Consumption (Consumo flessibile ) nella parte superiore di questo articolo. |
| Piano Elastic Premium | GA | Selezionare Premium nella parte superiore di questo articolo. |
| Piano dedicato (servizio app) | GA | Vedere Affidabilità nel servizio app di Azure. |
| Piano A consumo | non disponibile | Non supportato dal piano di consumo. |
Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di ogni area di Azure. In caso di errore di una zona, i servizi possono eseguire il failover in una delle zone rimanenti.
Per altre informazioni sulle zone di disponibilità in Azure, vedere Che cosa sono le zone di disponibilità?
Funzioni di Azure supporta una distribuzione con ridondanza della zona.
Supporto delle zone di disponibilità
Importante
Il supporto per le zone di disponibilità nell'hosting dell'app in un piano a consumo Flex è attualmente in fase di anteprima.
Quando si configurano le app del piano a consumo Flex come ridondanti a livello di zona, la piattaforma distribuisce automaticamente le istanze delle applicazioni per funzione tra le zone nell'area selezionata, con regole diverse per le istanze sempre pronte rispetto alle istanze su richiesta.
Quando ridondanza di zona è abilitata in un Piano a Consumo Flessibile, la distribuzione delle istanze è determinata secondo le seguenti regole:
- Le istanze sempre pronte vengono distribuite tra le zone in modo circolare.
- Le istanze su richiesta, che vengono create a seguito di volumi di eventi sorgente quando l'app è ridimensionata oltre il suo stato sempre pronto, vengono distribuite tra le zone di disponibilità in base al migliore impegno possibile. Ciò significa che, per le istanze su richiesta, la scalabilità orizzontale più veloce ha la preferenza rispetto alla distribuzione uniforme tra le zone di disponibilità. La piattaforma tenta di equilibrare la distribuzione nel tempo.
- Per garantire la resilienza della zona con le zone di disponibilità, la piattaforma gestisce automaticamente almeno due istanze sempre pronte per ogni funzione o gruppo di scalabilità, indipendentemente dalla configurazione sempre pronta per l'app. Tutte le istanze create dalla piattaforma sono gestite dalla piattaforma, fatturate come istanze sempre pronte e non modificano le impostazioni di configurazione sempre pronte.
Quando si configurano i piani di app per le funzioni Elastic Premium come ridondanti a livello zonale, la piattaforma distribuisce automaticamente le istanze dell'app per le funzioni nelle zone della regione 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 del numero di zone, le istanze vengono distribuite in modo uniforme solo quando la capacità è un multiplo del numero di zone.
- Per un valore di capacità maggiore del numero di zone * numero di istanze, le istanze aggiuntive vengono distribuite tra le 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 le app per le funzioni del piano Premium vengono definiti piani Elastic Premium, con nomi di SKU come EP1. Se scegli di eseguire l'app delle funzioni in un piano Premium, assicurati di creare un piano con un nome SKU che inizia con E, ad esempio EP1. I nomi degli SKU del piano di servizio app che iniziano con P, ad esempio P1V2 (piano Premium V2 Small), sono 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
Attualmente, non tutte le aree supportano la ridondanza di zona per i piani di consumo Flex. È possibile usare l'interfaccia della riga di comando di Azure per visualizzare le aree che lo supportano:
Se non è già stato fatto, installare e accedere ad Azure usando l'interfaccia della riga di comando di Azure:
az loginIl comando
az loginconsente di accedere all'account Azure.Usare questo
az functionapp list-flexconsumption-locationscomando con l'opzione--zone-redundant=trueper visualizzare un elenco di aree che supportano attualmente i piani Flex Consumption con ridondanza di zone:az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table
Quando si crea un'app Flex Consumption nel portale di Azure, la Zone redundancy sezione della pagina Informazioni di base viene abilitata quando l'area scelta la supporta.
I piani Premium con ridondanza zonale sono disponibili in queste regioni:
| 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 (Regione Ovest degli Stati Uniti 2) | Svizzera settentrionale | |||
| Stati Uniti occidentali 3 | Regno Unito meridionale | |||
| Europa occidentale |
Prerequisiti
Il supporto della zona di disponibilità è una proprietà del piano Flex Consumption. Di seguito sono riportate le considerazioni correnti per l'uso delle zone di disponibilità:
- È possibile abilitare le zone di disponibilità nel piano durante la creazione dell'app.
- È possibile abilitare o disabilitare le zone di disponibilità aggiornando le impostazioni delle risorse del piano.
- È necessario usare un account di archiviazione con ridondanza di zona per l'account di archiviazione host predefinito dell'app per le funzioni. Se usi un tipo diverso di account di archiviazione, l'app potrebbe comportarsi in modo imprevisto durante un'interruzione zonale.
- Deve essere ospitato in un piano Flex Consumption .
Il supporto della zona di disponibilità è una proprietà del piano Premium. Di seguito sono riportate le considerazioni correnti per le zone di disponibilità:
- È possibile abilitare le zone di disponibilità nel piano solo quando si crea l'app. Non è possibile convertire un piano Premium esistente per usare le zone di disponibilità.
- È necessario usare un account di archiviazione con ridondanza della zona perl'account di archiviazione host predefinito dell'app per le funzioni. Se usi un tipo di account di archiviazione diverso, l'app potrebbe comportarsi in modo imprevisto durante un'interruzione zonale.
- Sono supportati sia Windows che Linux.
- Le app per funzioni ospitate su un piano Premium devono avere almeno tre istanze sempre pronte.
- 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
Nessun contatore separato associato all'abilitazione delle zone di disponibilità. I prezzi delle istanze utilizzate per un'app Flex Consumption ridondante a livello di zona sono gli stessi di un'app Flex Consumption a singola zona. Per maggiori informazioni, vedere Fatturazione.
Quando si abilitano le zone di disponibilità in un'app con configurazione dell'istanza sempre pronta per meno di due istanze per ogni funzione o gruppo di scalabilità, la piattaforma crea automaticamente due istanze del tipo sempre pronto per ogni funzione o gruppo di scalabilità per ogni funzione. Queste nuove istanze vengono fatturate anche come istanze sempre pronte.
Non sono previsti costi aggiuntivi associati all'abilitazione delle zone di disponibilità. I prezzi per un piano di Servizio App Premium con ridondanza zonale sono uguali 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à in un piano con meno di tre istanze, la piattaforma applica un numero minimo di istanze pari a tre per il piano di servizio app e vengono addebitati i costi per tutte e tre le istanze.
Creare un'applicazione di funzione in un piano a ridondanza di zona
Esistono attualmente diversi modi per distribuire un'app Flex Consumption a ridondanza di zona.
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 Flex Consumption (Consumo flessibile ) e quindi selezionare il pulsante Seleziona .
Nella pagina Crea app per le funzioni (Consumo flessibile) immettere le impostazioni per l'app per le funzioni nella scheda Informazioni di base . 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 creato il piano Flex Consumption. È necessario selezionare un'area che supporta le zone di disponibilità. Vedere l'elenco di disponibilità dell'area. Ridondanza della zona Attivata Questa impostazione specifica se l'app è con ridondanza della zona. È possibile selezionare Enabledsolo quando è stata scelta un'area che supporta la ridondanza della zona.
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 a ridondanza di zona, l'app per le funzioni Flex Consumption ospitata nel nuovo piano viene considerata a ridondanza di zona.
Aggiornare un piano di consumo flessibile per garantire la ridondanza zonale
La modifica della ridondanza della zona dell'app richiede un riavvio, causando interruzioni nell'app.
Prima di aggiornare il piano Flex Consumption in modo che sia a zone-ridondante, è necessario aggiornare anche l'account di archiviazione host predefinito per renderlo anch'esso a zone-ridondante. Se si usa un account di archiviazione separato per il contenitore di distribuzione dell'app, è consigliabile aggiornarlo anche in modo che sia ridondante della zona.
Usare questi passaggi per preparare gli account di archiviazione per la modifica:
- Vedere Considerazioni sull'archiviazione.
- Creare o identificare un account di archiviazione a ridondanza di zona come account predefinito per l'archiviazione host dell'app.
- Aggiorna le impostazioni dell'app relative alla memorizzazione, come
AzureWebJobsStorage, per fare riferimento a un account di archiviazione a ridondanza di zona. Vedere Usare le impostazioni dell'applicazione. - Aggiornare l'account di archiviazione di distribuzione per l'app, che può essere uguale o diverso dall'account di archiviazione associato all'app. Vedere Configurare le impostazioni di distribuzione.
Dopo aver aggiornato gli account di archiviazione utilizzati dalla tua app, puoi aggiornare il piano Flex a consumo per renderlo ridondante rispetto alla zona, utilizzando modelli Bicep o ARM. Il portale di Azure attualmente non supporta modifiche alla ridondanza zonale del piano.
Attualmente non supportata.
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.
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 creato il piano Elastic Premium. È 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à
Non è attualmente possibile modificare il supporto della zona di disponibilità di un piano Elastic Premium per un'app per le funzioni esistente. Per informazioni su come eseguire la migrazione del piano Premium multi-tenant pubblico dalla zona di non 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 disponibili delle app di funzioni del piano Flex a consumo con ridondanza zonale sono abilitate ed elaborano eventi. Le app Flex Consumption continuano a essere eseguite anche quando altre zone nella stessa area subiscono un'interruzione. Tuttavia, è possibile che i comportamenti non runtime possano essere influenzati a causa di un'interruzione in zone di disponibilità diverse. I comportamenti standard dell'app per le funzioni che possono influire sulla disponibilità includono:
- Scalabilità
- Creazione di app
- Modifiche alla configurazione
- Implementazioni
La ridondanza della zona nei piani Flex Consumption garantisce unicamente un tempo di attività continuo per le applicazioni distribuite in esecuzione.
Quando una zona diventa inattiva, Funzioni rileva le istanze perse e tenta automaticamente di individuare o creare istanze di sostituzione, in base alle esigenze, nelle zone disponibili. Durante un'interruzione zonale, la piattaforma tenta di ripristinare il bilanciamento nelle restanti zone disponibili.
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 riduzione della zona non vi è alcuna garanzia che le richieste per più istanze abbiano successo, poiché il ripristino delle istanze perse avviene al meglio delle capacità. 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 runtime possano comunque essere impattati da un'interruzione del servizio 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 in tutte le altre zone usate dal piano Premium, più o meno una macchina virtuale.
Ripristino di emergenza e continuità aziendale tra aree
Il ripristino di emergenza si riferisce alle procedure usate dalle organizzazioni per 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 creare il piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Per il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In questo modello Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Tuttavia, 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, si è responsabili 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 indicazioni per supportare il ripristino di emergenza. È possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per sviluppare il piano di ripristino di emergenza.
Questa sezione illustra alcune delle strategie che è possibile usare per distribuire un'app per le 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 critiche attivate da HTTP, che possono instradare e eseguire richieste HTTP round robin tra 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.
Per un esempio, vedere l'esempio su come implementare il modello geode distribuendo l'API ai geodes nelle aree di Azure distribuite.
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'applicazione di funzione viene attivata sulla 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.
Modello attivo-attivo per le funzioni trigger non-HTTPS
Sebbene sia consigliabile usare il modello attivo-passivo per le funzioni trigger non HTTPS, è comunque possibile creare distribuzioni attive-attive per funzioni non attivate da HTTP. Prima di implementare questo modello, è necessario considerare il modo in cui le due aree attive interagiscono o coordinano tra loro.
Si supponga, ad esempio, di avere lo stesso codice di funzione attivato dal Service Bus distribuito in due regioni, ma che si attivi sulla stessa coda del Service Bus. In questo caso, entrambe le funzioni fungono da consumer concorrenti per annullare la coda singola. Anche se ogni messaggio può essere elaborato solo da una delle due istanze dell'app, significa anche che esiste ancora un singolo punto di errore, ovvero la 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.