Condividi tramite


Affidabilità in Servizio app di Azure

Questo articolo descrive il supporto dell'affidabilità in app Azure Service, che copre sia la resilienza all'interno dell'area con le zone di disponibilità che le informazioni sulle distribuzioni in più aree.

La resilienza è una responsabilità condivisa tra l'utente e Microsoft, quindi l'articolo illustra anche i modi per creare una soluzione resiliente che soddisfi le proprie esigenze.

Il Servizio app di Azure è un servizio per l'hosting di applicazioni Web, API REST e back-end mobili, basato su HTTP. app Azure Servizio aggiunge la potenza di Microsoft Azure all'applicazione, con funzionalità di sicurezza, bilanciamento del carico, scalabilità automatica e 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?

Quando si distribuisce app Azure Servizio, è possibile creare più istanze di un piano di servizio app, che rappresenta i ruoli di lavoro di calcolo che eseguono il codice dell'applicazione. Anche se la piattaforma si impegna a distribuire le istanze in domini di errore diversi, non distribuisce automaticamente le istanze tra le zone di disponibilità.

Raccomandazioni per la distribuzione di produzione

Per le distribuzioni di produzione, è necessario:

  • Usare piani di servizio app Premium v3.
  • Abilitare la ridondanza della zona, che richiede che il piano di servizio app usi almeno tre istanze.

Errori temporanei

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

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

Anche se gli SDK forniti da Microsoft gestiscono in genere errori temporanei, perché si ospitano applicazioni personalizzate nel servizio app Azure, è necessario considerare come evitare di causare errori temporanei assicurandosi di:

  • Distribuire più istanze del piano. app Azure Servizio esegue aggiornamenti automatizzati e altre forme di manutenzione nelle istanze del piano. Se un'istanza diventa non integra, il servizio può sostituire automaticamente l'istanza con una nuova istanza integra. Durante il processo di sostituzione, può verificarsi un breve periodo di tempo in cui l'istanza precedente non è disponibile e una nuova istanza non è ancora pronta per gestire il traffico. È possibile ridurre l'impatto di questo comportamento distribuendo più istanze del piano di servizio app.

  • Usare gli slot di distribuzione. app Azure slot di distribuzione del servizio consentono distribuzioni senza tempi di inattività delle applicazioni. Usare gli slot di distribuzione per ridurre al minimo l'impatto delle distribuzioni e delle modifiche di configurazione per gli utenti. L'uso degli slot di distribuzione riduce anche la probabilità che l'applicazione si riavvii, causando un errore temporaneo.

  • Evitare il ridimensionamento. Selezionare invece un livello e le dimensioni dell'istanza che soddisfano i requisiti di prestazioni in un carico tipico. Solo le istanze di scalabilità orizzontale per gestire le modifiche nel volume di traffico. Tenere presente che l'aumento e la riduzione possono attivare un riavvio dell'applicazione.

Supporto della zona di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di ogni area di Azure. In caso di errore di una zona, i servizi possono eseguire il failover in una delle zone rimanenti.

Per altre informazioni sulle zone di disponibilità in Azure, vedere Che cosa sono le zone di disponibilità?.

app Azure Servizio può essere configurato come ridondante della zona, il che significa che le risorse vengono distribuite tra più zone di disponibilità. La distribuzione in più zone consente ai carichi di lavoro di produzione di ottenere resilienza e affidabilità. Il supporto della zona di disponibilità è una proprietà del piano di servizio app.

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.

Quando la piattaforma servizio app alloca istanze per un piano di servizio app con ridondanza della zona, usa il bilanciamento della zona più efficiente offerto dai set di scalabilità di macchine virtuali di Azure sottostanti. Un piano di servizio app è "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.

Per i piani servizio app non configurati come ridondanti della zona, le istanze delle macchine virtuali non sono resilienti agli errori della zona di disponibilità. Possono riscontrare tempi di inattività durante un'interruzione in qualsiasi zona in tale area.

Aree supportate

Per configurare la ridondanza della zona, è necessario usare i tipi di piano Premium v2 o Premium v3.

  • 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.
  • È necessario distribuire almeno tre istanze del piano.

Per informazioni sulle aree che supportano le zone di disponibilità per l'ambiente del servizio app v3, vedere Aree.

Requisiti

::: zone-end

  • È necessario usare i tipi di piano Premium v2 o Premium v3.
  • 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.
  • È necessario distribuire almeno tre istanze del piano.

Considerazioni

Le applicazioni distribuite in un piano di servizio app con ridondanza della zona continuano a essere eseguite e a gestire il traffico anche se più zone nell'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 dell'applicazione possano essere ancora interessati durante un'interruzione della zona di disponibilità. La ridondanza della zona per i piani di servizio app garantisce solo un tempo di attività continuo per le applicazioni distribuite.

Costo

