Affidabilità nel servizio app Azure

Questo articolo descrive il supporto per l'affidabilità in app Azure Servizio e illustra sia la resilienza all'interno dell'area con le zone di disponibilità che il ripristino di emergenza tra aree e la continuità aziendale. Per una panoramica più dettagliata dei principi di affidabilità in Azure, vedere Affidabilità di Azure.

app Azure Servizio è un servizio basato su HTTP per l'hosting di applicazioni Web, API REST e back-end per dispositivi mobili e aggiunge la potenza di Microsoft Azure all'applicazione, ad esempio:

  • Sicurezza
  • Bilanciamento del carico
  • Scalabilità automatica
  • Gestione automatica

Per informazioni su come app Azure Service può migliorare l'affidabilità e la resilienza del carico di lavoro dell'applicazione, vedere Perché usare servizio app?

Raccomandazioni relative all'affidabilità

Questa sezione contiene raccomandazioni per ottenere resilienza e disponibilità. Ogni raccomandazione rientra in una delle due categorie seguenti:

  • Gli elementi di integrità riguardano aree come gli elementi di configurazione e la corretta funzione dei componenti principali che costituiscono il carico di lavoro di Azure, ad esempio le impostazioni di configurazione delle risorse di Azure, le dipendenze da altri servizi e così via.

  • Gli elementi di rischio riguardano aree quali requisiti di disponibilità e ripristino, test, monitoraggio, distribuzione e altri elementi che, se lasciati non risolti, aumentano le probabilità di problemi nell'ambiente.

Matrice di priorità delle raccomandazioni per l'affidabilità

Ogni raccomandazione è contrassegnata in base alla matrice di priorità seguente:

Image Priorità Descrizione
Fortemente Correzione immediata necessaria.
Medio Correzione entro 3-6 mesi.
Bassa Deve essere esaminato.

Riepilogo delle raccomandazioni per l'affidabilità

Category Priorità Elemento consigliato
Disponibilità elevata ASP-1 - Distribuire piani di servizio app con ridondanza della zona
Resilienza ASP-2 - Usare un piano di servizio app che supporta le zone di disponibilità
ASP-4 - Creare piani di servizio app separati per la produzione e il test
Scalabilità ASP-3 - Evitare spesso l'aumento o la riduzione delle prestazioni
ASP-5 - Abilitare la scalabilità automatica/Scalabilità automatica per garantire che le risorse adeguate siano disponibili per le richieste di servizio

Disponibilità elevata

ASP-1 - Distribuire piani di servizio app con ridondanza della zona

Per migliorare la resilienza e l'affidabilità dei carichi di lavoro critici per l'azienda, è consigliabile distribuire i nuovi piani di servizio app con ridondanza della zona. Seguire la procedura per ridistribuire il supporto della zona di disponibilità, configurare le pipeline per ridistribuire l'app Web nel nuovo piano servizio app e quindi usare un approccio di distribuzione Blue-Green per eseguire il failover nel nuovo sito.

Distribuendo le applicazioni in più zone di disponibilità, è possibile garantire il funzionamento continuo anche in caso di errore a livello di data center. Per altre informazioni sul supporto della zona di disponibilità in app Azure Servizio, vedere Supporto della zona di disponibilità.

// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A

resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"

Resilienza

ASP-2 - Usare un piano di servizio app che supporta le zone di disponibilità

Il supporto della zona di disponibilità è disponibile solo in determinati piani di servizio app. Per vedere quale piano è necessario per usare le zone di disponibilità, vedere Prerequisiti della zona di disponibilità.

// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.

resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
        tolower(sku_tier) !contains "premium" and
        tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)

ASP-4 - Creare piani di servizio app separati per la produzione e il test

Per migliorare la resilienza e l'affidabilità dei carichi di lavoro critici per l'azienda, è necessario eseguire la migrazione dei piani di servizio app esistenti e dei ambiente del servizio app al supporto della zona di disponibilità. Distribuendo le applicazioni in più zone di disponibilità, è possibile garantire il funzionamento continuo anche in caso di errore a livello di data center. Per altre informazioni sul supporto della zona di disponibilità in app Azure Servizio, vedere Supporto della zona di disponibilità.

Scalabilità

ASP-3 - Evitare spesso l'aumento o la riduzione delle prestazioni

È consigliabile evitare spesso di aumentare o ridurre le istanze del servizio app Azure. Scegliere invece un livello appropriato e le dimensioni dell'istanza che possono gestire il carico di lavoro tipico e aumentare le istanze per adattarsi alle modifiche apportate al volume di traffico. Il ridimensionamento verso l'alto o verso il basso può potenzialmente attivare un riavvio dell'applicazione, che può causare interruzioni del servizio.

