Raccomandazioni per l'uso di zone e aree di disponibilità

  • Articolo

Si applica a questa raccomandazione per l'affidabilità di Azure Well-Architected Framework:

RE:05 Aggiungere ridondanza a livelli diversi, soprattutto per i flussi critici. Applicare la ridondanza ai livelli di calcolo, dati, rete e altri livelli di infrastruttura in conformità alle destinazioni di affidabilità identificate.

Guide correlate:Ridondanzadella progettazione | multiregionale a disponibilità elevata

Questa guida descrive i consigli per determinare quando distribuire carichi di lavoro tra zone o aree di disponibilità.

Quando si progetta una soluzione per Azure, è necessario decidere se distribuire tra più zone di disponibilità in un'area o distribuire in più aree. Questa decisione influisce sull'affidabilità, sui costi e sulle prestazioni della soluzione e sulla capacità del team di gestire la soluzione. Questa guida fornisce informazioni sui requisiti aziendali principali che influenzano la decisione, gli approcci che è possibile considerare, i compromessi coinvolti in ogni approccio e l'effetto di ogni approccio sui pilastri principali di Azure Well-Architected Framework.

La decisione sulle aree di Azure migliori da usare per la soluzione è una scelta fondamentale. La guida Selezionare aree di Azure descrive come selezionare e operare in più aree geografiche. La scelta di come usare aree e zone di disponibilità all'interno della soluzione influisce anche su diversi pilastri del framework di Well-Architected:

  • Affidabilità: l'approccio di distribuzione scelto consente di attenuare vari tipi di rischi. In generale, distribuendo il carico di lavoro in un'area più geograficamente distribuita, è possibile ottenere una maggiore resilienza.
  • Ottimizzazione costi: alcuni approcci dell'architettura richiedono la distribuzione di più risorse di altre, che possono aumentare i costi delle risorse. Altri approcci comportano l'invio di dati tra zone o aree geografiche di disponibilità separate, che potrebbero comportare addebiti per il traffico di rete. È anche importante considerare il costo continuo della gestione delle risorse, che in genere è più elevato quando si hanno requisiti aziendali completi.
  • Efficienza delle prestazioni: le zone di disponibilità sono connesse insieme tramite un collegamento di rete a bassa latenza ad alta larghezza di banda, che è sufficiente per la maggior parte dei carichi di lavoro per abilitare la replica e la comunicazione sincrona tra le zone. Tuttavia, se il carico di lavoro è stato testato ed è sensibile alla latenza di rete tra le zone, potrebbe essere necessario valutare la possibilità di individuare fisicamente i componenti del carico di lavoro in modo da ridurre al minimo la latenza quando comunicano.
  • Eccellenza operativa: un'architettura complessa richiede più impegno per distribuire, configurare e gestire. Inoltre, per una soluzione a disponibilità elevata, potrebbe essere necessario pianificare come eseguire il failover in un set secondario di risorse. Il failover, il failback e il reindirizzamento trasparente del traffico possono essere complessi, soprattutto quando sono necessari passaggi manuali. È consigliabile automatizzare i processi di distribuzione e gestione. Per altre informazioni, vedere le guide ai pilastri dell'eccellenza operativa, tra cui OE:05 Infrastructure as code, OE:09 Task automation, OE:10 Automation design e OE:11 Deployment practices.

Tuttavia, si progetta la soluzione, il pilastro Sicurezza si applica. In genere, le decisioni su se e su come si usano zone di disponibilità e aree non modificano il comportamento di sicurezza. Azure applica lo stesso rigore di sicurezza a ogni area e zona di disponibilità.

Suggerimento

Per molti carichi di lavoro di produzione, una distribuzione con ridondanza della zona offre il migliore equilibrio tra i compromessi. È possibile estendere questo approccio con backup dei dati asincroni in un'altra area. Se non si è certi dell'approccio da selezionare, iniziare con questo tipo di distribuzione.

Prendere in considerazione altri approcci al carico di lavoro quando sono necessari i vantaggi specifici offerti da tali approcci, ma tenere presente i compromessi coinvolti.

Definizioni

Termine Definizione
Modalità attiva-attiva Architettura in cui più istanze di una soluzione elaborano attivamente le richieste contemporaneamente.
Modalità attiva-passiva Un'architettura in cui viene designata un'istanza di una soluzione come traffico primario e elabora e una o più istanze secondarie vengono distribuite per servire il traffico se il primario non è disponibile.
Replica asincrona Approccio alla replica dei dati in cui i dati vengono scritti e sottoposti a commit in una posizione. In un secondo momento, le modifiche vengono replicate in un'altra posizione.
Zona di disponibilità Un gruppo separato di data center all'interno di un'area. Ogni zona di disponibilità è indipendente dagli altri, con la propria alimentazione, raffreddamento e infrastruttura di rete. Molte aree supportano le zone di disponibilità.
Data center Struttura che contiene server, apparecchiature di rete e altro hardware per supportare risorse e carichi di lavoro di Azure.
Distribuzione con ridondanza locale Modello di distribuzione in cui una risorsa viene distribuita in una singola area senza riferimento a una zona di disponibilità. In un'area che supporta le zone di disponibilità, la risorsa potrebbe essere distribuita in una delle zone di disponibilità dell'area.
Distribuzione in più aree Modello di distribuzione in cui le risorse vengono distribuite in più aree di Azure.
Aree abbinate Relazione tra due aree di Azure. Alcune aree di Azure sono connesse a un'altra area definita per abilitare tipi specifici di soluzioni multi-area. Le aree di Azure più recenti non sono associate.
Region Perimetro geografico che contiene un set di data center.
Architettura dell'area Configurazione specifica dell'area di Azure, incluso il numero di zone di disponibilità e se l'area è associata a un'altra area.
Replica sincrona Approccio alla replica dei dati in cui i dati vengono scritti e sottoposti a commit in più posizioni. Ogni posizione deve confermare il completamento dell'operazione di scrittura prima del completamento dell'operazione di scrittura complessiva.
Distribuzione zonale (aggiunta) Modello di distribuzione in cui una risorsa viene distribuita in una zona di disponibilità specifica.
Distribuzione con ridondanza della zona Modello di distribuzione in cui una risorsa viene distribuita in più zone di disponibilità. Microsoft gestisce la sincronizzazione dei dati, la distribuzione del traffico e il failover se un'interruzione della zona viene eseguita.

Strategie di progettazione chiave

