Consigli per l'uso di zone e aree di disponibilità
Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:
| 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 base alle destinazioni di affidabilità identificate. |
|---|
Guide correlate: Ridondanza della progettazione | multimultidimensionale a disponibilità elevata
Questa guida descrive le raccomandazioni per determinare quando distribuire i carichi di lavoro tra zone o aree di disponibilità.
Quando si progetta una soluzione per Azure, è necessario decidere se distribuire in 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 principali requisiti aziendali che influiscono sulla decisione, sugli approcci che è possibile prendere in considerazione, sui compromessi coinvolti in ogni approccio e sull'effetto di ogni approccio sui pilastri principali del framework ben progettato di Azure.
La decisione sulle migliori aree di Azure 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 ben progettato:
- Affidabilità: la scelta dell'approccio di distribuzione 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 architetturali richiedono la distribuzione di più risorse rispetto ad altre, che possono aumentare i costi delle risorse. Altri approcci prevedono l'invio di dati tra zone o aree di disponibilità separate geograficamente, 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à vengono connesse insieme tramite un collegamento di rete a larghezza di banda elevata e a bassa latenza, sufficiente per la maggior parte dei carichi di lavoro per abilitare la replica sincrona e la comunicazione tra le zone. Tuttavia, se il carico di lavoro è stato testato ed è sensibile alla latenza di rete tra zone, potrebbe essere necessario prendere in considerazione la possibilità di individuare fisicamente i componenti del carico di lavoro vicini per 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 fondamentali per l'eccellenza operativa, tra cui OE:05 Infrastructure as code, OE:09 Task automation, OE:10 Automation design e OE:11 Deployment practices( Procedure di distribuzione OE:11).
Tuttavia, si progetta la soluzione, si applica il pilastro Sicurezza. In genere, le decisioni relative all'uso delle zone di disponibilità e delle 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 miglior equilibrio tra compromessi. È possibile estendere questo approccio con il backup asincrono dei dati 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 | Architettura in cui un'istanza di una soluzione è designata come primaria ed elabora il traffico, mentre una o più istanze secondarie vengono distribuite per gestire il traffico se la soluzione primaria non è disponibile. |
| Replica asincrona | Approccio di replica dei dati in cui i dati vengono scritti e sottoposti a commit in un'unica posizione. In un secondo momento, le modifiche vengono replicate in un'altra posizione. |
| Zona di disponibilità | Gruppo separato di data center all'interno di un'area. Ogni zona di disponibilità è indipendente dagli altri, con la propria potenza, 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 le risorse e i 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 qualsiasi 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 in più aree. Le aree di Azure più recenti non sono associate. |
| Paese | 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 l'eventuale associazione dell'area a un'altra area. |
| Replica sincrona | Approccio di 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 che l'operazione di scrittura complessiva sia considerata completata. |
| Distribuzione a livello di zona (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 in caso di interruzione di una zona. |
Strategie di progettazione chiave
Azure ha un footprint globale elevato. 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 un'ampia gamma di configurazioni, dette anche architetture di area.
Molte aree di Azure forniscono zone di disponibilità, che sono gruppi separati di data center. All'interno di una regione, le zone di disponibilità sono abbastanza vicine da avere connessioni a bassa latenza con altre zone di disponibilità, pur essendo sufficientemente distanti per ridurre la probabilità che più di una sia influenzata da interruzioni locali o dovute al meteo. Le zone di disponibilità hanno potenza, raffreddamento e infrastruttura di rete indipendenti. Sono progettati in modo che se si verifica un'interruzione di una zona, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle zone rimanenti.
Il diagramma seguente mostra diverse aree di Azure come esempio. Le zone di disponibilità sono supportate nelle aree 1 e 2.
Se si esegue la distribuzione in un'area di Azure che contiene zone di disponibilità, è possibile usare più zone di disponibilità insieme. Usando più zone di disponibilità, è possibile conservare copie separate dell'applicazione e dei dati all'interno di data center fisici distinti in un'area metropolitana di grandi dimensioni.
Esistono due modi per usare le zone di disponibilità in una soluzione:
- Le risorse di zona vengono aggiunte a una zona di disponibilità specifica. È possibile combinare più distribuzioni di zona in diverse zone per soddisfare requisiti di affidabilità elevati. Si è responsabili 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 cn 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) in genere supportano le distribuzioni con ridondanza della zona. I servizi IaaS (Infrastructure as a Service) in genere supportano le distribuzioni di zona. 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 problematici 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, è responsabilità del team del carico di lavoro assicurarsi 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. È anche possibile prendere in considerazione l'overprovisioning , ovvero la distribuzione di più istanze di una risorsa, in modo che alcune istanze rimangano disponibili mentre altre vengono aggiornate. Per altre informazioni su come Azure distribuisce gli aggiornamenti, vedere Informazioni dettagliate sulle procedure di distribuzione sicure.
Molte aree hanno anche un'area associata. Le aree associate supportano determinati tipi di approcci di distribuzione in più aree. Alcune aree più recenti hanno più zone di disponibilità, ma non hanno un'area associata. In queste aree è comunque possibile distribuire soluzioni in più aree, usando approcci diversi.
Per altre informazioni su come Azure usa aree e zone di disponibilità, vedere Che cosa sono le aree di Azure e le zone di disponibilità?
Comprendere le responsabilità condivise
Il principio di responsabilità condivisa descrive il modo in cui le responsabilità sono divise tra il provider di servizi cloud (Microsoft) e l'utente. A seconda del tipo di servizi che si usano, è possibile assumersi una maggiore o minore responsabilità per il funzionamento del servizio.
Microsoft fornisce zone di disponibilità e aree per rendere flessibile il modo di progettare la soluzione più adatta alle proprie esigenze. Quando si usano servizi gestiti, Microsoft si assume una maggiore responsabilità nella gestione delle risorse, che possono includere anche la replica dei dati, il failover, il failback e altre attività correlate al funzionamento di un sistema distribuito.
Il proprio codice deve usare procedure consigliate e modelli di progettazione per la gestione degli errori normalmente. Queste procedure sono ancora più importanti durante le operazioni di failover, ad esempio quelle che si verificano quando si verifica un failover di una zona di disponibilità o di un'area, perché il failover tra zone o aree richiede in genere che l'applicazione ritenta 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 guidati dalle discussioni tra i progettisti di soluzioni e gli stakeholder aziendali.
Tolleranza ai rischi
Le diverse organizzazioni hanno diversi gradi di tolleranza al rischio. Anche all'interno di un'organizzazione, la tolleranza ai rischi è spesso diversa per ogni carico di lavoro. La maggior parte dei carichi di lavoro non richiede una disponibilità estremamente elevata. Tuttavia, alcuni carichi di lavoro sono così importanti che vale la pena ridurre i rischi che potrebbero verificarsi, ad esempio gravi calamità naturali che influiscono su un'ampia area geografica.
Questa tabella elenca alcuni dei rischi comuni da considerare in un ambiente cloud:
| Rischio | Esempi | Probabilità |
|---|---|---|
| Interruzione hardware | Problema con il disco rigido o le apparecchiature di rete. Riavvii dell'host. |
Elevato. 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. Calamità naturali in una parte di una zona metropolitana. |
Medio |
| Interruzione dell'area | Grave calamità naturale che colpisce un'ampia area geografica. Problema di rete o di servizio che rende uno o più servizi di Azure non disponibili in un'intera area. |
Basso |
Sarebbe consigliabile ridurre ogni rischio possibile 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 da mitigare.
Suggerimento
Indipendentemente dagli obiettivi di affidabilità, tutti i carichi di lavoro devono avere alcune mitigazioni per il ripristino di emergenza. Se il carico di lavoro richiede obiettivi di affidabilità elevata, le strategie di mitigazione devono essere complete e ridurre il rischio di eventi anche con bassa probabilità. Per altri carichi di lavoro, prendere una decisione informata sui rischi che si è pronti ad accettare e sui quali è necessario attenuare.
Requisiti di resilienza
È importante comprendere i requisiti di resilienza per il carico di lavoro, inclusi 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 di destinazione.
Obiettivi a livello di servizio
È necessario comprendere l'obiettivo previsto del servizio SLO (Uptime Service Level Objective) della soluzione. Ad esempio, si potrebbe avere un requisito aziendale che la soluzione deve soddisfare il tempo di attività del 99,9%.
Azure fornisce 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 il contratto di servizio previsto. Tenere tuttavia presente 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 relative all'architettura influiscono sull'SLO composito della soluzione. In generale, maggiore è la ridondanza che si compila nella soluzione, maggiore è la probabilità che l'SLO sia maggiore. Molti servizi di Azure offrono contratti di servizio più elevati quando si distribuiscono servizi in una configurazione con ridondanza della zona o in più aree. 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 sono basati su 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 hanno requisiti di residenza dei dati rigorosi, potrebbe essere necessario usare una distribuzione a singola area o usare un subset di aree e servizi di Azure.
Nota
Evitare di fare ipotesi infondate sui requisiti di residenza dei dati. Se è necessario rispettare specifici standard normativi, verificare quali standard specificano effettivamente.
Ubicazione utente
Comprendendo dove si trovano gli utenti, è possibile prendere una decisione informata su come ottimizzare la latenza e l'affidabilità per le proprie esigenze. Azure offre molte opzioni per supportare una base utente geograficamente dispersa.
Se gli utenti si concentrano in un'unica area, una distribuzione a singola area può semplificare i requisiti operativi e ridurre i costi. È tuttavia necessario valutare se una distribuzione a singola area soddisfa i requisiti di affidabilità. Per le applicazioni cruciali, è comunque consigliabile usare una distribuzione in più aree anche se gli utenti sono raggruppati.
Se gli utenti sono geograficamente distribuiti, potrebbe essere opportuno distribuire il carico di lavoro in più aree. I servizi di Azure offrono funzionalità diverse per supportare una distribuzione in più aree ed è possibile usare il footprint globale di Azure per migliorare l'esperienza utente e avvicinare le applicazioni alla base degli utenti. È 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 in più aree. Valutare se è possibile raggiungere i requisiti all'interno di una singola area usando l'accelerazione globale del traffico, ad esempio l'accelerazione fornita da Frontdoor di Azure.
Budget
Se si opera con un budget vincolato, è importante considerare i costi necessari per la distribuzione di componenti del carico di lavoro ridondanti. Questi costi possono includere costi aggiuntivi per le risorse, costi di rete e costi operativi per la gestione di più risorse e un ambiente più complesso.
Complessità
È consigliabile evitare complessità non necessarie nell'architettura della soluzione. Maggiore è la complessità 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 tra cui 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 una sorta di archiviazione:
Questo esempio non è specifico di alcun particolare servizio di Azure. È 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 in più aree. Questa tabella riepiloga alcuni aspetti fondamentali:
| Concetto fondamentale | Ridondanza locale | Zonal (aggiunta) | Zone-redundant | Più aree |
|---|---|---|---|---|
| Affidabilità | Bassa affidabilità | Dipende dall'approccio | Affidabilità elevata o molto elevata | Affidabilità elevata o molto elevata |
| Ottimizzazione dei costi | Costi contenuti | 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 | Zonal (aggiunta) | Zone-redundant | Più aree |
|---|---|---|---|---|
| Conformità con la residenza dei dati | Alto | Alta | Alta | Dipende dall'area geografica |
| Disponibilità a livello di area | Tutte le aree geografiche | Aree con zone di disponibilità | Aree con zone di disponibilità | Dipende dall'area geografica |
Nella parte restante di questo articolo vengono descritti 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ù aree o zone di disponibilità 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à.
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 riscontra un'interruzione, è possibile che il carico di lavoro sia interessato. In caso affermativo, la soluzione potrebbe non essere disponibile o i dati potrebbero andarsi persi.
Per 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 certa 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 alcuni aspetti 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 più regioni. |
| 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à, quindi è possibile che vengano visualizzate prestazioni inferiori per i componenti altamente sensibili alla latenza. |
| Eccellenza operativa | Efficienza operativa elevata. È sufficiente distribuire e gestire una singola istanza di ogni risorsa. |
Questa tabella riepiloga alcune delle problematiche di un'architettura:
| Preoccupazione per l'architettura | Impatto |
|---|---|
| Conformità con la residenza dei dati | Elevato. Quando si distribuisce una soluzione che usa questo approccio, i dati vengono archiviati nell'area di Azure selezionata. |
| Disponibilità a livello di area | Elevato. 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:
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. Valutare la possibilità di creare la soluzione usando un approccio IaC (Infrastructure-as-Code) in modo da poter ridistribuire rapidamente in un'altra area se si verifica un'emergenza grave. Assicurarsi che gli strumenti e i processi di distribuzione siano altrettanto resilienti delle applicazioni in modo da poterli usare 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 alcuni aspetti 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 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 eseguire manualmente il ripristino nell'altra area. |
| Ottimizzazione dei costi | Basso. 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à, quindi è possibile che vengano visualizzate prestazioni inferiori per i componenti altamente 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. |
Questa tabella riepiloga alcune delle problematiche di un'architettura:
| Preoccupazione per l'architettura | Impatto |
|---|---|
| Conformità con la 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 | Elevato. È possibile usare questo approccio in qualsiasi area di Azure. |
Approccio di distribuzione 2: distribuzioni di zona (aggiunte)
In una distribuzione a livello di zona si specifica che le risorse devono essere distribuite in una zona di disponibilità specifica. Questo approccio viene talvolta definito distribuzione aggiunta a una zona.
Un approccio di zona riduce la latenza tra i componenti. Tuttavia, da solo, 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 :
Nell'esempio precedente un servizio di bilanciamento del carico viene distribuito in 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 prendere in considerazione l'uso di un servizio di bilanciamento del carico globale, ad esempio Frontdoor di Azure o Gestione traffico di Azure, che non viene distribuito affatto in un'area.
Quando si usa un modello di distribuzione a livello di zona, si assumono molte responsabilità:
- È necessario distribuire le risorse in ogni zona di disponibilità e configurare e gestire singolarmente tali risorse.
- È 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 metro.
Questa tabella riepiloga alcuni aspetti 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 distribuito in più zone di disponibilità: costo elevato. Si distribuiscono più istanze delle risorse, ognuna delle quali viene fatturata separatamente. |
| 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 zone di disponibilità. Durante un'interruzione della zona di disponibilità, il failover è responsabilità dell'utente. |
Questa tabella riepiloga alcune delle problematiche di un'architettura:
| Preoccupazione per l'architettura | Impatto |
|---|---|
| Conformità con la residenza dei dati | Elevato. 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 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 una zona 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à disponga sempre di 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.
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 coinvolta nella 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 alcuni aspetti 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. |
| 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. |
Questa tabella riepiloga alcune delle problematiche di un'architettura:
| Preoccupazione per l'architettura | Impatto |
|---|---|
| Conformità con la residenza dei dati | Elevato. 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 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 attenuare l'evento estremamente improbabile di un'interruzione completa dell'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 da poter 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 se si verifica un'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 tutte le problematiche architetturali. Se non si è certi dell'approccio da usare, iniziare con questo tipo di distribuzione.
Questa tabella riepiloga alcuni aspetti 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 le 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 completa dell'area 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 eseguire manualmente il ripristino 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. |
Questa tabella riepiloga alcune delle problematiche di un'architettura:
| Preoccupazione per l'architettura | Impatto |
|---|---|
| Conformità con la 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 temporanee in una singola area. Se la residenza dei dati è un problema importante per la soluzione, valutare attentamente le aree usate per assicurarsi che i dati vengano archiviati solo in località 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 in più aree attive, vedere Modello 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ù grande tra due aree comporta una latenza di rete maggiore 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 valutare 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.
Questa tabella riepiloga alcuni aspetti 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, quindi è possibile che alcune perdite di dati siano 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 può 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. Si è anche responsabili del failover tra aree durante un'interruzione a livello di area. |
Questa tabella riepiloga alcune delle problematiche di un'architettura:
| Preoccupazione per l'architettura | Impatto |
|---|---|
| Conformità con la residenza dei dati | Dipende dalla selezione dell'area. Questo approccio richiede di selezionare più aree in cui eseguire il carico di lavoro. Scegliere le aree compatibili con i requisiti di residenza dei dati. |
| Disponibilità a livello di area | Molte aree di Azure sono abbinate. Alcuni servizi di Azure usano aree abbinate 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 in più aree sincrone, l'applicazione deve attendere il completamento delle operazioni di scrittura in ogni area di Azure prima che la transazione venga considerata completata. La latenza generata dall'attesa delle operazioni di scrittura dipende dalla distanza tra le aree. Per molti carichi di lavoro, la latenza tra aree può rendere la replica sincrona troppo lenta per risultare utile.
Questa tabella riepiloga alcuni aspetti 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 dell'area, 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 manutenzione. Anche la replica dei dati tra aree può comportare costi significativi. |
| Efficienza delle prestazioni | Prestazioni ridotte. Le richieste dell'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. Si è anche responsabili del failover tra aree durante un'interruzione a livello di area. |
Questa tabella riepiloga alcune delle problematiche di un'architettura:
| Preoccupazione per l'architettura | Impatto |
|---|---|
| Conformità con la residenza dei dati | Dipende dalla selezione dell'area. Questo approccio richiede di selezionare più aree in cui eseguire il carico di lavoro. Selezionare le aree compatibili con i requisiti di residenza dei dati. |
| Disponibilità a livello di area | Molte aree di Azure sono abbinate. Alcuni servizi di Azure usano aree abbinate 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 di aree
Quando si progetta una soluzione in più aree, valutare se le aree di Azure che si prevede di usare sono abbinate.
È possibile creare una soluzione in più aree anche quando le aree non sono associate. Tuttavia, gli approcci usati per implementare un'architettura in più aree potrebbero essere diversi. Ad esempio, in Archiviazione di Azure è possibile usare l'archiviazione con ridondanza geografica (GRS) con aree abbinate. Se l'archiviazione con ridondanza geografica non è disponibile, prendere in considerazione l'uso di funzionalità come Archiviazione di Azure replica di oggetti o progettare l'applicazione per scrivere in più aree.
Combinare approcci tra più aree e più aree
È consigliabile combinare istruzioni in più aree e in più aree 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 livello di affidabilità molto elevato. 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 più zone di disponibilità e più aree. Per altre informazioni sulle considerazioni da tenere presenti durante la progettazione di carichi di lavoro cruciali, vedere la documentazione relativa ai carichi di lavoro cruciali.
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 per la prima volta 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 alla distribuzione.
Per altre informazioni sulle opzioni di distribuzione e sugli approcci specifici da prendere in considerazione per ogni servizio di Azure, visitare l'hub di affidabilità.
Esempi
Questa sezione descrive alcuni casi d'uso comuni e i requisiti chiave che in genere è necessario prendere in considerazione 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 manifatturiera. L'azienda sta implementando un'applicazione line-of-business per gestire alcuni componenti dei processi finanziari.
Requisiti aziendali: le informazioni gestite dal sistema sono difficili da sostituire, quindi i dati devono essere mantenuti in modo affidabile. Gli architetti dicono che il sistema deve comportare il minor tempo di inattività e la minor perdita di dati possibile. I dipendenti di Contoso usano il sistema durante tutto il giorno lavorativo, quindi le prestazioni elevate sono importanti per evitare che i membri del team siano in attesa. Anche il costo è un problema, perché il team finanziario deve pagare per la soluzione.
Approccio consigliato: la distribuzione con ridondanza della zona con backup tra aree offre più livelli di resilienza con prestazioni elevate.
Applicazione interna
Fourth Coffee è una piccola impresa. 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. Fourth Coffee ha valutato l'impatto aziendale del tempo di inattività e ha deciso che l'applicazione non deve dare 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:
- La distribuzione con ridondanza locale con backup in più aree ha il costo più basso, ma presenta anche rischi significativi.
- La distribuzione con ridondanza della zona con backup tra aree offre una migliore resilienza, ma a un costo leggermente superiore.
Migrazione di applicazioni legacy
Fabrikam, Inc., esegue la migrazione di un'applicazione legacy da un data center locale ad Azure. L'implementazione userà un approccio IaaS basato su macchine virtuali. L'applicazione non è stata progettata per un ambiente cloud e la comunicazione tra il livello applicazione e il database è molto chiacchierata.
Requisiti aziendali: le prestazioni sono una priorità per questa applicazione. Anche la resilienza è importante e l'applicazione deve continuare a funzionare anche se un data center di Azure riscontra un'interruzione.
Approccio suggerito:
- Fabrikan dovrebbe prima provare una distribuzione con ridondanza della zona. Devono verificare che le prestazioni soddisfino i requisiti.
- Se le prestazioni della soluzione con ridondanza della zona non sono accettabili, prendere in considerazione una distribuzione di zona (aggiunta), con distribuzioni passive in più zone di disponibilità (ripristino di emergenza nell'area).
Applicazione per il settore sanitario
Lamna Healthcare Company sta implementando un nuovo sistema di record sanitari elettronici 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:
- Distribuzione in più aree, se sono presenti più aree che soddisfano i requisiti di residenza dei dati di Lamna.
- Se esiste solo una singola area adatta alle proprie esigenze, prendere in considerazione una distribuzione con ridondanza della zona o una distribuzione con ridondanza della zona con backup tra aree offre una soluzione a singola area
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. Eventuali interruzioni possono causare un notevole impatto finanziario per i clienti. Di conseguenza, Woodgrove Bank ha una tolleranza di rischio molto bassa. Il sistema necessita del massimo livello di affidabilità possibile e l'architettura deve ridurre il rischio di eventuali errori che possono essere mitigati.
Approccio suggerito: per un sistema mission-critical, usare una distribuzione in più aree. Assicurarsi che le aree siano adatte ai requisiti di residenza dei dati dell'azienda.
Software come servizio (SaaS)
Proseware, Inc., crea software usato dalle aziende in tutto il mondo. La base di utenti dell'azienda è 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:
- Una distribuzione in più aree è in genere una scelta ottimale per un provider SaaS, soprattutto quando viene usata all'interno dello schema Deployment Stamps.
- Una distribuzione con ridondanza della zona a singola area insieme a una soluzione di accelerazione del traffico globale, ad esempio Frontdoor di Azure.
Collegamenti correlati
Di seguito sono riportate alcune architetture di riferimento e scenari di esempio per soluzioni multi-zona e in più aree:
- Applicazione Web con ridondanza della zona a disponibilità elevata di base
- Applicazione Web multi-area a disponibilità elevata
- Applicazione a più livelli in più aree
- Applicazione Web multilivello creata per disponibilità elevata/ripristino di emergenza
Molti servizi di Azure forniscono indicazioni su come usare più zone di disponibilità, inclusi gli esempi seguenti:
- Azure Site Recovery: abilitare il ripristino di emergenza di macchine virtuali di Azure tra le zone di disponibilità
- Azure NetApp Files: informazioni sulla replica tra zone di Azure NetApp Files
- Azure Storage redundancy (Ridondanza di Archiviazione di Azure)
Elenco di controllo per l'affidabilità
Fare riferimento al set completo di raccomandazioni.