ASP-5 - Abilitare la scalabilità automatica/Scalabilità automatica per garantire che le risorse adeguate siano disponibili per le richieste di servizio

È consigliabile abilitare la scalabilità automatica o automatica per il servizio app Azure per assicurarsi che siano disponibili risorse sufficienti per gestire le richieste in ingresso. La scalabilità automatica è basata su regole, mentre il ridimensionamento automatico esegue il ridimensionamento automatico in base al traffico HTTP. Per altre informazioni, vedere Scalabilità automatica nel servizio app Azure o introduzione alla scalabilità automatica in Azure.

// under-development

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono almeno tre gruppi di data center separati fisicamente all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di energia, raffreddamento e infrastruttura di rete indipendenti. In caso di errore della zona locale, le zone di disponibilità sono progettate in modo che se l'unica zona è interessata, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle due zone rimanenti.

Gli errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori si ottiene con ridondanza e isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.

I servizi abilitati per le zone di disponibilità di Azure sono progettati per offrire il giusto livello di affidabilità e flessibilità. Possono essere configurati in due modi. Possono essere ridondanti della zona, con replica automatica tra zone o zone, con istanze aggiunte a una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sull'architettura zonale e con ridondanza della zona, vedere Consigli per l'uso di zone e aree di disponibilità.

app Azure Servizio può essere distribuito tra zone di disponibilità (AZ) per ottenere resilienza e affidabilità per i carichi di lavoro critici per l'azienda. Questa architettura è nota anche come ridondanza della zona.

Quando si configura servizio app come ridondanza della zona, la piattaforma distribuisce automaticamente le istanze del piano di servizio app Azure 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 del piano servizio app è tre.
  • Se si specifica una capacità maggiore di tre e il numero di istanze è divisibile per tre, le istanze vengono distribuite in modo uniforme.
  • I conteggi delle istanze superiori a 3*N vengono distribuiti tra le altre due zone.

Il supporto della zona di disponibilità è una proprietà del piano di servizio app. servizio app piani possono essere creati in un ambiente multi-tenant gestito o in un ambiente dedicato usando ambiente del servizio app v3. Per altre informazioni su ambiente del servizio app v3, vedere panoramica di ambiente del servizio app v3.

Per le servizio app non configurate per la ridondanza della zona, le istanze di macchine virtuali non sono resilienti alla zona e possono riscontrare tempi di inattività durante un'interruzione in qualsiasi zona di tale area.

Per informazioni sull'architettura di distribuzione aziendale, vedere Distribuzione aziendale a disponibilità elevata con ambiente del servizio app.

Prerequisiti

I requisiti/limitazioni correnti per l'abilitazione delle zone di disponibilità sono:

  • Sono supportati sia Windows che Linux.

  • Le zone di disponibilità sono supportate solo nel footprint di servizio app più recente. Anche se si usa una delle aree supportate, si riceverà un errore se le zone di disponibilità non sono supportate per il gruppo di risorse. Per garantire che i carichi di lavoro vengano applicati a un timbro che supporta le zone di disponibilità, potrebbe essere necessario creare un nuovo gruppo di risorse, servizio app piano e servizio app.

  • Il piano di servizio app deve essere uno dei piani seguenti che supportano le zone di disponibilità:

    • In un ambiente multi-tenant usando servizio app piani Premium v2 o Premium v3.
    • In un ambiente dedicato che usa ambiente del servizio app v3, usato con piani di servizio app isolato v2.
  • Per gli ambienti dedicati, il ambiente del servizio app deve essere v3.

    Importante

    ambiente del servizio app v2 e v1 verranno ritirati il 31 agosto 2024. ambiente del servizio app v3 è più facile da usare e viene eseguito su un'infrastruttura più potente. Per altre informazioni su ambiente del servizio app v3, vedere ambiente del servizio app panoramica. Se si usa attualmente ambiente del servizio app v2 o v1 e si vuole eseguire l'aggiornamento alla versione 3, seguire la procedura descritta in questo articolo per eseguire la migrazione alla nuova versione.

  • Viene applicato il numero minimo di istanze di tre zone. La piattaforma applichererà questo conteggio minimo in background se si specifica un numero di istanze inferiore a tre.

  • Le zone di disponibilità possono essere specificate solo quando si crea un nuovo piano di servizio app. Non è possibile convertire un piano di servizio app preesistente per usare le zone di disponibilità.

  • Le aree seguenti supportano i servizi app Azure in esecuzione in ambienti multi-tenant:

    • Australia orientale
    • Brasile meridionale
    • Canada centrale
    • India centrale
    • Stati Uniti centrali
    • Asia orientale
    • Stati Uniti orientali
    • Stati Uniti orientali 2
    • Francia centrale
    • Germania centro-occidentale
    • Giappone orientale
    • Corea centrale
    • Europa settentrionale
    • Norvegia orientale
    • Polonia Centrale
    • Qatar centrale
    • Sudafrica settentrionale
    • Stati Uniti centro-meridionali
    • Asia sud-orientale
    • Svezia centrale
    • Svizzera settentrionale
    • Emirati Arabi Uniti settentrionali
    • Regno Unito meridionale
    • Europa occidentale
    • West US 2
    • Stati Uniti occidentali 3
    • Microsoft Azure gestito da 21Vianet - Cina settentrionale 3
    • Azure per enti pubblici - US Gov Virginia
  • Per informazioni sulle aree che supportano le zone di disponibilità per ambiente del servizio app v3, vedere Aree.

