Affidabilità in Funzioni di Azure

Funzioni di Azure è un servizio di calcolo basato su eventi che esegue piccoli blocchi di codice o functions, senza provisioning o gestione espliciti dell'infrastruttura. Le funzioni possono rispondere a eventi come richieste HTTP, timer, messaggi di coda e modifiche in altri servizi di Azure. Questa funzionalità rende funzioni particolarmente adatte per l'elaborazione dei dati, l'integrazione del sistema e le 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 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 sull'accordo sul livello di servizio (SLA) per le Azure Functions.

Raccomandazioni per la distribuzione di produzione

Azure Well-Architected Framework offre raccomandazioni su affidabilità, sicurezza, costi, operazioni e prestazioni. Per informazioni su come queste aree influiscono l'una sull'altra e contribuiscono a una soluzione reliable Functions, vedere Procedure consigliate per l'architettura per funzioni.

Panoramica dell'architettura di affidabilità

Quando si distribuiscono Funzioni, è importante acquisire familiarità con questi 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 tariffario 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 gestisce gli aspetti delle operazioni interne della funzione app, tra cui l'archiviazione del codice della funzione, il logging e la gestione della concorrenza, come i lease dei 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 una parte fondamentale dell'architettura di affidabilità di Funzioni. Configurarli per soddisfare i requisiti di resilienza dell'applicazione di funzione.

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

  • Funzioni durevoli: Funzioni durevoli è una funzionalità di Funzioni. Fornisce funzioni con stato, ad esempio orchestrazioni a esecuzione prolungata ed entità con stato.

    Quando si usano funzioni durevoli, si configura un provider di archiviazione che archivia lo stato. 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 include la gestione degli errori temporanei predefinita per trigger e associazioni. Quando si verifica un errore temporaneo durante l'attivazione di un trigger supportato o quando un'associazione supportata legge o scrive i dati, la piattaforma può ripetere automaticamente l'operazione. Questo comportamento di ripetizione dei tentativi predefinito garantisce che i problemi di connettività temporanei o le interruzioni del servizio non impediscano l'esecuzione della funzione. Per altre informazioni, vedere Gestione degli errori e tentativi di funzioni.

    Questa protezione copre solo gli errori temporanei. La piattaforma non ritenta gli errori persistenti, ad esempio un stringa di connessione non configurato correttamente o una risorsa eliminata.

    La piattaforma considera gli errori persistenti e gli errori temporanei ripetuti come errori. Configurare la registrazione per acquisire informazioni sugli errori di esecuzione delle funzioni. Per altre informazioni, vedere Configurare il monitoraggio per funzioni.

  • Codice della funzione: Nel codice della funzione si è responsabili della gestione degli errori temporanei quando la funzione chiama servizi esterni. Implementare la logica di ripetizione dei tentativi, i timeout e gli schemi di interruttore di circuito come appropriato per le chiamate di servizio esterne effettuate nel codice della tua funzione. Progettare le funzioni in modo che siano idempotenti, se possibile, in modo che i tentativi non creino effetti collaterali duplicati.

  • Clienti: Le applicazioni client che si connettono alle 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, considera di usare i piani Flex Consumption, Premium o Dedicated (Servizio app di Azure).

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à nell'area presenta un problema, le funzioni continuano a essere eseguite usando istanze in zone integre.

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

Diagramma che mostra un piano delle Funzioni con ridondanza di zona, con tre istanze distribuite tra tre zone e un account ZRS.

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 ulteriori informazioni su come Servizio app di Azure gestisce la ridondanza di zona, consultare Reliability in App Service.

Il piano è non zonale o regionale quando non si abilita la ridondanza della zona. La piattaforma può posizionare istanze di piano in qualsiasi zona di disponibilità nella regione o nella stessa zona. Le istanze del piano non sono resilienti agli errori della zona di disponibilità. Il tuo servizio potrebbe riscontrare tempi di inattività durante un'interruzione in una qualsiasi zona della regione.