Quando si usano servizio app piani Premium v2 o Premium v3, non sono previsti costi aggiuntivi associati all'abilitazione delle zone di disponibilità, purché nel piano di servizio app siano presenti tre o più istanze. 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 applica un numero minimo di istanze pari a tre e viene addebitato l'utente per queste tre istanze.

ambiente del servizio app v3 ha un modello tariffario specifico per la ridondanza della zona. Per informazioni sui prezzi per l'ambiente del servizio app v3, vedere Prezzi.

Configurare il supporto della zona di disponibilità

Per distribuire un nuovo piano di servizio con ridondanza della zona app Azure, selezionare l'opzione Ridondanza della zona quando si distribuisce il piano.

Per distribuire un nuovo ambiente del servizio con ridondanza della zona app Azure, vedere Creare un ambiente del servizio app.

La ridondanza della zona può essere configurata solo quando si crea un nuovo piano di servizio app. Se si dispone di un piano di servizio app esistente che non è ridondante per la zona, è necessario sostituirlo con un nuovo piano con ridondanza della zona. Non è possibile convertire un piano di servizio app esistente per usare le zone di disponibilità. Analogamente, non è possibile disabilitare la ridondanza della zona in un piano di servizio app esistente.

Pianificazione e gestione della capacità

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.

Routing del traffico tra zone

Durante le normali operazioni, il traffico viene instradato tra tutte le istanze del piano di servizio app disponibili in tutte le zone di disponibilità.

Esperienza di zona inattiva

Rilevamento e risposta: la piattaforma servizio app è responsabile del rilevamento di un errore in una zona di disponibilità e della risposta. Non è necessario eseguire alcuna operazione per avviare un failover di zona.

Richieste attive: quando una zona di disponibilità non è disponibile, tutte le richieste in corso connesse a un'istanza del piano servizio app nella zona di disponibilità difettosa vengono terminate e devono essere ritentate.

Reindirizzamento del traffico: quando una zona non è disponibile, app Azure Servizio rileva le istanze perse da tale zona. Tenta automaticamente di trovare nuove istanze di sostituzione. Distribuisce quindi il traffico tra le nuove istanze in base alle esigenze.

Se è stata configurata la scalabilità automatica e, se si decide che sono necessarie altre istanze, la scalabilità automatica invia anche una richiesta di servizio app per aggiungere altre istanze.

Nota

Il comportamento della scalabilità automatica è indipendente dal comportamento della piattaforma servizio app. La specifica del numero di istanze di scalabilità automatica non deve essere un multiplo di tre.

Importante

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. Se è necessaria una capacità garantita quando si perde una zona di disponibilità, è necessario creare e configurare i piani di servizio app per tenere conto della perdita di una zona. A tale scopo, è possibile effettuare il provisioning eccessivo della capacità del piano di servizio app.

Failback

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

Test per gli errori di zona

app Azure piattaforma del servizio gestisce il routing del traffico, il failover e il failback per i piani di servizio app con ridondanza della zona. Poiché questa funzionalità è completamente gestita, non è necessario avviare o convalidare i processi di errore della zona di disponibilità.

Supporto multi-area

app Azure Service è un servizio a singola area. Se l'area non è più disponibile, anche l'applicazione non è disponibile.

Soluzioni alternative in più aree

Per assicurarsi che l'applicazione diventi meno soggetta a un errore a singola area, è necessario distribuire l'applicazione in più aree. A tal fine, è necessario:

  • Distribuire l'applicazione nelle istanze di ogni area.
  • Configurare il bilanciamento del carico e i criteri di failover.
  • Replicare i dati tra le aree in modo da poter ripristinare l'ultimo stato dell'applicazione.

Per architetture di esempio che illustrano questo approccio, vedere:

Per seguire un'esercitazione che crea un'app in più aree, vedere Esercitazione: Creare un'app a più aree a disponibilità elevata nel servizio app Azure.

Per un approccio di esempio che illustra questa architettura, vedere Distribuzione aziendale a disponibilità elevata con ambiente del servizio app.

Backup

Quando si usa il livello Basic o superiore, è possibile eseguire il backup dell'app servizio app in un file usando le funzionalità di backup e ripristino servizio app. Questa funzionalità è utile se è difficile ridistribuire il codice o se si archivia lo stato su disco. Per la maggior parte delle soluzioni, tuttavia, non è consigliabile basarsi sui backup servizio app e usare invece gli altri metodi descritti in questo articolo per supportare i requisiti di resilienza.

Contratto di servizio

Il contratto di servizio per app Azure Servizio descrive la disponibilità prevista del servizio. Descrive inoltre le condizioni che devono essere soddisfatte per raggiungere tale aspettativa di disponibilità. Per comprendere queste condizioni, è importante esaminare i contratti di servizio (SLA) per i servizi online.

Quando si distribuisce un piano di servizio app con ridondanza della zona, la percentuale di tempo di attività definita nel contratto di servizio aumenta.