Creare una risorsa con la zona di disponibilità abilitata

Per distribuire un servizio app con ridondanza della zona multi-tenant

Per abilitare le zone di disponibilità usando l'interfaccia della riga di comando di Azure, includere il parametro quando si crea il --zone-redundant piano di servizio app. È anche possibile includere il parametro per specificare la --number-of-workers capacità. Se non si specifica una capacità, per impostazione predefinita la piattaforma è tre. La capacità deve essere impostata in base al requisito del carico di lavoro, ma non inferiore a tre. Una buona regola generale per scegliere la capacità consiste nel garantire istanze sufficienti per l'applicazione in modo che la perdita di una zona di istanze lasci capacità sufficiente per gestire il carico previsto.

az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6

Suggerimento

Per decidere la capacità dell'istanza, è possibile usare il calcolo seguente:

Poiché la piattaforma distribuisce le macchine virtuali tra tre zone ed è necessario tenere conto almeno dell'errore di una zona, moltiplicare il numero massimo di istanze del carico di lavoro per un fattore di zone/(zone-1) o 3/2. Ad esempio, se il carico di lavoro di picco tipico richiede quattro istanze, è necessario effettuare il provisioning di sei istanze: (2/3 * 6 istanze) = 4 istanze.

Distribuire un servizio app con ridondanza della zona usando un ambiente dedicato

Per informazioni su come creare un ambiente del servizio app v3 nel piano Isolated v2, vedere Creare un ambiente del servizio app.

Risoluzione dei problemi

Error message Descrizione Elemento consigliato
La ridondanza della zona non è disponibile per il gruppo di risorse 'RG-NAME'. Distribuire il piano di servizio app 'ASP-NAME' in un nuovo gruppo di risorse. Le zone di disponibilità sono supportate solo nel footprint di servizio app più recente. Anche se si usa una delle aree supportate, si riceverà un errore se le zone di disponibilità non sono supportate per il gruppo di risorse. Per assicurarsi che i carichi di lavoro vengano applicati a un timbro che supporta le zone di disponibilità, creare un nuovo gruppo di risorse, servizio app piano e servizio app.

Tolleranza di errore

Per preparare l'errore della zona di disponibilità, è necessario effettuare il over-provisioning della capacità del servizio per garantire che la soluzione possa tollerare una perdita di capacità di 1/3 e continuare a funzionare senza prestazioni ridotte durante interruzioni a livello di zona. Poiché la piattaforma distribuisce le macchine virtuali tra tre zone ed è necessario tenere conto almeno dell'errore di una zona, moltiplicare il numero massimo di istanze del carico di lavoro per un fattore di zone/(zone-1) o 3/2. Ad esempio, se il carico di lavoro di picco tipico richiede quattro istanze, è necessario effettuare il provisioning di sei istanze: (2/3 * 6 istanze) = 4 istanze.

Esperienza di riduzione della zona

Il traffico viene instradato a tutte le istanze di servizio app disponibili. Nel caso in cui una zona si arresti, la piattaforma servizio app rileverà le istanze perse e tenterà automaticamente di trovare nuove istanze di sostituzione e di distribuire il traffico in base alle esigenze. Se è stata configurata la scalabilità automatica e, se si decide che sono necessarie altre istanze, la scalabilità automatica invierà anche una richiesta di servizio app per aggiungere altre istanze. Si noti che il comportamento della scalabilità automatica è indipendente dal comportamento della piattaforma servizio app e che la specifica del numero di istanze di scalabilità automatica non deve essere un multiplo di tre.

Nota

Non esiste alcuna garanzia che le richieste di istanze aggiuntive in uno scenario di zone-down abbiano esito positivo. Il riempimento nascosto delle istanze perse si verifica in modo ottimale. La soluzione consigliata consiste nel creare e configurare i piani di servizio app per tenere conto della perdita di una zona, come descritto nella sezione successiva.