Requisiti

  • Supporto per la regione: È possibile distribuire piani Flex Consumption con ridondanza tra zone in un set 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 della regione: È possibile distribuire piani Premium a ridondanza zonale nelle regioni 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

  • Operating systems: La piattaforma supporta la distribuzione di piani Windows e Linux ridondanti a livello di zona.

  • Numero minimo di istanze: La ridondanza della zona per i piani Premium richiede almeno due istanze sempre pronte.

  • Account di archiviazione host: È necessario configurare l'account di archiviazione dell'host di default dell'app per le funzioni per usare ZRS. Se utilizzi un account di archiviazione host non configurato per l'archiviazione con ridondanza della zona, l'app potrebbe comportarsi in modo imprevisto durante un'interruzione della zona.
  • Account di archiviazione del contenitore di distribuzione: Se si utilizza un account di archiviazione separato per il contenitore di distribuzione dell'app, aggiornarlo anche per renderlo ridondante a livello di zona.

Considerazioni

Comportamenti non di runtime: La ridondanza zonale garantisce solo un'operatività continua per le applicazioni distribuite. Un'interruzione della zona di disponibilità potrebbe influire sugli aspetti di Funzioni, 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 del piano in più zone nell'area selezionata, con regole diverse per le istanze sempre pronte rispetto alle istanze su richiesta:

  • Le istanze always-ready vengono distribuite in almeno due zone usando la distribuzione round robin.

    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. Le istanze create dalla piattaforma vengono gestite dalla piattaforma, fatturate come istanze sempre pronte e non modificano le impostazioni di configurazione sempre pronte.

  • Le istanze su richiesta derivano dai volumi degli eventi sorgente all'aumentare delle dimensioni dell'app oltre il numero di istanze sempre attive. Le istanze su richiesta vengono distribuite tra le zone di disponibilità in modo ottimale. La piattaforma assegna priorità al rapido aumento della capacità piuttosto che alla distribuzione uniforme tra le zone. La piattaforma tenta di uniformare la distribuzione nel corso del tempo.

Quando si configurano i piani di app Elastic Premium a ridondanza zonale, la piattaforma distribuisce automaticamente le istanze di piano tra zone multiple nella regione 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 moltiplicate per il numero di istanze, le istanze aggiuntive vengono distribuite tra le zone rimanenti.

Quando Funzioni alloca istanze a un piano Premium con ridondanza della zona, usa best-effort zone balancing, che fornisce il Set di scalabilità di macchine virtuali di Azure sottostante. Azure considera un piano Premium balanced quando ogni zona ha lo stesso numero di macchine virtuali (VM) delle altre zone del piano, più o meno una macchina virtuale.

Cost

Non ci sono costi extra quando si abilita la ridondanza della zona geografica. I prezzi per un piano a zona ridondante sono gli stessi di un piano a zona singola. Tuttavia, abilitare la ridondanza zonale influisce sul numero minimo di istanze del piano.

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 di scalabilità per funzione. Queste nuove istanze vengono fatturate anche come istanze sempre pronte.

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 delle Funzioni.

Configurare il supporto delle zone di disponibilità

  • Creare un nuovo piano di Funzioni con ridondanza zonale. È possibile abilitare la ridondanza della zona quando si crea un nuovo piano. Per altre informazioni, vedere Creare un'applicazione di funzione ridondante a livello di zona.

  • Abilitare la ridondanza della zona in un piano esistente. È possibile attivare o disattivare le zone di disponibilità per i piani Elastic Premium esistenti. I piani Elastic Premium hanno un comportamento specifico della capacità che differisce dai piani dedicati (servizio app) e richiede passaggi di configurazione aggiuntivi. Per i passaggi dettagliati, vedere Abilitare la ridondanza della zona in un piano esistente.

  • Creare un nuovo piano di Funzioni con ridondanza di zona. È possibile abilitare la ridondanza della zona quando si crea un nuovo piano. Per ulteriori informazioni, consultare Creare un'app per le funzioni a tolleranza di errore zonale.

  • Abilitare la ridondanza zonale in un piano esistente. Per i piani Premium, è possibile abilitare la ridondanza di zona solo durante la creazione del piano. Non è possibile convertire un piano Premium esistente in un piano a disponibilità di zona. Eseguire invece la migrazione dell'app creando una distribuzione affiancata 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 applicazioni con ridondanza regionale continuano a funzionare anche quando le zone subiscono un'interruzione.

