Condividi tramite

Affidabilità in Funzioni di Azure

Funzioni di Azure è un servizio di calcolo basato su eventi che consente di eseguire piccoli blocchi di codice (funzioni) senza dover effettuare in modo esplicito il provisioning o la gestione dell'infrastruttura. Le funzioni possono rispondere a eventi come richieste HTTP, timer, messaggi in coda e modifiche in altri servizi di Azure, rendendoli particolarmente adatti per l'elaborazione dei dati, l'integrazione dei sistemi e l'esecuzione di attività in background.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere resilienti Funzioni di Azure a vari potenziali interruzioni e problemi, tra cui errori temporanei, errori della zona di disponibilità e errori a livello di area. Vengono inoltre evidenziate le informazioni chiave sul contratto di servizio di Funzioni di Azure.

Raccomandazioni per la distribuzione di produzione

Azure Well-Architected Framework offre raccomandazioni su affidabilità, prestazioni, sicurezza, costi e operazioni. Per comprendere in che modo queste aree influiscono tra loro e contribuiscono a una soluzione affidabile di Funzioni di Azure, vedere Procedure consigliate per l'architettura per Funzioni di Azure.

Panoramica dell'architettura di affidabilità

Quando si distribuisce Funzioni di Azure, è importante avere familiarità con diversi concetti:

  • Piani di hosting: I piani rappresentano l'ambiente di hosting per le app per le funzioni. Il piano determina le risorse di calcolo disponibili, il modello di determinazione prezzi e il comportamento di ridimensionamento.

  • Account di archiviazione: Quando si crea un'app per le funzioni, è necessario specificare un account di archiviazione host. L'account di archiviazione viene usato per gestire alcuni aspetti delle operazioni interne dell'app delle funzioni, tra cui l'archiviazione del codice della funzione, il logging e la gestione della concorrenza, come i lease blob per determinati tipi di trigger.

    È anche possibile usare un account di archiviazione per la distribuzione. Questo account di archiviazione potrebbe corrispondere all'account di archiviazione host o a un account di archiviazione diverso.

    Importante

    Gli account di archiviazione sono parti critiche dell'architettura di affidabilità di Funzioni di Azure e devono essere configurati per soddisfare i requisiti di resilienza dell'app per le funzioni.

  • Trigger e associazioni: consentono alla funzione di rispondere agli eventi, ricevere e scrivere dati da altri servizi.

  • Durable Functions: Le funzioni durevoli sono funzioni con stato, includendo orchestrazioni a lungo termine ed entità con stato.

    Quando si usa Durable Functions, si configura un provider di archiviazione che archivia lo stato. È necessario valutare le caratteristiche di affidabilità dell'archivio stati scelto e configurarlo per soddisfare i requisiti di resilienza.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Prendere in considerazione i consigli seguenti per la gestione degli errori temporanei nelle app per le funzioni:

  • Trigger e associazioni: La piattaforma Funzioni di Azure include la gestione degli errori temporanei predefinita per molti trigger e associazioni. Quando si verifica un errore temporaneo durante l'attivazione di un trigger supportato o quando un'associazione supportata sta leggendo o scrivendo dati, la piattaforma può ritentare automaticamente l'operazione. Questo comportamento di ripetizione dei tentativi predefinito consente di garantire che i problemi di connettività temporanei o i blip del servizio non impediscano l'esecuzione della funzione. Per ulteriori informazioni, vedere Gestione degli errori e ripetizioni in Azure Functions.

    Tuttavia, questa protezione riguarda solo gli errori temporanei. Gli errori permanenti, ad esempio una stringa di connessione non configurata correttamente o una risorsa eliminata, non vengono ritentati.

    Gli errori permanenti e gli errori temporanei ripetuti vengono considerati come errori ed è possibile configurare la registrazione per acquisire informazioni sugli errori di esecuzione delle funzioni. Per altre informazioni, vedere Come configurare il monitoraggio per Azure Functions.

  • Codice della funzione: All'interno del corpo della funzione, si è responsabili della gestione degli errori temporanei quando si effettuano chiamate a servizi esterni. È consigliabile implementare la logica di ripetizione dei tentativi, i timeout e i modelli di interruttore in base alle esigenze di qualsiasi chiamata al servizio esterno effettuata nel codice della funzione. Progetta le funzioni affinché siano idempotenti laddove possibile, in modo che le ripetizioni non causino effetti collaterali duplicati.

  • Clienti: Tutte le applicazioni client che si connettono a funzioni in modo sincrono, ad esempio tramite una connessione HTTP, devono essere resilienti agli errori temporanei.

