Approcci alle app servizio app in più aree per il ripristino di emergenza

Servizio app di Azure

Frontdoor di Azure

Quando si distribuisce un'app Web del servizio app Azure in una singola area che, a causa di emergenza o interruzione, non è più disponibile, si rischia di non essere più disponibile dell'applicazione. Per assicurarsi che l'applicazione continui a essere disponibile quando l'area non è disponibile, è possibile implementare un'architettura in più aree. Con un'architettura in più aree si crea una distribuzione identica in un'area di Azure secondaria. Con una distribuzione dell'area secondaria, è possibile replicare i dati per ripristinare l'ultimo stato dell'applicazione; e possono replicare anche altri componenti della soluzione.

Questo articolo descrive tre approcci architetturali in più aree comunemente usati per servizio app e ambiente del servizio app.

Approcci da considerare

I piani di continuità aziendale sono influenzati da due metriche chiave:

• Obiettivo del tempo di ripristino (RTO), ovvero il tempo di inattività massimo tollerabile durante un'emergenza.
• Obiettivo del punto di ripristino (RPO), ovvero la perdita massima di dati tollerabile durante un'emergenza.

Per altre informazioni sugli obiettivi di ripristino, ad esempio RTO e RPO, vedere Obiettivi di ripristino e raccomandazioni per la definizione degli obiettivi di affidabilità.

Con la piattaforma Azure è possibile progettare soluzioni applicative in più aree in modi diversi. Questo articolo descrive le architetture che supportano requisiti RTO e RPO diversi e presentano altri compromessi per i costi e la complessità:

Metrica	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ì	NO	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

Anche se i tre approcci descritti di seguito sono comuni, non sono l'unico modo per ottenere una soluzione in più aree in Azure. Adattare le soluzioni per soddisfare i propri requisiti.

Nota

L'applicazione dipende molto probabilmente da altri servizi in Azure, ad esempio database SQL di Azure, account Archiviazione di Azure e code di messaggi. Quando si progetta una strategia di ripristino di emergenza, è necessario prendere in considerazione anche ognuno di questi servizi di Azure dipendenti.

Per altre informazioni sulle soluzioni in più aree per i servizi di Azure, vedere Guide all'affidabilità dei servizi di Azure.

Monitoraggio

È importante configurare il monitoraggio e gli avvisi per le app Web in modo che il team ottenga notifiche tempestive durante un errore dell'area. app Azure test di disponibilità di Insights offre un modo per monitorare la disponibilità di un'applicazione. Per altre informazioni, vedere Test di disponibilità di Application Insights.

Distribuzione

Le soluzioni in più aree possono essere complesse da distribuire e configurare. È importante che le istanze in ogni area vengano mantenute sincronizzate.

Per gestire la distribuzione e la configurazione di risorse di Azure come servizio app, 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 Bicep, modelli di Azure Resource Manager o Terraform.

È anche necessario configurare le pipeline CI/CD per distribuire il codice, incluso quando si usano più aree. Prendere in considerazione l'uso di Azure Pipelines o GitHub Actions. Per altre informazioni, vedere Distribuzione continua in servizio app di Azure.

Architettura attiva-attiva

In un'architettura attiva-attiva, le app Web identiche vengono distribuite in due aree separate. Frontdoor di Azure viene usato per instradare il traffico a entrambe le aree attive:

Le applicazioni servizio app di ogni area usano la stessa configurazione, incluso il piano tariffario e il numero di istanze.

Durante le normali operazioni, il traffico pubblico diretto all'app servizio app viene bloccato. Il traffico viene invece instradato tramite Frontdoor di Azure a entrambe le aree attive. Questo approccio consente di assicurarsi che le richieste vengano esaminate dal web application firewall (WAF) di Frontdoor di Azure o che altrimenti siano protette o gestite centralmente.