Azure ha un footprint globale di grandi dimensioni. Un'area di Azure è un perimetro geografico che contiene un set di data center. È necessario avere una conoscenza completa delle aree di Azure e delle zone di disponibilità.

Le aree di Azure hanno diverse configurazioni, denominate anche architetture di area.

Molte aree di Azure forniscono zone di disponibilità, che sono gruppi separati di data center. All'interno di un'area, le zone di disponibilità sono abbastanza vicine per avere connessioni a bassa latenza ad altre zone di disponibilità, ma sono abbastanza lontane per ridurre la probabilità che più di uno sarà interessato da interruzioni locali o meteo. Le zone di disponibilità hanno energia, raffreddamento e infrastruttura di rete indipendenti. Sono progettati in modo che se una zona sperimenta un'interruzione, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle zone rimanenti.

Il diagramma seguente mostra diverse aree di Azure di esempio. Aree 1 e 2 supportano le zone di disponibilità.

Diagramma che mostra data center, zone di disponibilità e aree geografiche.

Se si distribuisce in un'area di Azure che contiene zone di disponibilità, è possibile usare più zone di disponibilità insieme. Usando più zone di disponibilità, è possibile mantenere copie separate dell'applicazione e dei dati all'interno di data center fisici separati in un'area metropolitana di grandi dimensioni.

Esistono due modi per usare le zone di disponibilità in una soluzione:

  • Le risorse zonali vengono aggiunte a una zona di disponibilità specifica. È possibile combinare più distribuzioni zonali in diverse zone per soddisfare i requisiti di affidabilità elevata. È responsabile della gestione della replica dei dati e della distribuzione delle richieste tra zone. Se si verifica un'interruzione in una singola zona di disponibilità, si è responsabili del failover in un'altra zona di disponibilità.
  • Le risorse con ridondanza della zona vengono distribuite in più zone di disponibilità. Microsoft gestisce la distribuzione delle richieste tra zone e la replica dei dati tra zone. Se si verifica un'interruzione in una singola zona di disponibilità, Microsoft gestisce automaticamente il failover.

I servizi di Azure supportano uno o entrambi questi approcci. I servizi PaaS (Platform as a Service) supportano in genere le distribuzioni con ridondanza della zona. I servizi infrastruttura come servizio (IaaS) supportano in genere le distribuzioni zonali. Per altre informazioni sul funzionamento dei servizi di Azure con le zone di disponibilità, vedere Servizi di Azure con supporto per la zona di disponibilità.

Quando Microsoft distribuisce gli aggiornamenti ai servizi, si tenta di usare approcci meno dirompenti per l'utente. Ad esempio, si intende distribuire gli aggiornamenti in un singolo fuso di disponibilità alla volta. Questo approccio può ridurre l'impatto che gli aggiornamenti potrebbero avere su un carico di lavoro attivo, perché il carico di lavoro può continuare a essere eseguito in altre zone mentre l'aggiornamento è in corso. Tuttavia, è in definitiva responsabilità del team del carico di lavoro garantire che il carico di lavoro continui a funzionare durante gli aggiornamenti della piattaforma. Ad esempio, quando si usano set di scalabilità di macchine virtuali con la modalità di orchestrazione flessibile o la maggior parte dei servizi PaaS di Azure, Azure inserisce in modo intelligente le risorse per ridurre l'impatto degli aggiornamenti della piattaforma. Inoltre, è possibile considerare l'overprovisioning , la distribuzione di più istanze di una risorsa, in modo che alcune istanze rimangano disponibili mentre altre istanze vengono aggiornate. Per altre informazioni sul modo in cui Azure distribuisce gli aggiornamenti, vedere Avanzamento delle procedure di distribuzione sicura.

Molte aree hanno anche un'area associata. Le aree associate supportano determinati tipi di approcci di distribuzione multi-area. Alcune aree più recenti hanno più zone di disponibilità e non hanno un'area associata. È comunque possibile distribuire soluzioni multi-area in queste aree, ma gli approcci usati potrebbero essere diversi.

Per altre informazioni su come Azure usa aree e zone di disponibilità, vedere Quali sono le aree di Azure e le zone di disponibilità?

Comprendere le responsabilità condivise

Il principio di responsabilità condivisa descrive in che modo le responsabilità sono suddivise tra il provider di servizi cloud (Microsoft) e l'utente. A seconda del tipo di servizi usati, potrebbe essere necessario assumere più o meno responsabilità per il funzionamento del servizio.

Microsoft offre zone di disponibilità e aree geografiche per offrire flessibilità nel modo in cui si progetta la soluzione per soddisfare i requisiti. Quando si usano i servizi gestiti, Microsoft assume più delle responsabilità di gestione per le risorse, che potrebbero anche includere replica dei dati, failover, failover, failback e altre attività correlate all'funzionamento di un sistema distribuito.

Il proprio codice deve usare procedure consigliate e modelli di progettazione per la gestione degli errori in modo normale. Queste procedure sono ancora più importanti durante le operazioni di failover, ad esempio quelle che si verificano quando si verifica un failover della zona di disponibilità o dell'area, perché il failover tra zone o aree richiede in genere che l'applicazione riprova le connessioni ai servizi.

Identificare i requisiti chiave di business e carico di lavoro

Per prendere una decisione informata su come usare zone di disponibilità e aree nella soluzione, è necessario comprendere i requisiti. Questi requisiti devono essere basati su discussioni tra progettisti di soluzioni e stakeholder aziendali.

Tolleranza di rischio

Le diverse organizzazioni hanno diversi gradi di tolleranza di rischio. Anche all'interno di un'organizzazione, la tolleranza di rischio è spesso diversa per ogni carico di lavoro. La maggior parte dei carichi di lavoro non necessita di disponibilità estremamente elevata. Tuttavia, alcuni carichi di lavoro sono così importanti che vale anche la pena mitigare i rischi che potrebbero verificarsi, come le principali calamità naturali che influiscono su un'ampia area geografica.

Questa tabella elenca alcuni dei rischi comuni da considerare in un ambiente cloud:

Rischio Esempio Probabilità
Interruzione hardware Problema con il disco rigido o le apparecchiature di rete.

Riavvii host.		 Elevata. Qualsiasi strategia di resilienza deve tenere conto di questi rischi.
Interruzione del data center Alimentazione, raffreddamento o errore di rete in un intero data center.

Emergenza naturale in una parte di una zona metropolitana.		 Medio
Interruzione dell'area Grave emergenza naturale che colpisce un'ampia area geografica.

Problema di rete o servizio che rende uno o più servizi di Azure non disponibili in un'intera area.		 Basso