Durante un'interruzione di zona, Funzione rileva le istanze perse e tenta automaticamente di individuare o creare istanze di sostituzione nelle zone sane. La piattaforma esegue questo processo in modo ottimale e non garantisce il successo. Se il carico di lavoro richiede un numero specifico di istanze per mantenere il livello di servizio previsto, considerare il sovraprovisionamento del numero di istanze in standby. L'overprovisioning consente alla soluzione di tollerare la perdita di capacità e continuare a funzionare senza ridurre le prestazioni. Per maggiori informazioni, consultare Gestire la capacità tramite l'overprovisioning.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando un piano è ridondante a livello di zona, l'account di archiviazione host usa ZRS (Zona di Ridondanza dello Storage) e tutte le zone di disponibilità sono operative.

  • Operazione tra zone: Quando si configura la ridondanza della zona in Funzioni, 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 è un servizio di calcolo senza stato, quindi non sono presenti dati da replicare tra 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 le funzioni durevoli, verifica il tuo provider di archiviazione per scoprire come replica i dati tra le zone.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando un piano è a ridondanza geografica, l'account di archiviazione host utilizza ZRS e si verifica un'interruzione di una zona di disponibilità.

  • Rilevamento e risposta: La piattaforma Funzioni è responsabile del rilevamento di un errore in una zona di disponibilità. Non è necessario avviare un failover di zona.

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

  • Perdita di dati prevista: Gli errori di zona non devono causare la perdita di dati perché Funzioni è un servizio senza stato.

    Se l'account di archiviazione host utilizza l'archiviazione con ridondanza della zona (ZRS), viene assicurato che non ci sia perdita di dati in caso di un errore di zona.

    Per le funzioni durevoli, esamina il provider di archiviazione per scoprire se è possibile la perdita di dati durante un guasto di 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 siano preparate seguendo le indicazioni sulla gestione degli errori temporanei.

  • Reindirizzamento del traffico: Funzioni rileva le istanze perse da tale zona e tenta di trovare nuove istanze di sostituzione. Dopo che Funzioni 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'interruzione della zona di disponibilità, creare e configurare i piani per tenere conto della perdita di zona sovrapprovvigionando la 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 ripristina automaticamente le istanze nella zona di disponibilità, rimuove 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 gestisce l'instradamento del traffico, il failover, e il ripristino della zona per le risorse ridondate a livello di zona. Non è necessario avviare nulla. Azure completamente gestisce questa funzionalità, quindi non è necessario convalidare i processi di errore della zona di disponibilità.

Resilienza agli errori a livello di area

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

Soluzioni personalizzate in più aree per la resilienza

Per evitare interruzioni del servizio durante le interruzioni a livello di area, è possibile distribuire in modo ridondante le stesse funzioni nelle 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, considerare i modelli attivo-attivo e attivo-passivo . Le sezioni seguenti introducono questi modelli, ma non forniscono indicazioni dettagliate o passaggi di configurazione.

Modello attivo-attivo per le funzioni trigger HTTP

In un modello attivo-attivo, le funzioni in entrambe le aree eseguono attivamente ed elaborano gli eventi, in modo duplicato o in rotazione. 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 eseguite 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à, Frontdoor di Azure la rimuove dalla rotazione e inoltra solo il traffico alle funzioni integre rimanenti.

Diagramma che mostra un'architettura attiva-attiva di esempio. Frontdoor di Azure instrada tra app di Funzioni nelle diverse regioni, ognuna con il proprio database.