Le applicazioni distribuite in un piano di servizio app con zone di disponibilità abilitate continueranno a essere eseguite e a gestire il traffico anche se altre zone nella stessa area subiscono un'interruzione. Tuttavia, è possibile che i comportamenti non in fase di esecuzione, tra cui il ridimensionamento del piano servizio app, la creazione di applicazioni, la configurazione dell'applicazione e la pubblicazione delle applicazioni possano essere ancora interessati da un'interruzione in altri zone di disponibilità. La ridondanza della zona per i piani di servizio app garantisce solo un tempo di attività continuo per le applicazioni distribuite.

Quando la piattaforma servizio app alloca istanze a un piano di servizio app con ridondanza della zona, usa il bilanciamento della zona più efficiente offerto dal set di scalabilità di macchine virtuali di Azure sottostante. Un piano di servizio app verrà "bilanciato" se ogni zona ha lo stesso numero di macchine virtuali o +/- una macchina virtuale in tutte le altre zone usate dal piano di servizio app.

Migrazione della zona di disponibilità

Non è possibile eseguire la migrazione di istanze di servizio app esistenti o risorse di ambiente dal supporto della zona non di disponibilità al supporto della zona di disponibilità. Per ottenere supporto per le zone di disponibilità, è necessario creare le risorse con le zone di disponibilità abilitate.

Prezzi

Non sono previsti costi aggiuntivi associati all'abilitazione delle zone di disponibilità. I prezzi per un servizio app con ridondanza della zona corrispondono a una singola zona servizio app. Verranno addebitati i costi in base allo SKU del piano di servizio app, 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, la piattaforma applicherrà un numero minimo di istanze pari a tre e verrà addebitato l'addebito per queste tre istanze. Per informazioni sui prezzi per ambiente del servizio app v3, vedere Prezzi.

Ripristino di emergenza tra aree e continuità aziendale

Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.

Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.

Questa sezione illustra alcune strategie comuni per le app Web distribuite in servizio app.

Quando si crea un'app Web in servizio app e si sceglie un'area di Azure durante la creazione di risorse, si tratta di un'app a singola area. Quando l'area non è più disponibile durante un'emergenza, l'applicazione diventa anche non disponibile. Se si crea una distribuzione identica in un'area di Azure secondaria usando un'architettura geografica in più aree, l'applicazione diventa meno soggetta a un'emergenza a singola area, garantendo la continuità aziendale. Qualsiasi replica di dati tra le aree consente di ripristinare l'ultimo stato dell'applicazione.

Per l'IT, i piani di continuità aziendale sono in gran parte guidati dall'obiettivo del tempo di ripristino (RTO) e dall'obiettivo del punto di ripristino (RPO). Per altre informazioni su RTO e RPO, vedere Obiettivi di ripristino.

