Affidabilità in Servizio app di Azure
Questo articolo descrive il supporto per l'affidabilità in servizio app di Azure e illustra sia la resilienza all'interno dell'area con 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.
Servizio app di Azure è un servizio basato su HTTP per l'hosting di applicazioni Web, API REST e back-end mobili; e aggiunge la potenza di Microsoft Azure all'applicazione; ad esempio:
- Sicurezza
- Bilanciamento del carico
- Scalabilità automatica
- Gestione automatica
Per esplorare i modi in cui il Servizio app di Azure può migliorare affidabilità e resilienza del carico di lavoro delle applicazioni, vedere Perché usare il servizio app?
Supporto della zona di disponibilità
Le zone di disponibilità di Azure sono costituite da almeno tre gruppi fisicamente separati di data center all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di alimentazione, raffreddamento e infrastruttura di rete indipendenti. Le zone di disponibilità sono progettate in modo che, in caso di errore in una zona locale, i servizi regionali, la capacità e la disponibilità elevata della zona interessata siano supportati dalle altre due zone.
Gli errori possono essere di tipo hardware o software oppure correlati a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene conseguita mediante la ridondanza e l'isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.
I servizi abilitati per le zone di disponibilità sono progettati per fornire il livello adeguato di affidabilità e flessibilità. Tali servizi possono essere configurati in due modi. Possono essere con ridondanza della zona, che prevede la replica automatica tra le zone, o a zona, con istanze aggiunte in una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sulle architetture a zona e con ridondanza della zona, vedere Raccomandazioni per l'uso delle zone e delle aree di disponibilità.
Il servizio app di Azure 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 il servizio app come ridondante della zona, la piattaforma distribuisce automaticamente le istanze del piano di servizio app di Azure tra 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 di 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. I piani di servizio app possono essere creati in un ambiente multi-tenant gestito o in un ambiente dedicato usando l'ambiente del servizio app v3. Per altre informazioni sull'ambiente del servizio app v3, vedere Panoramica dell'ambiente del servizio app v3.
Per i servizi app non configurati 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 del 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à, potrebbe essere necessario creare un nuovo gruppo di risorse, un piano di servizio app e un servizio app.
Il piano di Servizi app deve essere uno dei piani seguenti che supportano le zone di disponibilità:
- In un ambiente multi-tenant con piani Premium v2 o Premium v3 del servizio app.
- In un ambiente dedicato che usa l'ambiente del servizio app v3 usato con i piani di servizio app isolato v2.
Per gli ambienti dedicati, l'ambiente del servizio app deve essere v3.
Importante
L'ambiente del servizio app v2 e v1 verrà ritirato il 31 agosto 2024. L'ambiente del servizio app v3 è più facile da usare e viene eseguito in un'infrastruttura più potente. Per altre informazioni sull'ambiente del servizio app v3, vedere Panoramica dell'ambiente del servizio app. Se si usa attualmente l'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 pari a tre zone. La piattaforma applicherà 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 Servizi app di 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
- Israele centrale
- Italia settentrionale
- Giappone orientale
- Corea centrale
- Messico centrale
- Europa settentrionale
- Norvegia orientale
- Polonia Centrale
- Qatar centrale
- Sudafrica settentrionale
- Stati Uniti centro-meridionali
- Asia sud-orientale
- Spagna centrale
- 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 l'ambiente del servizio app v3, vedere Aree.
Creare una risorsa con zone di disponibilità abilitate
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 --zone-redundant quando si crea il piano di servizio app. È anche possibile includere il parametro per specificare la capacità --number-of-workers. Se non si specifica una capacità, l’impostazione predefinita della 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 dell'errore di almeno 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 Isolato 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 del 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, un piano di servizio app e un servizio app. |
Tolleranza di errore
Per prepararsi per l'errore della zona di disponibilità, è necessario effettuare l’over-provisioning della capacità del servizio per garantire che la soluzione possa tollerare una perdita di capacità di 1/3 e possa 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 dell'errore di almeno 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 inattività della zona
Il traffico viene instradato a tutte le istanze del servizio app disponibili. Nel caso in cui una zona si arresti, la piattaforma del servizio app rileverà le istanze perse, tenterà automaticamente di trovare nuove istanze di sostituzione e distribuirà 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 al servizio app per aggiungere altre istanze. Si noti che il comportamento della scalabilità automatica è indipendente dal comportamento della piattaforma del 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 recupero delle istanze perse avviene nel modo più efficiente possibile. 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. È possibile, tuttavia, che i comportamenti non in fase di esecuzione, tra cui Il ridimensionamento del piano di servizio dell'app, la creazione di applicazioni, la configurazione di applicazioni e la pubblicazione di applicazioni, siano comunque essere interessati da un'interruzione in altre 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 del servizio app alloca le istanze a un piano di servizio app con ridondanza della zona, usa il bilanciamento della zona ottimale offerto dai set di scalabilità di macchine virtuali di Azure sottostanti. 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 del servizio app o risorse di ambiente esistenti 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 un servizio app con singola zona. 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 applicherà un numero minimo di istanze pari a tre e verrà addebitato l'addebito per queste tre istanze. Per informazioni sui prezzi per l'ambiente del servizio app v3, vedere Prezzi.
Ripristino di emergenza e continuità aziendale tra aree
Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per tali servizi, l'utente ha la responsabilità di configurare un piano di ripristino di emergenza che funzioni per i propri carichi di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il piano di ripristino di emergenza.
Questa sezione illustra alcune strategie comuni per le app Web distribuite nel servizio app.
Quando si crea un'app Web nel 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 solo 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 il 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 sia per gli ambienti multi-tenant del servizio app che per gli ambienti del servizio app. Ogni architettura è descritta nella tabella seguente:
| Metric | Attivo/attivo | Attivo/passivo | Passivo/saltuario |
|---|---|---|---|
| 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ì | Sì/forse | No |
| Distribuzione del codice | Pipeline CI/CD preferite | Pipeline CI/CD preferite | Backup e ripristino |
| Creazione di nuove risorse del servizio app durante il tempo di inattività | Non obbligatorio | Non obbligatorio | Richiesto |
Nota
L'applicazione dipende molto probabilmente da altri servizi dati in Azure, ad esempio il database SQL di Azure e gli account di archiviazione di Microsoft Azure. È consigliabile sviluppare anche strategie di ripristino di emergenza per ognuno di questi servizi di Azure dipendenti. Per il database SQL, vedere Replica geografica attiva per il database SQL di Azure. Per Archiviazione di Azure, vedere Ridondanza di archiviazione di Azure.
Ripristino di emergenza nella geografia 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 temporizzati 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 backup e sul ripristino e indicazioni sul ripristino di emergenza:
Backup e ripristino vs. 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. | Ripristinare online le risorse del servizio app in un'area di Azure diversa durante un'emergenza a livello di area. A partire dal 31 marzo 2025, le applicazioni del 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) |
Nel servizio app 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 di Azure. |
Le indicazioni correnti su come riportare online le risorse del servizio app 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 di Azure. A partire dal 31 marzo 2025, le applicazioni Web del servizio app di 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 e V3) | In Ambiente del servizio app di Azure è possibile eseguire backup personalizzati su richiesta o usare backup automatici. I backup automatici possono essere ripristinati in un'app di destinazione all'interno dello stesso ambiente del servizio app, non in un altro ambiente del servizio app. I backup personalizzati possono essere ripristinati in un'app di destinazione in un altro ambiente del servizio app ( ad esempio da un ambiente del servizio app V2 a un ambiente del servizio app V3). 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 di Azure. |
È consigliabile implementare linee guida per il ripristino di emergenza per le app Web distribuite nell'ambiente del servizio app usando tecniche di ripristino di emergenza di uso comune. |
| Funzioni di Azure: Piano dedicato |
Quando si esegue l'app per le funzioni in un pianodedicato (servizio app), il contenuto dell'app per le funzioni richiesto viene mantenuto usando l'archiviazione predefinita. In un piano dedicato è 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 di Azure. File di Azure non viene usato da un piano dedicato, ma se l'app non è stata configurata correttamente con una connessione file di Azure, il backup non è supportato. |
Le linee guida correnti su come portare online le risorse dell'app per le funzioni in un piano dedicato 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 di Azure. A partire dal 31 marzo 2025, le applicazioni del 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. È invece consigliabile pianificare l'affidabilità nelle app per le funzioni. È anche possibile fare riferimento alle tecniche di ripristino di emergenza comunemente usate per le app per le funzioni in un piano dedicato. |
| Funzioni di Azure: Consumo Flex, Piani a consumo e Premium |
Le app per le funzioni eseguite in un piano a consumo flessibile, in un piano a consumo o in un piano Premium non possono usare funzionalità di backup personalizzate e automatiche nel servizio app. In questi piani di scalabilità dinamica il contenuto dell'app per le funzioni viene gestito in Archiviazione di Azure. Usare le opzioni di ridondanza di Archiviazione di Azure per assicurarsi che l'account di archiviazione soddisfi le destinazioni di disponibilità e durabilità durante un'interruzione. È anche possibile scaricare il progetto di app per le funzioni esistente come file .zip dal portale di Azure. |
È consigliabile pianificare l'affidabilità nelle app per le funzioni. |
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 in servizio app di 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, 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 con 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.
Con questa architettura di esempio:
- Le app del servizio app identiche vengono distribuite in due aree separate, tra cui il piano tariffario e il numero di istanze.
- Il traffico pubblico diretto alle app del 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 di 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 nel servizio app sono riepilogati nel modo seguente:
Creare due piani di servizio app in due aree di Azure diverse. Configurare i due piani di servizio app in modo identico.
Creare due istanze dell'app Web, con una in ogni piano di servizio app.
Creare una risorsa Frontdoor di Azure con:
- Endpoint.
- Due gruppi di origine, ognuno con priorità uno. La priorità uguale indica a Frontdoor di Azure di instradare il traffico a entrambe le aree in modo uniforme (quindi attivo-attivo).
- Un itinerario.
Limitare il traffico di rete alle app Web solo dall'istanza di Frontdoor di Azure.
Impostare e configurare tutti gli altri servizi back-end di Azure, ad esempio database, account di archiviazione e provider di autenticazione.
Distribuire il codice in entrambe le app Web con distribuzione continua.
Esercitazione: Creare un'app a più aree a disponibilità elevata nel servizio app di Azure illustra come configurare un'architettura attiva-passiva. Gli stessi passaggi con modifiche minime (impostazione della priorità su "1" per entrambe le origini nel gruppo 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).
Con questa architettura di esempio:
Le app del servizio app identiche vengono distribuite in due aree separate.
Il traffico pubblico diretto alle app del 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 la 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 potrebbe richiedere una scalabilità manuale quando l'area secondaria diventa l'area attiva. L'obiettivo RTO durante un failover geografico dipende dal tempo necessario per aumentare le istanze ed effettuare lo scale out.
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 disponga di 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 ed effettuare lo scale out.
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 essa 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 di 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 nel servizio app sono riepilogati nel modo seguente:
- Creare due piani di 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.
- Configurare le regole di scalabilità automatica per il piano di servizio app secondario in modo che venga ridimensionata allo stesso numero di istanze del database primario quando l'area primaria diventa inattiva.
- Creare due istanze dell'app Web, con una in ogni piano di servizio app.
- Creare una risorsa Frontdoor di Azure con:
- Endpoint.
- Un gruppo di origine con priorità uno per l'area primaria.
- Un secondo gruppo di origine con priorità due 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.
- Limitare il traffico di rete alle app Web solo dall'istanza di Frontdoor di Azure.
- Impostare e configurare tutti gli altri servizi back-end di Azure, ad esempio database, account di archiviazione e provider di autenticazione.
- Distribuire il codice in entrambe le app Web con distribuzione continua.
Esercitazione: Creare un'app a più aree a disponibilità elevata nel servizio app di Azure 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 di archiviazione di Microsoft 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 di archiviazione di Microsoft Azure nella stessa area.
La replica tra aree dei backup dipende dalla configurazione della ridondanza dei dati nell'account di archiviazione di Azure. Se possibile, è consigliabile impostare l'account di archiviazione di Microsoft Azure come archiviazione con ridondanza geografica della zona. 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 su come progettare le 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 dipendenti del servizio app necessarie usando i backup dall'account di archiviazione di Microsoft 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 nel servizio app sono riepilogati nel modo seguente:
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.
Abilitare RA-GRS o RA-GZRS (accesso in lettura per l'area secondaria).
Configurare il backup personalizzato per l'app Web. È possibile decidere di impostare una pianificazione per i backup dell'app Web, ad esempio ogni ora.
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 è parte di 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:
I passaggi per creare un'area ad accesso sporadico passivo senza archiviazione con ridondanza geografica e archiviazione con ridondanza geografica sono riepilogati come segue:
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.
Configurare il backup personalizzato per l'app Web. È possibile decidere di impostare una pianificazione per i backup dell'app Web, ad esempio ogni ora.
Verificare che i file di backup dell'app Web possano essere recuperati nell'area secondaria dell'account di archiviazione.
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.
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.