Resilienza ai guasti delle zone di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

I piani a consumo non supportano le zone di disponibilità. Se la ridondanza della zona è un requisito per il carico di lavoro, si consiglia di utilizzare il piano Flex Consumption, il piano Premium o il piano Dedicated (App Service).

I piani Flex Consumption supportano le distribuzioni con ridondanza di zona.

I piani Premium supportano distribuzioni con ridondanza zonale.

Quando la ridondanza della zona è abilitata, la piattaforma distribuisce automaticamente le istanze del piano in tutte le zone di disponibilità nell'area selezionata. Se una zona di disponibilità nella regione presenta un problema, le funzioni continuano a essere eseguite usando istanze in zone funzionanti.

È anche necessario abilitare l'archiviazione zona ridondante (ZRS) nell'account di archiviazione host, assicurando che sia resiliente anche alle interruzioni della zona.

Diagramma che mostra il piano di Funzioni di Azure con ridondanza della zona con tre istanze distribuite tra tre zone e un account di archiviazione con ridondanza della zona.

Il piano dedicato (App Service) supporta le distribuzioni ridondanti a livello di zona. Quando la ridondanza della zona è abilitata, la piattaforma distribuisce automaticamente le istanze in tutte le zone di disponibilità nell'area selezionata. Configuri la ridondanza della zona nel piano. Per informazioni dettagliate su come il servizio app gestisce la ridondanza della zona, vedere Affidabilità nel servizio app di Azure.

Se non si abilita la ridondanza della zona, il piano è non zonale o regionale, il che significa che le istanze del piano potrebbero essere inserite in qualsiasi zona di disponibilità all'interno della regione o all'interno della stessa zona e non sono resilienti ai guasti delle zone di disponibilità. Il tuo servizio potrebbe riscontrare tempi di inattività durante un'interruzione in una qualsiasi zona della regione.

Requisiti

  • Supporto per regione: I piani di consumo Flex con ridondanza zonale possono essere distribuiti in un insieme specifico di regioni. È possibile recuperare l'elenco corrente delle aree supportate usando l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Visualizzare le aree che supportano le zone di disponibilità.

  • Supporto regionale: I piani Premium con ridondanza zonale possono essere distribuiti nelle aree seguenti:

    Americhe Europa Medio Oriente Africa Asia Pacifico
    Brasile meridionale Francia centrale Israel Central Sudafrica settentrionale Australia East
    Canada Central Germania centro-occidentale Qatar Central India centrale
    Central US Italia settentrionale UAE North Cina settentrionale 3
    East US North Europe East Asia
    Stati Uniti orientali 2 Norway East Japan East
    Stati Uniti centro-meridionali Svezia centrale Sud-est asiatico
    West US 2 (Regione Ovest degli Stati Uniti 2) Switzerland North
    Stati Uniti occidentali 3 UK South
    West Europe

  • Sistemi operativi: Sono supportati sia i piani Windows che Linux.

  • Numero minimo di istanze: Quando è abilitata la ridondanza di zona per i piani Premium, sono necessarie almeno due istanze sempre pronte.

  • Account di archiviazione host: È necessario configurare l'account di archiviazione host predefinito dell'app di funzione per usare l'archiviazione con ridondanza della zona (ZRS). Se si usa un account di archiviazione host che non è configurato per ZRS (zona a ridondanza), l'app potrebbe comportarsi in modo imprevisto durante un'interruzione della zona.
  • Account di archiviazione del contenitore di distribuzione: Se usi un account di archiviazione separato per il contenitore di distribuzione dell'app, dovresti aggiornarlo in modo che sia ridondante a livello di zona.