Durante un errore di area, se una delle aree passa offline, i probe di integrità di Frontdoor di Azure rilevano l'origine difettosa e riconfigurano le route in modo che il traffico venga inviato esclusivamente all'area che rimane online.

Durante un ripristino di area difettosa (failback), i probe di integrità di Frontdoor di Azure rilevano l'origine integra e ripristinano il normale routing del traffico.

Consigli

• Per soddisfare un RPO pari a zero per il contenuto dell'applicazione, usare una soluzione CI/CD per distribuire i file dell'applicazione in entrambe le app Web.

• Se possibile, archiviare lo stato dell'applicazione all'esterno del file system servizio app, ad esempio in un database o Archiviazione di Azure. Configurare questi componenti per soddisfare i requisiti di ridondanza geografica.

  Suggerimento

  Se l'applicazione modifica attivamente il file system e l'area dell'app servizio app ha un'area abbinata, è possibile ridurre l'RPO per il file system scrivendo 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.

Considerazioni

• RTO basso: L'RTO durante un failover geografico di questo tipo dipende dalla frequenza con cui i probe di integrità rilevano l'area difettosa. Per impostazione predefinita, i probe controllano ogni 30 secondi, ma è possibile configurare una frequenza di probe diversa.

• Bilanciamento del carico e failover: questo approccio usa Frontdoor di Azure per il bilanciamento del carico globale, la distribuzione del traffico e il failover. 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.

Distribuire app Web active-active-active servizio app

Seguire questa procedura per creare un approccio attivo-attivo per le app Web usando servizio app:

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

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