In genere, la gestione di un contratto di servizio per L'obiettivo RTO è poco pratica per le emergenze a livello di area e in genere si progetta la strategia di ripristino di emergenza in base all'obiettivo rpo (ovvero concentrarsi sul ripristino dei dati e non sulla riduzione dell'interruzione). Con Azure, tuttavia, non è solo pratico, ma può anche essere semplice distribuire servizio app per i failover geografici automatici. In questo modo è possibile verificare ulteriormente le applicazioni in caso di emergenza prendendo in considerazione sia RTO che RPO.

A seconda delle metriche RTO e RPO desiderate, vengono comunemente usate tre architetture di ripristino di emergenza per servizio app multi-tenant e ambiente del servizio app. Ogni architettura è descritta nella tabella seguente:

Metric Attivo-Attivo Attivo-passivo Passivo/freddo
RTO Tempo reale o secondi Minuti Ore
RPO Tempo reale o secondi Minuti Ore
Costo $$$ $$ $
Scenari App cruciali App con priorità alta App con priorità bassa
Possibilità di gestire il traffico utente in più aree Sì/forse No
Distribuzione del codice Pipeline CI/CD preferite Pipeline CI/CD preferite Backup e ripristino
Creazione di nuove risorse servizio app durante i tempi di inattività Non obbligatorio Non obbligatorio Richiesto

Nota

L'applicazione dipende molto probabilmente da altri servizi dati in Azure, ad esempio database SQL di Azure e account Archiviazione di Azure. È consigliabile sviluppare anche strategie di ripristino di emergenza per ognuno di questi servizi di Azure dipendenti. Per database SQL, vedere Replica geografica attiva per database SQL di Azure. Per Archiviazione di Azure, vedere ridondanza Archiviazione di Azure.

Ripristino di emergenza nell'area geografica in più aree

Esistono diversi modi per replicare il contenuto e le configurazioni delle app Web tra aree di Azure in un'architettura attiva-attiva o passiva attiva, ad esempio usando il backup e il ripristino del servizio app. Tuttavia, il backup e il ripristino creano snapshot temporizzato e alla fine comportano problemi di controllo delle versioni delle app Web tra aree. Vedere la tabella seguente per un confronto tra linee guida sul ripristino e sul ripristino e indicazioni sul ripristino diaster:

Backup e ripristino e ripristino di emergenza

Piattaforma Linee guida per il backup e il ripristino Indicazioni sul ripristino di emergenza
App Web del servizio app
(Piano tariffario gratuito e condiviso)
Se sono state distribuite applicazioni Web nel livello Gratuito o Condiviso e richiedono l'accesso alle funzionalità di backup e ripristino per queste app Web, aumentare fino al livello Basic o superiore. Riportare online servizio app risorse in un'area di Azure diversa durante un'emergenza a livello di area.

A partire dal 31 marzo 2025, le applicazioni servizio app non verranno inserite in modalità di ripristino di emergenza durante un'emergenza in un'area di Azure, come illustrato nell'articolo Relativo al ripristino da un errore a livello di area. È consigliabile implementare tecniche di ripristino di emergenza comunemente usate per evitare tempi di inattività e perdita di dati durante un'emergenza a livello di area.
App Web del servizio app
(Piano tariffario Basic\Standard\Premium)
In app Azure Servizio è possibile eseguire backup personalizzati su richiesta o usare backup automatici. È possibile ripristinare un backup sovrascrivendo un'app esistente ripristinando una nuova app o uno slot.

Per altre informazioni, vedere Backup e ripristino dell'app nel servizio app Azure.
Le linee guida correnti su come riportare online servizio app risorse in un'area di Azure diversa durante un'emergenza a livello di area sono disponibili in Ripristino da un errore a livello di area - servizio app Azure.

A partire dal 31 marzo 2025, le applicazioni Web del servizio app Azure non verranno più inserite in modalità di ripristino di emergenza durante un'emergenza in un'area di Azure, come illustrato nell'articolo Relativo al ripristino da un errore a livello di area. È consigliabile implementare tecniche di ripristino di emergenza di uso comune per evitare la perdita di funzionalità o dati per le app Web in caso di emergenza a livello di area.
ambiente del servizio app (V2 & V3) In app Azure ambiente del servizio è possibile eseguire backup personalizzati su richiesta o usare backup automatici. I backup automatici possono essere ripristinati in un'app di destinazione all'interno della stessa A edizione Standard, non in un altro A edizione Standard. I backup personalizzati possono essere ripristinati in un'app di destinazione in un'altra A edizione Standard (ad esempio da una versione 2 A edizione Standard a una versione 3 A edizione Standard). I backup possono essere ripristinati nell'app di destinazione della stessa piattaforma del sistema operativo dell'app di origine.

Per altri dettagli, vedere Backup e ripristino dell'app nel servizio app Azure.
È consigliabile implementare linee guida per il ripristino di emergenza per le app Web distribuite in ambiente del servizio app usando tecniche di ripristino di emergenza di uso comune.
Funzioni di Azure (dedicato) In Funzioni di Azure è possibile eseguire backup personalizzati su richiesta o usare backup automatici. È possibile ripristinare un backup sovrascrivendo un'app esistente ripristinando una nuova app o uno slot.

Per altre informazioni, vedere Backup e ripristino dell'app nel servizio app Azure.
Le linee guida correnti su come riportare online le risorse di Funzioni di Azure app (dedicate) in un'area di Azure diversa durante un'emergenza a livello di area sono disponibili in Ripristino da un errore a livello di area - servizio app Azure.

A partire dal 31 marzo 2025, le applicazioni servizio app non verranno inserite in modalità di ripristino di emergenza durante un'emergenza in un'area di Azure, come illustrato nell'articolo Relativo al ripristino da un errore a livello di area. Implementare invece Funzioni di Azure ripristino di emergenza geografico.

Inoltre, è anche possibile fare riferimento a tecniche di ripristino di emergenza comunemente usate per Funzioni di Azure dedicato.
Funzioni di Azure consumo e Premium Le funzioni di Azure distribuite nei piani a consumo e Premium non forniscono l'accesso ai backup personalizzati e automatici. Il contenuto dell'app per le funzioni si trova in un account di archiviazione di Azure. Usare Archiviazione di Azure opzioni di ridondanza per assicurarsi che l'account di archiviazione soddisfi le destinazioni di disponibilità e durabilità durante un'interruzione.

Se le funzioni sono state create usando l'editor nella portale di Azure, è anche possibile scaricare il progetto dell'app per le funzioni esistente come file di .zip.
È consigliabile implementare Funzioni di Azure ripristino di emergenza geografico e affidabilità.

Per evitare le limitazioni dei metodi di backup e ripristino, configurare le pipeline CI/CD per distribuire il codice in entrambe le aree di Azure. Prendere in considerazione l'uso di Azure Pipelines o GitHub Actions. Per altre informazioni, vedere Distribuzione continua nel servizio app Azure.

Rilevamento, notifica e gestione di interruzioni

  • È consigliabile configurare il monitoraggio e gli avvisi per le app Web per ricevere notifiche tempestive durante un'emergenza. Per altre informazioni, vedere Test di disponibilità di Application Insights.

  • Per gestire le risorse dell'applicazione in Azure, usare un meccanismo IaC (Infrastructure-as-Code). In una distribuzione complessa in più aree, per gestire le aree in modo indipendente e mantenere la configurazione sincronizzata tra aree in modo affidabile richiede un processo prevedibile, testabile e ripetibile. Si consideri uno strumento IaC, ad esempio modelli di Azure Resource Manager o Terraform.

Configurare il ripristino di emergenza e il rilevamento di interruzioni

Per preparare il ripristino di emergenza in un'area geografica in più aree, è possibile usare un'architettura attiva-attiva o attiva-passiva.

Architettura attiva-attiva

Nell'architettura di ripristino di emergenza attivo-attivo, le app Web identiche vengono distribuite in due aree separate e Frontdoor di Azure viene usato per instradare il traffico a entrambe le aree attive.

Diagram that shows an active-active deployment of App Service.

Con questa architettura di esempio:

  • Le app servizio app identiche vengono distribuite in due aree separate, tra cui il piano tariffario e il numero di istanze.
  • Il traffico pubblico direttamente verso le app servizio app è bloccato.
  • Frontdoor di Azure viene usato per instradare il traffico a entrambe le aree attive.
  • Durante un'emergenza, una delle aree diventa offline e Frontdoor di Azure instrada il traffico esclusivamente all'area che rimane online. L'obiettivo RTO durante un failover geografico di questo tipo è vicino a zero.
  • I file dell'applicazione devono essere distribuiti in entrambe le app Web con una soluzione CI/CD. In questo modo si garantisce che l'RPO sia praticamente zero.
  • Se l'applicazione modifica attivamente il file system, il modo migliore per ridurre al minimo l'RPO consiste nel scrivere solo in una condivisione di Archiviazione di Azure montata anziché scrivere direttamente nella condivisione di contenuto /home dell'app Web. Usare quindi le funzionalità di ridondanza Archiviazione di Azure (GZRS o GRS) per la condivisione montata, con un RPO di circa 15 minuti.

I passaggi per creare un'architettura attiva-attiva per l'app Web in servizio app sono riepilogati nel modo seguente:

  1. Creare due piani servizio app in due aree di Azure diverse. Configurare i due piani servizio app in modo identico.

  2. Creare due istanze dell'app Web, con una in ogni piano servizio app.

  3. Creare un profilo frontdoor di Azure con:

    • Endpoint.
    • Due gruppi di origine, ognuno con priorità 1. La priorità uguale indica a Frontdoor di Azure di instradare il traffico a entrambe le aree in modo uniforme (quindi attivo-attivo).
    • Un itinerario.
  4. Limitare il traffico di rete alle app Web solo dall'istanza di Frontdoor di Azure.

  5. Configurare e configurare tutti gli altri servizi back-end di Azure, ad esempio database, account di archiviazione e provider di autenticazione.

  6. Distribuire il codice in entrambe le app Web con distribuzione continua.

Esercitazione: Creare un'app a più aree a disponibilità elevata in app Azure Service illustra come configurare un'architettura attiva-passiva. Gli stessi passaggi con modifiche minime (impostazione della priorità su "1" per entrambi i gruppi di origine in Frontdoor di Azure) offrono un'architettura attiva-attiva .

Architettura attiva-passiva

In questo approccio di ripristino di emergenza, le app Web identiche vengono distribuite in due aree separate e Frontdoor di Azure viene usato per instradare il traffico a un'unica area (l'area attiva ).