Considerazioni

La ridondanza delle zone garantisce solo la continuità operativa per le applicazioni distribuite. Un'interruzione della zona di disponibilità potrebbe influire su alcuni aspetti di Funzioni di Azure, anche se l'applicazione continua a gestire il traffico. Questi comportamenti includono la scalabilità del piano, la creazione di applicazioni, la configurazione dell'applicazione e la pubblicazione di applicazioni.

Distribuzione di istanze tra zone

Quando si configurano le app del piano a consumo Flex come con ridondanza della zona, la piattaforma distribuisce automaticamente le istanze di piano tra più zone nell'area selezionata, con regole diverse per le istanze sempre pronte rispetto alle istanze su richiesta:

  • Le istanze sempre pronte vengono distribuite tra almeno due zone seguendo un ordine rotante.

    Per garantire la resilienza della zona, 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.

  • Le istanze su richiesta vengono create come risultato di volumi di origine degli eventi man mano che l'app viene ridimensionata oltre il conteggio delle istanze sempre pronte. Le istanze su richiesta vengono distribuite tra le zone di disponibilità in modo ottimale. La scalabilità orizzontale più veloce è prioritaria rispetto alla distribuzione uniforme tra le zone. La piattaforma tenta di uniformare la distribuzione nel corso del tempo.

Quando si configurano i piani di applicazioni di funzioni Elastic Premium come a zone ridondanti, la piattaforma distribuisce automaticamente le istanze del piano tra più zone nell'area selezionata. La distribuzione delle istanze segue queste regole, anche quando l'app viene ridimensionata in ingresso e in uscita:

  • Il numero minimo di istanze delle app funzionali è due.
  • 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.

Quando Functions alloca le istanze a un piano Premium con zona ridondante, usa il bilanciamento zonale best-effort, che offrono i set di scalabilità delle 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.

Cost

Non sono previsti costi aggiuntivi associati all'abilitazione della ridondanza della zona. I prezzi per un piano a zona ridondante sono gli stessi di un piano a zona singola.

Tuttavia, quando si abilitano le zone di disponibilità in un'app con una configurazione di 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. Queste nuove istanze vengono fatturate anche come istanze sempre pronte.

Tuttavia, se si abilitano le zone di disponibilità in un piano con meno di due istanze, la piattaforma applica un numero minimo di istanze di due per tale piano e vengono addebitati i costi per entrambe le istanze.

Per informazioni dettagliate sui prezzi completi, vedere Prezzi di Funzioni di Azure.

Configurare il supporto delle zone di disponibilità

  • Creare un nuovo piano di Funzioni di Azure a ridondanza zonale. È possibile abilitare la ridondanza di zona quando si crea un nuovo piano. Per i passaggi dettagliati, vedere Creare un'app per le funzioni con ridondanza della zona.

  • Abilitare la ridondanza della zona in un piano esistente: Per i piani Premium, è possibile abilitare solo la ridondanza della zona durante la creazione del piano. Non è possibile convertire un piano Premium esistente in un piano con ridondanza di zona. È invece necessario eseguire la migrazione dell'app creando una distribuzione side-by-side in una nuova app del piano Premium. Per ulteriori informazioni, vedere Abilitare la ridondanza zonale in un piano esistente.

Pianificazione e gestione della capacità

Le app per funzioni a ridondanza zonale continuano a funzionare anche quando le zone nella regione subiscono un’interruzione.