Sarebbe ideale attenuare ogni possibile rischio per ogni carico di lavoro, ma non è pratico o conveniente farlo. È importante avere una discussione aperta con gli stakeholder aziendali in modo da poter prendere decisioni informate sui rischi che è necessario attenuare.

Suggerimento

Indipendentemente dalle destinazioni di affidabilità, tutti i carichi di lavoro devono avere una mitigazione per il ripristino di emergenza. Se il carico di lavoro richiede obiettivi di affidabilità elevata, le strategie di mitigazione devono essere complete e è necessario ridurre il rischio di eventi a bassa probabilità. Per altri carichi di lavoro, prendere una decisione informata su quali rischi si è pronti ad accettare e che è necessario attenuare.

Requisiti di resilienza

È importante comprendere i requisiti di resilienza per il carico di lavoro, tra cui l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO). Questi obiettivi consentono di decidere quali approcci escludere. Se non si hanno requisiti chiari, non è possibile prendere una decisione informata su quale approccio seguire. Per altre informazioni, vedere Requisiti funzionali e non funzionali.

Obiettivi a livello di servizio

È consigliabile comprendere l'obiettivo previsto del livello di tempo di attività della soluzione (SLO). Ad esempio, potrebbe essere necessario avere un requisito aziendale che la soluzione deve soddisfare il 99,9% del tempo di attività.

Azure fornisce contratti di servizio (contratti di servizio) per ogni servizio. Un contratto di servizio indica il livello di tempo di attività previsto dal servizio e le condizioni che è necessario soddisfare per ottenere tale contratto di servizio previsto. Tenere presente tuttavia che il modo in cui un contratto di servizio di Azure indica che la disponibilità del servizio non corrisponde sempre al modo in cui si considera l'integrità del carico di lavoro.

Le decisioni dell'architettura influiscono sul SLO composito della soluzione. In generale, la maggiore ridondanza che si compila nella soluzione, è probabile che il SLO più alto sia. Molti servizi di Azure offrono contratti di servizio più elevati quando si distribuiscono servizi in una configurazione con ridondanza della zona o multi-area. Esaminare i contratti di servizio per ognuno dei servizi di Azure usati per assicurarsi di comprendere come ottimizzare la resilienza e il contratto di servizio del servizio.

Residenza dei dati

Alcune organizzazioni applicano restrizioni alle posizioni fisiche in cui è possibile archiviare ed elaborare i dati. A volte questi requisiti si basano sugli standard legali o normativi. In altre situazioni, un'organizzazione potrebbe decidere di adottare criteri di residenza dei dati per evitare problemi dei clienti. Se si dispone di requisiti di residenza dei dati rigorosi, potrebbe essere necessario usare una distribuzione a area singola o usare un subset di aree e servizi di Azure.

Nota

Evitare di prendere presupposti non fondati sui requisiti di residenza dei dati. Se è necessario rispettare specifici standard normativi, verificare quali standard specificano effettivamente tali standard.

Posizione degli utenti

Comprendendo dove si trovano gli utenti, è possibile prendere una decisione informata su come ottimizzare la latenza e affidabilità per le proprie esigenze. Azure offre molte opzioni per supportare una base utente geograficamente dispersa.

Se gli utenti sono concentrati in un'unica area, una distribuzione a area singola può semplificare i requisiti operativi e ridurre i costi. È tuttavia necessario valutare se una distribuzione a area singola soddisfa i requisiti di affidabilità. Per le applicazioni cruciali, è comunque consigliabile usare una distribuzione multi-area anche se gli utenti sono colocated.

Se gli utenti sono geograficamente dispersi, potrebbe essere opportuno distribuire il carico di lavoro in più aree. I servizi di Azure offrono funzionalità diverse per supportare una distribuzione multi-area e è possibile usare il footprint globale di Azure per migliorare l'esperienza utente e portare le applicazioni in prossimità della base utente. È possibile usare il modello Deployment Stamps o il modello Geodes oppure replicare le risorse in più aree.

Anche se gli utenti si trovano in aree geografiche diverse, valutare se è necessaria una distribuzione multi-area. Valutare se è possibile ottenere i requisiti all'interno di un'unica area usando l'accelerazione del traffico globale, ad esempio l'accelerazione fornita da Frontdoor di Azure.

Budget

Se si opera sotto un budget vincolato, è importante considerare i costi coinvolti nella distribuzione di componenti del carico di lavoro ridondanti. Questi costi possono includere costi aggiuntivi per le risorse, i costi di rete e i costi operativi per la gestione di più risorse e un ambiente più complesso.

Complessità

È consigliabile evitare complessità inutili nell'architettura della soluzione. La complessità più complessa introdotta, più difficile diventa prendere decisioni sull'architettura. Le architetture complesse sono più difficili da gestire, più difficili da proteggere e spesso meno efficienti. Seguire il principio di semplicità.

Facilitazione di Azure

Fornendo aree e zone di disponibilità, Azure consente di selezionare un approccio di distribuzione adatto alle proprie esigenze. Esistono molti approcci che è possibile scegliere, ognuno dei quali offre vantaggi e comporta costi.

Per illustrare gli approcci di distribuzione che è possibile usare, considerare uno scenario di esempio. Si supponga di pensare alla distribuzione di una nuova soluzione che include un'applicazione che scrive i dati in un certo tipo di archiviazione:

Diagramma che mostra un utente che si connette a un'applicazione che si connette all'archiviazione.

Questo esempio non è specifico per i servizi di Azure specifici. È destinato a fornire un semplice esempio per illustrare i concetti fondamentali.

Esistono diversi modi per distribuire questa soluzione. Ogni approccio offre un set diverso di vantaggi e comporta costi diversi. A livello generale, è possibile considerare una distribuzione con ridondanza locale, zonale (aggiunta),ridondanza della zona o distribuzione in più aree . Questa tabella riepiloga alcune delle preoccupazioni fondamentali:

Concetto fondamentale Ridondanza locale Zonale (bloccata) Zone-redundant Multiarea
Affidabilità Bassa affidabilità Dipende dall'approccio Affidabilità elevata o molto elevata Affidabilità elevata o molto elevata
Ottimizzazione dei costi Basso costo Dipende dall'approccio Costo moderato Costo elevato
Efficienza delle prestazioni Prestazioni accettabili (per la maggior parte dei carichi di lavoro) Prestazioni elevate Prestazioni accettabili (per la maggior parte dei carichi di lavoro) Dipende dall'approccio
Eccellenza operativa Requisiti operativi bassi Requisiti operativi elevati Requisiti operativi bassi Requisiti operativi elevati