A diagram showing an active-passive architecture of Azure App Service.

Con questa architettura di esempio:

  • Le app di servizio app identiche vengono distribuite in due aree separate.

  • Il traffico pubblico direttamente verso le app servizio app è bloccato.

  • Frontdoor di Azure viene usato per instradare il traffico all'area primaria.

  • Per risparmiare sui costi, il piano di servizio app secondario è configurato per avere meno istanze e/o essere in un piano tariffario inferiore. Esistono tre possibili approcci:

    • Preferito Il piano di servizio app secondario ha lo stesso piano tariffario del database primario, con lo stesso numero di istanze o meno. Questo approccio garantisce parità sia nella funzionalità che nel dimensionamento delle macchine virtuali per i due piani di servizio app. L'obiettivo RTO durante un failover geografico dipende solo dal tempo necessario per aumentare le istanze.

    • Meno preferito Il piano di servizio app secondario ha lo stesso tipo di piano tariffario (ad esempio PremiumV3) ma il dimensionamento delle macchine virtuali più piccolo, con istanze minori. Ad esempio, l'area primaria può trovarsi nel livello P3V3 mentre l'area secondaria è nel livello P1V3. Questo approccio garantisce comunque la parità delle funzionalità per i due piani di servizio app, ma la mancanza di parità delle dimensioni può richiedere un aumento manuale delle prestazioni quando l'area secondaria diventa l'area attiva. L'obiettivo RTO durante un failover geografico dipende dal tempo necessario per aumentare le istanze e aumentare le istanze.

    • Meno preferito Il piano di servizio app secondario ha un piano tariffario diverso rispetto alle istanze primarie e minori. Ad esempio, l'area primaria può trovarsi nel livello P3V3 mentre l'area secondaria è nel livello S1. Assicurarsi che il piano di servizio app secondario abbia tutte le funzionalità necessarie per l'esecuzione dell'applicazione. Le differenze nella disponibilità delle funzionalità tra i due possono causare ritardi nel ripristino dell'app Web. L'obiettivo RTO durante un failover geografico dipende dal tempo necessario per aumentare le istanze e aumentare le istanze.

  • La scalabilità automatica viene configurata nell'area secondaria nel caso in cui l'area attiva diventi inattiva. È consigliabile avere regole di scalabilità automatica simili nelle aree attive e passive.

  • Durante un'emergenza, l'area primaria diventa inattiva e l'area secondaria inizia a ricevere traffico e diventa l'area attiva.

  • Quando l'area secondaria diventa attiva, il carico di rete attiva le regole di scalabilità automatica preconfigurate per aumentare il numero di istanze dell'app Web secondaria.

  • Potrebbe essere necessario aumentare manualmente il piano tariffario per l'area secondaria, se non dispone già delle funzionalità necessarie per l'esecuzione come area attiva. Ad esempio, la scalabilità automatica richiede il livello Standard o superiore.

  • Quando l'area primaria è nuovamente attiva, Frontdoor di Azure indirizza automaticamente il traffico verso di esso e l'architettura torna attiva-passiva come in precedenza.

  • I file dell'applicazione devono essere distribuiti in entrambe le app Web con una soluzione CI/CD. In questo modo si garantisce che l'RPO sia praticamente zero.

  • Se l'applicazione modifica attivamente il file system, il modo migliore per ridurre al minimo l'RPO consiste nel scrivere solo in una condivisione di Archiviazione di Azure montata anziché scrivere direttamente nella condivisione di contenuto /home dell'app Web. Usare quindi le funzionalità di ridondanza Archiviazione di Azure (GZRS o GRS) per la condivisione montata, con un RPO di circa 15 minuti.