Durante un'interruzione di zona, Azure Functions rileva le istanze mancanti e tenta automaticamente di individuare o creare istanze di sostituzione nelle zone funzionanti. Questo processo viene eseguito su base di miglior sforzo e non è garantito. Se il carico di lavoro deve avere un certo numero di istanze per mantenere il livello di servizio previsto, considerare la sovraprovvisione del numero di istanze sempre pronte. Questo approccio consente alla soluzione di tollerare alcune perdite di capacità e continuare a funzionare senza riduzione delle prestazioni. Per altre informazioni, vedere Gestire la capacità usando l'over-provisioning.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando un piano ha la ridondanza di zona, l'account di archiviazione host utilizza ZRS e tutte le zone di disponibilità sono operative.

  • Operazione tra zone: Quando si configura la ridondanza della zona in Funzioni di Azure, le richieste vengono distribuite automaticamente tra le istanze in ogni zona di disponibilità. Una richiesta potrebbe raggiungere qualsiasi istanza in qualsiasi zona di disponibilità.

  • Replica dei dati tra zone: Funzioni di Azure è un servizio di calcolo senza stato, quindi non sono presenti dati dei clienti da replicare tra le zone. La piattaforma replica automaticamente la configurazione tra le zone.

    L'Archiviazione di Azure, se l'account di archiviazione host utilizza ZRS, replica in modo sincrono i suoi dati in più zone di disponibilità.

    Per Durable Functions, rivedere il provider di archiviazione per comprendere come distribuisce i dati tra le zone.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando un piano è zone ridondante, l'account di archiviazione host utilizza ZRS, e si verifica un'interruzione della zona di disponibilità.

  • Rilevamento e risposta: La piattaforma Funzioni di Azure è responsabile del rilevamento di un errore in una zona di disponibilità. Non è necessario eseguire alcuna operazione per avviare un failover di zona.
  • Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Azure Resource Health per monitorare l'integrità di una singola risorsa ed è possibile configurare Resource Health avvisi per segnalare eventuali problemi. È anche possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità dei servizi per notificare i problemi.

  • Richieste attive: Quando una zona di disponibilità non è disponibile, tutte le richieste in corso connesse a un'istanza nella zona di disponibilità difettosa vengono terminate e devono essere ritentate. Assicurarsi che le applicazioni vengano preparate seguendo le indicazioni sulla gestione degli errori temporanei.

  • Perdita di dati prevista: Gli errori di zona non si prevede che causino perdite di dati perché Funzioni di Azure è un servizio senza stato.

    Se l'account di archiviazione host utilizza l'archiviazione con ridondanza della zona (ZRS), Archiviazione di Azure assicura che non vi sia alcuna perdita di dati in caso di errore di zona.

    Per le Durable Functions, esaminare il provider di archiviazione per capire se è possibile la perdita di dati durante un guasto nella zona.

  • Tempo di inattività previsto: Durante le interruzioni della zona, le connessioni potrebbero riscontrare brevi interruzioni che in genere durano alcuni secondi perché il traffico viene ridistribuito. Assicurarsi che le applicazioni vengano preparate seguendo le indicazioni sulla gestione degli errori temporanei.

  • Reindirizzamento del traffico: Funzioni di Azure rileva le istanze perse da tale zona e tenta di trovare nuove istanze di sostituzione. Dopo che Funzioni di Azure trova le sostituzioni, distribuisce il traffico tra le nuove istanze in base alle esigenze.

    Importante

    Azure non garantisce che le richieste per più istanze riescano in uno scenario zone-down. La piattaforma tenta di eseguire il back-fill delle istanze perse su una base best-effort. Se è necessaria capacità garantita durante un errore della zona di disponibilità, creare e configurare i piani per tenere conto della perdita di una zona attraverso il sovra-provisionamento della capacità.

  • Comportamenti non di esecuzione: Le applicazioni in un piano di app per le funzioni con ridondanza della zona continuano a essere eseguite e a gestire il traffico anche se si verifica un'interruzione della zona di disponibilità. Tuttavia, l'interruzione di una zona di disponibilità può influire sui comportamenti non di runtime. Questi comportamenti includono il ridimensionamento delle app per le funzioni, la creazione di applicazioni, la configurazione dell'applicazione e la pubblicazione di applicazioni.