3. Creare una risorsa Frontdoor di Azure con:

   • Endpoint.
   • Un gruppo di origine con due origini, ognuna con priorità 1. I valori di priorità uguali indicano a Frontdoor di Azure di instradare il traffico alle applicazioni in entrambe le aree (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.

L'esercitazione Creare un'app a più aree a disponibilità elevata in app Azure Service illustra come configurare un'architettura attiva-passiva. Per distribuire un approccio attivo-attivo, seguire la stessa procedura, ma con un'unica eccezione: in Frontdoor di Azure configurare entrambe le origini nel gruppo di origine per avere una priorità pari a 1.

Architettura attiva-passiva

In un'architettura attiva-passiva, le app Web identiche vengono distribuite in due aree separate. Frontdoor di Azure viene usato per instradare il traffico a un'unica area (l'area attiva ).

Durante le normali operazioni, Frontdoor di Azure instrada il traffico solo all'area primaria. Il traffico pubblico diretto alle app del servizio app è bloccato.

Durante un errore di area, se l'area primaria diventa inattiva, i probe di integrità di Frontdoor di Azure rilevano l'origine difettosa e avviano il routing del traffico all'origine nell'area secondaria. L'area secondaria diventa quindi 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.

Durante un ripristino dell'area difettosa (failback), Frontdoor di Azure indirizza automaticamente il traffico all'area primaria e l'architettura torna attiva-passiva come in precedenza.

Nota

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.

Consigli

• Per soddisfare un RPO pari a zero per il contenuto dell'applicazione, usare una soluzione CI/CD per distribuire i file dell'applicazione in entrambe le app Web.

• Se possibile, archiviare lo stato dell'applicazione all'esterno del file system servizio app, ad esempio in un database o Archiviazione di Azure. Configurare questi componenti per soddisfare i requisiti di ridondanza geografica.

  Suggerimento

  Se l'applicazione modifica attivamente il file system e l'area dell'app servizio app ha un'area abbinata, è possibile ridurre l'RPO per il file system scrivendo 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.

Considerazioni

• Controlli dei costi: le app di servizio app identiche vengono distribuite in due aree separate. 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 deve essere configurata nell'area secondaria nel caso in cui il traffico venga reindirizzato e si verifichi un improvviso afflusso di richieste. È consigliabile avere regole di scalabilità automatica simili nelle aree attive e passive.

• Bilanciamento del carico e failover: questo approccio usa Frontdoor di Azure per il bilanciamento del carico globale, la distribuzione del traffico e il failover. 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.

Distribuire app Web attive-passive servizio app

Seguire questa procedura per creare un approccio attivo-passivo per le app Web usando servizio app:

1. 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.

2. 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.

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

4. Creare una risorsa Frontdoor di Azure con:

   • Endpoint.

   • Un gruppo di origine con due origini:

     • Origine con priorità 1 per l'applicazione nell'area primaria.
     • Seconda origine con priorità 2 per l'applicazione nell'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 nel servizio app di Azure illustra come configurare un'architettura attiva-passiva.

Architettura a freddo passivo

In un'architettura passiva/fredda, l'app Web viene distribuita in una singola area primaria. I file dell'applicazione e alcuni database vengono sottoposti a backup in un account Archiviazione di Azure. I backup vengono replicati in un'altra area. Se l'area primaria non è disponibile, distribuire manualmente un'altra app in una seconda area e ripristinare dal backup.

Nota

Gli approcci passivi a freddo si basano sull'intervento manuale durante una falure dell'area e spesso comportano tempi di inattività e perdita di dati significativi. Per la maggior parte delle soluzioni di livello di produzione, è consigliabile considerare una soluzione attiva-attiva o attiva-passiva.

Replica tra più aree

Questo approccio usa servizio app backup per eseguire regolarmente il backup dell'app Web in un account Archiviazione di Azure nella stessa area. Per configurare la replica tra aree dei backup, configurare l'account di archiviazione.

L'approccio usato per configurare la replica tra aree dipende dal fatto che l'area disponga di una coppia. Per altre informazioni, vedere Aree e aree abbinate di Azure con zone di disponibilità e nessuna coppia di aree.

Aree con una coppia

Usare la replica ra-GZRS , se disponibile. RA-GZRS offre ridondanza della zona sincrona all'interno di un'area e asincrona in un'area secondaria. Fornisce anche l'accesso in sola lettura all'interno dell'area secondaria, essenziale per garantire che sia possibile recuperare i backup quando l'area primaria dell'account di archiviazione diventa non disponibile.

Se l'archiviazione con ridondanza geografica e accesso in lettura non è disponibile, configurare l'account come archiviazione con ridondanza geografica e accesso in lettura.

Ra-GZRS e RA-GRS hanno un RPO di circa 15 minuti.

Per altre informazioni sulla progettazione delle applicazioni per sfruttare l'archiviazione con ridondanza geografica, vedere Usare la ridondanza geografica per progettare applicazioni a disponibilità elevata.

Aree senza coppia

È necessario replicare i backup dell'app in un account di archiviazione in un'area diversa. La replica degli oggetti di archiviazione di Azure consente di configurare la replica automatica dei BLOB tra due account di archiviazione, anche se si trovano in aree diverse. Archiviazione di Azure gestisce automaticamente il processo di replica.

La replica degli oggetti non garantisce la velocità con cui vengono replicati i dati. Tuttavia, è possibile controllare lo stato di replica di un BLOB.

Se è necessario controllare la frequenza di replica dei dati tra account di archiviazione, è possibile usare uno strumento come AzCopy per copiare in modo esplicito i file di backup tra account di archiviazione in aree diverse. AzCopy è uno strumento, non un servizio, quindi è necessario configurarlo per l'esecuzione usando Automazione di Azure o un'altra piattaforma di calcolo:

Esperienza inattiva per l'area

Se l'area primaria non è disponibile, è necessario rilevare la perdita di area. Per altre informazioni, vedere Monitoraggio.

Per preparare l'area secondaria a ricevere il traffico, distribuire tutte le risorse necessarie servizio app e le risorse dipendenti usando i backup dell'account Archiviazione di Azure nell'area secondaria.

Considerazioni

• RTO elevato: poiché questo processo richiede il rilevamento e la risposta manuali, l'obiettivo RTO per questo scenario potrebbe essere di ore o persino giorni. Per ridurre al minimo l'RTO, compilare e testare un playbook completo che delinea tutti i passaggi necessari per ripristinare il backup dell'app Web in un'altra area di Azure.

  Anche dopo aver creato l'applicazione nell'area secondaria, potrebbe essere necessario gestire complessità come i record DNS e i certificati TLS. Assicurarsi di aver pianificato ogni passaggio necessario per inviare il traffico all'area secondaria e testare regolarmente i piani.

• RPO elevato: i backup possono essere pianificati fino a una volta all'ora. Se l'applicazione primaria diventa offline, il backup ripristinato in un'area secondaria potrebbe essere obsoleto. L'RPO dipende dalla frequenza dei backup e dalla velocità con cui vengono replicati i backup tra aree.

Procedura

La procedura usata per configurare una distribuzione a freddo passivo dipende dal fatto che l'area disponga di una coppia. Per altre informazioni, vedere Aree e aree abbinate di Azure con zone di disponibilità e nessuna coppia di aree.

Aree con una coppia

I passaggi per creare un'area ad accesso sporadico passivo per l'app Web in servizio app sono i seguenti:

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.

Aree senza coppia

I passaggi per creare un'area ad accesso sporadico passivo per l'app Web in servizio app sono i seguenti:

1. Creare un account di archiviazione di Azure nella stessa area dell'app Web. Scegliere Livello di prestazioni Standard e selezionare ridondanza come archiviazione con ridondanza della zona (ZRS) se disponibile.

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

4. Configurare la replica di oggetti nel contenitore nell'account di archiviazione primario in modo che venga replicata in un contenitore nell'account di archiviazione secondario.

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

Passaggi successivi

Esaminare le architetture di riferimento del servizio app Azure:

• Per un'applicazione con ridondanza della zona a singola area, vedere Applicazione Web con ridondanza della zona a disponibilità elevata di base.
• Per un'applicazione multi-area attiva/passiva, vedere Applicazione Web multi-area a disponibilità elevata.

Quando si distribuisce un'app Web del servizio app Azure in una singola area che, a causa di emergenza o interruzione, non è più disponibile, si rischia di non essere più disponibile dell'applicazione. Per assicurarsi che l'applicazione continui a essere disponibile quando l'area non è disponibile, è possibile implementare un'architettura in più aree. Con un'architettura in più aree si crea una distribuzione identica in un'area di Azure secondaria. Con una distribuzione dell'area secondaria, è possibile replicare i dati per ripristinare l'ultimo stato dell'applicazione; e possono replicare anche altri componenti della soluzione.

Questo articolo descrive tre approcci architetturali in più aree comunemente usati per servizio app e ambiente del servizio app.

Approcci da considerare

I piani di continuità aziendale sono influenzati da due metriche chiave:

• Obiettivo del tempo di ripristino (RTO), ovvero il tempo di inattività massimo tollerabile durante un'emergenza.
• Obiettivo del punto di ripristino (RPO), ovvero la perdita massima di dati tollerabile durante un'emergenza.

Per altre informazioni sugli obiettivi di ripristino, ad esempio RTO e RPO, vedere Obiettivi di ripristino e raccomandazioni per la definizione degli obiettivi di affidabilità.

Con la piattaforma Azure è possibile progettare soluzioni applicative in più aree in modi diversi. Questo articolo descrive le architetture che supportano requisiti RTO e RPO diversi e presentano altri compromessi per i costi e la complessità:

Metrica	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ì	NO	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

Anche se i tre approcci descritti di seguito sono comuni, non sono l'unico modo per ottenere una soluzione in più aree in Azure. Adattare le soluzioni per soddisfare i propri requisiti.

Nota

L'applicazione dipende molto probabilmente da altri servizi in Azure, ad esempio database SQL di Azure, account Archiviazione di Azure e code di messaggi. Quando si progetta una strategia di ripristino di emergenza, è necessario prendere in considerazione anche ognuno di questi servizi di Azure dipendenti.

Per altre informazioni sulle soluzioni in più aree per i servizi di Azure, vedere Guide all'affidabilità dei servizi di Azure.

Monitoraggio

È importante configurare il monitoraggio e gli avvisi per le app Web in modo che il team ottenga notifiche tempestive durante un errore dell'area. app Azure test di disponibilità di Insights offre un modo per monitorare la disponibilità di un'applicazione. Per altre informazioni, vedere Test di disponibilità di Application Insights.

Distribuzione

Le soluzioni in più aree possono essere complesse da distribuire e configurare. È importante che le istanze in ogni area vengano mantenute sincronizzate.

Per gestire la distribuzione e la configurazione di risorse di Azure come servizio app, 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 Bicep, modelli di Azure Resource Manager o Terraform.

È anche necessario configurare le pipeline CI/CD per distribuire il codice, incluso quando si usano più aree. Prendere in considerazione l'uso di Azure Pipelines o GitHub Actions. Per altre informazioni, vedere Distribuzione continua in servizio app di Azure.

Architettura attiva-attiva

In un'architettura attiva-attiva, le app Web identiche vengono distribuite in due aree separate. Frontdoor di Azure viene usato per instradare il traffico a entrambe le aree attive:

Le applicazioni servizio app di ogni area usano la stessa configurazione, incluso il piano tariffario e il numero di istanze.

Durante le normali operazioni, il traffico pubblico diretto all'app servizio app viene bloccato. Il traffico viene invece instradato tramite Frontdoor di Azure a entrambe le aree attive. Questo approccio consente di assicurarsi che le richieste vengano esaminate dal web application firewall (WAF) di Frontdoor di Azure o che altrimenti siano protette o gestite centralmente.

Durante un errore di area, se una delle aree passa offline, i probe di integrità di Frontdoor di Azure rilevano l'origine difettosa e riconfigurano le route in modo che il traffico venga inviato esclusivamente all'area che rimane online.

Durante un ripristino di area difettosa (failback), i probe di integrità di Frontdoor di Azure rilevano l'origine integra e ripristinano il normale routing del traffico.

Consigli

• Per soddisfare un RPO pari a zero per il contenuto dell'applicazione, usare una soluzione CI/CD per distribuire i file dell'applicazione in entrambe le app Web.

• Se possibile, archiviare lo stato dell'applicazione all'esterno del file system servizio app, ad esempio in un database o Archiviazione di Azure. Configurare questi componenti per soddisfare i requisiti di ridondanza geografica.

  Suggerimento

  Se l'applicazione modifica attivamente il file system e l'area dell'app servizio app ha un'area abbinata, è possibile ridurre l'RPO per il file system scrivendo 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.

Considerazioni

• RTO basso: L'RTO durante un failover geografico di questo tipo dipende dalla frequenza con cui i probe di integrità rilevano l'area difettosa. Per impostazione predefinita, i probe controllano ogni 30 secondi, ma è possibile configurare una frequenza di probe diversa.

• Bilanciamento del carico e failover: questo approccio usa Frontdoor di Azure per il bilanciamento del carico globale, la distribuzione del traffico e il failover. 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.

Distribuire app Web active-active-active servizio app

Seguire questa procedura per creare un approccio attivo-attivo per le app Web usando servizio app:

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

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

3. Creare una risorsa Frontdoor di Azure con:

   • Endpoint.
   • Un gruppo di origine con due origini, ognuna con priorità 1. I valori di priorità uguali indicano a Frontdoor di Azure di instradare il traffico alle applicazioni in entrambe le aree (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.

L'esercitazione Creare un'app a più aree a disponibilità elevata in app Azure Service illustra come configurare un'architettura attiva-passiva. Per distribuire un approccio attivo-attivo, seguire la stessa procedura, ma con un'unica eccezione: in Frontdoor di Azure configurare entrambe le origini nel gruppo di origine per avere una priorità pari a 1.

Architettura attiva-passiva

In un'architettura attiva-passiva, le app Web identiche vengono distribuite in due aree separate. Frontdoor di Azure viene usato per instradare il traffico a un'unica area (l'area attiva ).

Durante le normali operazioni, Frontdoor di Azure instrada il traffico solo all'area primaria. Il traffico pubblico diretto alle app del servizio app è bloccato.

Durante un errore di area, se l'area primaria diventa inattiva, i probe di integrità di Frontdoor di Azure rilevano l'origine difettosa e avviano il routing del traffico all'origine nell'area secondaria. L'area secondaria diventa quindi 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.

Durante un ripristino dell'area difettosa (failback), Frontdoor di Azure indirizza automaticamente il traffico all'area primaria e l'architettura torna attiva-passiva come in precedenza.

Nota

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.

Consigli

• Per soddisfare un RPO pari a zero per il contenuto dell'applicazione, usare una soluzione CI/CD per distribuire i file dell'applicazione in entrambe le app Web.

• Se possibile, archiviare lo stato dell'applicazione all'esterno del file system servizio app, ad esempio in un database o Archiviazione di Azure. Configurare questi componenti per soddisfare i requisiti di ridondanza geografica.

  Suggerimento

  Se l'applicazione modifica attivamente il file system e l'area dell'app servizio app ha un'area abbinata, è possibile ridurre l'RPO per il file system scrivendo 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.

Considerazioni

• Controlli dei costi: le app di servizio app identiche vengono distribuite in due aree separate. 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 deve essere configurata nell'area secondaria nel caso in cui il traffico venga reindirizzato e si verifichi un improvviso afflusso di richieste. È consigliabile avere regole di scalabilità automatica simili nelle aree attive e passive.

• Bilanciamento del carico e failover: questo approccio usa Frontdoor di Azure per il bilanciamento del carico globale, la distribuzione del traffico e il failover. 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.

Distribuire app Web attive-passive servizio app

Seguire questa procedura per creare un approccio attivo-passivo per le app Web usando servizio app:

1. 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.

2. 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.

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

4. Creare una risorsa Frontdoor di Azure con:

   • Endpoint.

   • Un gruppo di origine con due origini:

     • Origine con priorità 1 per l'applicazione nell'area primaria.
     • Seconda origine con priorità 2 per l'applicazione nell'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 nel servizio app di Azure illustra come configurare un'architettura attiva-passiva.

Architettura a freddo passivo

In un'architettura passiva/fredda, l'app Web viene distribuita in una singola area primaria. I file dell'applicazione e alcuni database vengono sottoposti a backup in un account Archiviazione di Azure. I backup vengono replicati in un'altra area. Se l'area primaria non è disponibile, distribuire manualmente un'altra app in una seconda area e ripristinare dal backup.

Nota

Gli approcci passivi a freddo si basano sull'intervento manuale durante una falure dell'area e spesso comportano tempi di inattività e perdita di dati significativi. Per la maggior parte delle soluzioni di livello di produzione, è consigliabile considerare una soluzione attiva-attiva o attiva-passiva.

Replica tra più aree

Questo approccio usa servizio app backup per eseguire regolarmente il backup dell'app Web in un account Archiviazione di Azure nella stessa area. Per configurare la replica tra aree dei backup, configurare l'account di archiviazione.

L'approccio usato per configurare la replica tra aree dipende dal fatto che l'area disponga di una coppia. Per altre informazioni, vedere Aree e aree abbinate di Azure con zone di disponibilità e nessuna coppia di aree.

Aree con una coppia

Usare la replica ra-GZRS , se disponibile. RA-GZRS offre ridondanza della zona sincrona all'interno di un'area e asincrona in un'area secondaria. Fornisce anche l'accesso in sola lettura all'interno dell'area secondaria, essenziale per garantire che sia possibile recuperare i backup quando l'area primaria dell'account di archiviazione diventa non disponibile.

Se l'archiviazione con ridondanza geografica e accesso in lettura non è disponibile, configurare l'account come archiviazione con ridondanza geografica e accesso in lettura.

Ra-GZRS e RA-GRS hanno un RPO di circa 15 minuti.

Per altre informazioni sulla progettazione delle applicazioni per sfruttare l'archiviazione con ridondanza geografica, vedere Usare la ridondanza geografica per progettare applicazioni a disponibilità elevata.

Aree senza coppia

È necessario replicare i backup dell'app in un account di archiviazione in un'area diversa. La replica degli oggetti di archiviazione di Azure consente di configurare la replica automatica dei BLOB tra due account di archiviazione, anche se si trovano in aree diverse. Archiviazione di Azure gestisce automaticamente il processo di replica.

La replica degli oggetti non garantisce la velocità con cui vengono replicati i dati. Tuttavia, è possibile controllare lo stato di replica di un BLOB.

Se è necessario controllare la frequenza di replica dei dati tra account di archiviazione, è possibile usare uno strumento come AzCopy per copiare in modo esplicito i file di backup tra account di archiviazione in aree diverse. AzCopy è uno strumento, non un servizio, quindi è necessario configurarlo per l'esecuzione usando Automazione di Azure o un'altra piattaforma di calcolo:

Esperienza inattiva per l'area

Se l'area primaria non è disponibile, è necessario rilevare la perdita di area. Per altre informazioni, vedere Monitoraggio.

Per preparare l'area secondaria a ricevere il traffico, distribuire tutte le risorse necessarie servizio app e le risorse dipendenti usando i backup dell'account Archiviazione di Azure nell'area secondaria.

Considerazioni

• RTO elevato: poiché questo processo richiede il rilevamento e la risposta manuali, l'obiettivo RTO per questo scenario potrebbe essere di ore o persino giorni. Per ridurre al minimo l'RTO, compilare e testare un playbook completo che delinea tutti i passaggi necessari per ripristinare il backup dell'app Web in un'altra area di Azure.

  Anche dopo aver creato l'applicazione nell'area secondaria, potrebbe essere necessario gestire complessità come i record DNS e i certificati TLS. Assicurarsi di aver pianificato ogni passaggio necessario per inviare il traffico all'area secondaria e testare regolarmente i piani.

• RPO elevato: i backup possono essere pianificati fino a una volta all'ora. Se l'applicazione primaria diventa offline, il backup ripristinato in un'area secondaria potrebbe essere obsoleto. L'RPO dipende dalla frequenza dei backup e dalla velocità con cui vengono replicati i backup tra aree.

Procedura

La procedura usata per configurare una distribuzione a freddo passivo dipende dal fatto che l'area disponga di una coppia. Per altre informazioni, vedere Aree e aree abbinate di Azure con zone di disponibilità e nessuna coppia di aree.

Aree con una coppia

I passaggi per creare un'area ad accesso sporadico passivo per l'app Web in servizio app sono i seguenti:

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.

Aree senza coppia

I passaggi per creare un'area ad accesso sporadico passivo per l'app Web in servizio app sono i seguenti:

1. Creare un account di archiviazione di Azure nella stessa area dell'app Web. Scegliere Livello di prestazioni Standard e selezionare ridondanza come archiviazione con ridondanza della zona (ZRS) se disponibile.

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

4. Configurare la replica di oggetti nel contenitore nell'account di archiviazione primario in modo che venga replicata in un contenitore nell'account di archiviazione secondario.

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

Passaggi successivi

Esaminare le architetture di riferimento del servizio app Azure:

• Per un'applicazione con ridondanza della zona a singola area, vedere Applicazione Web con ridondanza della zona a disponibilità elevata di base.
• Per un'applicazione multi-area attiva/passiva, vedere Applicazione Web multi-area a disponibilità elevata.