Questa tabella riepiloga alcuni degli approcci che è possibile usare e come influiscono sull'architettura:

Preoccupazione per l'architettura Ridondanza locale Zonale (bloccata) Zone-redundant Multiarea
Conformità alla residenza dei dati Alto Alto Alto Dipende dall'area geografica
Disponibilità a livello di area Tutte le aree Aree con zone di disponibilità Aree con zone di disponibilità Dipende dall'area geografica

Il resto di questo articolo descrive ognuno degli approcci elencati nella tabella precedente. L'elenco degli approcci non è esaustivo. È possibile decidere di combinare più approcci o usare approcci diversi in diverse parti della soluzione.

Approccio alla distribuzione 1: distribuzioni con ridondanza locale

Se non si specificano più zone di disponibilità o aree quando si distribuiscono le risorse, Azure non garantisce se le risorse vengono distribuite in un singolo data center o suddivise tra più data center nell'area. In alcune situazioni, Azure potrebbe anche spostare la risorsa tra le zone di disponibilità.

Diagramma che mostra la soluzione distribuita in un singolo data center, all'interno di una singola zona di disponibilità.

La maggior parte delle risorse di Azure è a disponibilità elevata per impostazione predefinita, con contratti di servizio elevati e ridondanza predefinita all'interno di un data center gestito dalla piattaforma. Tuttavia, dal punto di vista dell'affidabilità, se una parte dell'area si verifica un'interruzione, è possibile che il carico di lavoro sia interessato. In caso affermativo, la soluzione potrebbe non essere disponibile o i dati potrebbero andare persi.

Per i carichi di lavoro altamente sensibili alla latenza, questo approccio potrebbe comportare anche prestazioni inferiori. I componenti del carico di lavoro potrebbero non essere raggruppati nello stesso data center, quindi è possibile osservare una latenza per il traffico all'interno dell'area. Azure potrebbe anche spostare in modo trasparente le istanze del servizio tra zone di disponibilità, che potrebbero influire leggermente sulle prestazioni. Tuttavia, questo non è un problema per la maggior parte dei carichi di lavoro.

Questa tabella riepiloga alcune delle preoccupazioni fondamentali:

Concetto fondamentale Impatto
Affidabilità Bassa affidabilità. I servizi sono soggetti a interruzioni in caso di errore di un data center. È tuttavia possibile compilare un'applicazione in modo che sia resiliente ad altri tipi di errori.
Ottimizzazione dei costi Costo più basso. È sufficiente avere una singola istanza di ogni risorsa e non si comportano costi di larghezza di banda tra zone o tra aree.
Efficienza delle prestazioni Per la maggior parte dei carichi di lavoro:prestazioni accettabili. È probabile che questo approccio fornisca prestazioni soddisfacenti.

Per carichi di lavoro altamente sensibili alla latenza:prestazioni ridotte. Non è garantito che i componenti si trovino nella stessa zona di disponibilità, pertanto è possibile che si verifichino prestazioni inferiori per i componenti sensibili alla latenza.
Eccellenza operativa Efficienza operativa elevata. È sufficiente distribuire e gestire una singola istanza di ogni risorsa.

In questa tabella vengono riepilogate alcune problematiche dal punto di vista dell'architettura:

Preoccupazione per l'architettura Impatto
Conformità alla residenza dei dati Elevata. Quando si distribuisce una soluzione che usa questo approccio, i dati vengono archiviati nell'area di Azure selezionata.
Disponibilità a livello di area Elevata. Questo approccio può essere usato in qualsiasi area di Azure.

Distribuzioni con ridondanza locale con backup tra aree

È possibile estendere una distribuzione con ridondanza locale eseguendo backup regolari dell'infrastruttura e dei dati in un'area secondaria. Questo approccio aggiunge un ulteriore livello di protezione per attenuare un'interruzione nell'area primaria. Di seguito è riportata un'immagine di tale finestra:

Diagramma che mostra la soluzione distribuita in un singolo data center, con backup in un'altra area.

Quando si implementa questo approccio, è necessario considerare attentamente il valore RTO e RPO:

  • Tempo di ripristino: se si verifica un'interruzione a livello di area, potrebbe essere necessario ricompilare la soluzione in un'altra area di Azure, che influisce sul tempo di ripristino. Prendere in considerazione la creazione della soluzione usando un approccio IaC (Infrastructure-as-Code) in modo da poter ridistribuire rapidamente in un'altra area in caso di emergenza grave. Assicurarsi che gli strumenti e i processi di distribuzione siano altrettanto resilienti delle applicazioni in modo che sia possibile usarli per ridistribuire la soluzione anche in caso di interruzione. Pianificare e ripetere i passaggi necessari per ripristinare la soluzione in uno stato di lavoro.
  • Punto di ripristino: la frequenza di backup determina la quantità di perdita di dati che potrebbe verificarsi (il punto di ripristino). In genere è possibile controllare la frequenza dei backup in modo che sia possibile soddisfare il valore RPO.

Questa tabella riepiloga alcune delle preoccupazioni fondamentali:

Concetto fondamentale Impatto
Affidabilità Affidabilità moderata. I servizi sono soggetti a interruzioni in caso di errore di un data center. Il backup dei dati viene eseguito in modo asincrono in un'area geograficamente separata, riducendo l'effetto di un'interruzione completa dell'area riducendo al minimo la perdita di dati. In un'interruzione completa dell'area è possibile ripristinare manualmente le operazioni in un'altra area. Tuttavia, i processi di ripristino possono essere complessi e possono richiedere tempo per il ripristino manuale nell'altra area.
Ottimizzazione dei costi Costi contenuti. In genere, l'aggiunta di un backup a un'altra area costa solo leggermente di più rispetto alla distribuzione di una risorsa con ridondanza locale.
Efficienza delle prestazioni Per la maggior parte dei carichi di lavoro:prestazioni accettabili. È probabile che questo approccio fornisca prestazioni soddisfacenti.

Per carichi di lavoro altamente sensibili alla latenza:prestazioni ridotte. Non è garantito che i componenti si trovino nella stessa zona di disponibilità, pertanto è possibile che si verifichino prestazioni inferiori per i componenti sensibili alla latenza.
Eccellenza operativa Durante qualsiasi interruzione all'interno di un'area:Bassa efficienza operativa. Il failover è responsabilità dell'utente e potrebbe richiedere operazioni manuali e ridistribuzioni.