Ripristino della zona

Quando la zona di disponibilità viene ripristinata, Funzioni di Azure ripristina automaticamente le istanze nella zona di disponibilità, rimuove tutte le istanze temporanee create nelle altre zone di disponibilità e reindirizza il traffico tra le istanze come di consueto.

Verifica dei guasti di zona

La piattaforma Funzioni di Azure gestisce il routing del traffico, il failover e il ripristino della zona per le risorse con ridondanza della zona. Non è necessario avviare nulla. Poiché questa funzionalità è completamente gestita, non è necessario convalidare i processi di errore della zona di disponibilità.

Resilienza agli errori a livello di area

Funzioni di Azure è un servizio a singola area. Se l'area non è più disponibile, anche la risorsa di Funzioni di Azure non è disponibile.

Soluzioni personalizzate in più aree per la resilienza

Per evitare la perdita di esecuzione durante le interruzioni, è possibile distribuire in modo ridondante le stesse funzioni in app per le funzioni in più aree.

L'utente è responsabile di:

  • Distribuzione di app per le funzioni in più aree
  • Gestione della distribuzione del traffico tra aree
  • Implementazione di meccanismi di failover
  • Garantire la coerenza dei dati tra aree (se applicabile)
  • Monitoraggio e gestione delle distribuzioni tra aree

Quando si esegue lo stesso codice di funzione in più aree, è possibile considerare due modelli di uso comune: attivo-attivo e attivo-passivo. Le sezioni seguenti forniscono una breve introduzione a questi modelli, ma non forniscono istruzioni dettagliate o passaggi di configurazione.

Modello attivo-attivo per le funzioni trigger HTTP

Con un modello attivo-attivo, le funzioni in entrambe le aree eseguono ed elaborano eventi attivamente, in modo duplicato o a rotazione. È consigliabile usare un modello attivo-attivo in combinazione con Azure Front Door per le funzioni critiche attivate da HTTP, che possono instradare ed eseguire richieste HTTP in modalità round-robin tra funzioni in esecuzione in più aree. Frontdoor di Azure può anche controllare periodicamente l'integrità di ogni endpoint. Se una funzione in un'area smette di rispondere ai controlli di integrità, Azure Front Door la rimuove dalla rotazione e inoltra solo il traffico alle funzioni ancora integre rimanenti.

Diagramma che mostra un'architettura attiva-attiva di esempio, con il routing di Frontdoor di Azure tra le app di Funzioni di Azure in aree diverse, ognuna con il proprio database.

Modello attivo-passivo per le funzioni trigger non HTTP

Per le funzioni attivate da eventi non HTTP ,ad esempio il bus di servizio e le funzioni attivate da Hub eventi, usare un modello attivo-passivo. Con un modello attivo-passivo, le funzioni vengono eseguite attivamente nell'area che riceve eventi, mentre le stesse funzioni in una seconda area rimangono inattive. Il modello attivo-passivo consente a una sola funzione di elaborare ogni messaggio, che è importante per mantenere la coerenza dei dati, fornendo anche un meccanismo per eseguire il failover nell'area secondaria in un'emergenza come un'interruzione dell'area.

Il failover dell'applicazione delle funzioni deve essere considerato insieme ai comportamenti di failover di altri servizi, ad esempio:

Si consideri una topologia di esempio utilizzando un trigger di Azure Event Hubs, in cui lo spazio dei nomi di Event Hubs è configurato per il ripristino di emergenza geografico. In questo caso, il modello attivo-passivo richiede i componenti seguenti:

  • Hub eventi di Azure distribuito in un'area primaria e secondaria.
  • Abilitazione del ripristino di emergenza geografico per associare l'event hub primario e secondario. Viene creato anche un alias che puoi usare per connetterti al namespace di Event Hubs, e passare dal primario al secondario senza dover cambiare le informazioni di connessione.
  • Le applicazioni function sono distribuite nell'area primaria e secondaria (failover), in quanto l'app nell'area secondaria è essenzialmente inattiva perché i messaggi non vengono inviati in quell'area.
  • L'app per le funzioni viene attivata sulla stringa di connessione diretta (nonalias) per il rispettivo namespace di Event Hubs.
  • I publisher del namespace di Event Hubs devono utilizzare la stringa di connessione dell'alias.