Modello attivo-passivo per le funzioni trigger non HTTP

Per le funzioni attivate da eventi non HTTP (ad esempio bus di servizio di Azure e trigger di Hub eventi di Azure), usare un modello attivo-passivo. In un modello attivo-passivo le istanze di funzione vengono eseguite nell'area che riceve eventi, mentre le istanze nell'area secondaria rimangono inattive. Questo modello garantisce che ogni messaggio sia elaborato da una sola funzione, che consente di mantenere la coerenza dei dati. Offre anche un modo per eseguire il failover verso la regione secondaria durante un'emergenza, ad esempio un'interruzione della regione.

Prendere in considerazione il failover dell'app per le funzioni insieme ai comportamenti di failover di altri servizi usati, ad esempio:

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

  • Namespace di Event Hubs implementati nelle regioni primaria e secondaria.

  • Abilitazione del ripristino di emergenza geografico per associare l'event hub primario e secondario. Questa configurazione crea anche un alias che è possibile usare per connettersi allo spazio dei nomi di Hub eventi e passare dall'alias primario al secondario senza apportare modifiche alle informazioni di connessione.

  • App di funzione distribuite sia nella regione primaria che secondaria. L'app nell'area secondaria rimane inattiva perché non riceve messaggi.

  • I trigger di ogni app per le funzioni usano il < stringa di connessione c0>direct (nonalias) per il rispettivo spazio dei nomi di Hub eventi.

  • I server di pubblicazione nello spazio dei nomi di Hub eventi pubblicano nell'alias stringa di connessione.

Diagramma che mostra un'architettura attiva-passiva di esempio. Il ripristino di emergenza geografico dei Event Hubs si estende su più aree, con app per le funzioni e database separati in ogni area.

Prima del failover, i pubblicatori che inviano eventi instradano il traffico attraverso l'alias condiviso all'hub eventi primario. L'app della funzione principale ascolta esclusivamente l'hub eventi principale. L'app per le funzioni secondaria rimane passiva e inattiva.

All'avvio del failover, i server di pubblicazione che inviano eventi all'alias condiviso vengono indirizzati all'hub eventi secondario. L'app delle funzioni secondaria diventa attiva e si avvia automaticamente. L'hub eventi può guidare l'intero processo di failover e ogni app per le funzioni viene eseguita solo quando l'hub eventi corrispondente è attivo.

Funzioni durevoli

Per il ripristino di emergenza in più aree per le funzioni durevoli di Azure, consultare Disaster recovery and geo-distribution in Azure Durable Functions.

Resilienza alla manutenzione del servizio

La funzione 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 riavviare o riscontrare interruzioni temporanee. Assicurarsi che 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. La distribuzione di più istanze nel tuo piano e l'abilitazione della ridondanza a livello di zona per il piano aggiungono un ulteriore livello di resilienza se un'istanza o una zona diventa non funzionante durante un aggiornamento.

  • Istanze temporanee aggiuntive: 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 zonale per il piano aggiungono un ulteriore livello di resilienza se un'istanza o una zona diventa non funzionante 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. Usare questo approccio per convalidare e testare un'istanza non di produzione prima di applicare gli aggiornamenti 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 in un ambiente di produzione. Se si verificano problemi, è possibile eseguire il rollback di un aggiornamento. Controllare la modalità di implementazione degli aggiornamenti per ridurre le interruzioni dai riavvii dell'applicazione.

I Piani di Consumo Flex sostengono le strategie di aggiornamento del sito, che offrono diversi modi per distribuire gli aggiornamenti delle app. Queste strategie includono aggiornamenti continui per distribuzioni senza tempi di inattività.

Gli slot di distribuzione delle funzioni consentono distribuzioni senza tempi di inattività delle 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. I riavvii dell'applicazione causano errori temporanei.

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.

Functions fornisce SLA di disponibilità distinti per il piano a consumo e per altri tipi di piano.

Contenuti correlati

  • Last updated on