In questa tabella vengono riepilogate alcune problematiche dal punto di vista dell'architettura:

Preoccupazione per l'architettura Impatto
Conformità alla residenza dei dati Dipende dalla selezione dell'area. I dati vengono archiviati principalmente nell'area di Azure specificata. Tuttavia, è necessario selezionare un'altra area per archiviare i backup, quindi è importante selezionare un'area compatibile con i requisiti di residenza dei dati.
Disponibilità a livello di area Elevata. È possibile usare questo approccio in qualsiasi area di Azure.

Approccio alla distribuzione 2: distribuzioni di zona (aggiunte)

In una distribuzione a livello di zona specificare che le risorse devono essere distribuite in una zona di disponibilità specifica. Questo approccio viene talvolta definito distribuzione aggiunta alla zona .

Diagramma che mostra la soluzione distribuita in una zona di disponibilità specifica. Viene usato un approccio di distribuzione di zona.

Un approccio di zona riduce la latenza tra i componenti. Tuttavia, per sé, non aumenta la resilienza della soluzione. Per aumentare la resilienza, è necessario distribuire più istanze dei componenti in più zone di disponibilità e decidere come instradare il traffico tra ogni istanza. Questo esempio mostra un approccio di routing del traffico attivo-passivo :

Diagramma che mostra la soluzione distribuita in più zone di disponibilità. Viene usato un approccio di routing del traffico attivo-passivo.

Nell'esempio precedente viene distribuito un servizio di bilanciamento del carico tra più zone di disponibilità. È importante considerare come instradare il traffico tra istanze in zone di disponibilità diverse, perché un'interruzione della zona potrebbe influire anche sulle risorse di rete distribuite in tale zona. È anche possibile usare un servizio di bilanciamento del carico globale, ad esempio Frontdoor di Azure o Gestione traffico di Azure, che non viene distribuito in un'area.

Quando si usa un modello di distribuzione di zona, si assumono molte responsabilità:

  • È necessario distribuire le risorse in ogni zona di disponibilità e configurare e gestire le risorse singolarmente.
  • È necessario decidere come e quando replicare i dati tra le zone di disponibilità e quindi configurare e gestire la replica.
  • L'utente è responsabile della distribuzione delle richieste alle risorse corrette, usando, ad esempio, un servizio di bilanciamento del carico. È necessario assicurarsi che il servizio di bilanciamento del carico soddisfi i requisiti di resilienza. È anche necessario decidere se usare un modello di distribuzione di richieste attivo-passivo o attivo-attivo.
  • Se si verifica un'interruzione di una zona di disponibilità, è necessario gestire il failover per inviare il traffico alle risorse in un'altra zona di disponibilità.

Una distribuzione attiva-passiva in più zone di disponibilità viene talvolta chiamata ripristino di emergenza nell'area o ripristino di emergenza della metropolitana.

Questa tabella riepiloga alcune delle preoccupazioni fondamentali:

Concetto fondamentale Impatto
Affidabilità Quando viene distribuita in una singola zona di disponibilità:affidabilità bassa. Una distribuzione a livello di zona non fornisce resilienza a un'interruzione in un data center o in una zona di disponibilità. Per ottenere una resilienza elevata, è necessario distribuire risorse ridondanti in più zone di disponibilità.

Quando viene distribuita in più zone di disponibilità:affidabilità elevata. I servizi possono essere resi resilienti a un data center o a un'interruzione della zona di disponibilità.
Ottimizzazione dei costi Quando viene distribuita in una singola zona di disponibilità:costo basso. Una distribuzione a zona singola richiede solo una singola istanza di ogni risorsa.

Quando viene distribuita in più zone di disponibilità:costo elevato. Si distribuiscono più istanze delle risorse, ognuna delle quali viene fatturata separatamente. È anche necessario pagare per il traffico tra zone per la replica dei dati.
Efficienza delle prestazioni Prestazioni elevate. La latenza può essere molto bassa quando i componenti che servono una richiesta si trovano nella stessa zona di disponibilità.
Eccellenza operativa Bassa efficienza operativa. È necessario configurare e gestire più istanze del servizio. È necessario replicare i dati tra le zone di disponibilità. Durante un'interruzione della zona di disponibilità, il failover è responsabilità dell'utente.

In questa tabella vengono riepilogate alcune problematiche dal punto di vista dell'architettura:

Preoccupazione per l'architettura Impatto
Conformità alla residenza dei dati Elevata. Quando si distribuisce una soluzione che usa questo approccio, i dati vengono archiviati nell'area di Azure selezionata.
Disponibilità a livello di area Aree con zone di disponibilità. Questo approccio è disponibile in qualsiasi area che supporta le zone di disponibilità.

Questo approccio viene in genere usato per i carichi di lavoro basati su macchine virtuali. Per un elenco completo dei servizi che supportano le distribuzioni di zona, vedere Servizio di zona di disponibilità e supporto a livello di area.

Quando si pianifica una distribuzione a livello di zona, verificare che i servizi di Azure usati siano supportati nelle zone di disponibilità che si prevede di usare. Ad esempio, per elencare gli SKU delle macchine virtuali disponibili in ogni zona di disponibilità, vedere Controllare la disponibilità dello SKU della macchina virtuale.

Suggerimento

Quando si distribuisce una risorsa in una zona di disponibilità specifica, si seleziona il numero di zona. La sequenza di numeri di zona è diversa per ogni sottoscrizione di Azure. Se si distribuiscono risorse in più sottoscrizioni di Azure, verificare i numeri di zona da usare in ogni sottoscrizione. Per altre informazioni, vedere Zone di disponibilità fisiche e logiche.

Approccio alla distribuzione 3: distribuzioni con ridondanza della zona

Quando si usa questo approccio, il livello applicazione viene distribuito tra più zone di disponibilità. Quando arrivano le richieste, un servizio di bilanciamento del carico integrato nel servizio (che si estende su zone di disponibilità) distribuisce le richieste tra le istanze in ogni zona di disponibilità. Se si verifica un'interruzione di un'area di disponibilità, il servizio di bilanciamento del carico indirizza il traffico alle istanze nelle zone di disponibilità integre.

Il livello di archiviazione viene distribuito anche tra più zone di disponibilità. Le copie dei dati dell'applicazione vengono distribuite tra più zone di disponibilità tramite la replica sincrona. Quando l'applicazione apporta una modifica ai dati, il servizio di archiviazione scrive la modifica in più zone di disponibilità e la transazione viene considerata completa solo quando tutte queste modifiche vengono completate. Questo processo garantisce che ogni zona di disponibilità abbia sempre una copia aggiornata dei dati. Se si verifica un'interruzione di una zona di disponibilità, è possibile usare un'altra zona di disponibilità per accedere agli stessi dati.