I passaggi per creare un'architettura attiva-passiva per l'app Web in servizio app sono riepilogati nel modo seguente:

  1. Creare due piani servizio app in due aree di Azure diverse. È possibile eseguire il provisioning del piano di servizio app secondario usando uno degli approcci indicati in precedenza.
  2. Configurare le regole di scalabilità automatica per il piano di servizio app secondario in modo che venga ridimensionato allo stesso numero di istanze del database primario quando l'area primaria diventa inattiva.
  3. Creare due istanze dell'app Web, con una in ogni piano servizio app.
  4. Creare un profilo frontdoor di Azure con:
    • Endpoint.
    • Gruppo di origine con priorità 1 per l'area primaria.
    • Un secondo gruppo di origine con priorità 2 per l'area secondaria. La differenza di priorità indica a Frontdoor di Azure di preferire l'area primaria quando è online (quindi attivo-passivo).
    • Un itinerario.
  5. Limitare il traffico di rete alle app Web solo dall'istanza di Frontdoor di Azure.
  6. Configurare e configurare tutti gli altri servizi back-end di Azure, ad esempio database, account di archiviazione e provider di autenticazione.
  7. Distribuire il codice in entrambe le app Web con distribuzione continua.

Esercitazione: Creare un'app a più aree a disponibilità elevata in app Azure Service illustra come configurare un'architettura attiva-passiva.

Architettura a freddo passivo