Diagramma che illustra un esempio di architettura attiva-passiva, con il ripristino geo-disaster di Event Hubs che si estende su più regioni e app di funzione e database separati in ogni regione.

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.

Funzioni durevoli

Per il ripristino di emergenza in più aree per Azure Durable Functions, vedere Ripristino di emergenza e distribuzione geografica in Azure Durable Functions.

Resilienza alla manutenzione del servizio

Funzioni di Azure esegue aggiornamenti regolari del servizio e altre attività di manutenzione.

  • Resilienza degli errori temporanei: Durante la manutenzione del servizio, le istanze che eseguono l'app per le funzioni potrebbero essere riavviate o potrebbero verificarsi interruzioni temporanee. Assicurarsi che tutte le applicazioni client che interagiscono con l'app per le funzioni siano resilienti agli errori temporanei.
  • Abilitare la ridondanza della zona: Quando si abilita la ridondanza della zona nel piano, si migliora anche la resilienza durante gli aggiornamenti della piattaforma. Distribuire più istanze nel piano e abilitare la ridondanza di zona per il piano aggiungono un ulteriore livello di resilienza se un'istanza o una zona diventa non disponibile nel corso di un aggiornamento.

Per mantenere la capacità prevista durante un aggiornamento, la piattaforma aggiunge automaticamente istanze aggiuntive del piano durante il processo di aggiornamento.

  • Abilitare la ridondanza della zona: Quando si abilita la ridondanza della zona nel piano, si migliora anche la resilienza durante gli aggiornamenti della piattaforma. I domini di aggiornamento sono costituiti da raccolte di macchine virtuali che passano offline durante un aggiornamento ed eseguono il mapping alle zone di disponibilità. La distribuzione di più istanze nel piano e l'abilitazione della ridondanza di zona per il piano aggiungono un ulteriore livello di resilienza se un'istanza o una zona diventa non funzionale durante un aggiornamento.

  • Ambiente del servizio app: Se si ospita l'app per le funzioni in un ambiente del servizio app, è possibile personalizzare il ciclo di aggiornamento. Se è necessario convalidare l'effetto degli aggiornamenti nel carico di lavoro, abilitare gli aggiornamenti manuali. Questo approccio consente di eseguire la convalida e i test su un'istanza non di produzione prima di applicarli all'istanza di produzione.

    Per altre informazioni sulle preferenze di manutenzione, vedere Preferenze di aggiornamento per la manutenzione pianificata dell'ambiente del servizio app.

Resilienza alle distribuzioni di applicazioni

Le distribuzioni di applicazioni introducono il rischio di problemi a un ambiente di produzione. È consigliabile essere pronti a eseguire il rollback di un aggiornamento in caso di problemi. È anche consigliabile controllare come vengono implementati gli aggiornamenti per ridurre al minimo le interruzioni dai riavvii dell'applicazione.

I piani Flex Consumption supportano le strategie di aggiornamento del sito, che offre diversi modi per distribuire gli aggiornamenti delle app, inclusi gli aggiornamenti in sequenza per distribuzioni senza tempi di inattività.

Gli slot di distribuzione di Azure Functions consentono implementazioni senza interruzioni delle tue app per le funzioni. Usare gli slot di distribuzione per ridurre al minimo l'effetto delle distribuzioni e delle modifiche di configurazione per gli utenti. Gli slot di distribuzione riducono anche la probabilità che l'applicazione si riavvii. Il riavvio dell'applicazione causa un errore temporaneo.

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per altre informazioni, vedere SLA per servizi online.

Funzioni di Azure offre contratti di servizio di disponibilità distinti per il piano a consumo e per altri tipi di piano.

Contenuti correlati

  • Last updated on