Diagramma che mostra la soluzione distribuita in più zone di disponibilità. Viene usato un approccio di distribuzione con ridondanza della zona.

Un approccio con ridondanza della zona aumenta la resilienza della soluzione a problemi come le interruzioni del data center. Poiché i dati vengono replicati in modo sincrono, tuttavia, l'applicazione deve attendere che i dati vengano scritti in più posizioni separate che potrebbero trovarsi in parti diverse di un'area metropolitana. Per la maggior parte delle applicazioni, la latenza interessata dalla comunicazione tra zone è trascurabile. Tuttavia, per alcuni carichi di lavoro altamente sensibili alla latenza, la replica sincrona tra zone di disponibilità potrebbe influire sulle prestazioni dell'applicazione.

Questa tabella riepiloga alcune delle preoccupazioni fondamentali:

Concetto fondamentale Impatto
Affidabilità Affidabilità elevata. I servizi sono resilienti a un'interruzione di un data center o di una zona di disponibilità. I dati vengono replicati in modo sincrono tra zone di disponibilità e senza ritardi.
Ottimizzazione dei costi Costo moderato. A seconda dei servizi usati, è possibile che vengano addebitati alcuni costi per i livelli di servizio più elevati per abilitare la ridondanza della zona o alcuni costi di rete tra zone.
Efficienza delle prestazioni Per la maggior parte dei carichi di lavoro:prestazioni accettabili. È probabile che questo approccio fornisca prestazioni soddisfacenti.

Per carichi di lavoro altamente sensibili alla latenza:prestazioni ridotte. Alcuni componenti potrebbero essere sensibili alla latenza a causa del traffico tra zone o del tempo di replica dei dati.
Eccellenza operativa Efficienza operativa elevata. In genere è necessario gestire solo una singola istanza logica di ogni risorsa. Per la maggior parte dei servizi, durante un'interruzione della zona di disponibilità, il failover è responsabilità di Microsoft e viene eseguito automaticamente.

In questa tabella vengono riepilogate alcune problematiche dal punto di vista dell'architettura:

Preoccupazione per l'architettura Impatto
Conformità alla residenza dei dati Elevata. Quando si distribuisce una soluzione che usa questo approccio, i dati vengono archiviati nell'area di Azure selezionata.
Disponibilità a livello di area Aree con zone di disponibilità. Questo approccio è disponibile in qualsiasi area che supporta le zone di disponibilità.

Questo approccio è possibile con molti servizi di Azure, tra cui Azure set di scalabilità di macchine virtuali, Servizio app di Azure, Funzioni di Azure, servizio Azure Kubernetes, Archiviazione di Azure, Azure SQL, bus di servizio di Azure e molti altri. Per un elenco completo dei servizi che supportano la ridondanza della zona, vedere Servizio di zona di disponibilità e supporto a livello di area.

Distribuzioni con ridondanza della zona con backup tra aree

È possibile estendere una distribuzione con ridondanza della zona eseguendo backup regolari dell'infrastruttura e dei dati in un'area secondaria. Questo approccio offre i vantaggi di un approccio con ridondanza della zona e aggiunge un livello di protezione per mitigare l'evento estremamente improbabile di un'interruzione completa dell'area.

Diagramma che mostra la soluzione distribuita in più zone di disponibilità in una distribuzione con ridondanza della zona, con backup che si trovano in un'altra area.

Quando si implementa questo approccio, è necessario considerare attentamente il valore RTO e RPO:

  • Tempo di ripristino: se si verifica un'interruzione a livello di area, potrebbe essere necessario ricompilare la soluzione in un'altra area di Azure, che influisce sul tempo di ripristino. Prendere in considerazione la creazione della soluzione usando un approccio IaC in modo che sia possibile ridistribuire rapidamente in un'altra area durante un'emergenza grave. Assicurarsi che gli strumenti e i processi di distribuzione siano altrettanto resilienti delle applicazioni in modo che sia possibile usarli per ridistribuire la soluzione anche in caso di interruzione. Pianificare e ripetere i passaggi necessari per ripristinare lo stato di lavoro della soluzione.

  • Punto di ripristino: la frequenza di backup determina la quantità di perdita di dati che potrebbe verificarsi (il punto di ripristino). In genere è possibile controllare la frequenza dei backup per soddisfare il valore RPO.

Suggerimento

Questo approccio offre spesso un buon equilibrio per tutti i problemi architetturali. Se non si è certi dell'approccio da usare, iniziare con questo tipo di distribuzione.

Questa tabella riepiloga alcune delle preoccupazioni fondamentali:

Concetto fondamentale Impatto
Affidabilità Affidabilità molto elevata. I servizi sono resilienti a un'interruzione di un data center o di una zona di disponibilità. Per la maggior parte dei servizi, i dati vengono replicati automaticamente tra zone e senza ritardi. Il backup dei dati viene eseguito in modo asincrono in un'area geograficamente separata. Questo backup riduce l'effetto di un'interruzione dell'area completa riducendo al minimo la perdita di dati. Dopo un'interruzione completa dell'area, è possibile ripristinare manualmente le operazioni in un'altra area. Tuttavia, i processi di ripristino possono essere complessi e possono richiedere tempo per il ripristino manuale nell'altra area.
Ottimizzazione dei costi Costo moderato. In genere, l'aggiunta di un backup a un'altra area costa solo leggermente di più rispetto all'implementazione della ridondanza della zona.
Efficienza delle prestazioni Per la maggior parte dei carichi di lavoro:prestazioni accettabili. È probabile che questo approccio fornisca prestazioni soddisfacenti.

Per carichi di lavoro altamente sensibili alla latenza:prestazioni ridotte. Alcuni componenti potrebbero essere sensibili alla latenza a causa del traffico tra zone o del tempo di replica dei dati.
Eccellenza operativa Durante un'interruzione della zona di disponibilità:Efficienza operativa elevata. Il failover è responsabilità di Microsoft e viene eseguito automaticamente.

Durante un'interruzione a livello di area:bassa efficienza operativa. Il failover è responsabilità dell'utente e potrebbe richiedere operazioni manuali e ridistribuzioni.

In questa tabella vengono riepilogate alcune problematiche dal punto di vista dell'architettura:

Preoccupazione per l'architettura Impatto
Conformità alla residenza dei dati Dipende dalla selezione dell'area. I dati vengono archiviati principalmente nell'area di Azure specificata, ma è necessario selezionare un'altra area per archiviare i backup. Selezionare un'area compatibile con i requisiti di residenza dei dati.
Disponibilità a livello di area Aree con zone di disponibilità. Questo approccio è disponibile in qualsiasi area che supporta le zone di disponibilità.

Approccio alla distribuzione 4: distribuzioni in più aree

È possibile usare più aree di Azure insieme per distribuire la soluzione in un'ampia area geografica. È possibile usare questo approccio in più aree per migliorare l'affidabilità della soluzione o per supportare gli utenti distribuiti geograficamente. Distribuendo in più aree, si riduce anche il rischio che si verifichi un vincolo di capacità delle risorse temporanea in una singola area. Se la residenza dei dati è un problema importante per la soluzione, considerare attentamente le aree usate per assicurarsi che i dati vengano archiviati solo in posizioni che soddisfano i requisiti.

Aree attive e passive

Le architetture in più aree sono complesse e esistono molti modi per progettare una soluzione in più aree. Per alcuni carichi di lavoro, è opportuno che più aree eselaborino attivamente le richieste contemporaneamente (distribuzioni attive-attive). Per altri carichi di lavoro, è preferibile designare un'area primaria e usare una o più aree secondarie per il failover (distribuzioni attive-passive). Questa sezione è incentrata sul secondo scenario, in cui un'area è attiva e un'altra è passiva. Per informazioni sulle soluzioni con più aree attive, vedere Modello stamp di distribuzione e modello Geode.

Replica dei dati

La comunicazione tra aree è molto più lenta rispetto alla comunicazione all'interno di un'area. In generale, una distanza geografica più ampia tra due aree comporta una maggiore latenza di rete a causa della distanza fisica più lunga che i dati devono viaggiare. Vedere Statistiche di latenza round trip della rete di Azure per la latenza di rete prevista quando ci si connette tra due aree.

La latenza di rete tra aree può influire in modo significativo sulla progettazione della soluzione, perché è necessario considerare attentamente il modo in cui la latenza aggiuntiva influisce sulla replica dei dati e su altre transazioni. Per molte soluzioni, un'architettura tra aree richiede la replica asincrona per ridurre al minimo l'effetto del traffico tra aree sulle prestazioni.

Replica asincrona dei dati

Quando si implementa la replica asincrona tra aree, l'applicazione non attende che tutte le aree riconoscano una modifica. Dopo il commit della modifica nell'area primaria, la transazione viene considerata completa. La modifica viene replicata nelle aree secondarie in un secondo momento. Questo approccio garantisce che la latenza di connessione tra più regioni non influisca direttamente sulle prestazioni dell'applicazione. Tuttavia, a causa del ritardo nella replica, un'interruzione a livello di area potrebbe comportare una perdita di dati. Questa perdita di dati può verificarsi perché un'area potrebbe riscontrare un'interruzione dopo il completamento di una scrittura nell'area primaria, ma prima che la modifica possa essere replicata in un'altra area.

Diagramma che mostra la soluzione distribuita in più aree. La replica dei dati viene eseguita in modo asincrono.

Questa tabella riepiloga alcune delle preoccupazioni fondamentali:

Concetto fondamentale Impatto
Affidabilità Affidabilità elevata. La soluzione è resiliente a un'interruzione di un data center, a una zona di disponibilità o a un'intera area. I dati vengono replicati, ma potrebbero non essere sincroni, pertanto è possibile una perdita di dati in uno scenario di failover.
Ottimizzazione dei costi Costo elevato. È necessario distribuire risorse separate in ogni area e ogni risorsa comporta costi di distribuzione e manutenzione. Anche la replica dei dati tra aree potrebbe comportare costi significativi.
Efficienza delle prestazioni Prestazioni elevate. Le richieste dell'applicazione non richiedono traffico tra aree, quindi il traffico è in genere bassa latenza.
Eccellenza operativa Bassa efficienza operativa. È necessario distribuire e gestire le risorse in più aree. È anche responsabile del failover tra aree durante un'interruzione a livello di area.

Questa tabella riepiloga alcune delle preoccupazioni da un punto di vista architettonico:

Preoccupazione per l'architettura Impatto
Conformità alla residenza dei dati Dipende dalla selezione dell'area. Questo approccio richiede di selezionare più aree per l'esecuzione del carico di lavoro. Scegliere aree compatibili con i requisiti di residenza dei dati.
Disponibilità a livello di area Molte aree di Azure sono associate. Alcuni servizi di Azure usano aree associate per replicare automaticamente i dati. Se si esegue il carico di lavoro in un'area che non ha una coppia, potrebbe essere necessario usare un approccio diverso per replicare i dati.
Replica dei dati sincrona

Se si implementa una soluzione multi-area sincrona, l'applicazione deve attendere il completamento delle operazioni di scrittura in ogni area di Azure prima del completamento della transazione. La latenza in attesa delle operazioni di scrittura dipende dalla distanza tra le aree. Per molti carichi di lavoro, la latenza tra aree può rendere troppo lenta la replica sincrona.

Diagramma che mostra la soluzione distribuita in più aree. La replica dei dati si verifica in modo sincrono.

Questa tabella riepiloga alcune delle preoccupazioni fondamentali:

Concetto fondamentale Impatto
Affidabilità Affidabilità molto elevata. La soluzione è resiliente a un'interruzione di un data center, a una zona di disponibilità o a un'intera area. I dati sono sempre sincronizzati tra aree, quindi, anche se si verifica una perdita completa di aree, i dati sono disponibili e completati in un'altra area.
Ottimizzazione dei costi Costo elevato. È necessario distribuire risorse separate in ogni area e ogni risorsa comporta costi di distribuzione e gestione. La replica dei dati tra aree potrebbe anche comportare costi significativi.
Efficienza delle prestazioni Prestazioni ridotte. Le richieste di applicazione richiedono traffico tra aree. A seconda della distanza tra le aree, la replica sincrona potrebbe aggiungere una latenza significativa alle richieste.
Eccellenza operativa Bassa efficienza operativa. È necessario distribuire e gestire le risorse in più aree. È anche responsabile del failover tra aree durante un'interruzione a livello di area.

Questa tabella riepiloga alcune delle preoccupazioni da un punto di vista architettonico:

Preoccupazione per l'architettura Impatto
Conformità alla residenza dei dati Dipende dalla selezione dell'area. Questo approccio richiede di selezionare più aree per l'esecuzione del carico di lavoro. Selezionare le aree compatibili con i requisiti di residenza dei dati.
Disponibilità a livello di area Molte aree di Azure sono associate. Alcuni servizi di Azure usano aree associate per replicare automaticamente i dati. Se si esegue il carico di lavoro in un'area che non ha una coppia, potrebbe essere necessario usare un approccio diverso per replicare i dati.

Architetture dell'area

Quando si progetta una soluzione multi-area, valutare se le aree di Azure che si prevede di usare sono associate.

È possibile creare una soluzione multi-area anche quando le aree non sono associate. Tuttavia, gli approcci usati per implementare un'architettura a più aree potrebbero essere diversi. Ad esempio, in Archiviazione di Azure è possibile usare l'archiviazione con ridondanza geografica (GRS) con aree associate. Se grS non è disponibile, è consigliabile usare funzionalità come la replica degli oggetti di Archiviazione di Azure o progettare l'applicazione per scrivere in più aree.

Combinare approcci multi-zona e multi-area

È consigliabile combinare istruzioni multi-zona e multi-area se i requisiti aziendali richiedono una soluzione di questo tipo. Ad esempio, è possibile distribuire componenti con ridondanza della zona in ogni area e configurare anche la replica tra le aree. Per alcune soluzioni, questo approccio offre un grado molto elevato di affidabilità. Tuttavia, la configurazione di questo tipo di approccio può essere complessa e questo approccio può essere costoso.

Importante

I carichi di lavoro cruciali devono usare sia più zone di disponibilità che più aree. Per altre informazioni sulle considerazioni che è necessario assegnare durante la progettazione di carichi di lavoro cruciali, vedere documentazione del carico di lavoro mission-critical.

Come i servizi di Azure supportano gli approcci di distribuzione

È importante comprendere i dettagli specifici dei servizi di Azure usati. Ad esempio, alcuni servizi di Azure richiedono di configurare la configurazione della zona di disponibilità quando si distribuisce prima la risorsa, mentre altri supportano la modifica dell'approccio di distribuzione in un secondo momento. Analogamente, alcune funzionalità del servizio potrebbero non essere disponibili con ogni approccio di distribuzione.

Per altre informazioni sulle opzioni di distribuzione e sugli approcci specifici da considerare per ogni servizio di Azure, visitare l'hub di affidabilità.

Esempio

Questa sezione descrive alcuni casi d'uso comuni e i requisiti chiave da considerare in genere per ogni carico di lavoro. Per ogni carico di lavoro vengono forniti uno o più approcci di distribuzione suggeriti, in base ai requisiti e agli approcci descritti in questo articolo.

Applicazione line-of-business per un'azienda

Contoso, Ltd., è una grande azienda di produzione. L'azienda sta implementando un'applicazione line-of-business per gestire alcuni componenti dei propri processi finanziari.

Requisiti aziendali: le informazioni gestite dal sistema sono difficili da sostituire, pertanto i dati devono essere mantenuti in modo affidabile. Gli architetti dicono che il sistema deve incorrere nel minor tempo di inattività e il minor numero possibile di perdite di dati. I dipendenti di Contoso usano il sistema durante il giorno di lavoro, quindi le prestazioni elevate sono importanti per evitare di mantenere in attesa i membri del team. Il costo è anche un problema, perché il team finanziario deve pagare per la soluzione.

Approccio suggerito: la distribuzione con ridondanza della zona con backup tra aree offre più livelli di resilienza con prestazioni elevate.

Applicazione interna

Quarto caffè è un piccolo business. L'azienda sta sviluppando una nuova applicazione interna che i dipendenti possono usare per inviare schede attività.

Requisiti aziendali: per questo carico di lavoro, l'efficienza dei costi è un problema principale. Quarto Caffè ha valutato l'impatto aziendale del tempo di inattività e ha deciso che l'applicazione non deve assegnare priorità alla resilienza o alle prestazioni. L'azienda accetta il rischio che un'interruzione in una zona o un'area di disponibilità di Azure possa rendere l'applicazione temporaneamente non disponibile.

Approcci suggeriti:

Migrazione dell'applicazione legacy

Fabrikam, Inc., esegue la migrazione di un'applicazione legacy da un data center locale ad Azure. L'implementazione userà un approccio IaaS basato sulle macchine virtuali. L'applicazione non è stata progettata per un ambiente cloud e la comunicazione tra il livello applicazione e il database è molto chatty.

Requisiti aziendali: le prestazioni sono una priorità per questa applicazione. La resilienza è importante e l'applicazione deve continuare a funzionare anche se un data center di Azure ha avuto un'interruzione.

Approccio suggerito:

Applicazione per il settore sanitario

Lamna Healthcare Company sta implementando un nuovo sistema di registrazione dell'integrità elettronica in Azure.

Requisiti aziendali: a causa della natura dei dati archiviati da questa soluzione, la residenza dei dati è fondamentale. Lamna opera in un quadro normativo rigoroso che impone che i dati rimangano in una posizione specifica.

Approcci suggeriti:

Sistema bancario

Woodgrove Bank esegue le operazioni bancarie principali da una soluzione di grandi dimensioni distribuita in Azure.

Requisiti aziendali: si tratta di un sistema cruciale. Qualsiasi interruzione può causare un impatto finanziario importante per i clienti. Di conseguenza, Woodgrove Bank ha una tolleranza di rischio molto bassa. Il sistema richiede il massimo livello di affidabilità possibile e l'architettura deve attenuare il rischio di eventuali errori che possono essere mitigati.

Approccio consigliato: per un sistema mission-critical, usare una distribuzione in più aree. Assicurarsi che le aree siano idonee ai requisiti di residenza dei dati dell'azienda.

Software come un servizio (SaaS, Software as a Service)

Proseware, Inc., crea software usato dalle aziende di tutto il mondo. La base di utenti della società è ampiamente distribuita geograficamente.

Requisiti aziendali: Proseware deve consentire a ogni cliente di scegliere un'area di distribuzione vicina al cliente. L'abilitazione di questa scelta è importante per la latenza e per i requisiti di residenza dei dati dei clienti.

Approcci suggeriti:

Di seguito sono riportate alcune architetture di riferimento e scenari di esempio per soluzioni con più aree e più aree:

Molti servizi di Azure forniscono indicazioni su come usare più zone di disponibilità, inclusi gli esempi seguenti:

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'affidabilità