Usare un'architettura passiva/fredda per creare e gestire backup regolari delle app Web in un account Archiviazione di Azure che si trova in un'altra area.

Con questa architettura di esempio:

  • Una singola app Web viene distribuita in una singola area.

  • Il backup dell'app Web viene eseguito regolarmente in un account Archiviazione di Azure nella stessa area.

  • La replica tra aree dei backup dipende dalla configurazione della ridondanza dei dati nell'account di archiviazione di Azure. È consigliabile impostare l'account Archiviazione di Azure come archiviazione con ridondanza della zona, se possibile. Archiviazione con ridondanza della zona sincrona in un'area e asincrona in un'area secondaria. Se L'archiviazione con ridondanza geografica della zona non è disponibile, configurare l'account come archiviazione con ridondanza geografica. L'archiviazione con ridondanza geografica e l'archiviazione con ridondanza geografica e archiviazione con ridondanza geografica hanno un RPO di circa 15 minuti.

  • Per assicurarsi di poter recuperare i backup quando l'area primaria dell'account di archiviazione non è più disponibile, abilitare l'accesso in sola lettura all'area secondaria (rendendo rispettivamente l'account di archiviazione RA-GZRS o RA-GRS). Per altre informazioni sulla progettazione delle applicazioni per sfruttare la ridondanza geografica, vedere Usare la ridondanza geografica per progettare applicazioni a disponibilità elevata.

  • Durante un'emergenza nell'area dell'app Web, è necessario distribuire manualmente tutte le risorse necessarie servizio app dipendenti usando i backup dall'account Archiviazione di Azure, probabilmente dall'area secondaria con accesso in lettura. L'obiettivo RTO può essere di ore o giorni.

  • Per ridurre al minimo l'RTO, è consigliabile disporre di un playbook completo che delinea tutti i passaggi necessari per ripristinare il backup dell'app Web in un'altra area di Azure.

I passaggi per creare un'area ad accesso sporadico passivo per l'app Web in servizio app sono riepilogati nel modo seguente:

  1. Creare un account di archiviazione di Azure nella stessa area dell'app Web. Scegliere Il livello di prestazioni Standard e selezionare ridondanza come archiviazione con ridondanza geografica o archiviazione con ridondanza geografica della zona.

  2. Abilitare RA-GRS o RA-GZRS (accesso in lettura per l'area secondaria).

  3. Configurare il backup personalizzato per l'app Web. È possibile decidere di impostare una pianificazione per i backup dell'app Web, ad esempio ogni ora.

  4. Verificare che i file di backup dell'app Web possano essere recuperati nell'area secondaria dell'account di archiviazione.

Suggerimento

Oltre a Frontdoor di Azure, Azure offre altre opzioni di bilanciamento del carico, ad esempio Gestione traffico di Azure. Per un confronto delle varie opzioni, vedere Opzioni di bilanciamento del carico - Centro architetture di Azure.

Ripristino di emergenza in area geografica singola

Se l'area dell'app Web non ha archiviazione con ridondanza della zona o archiviazione con ridondanza geografica o se ci si trova in un'area di Azure che non è una coppia a livello di area, è necessario usare l'archiviazione con ridondanza della zona o l'archiviazione con ridondanza locale per creare un'architettura simile. Ad esempio, è possibile creare manualmente un'area secondaria per l'account di archiviazione come indicato di seguito:

Diagram that shows how to create a passive or cold region without GRS or GZRS.

I passaggi per creare un'area ad accesso sporadico passivo senza archiviazione con ridondanza geografica e archiviazione con ridondanza geografica sono riepilogati come segue:

  1. Creare un account di archiviazione di Azure nella stessa area dell'app Web. Scegliere Il livello di prestazioni Standard e selezionare ridondanza come archiviazione con ridondanza della zona.

  2. Configurare il backup personalizzato per l'app Web. È possibile decidere di impostare una pianificazione per i backup dell'app Web, ad esempio ogni ora.

  3. Verificare che i file di backup dell'app Web possano essere recuperati nell'area secondaria dell'account di archiviazione.

  4. Creare un secondo account di archiviazione di Azure in un'area diversa. Scegliere Il livello di prestazioni Standard e selezionare ridondanza come archiviazione con ridondanza locale.

  5. Usando uno strumento come AzCopy, replicare il backup personalizzato (file ZIP, XML e di log) dall'area primaria alla risorsa di archiviazione secondaria. Ad esempio:

    azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'
    

    È possibile usare Automazione di Azure con un runbook del flusso di lavoro PowerShell per eseguire lo script di replica in base a una pianificazione. Assicurarsi che la pianificazione della replica segua una pianificazione simile ai backup dell'app Web.

Passaggi successivi