Share via

Suggerimenti per la progettazione per la ridondanza

  • 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 base alle destinazioni di affidabilità identificate.

Guide correlate:Progettazione | multimultidimensionale a disponibilità elevataCon zone e aree di disponibilità

Questa guida descrive le raccomandazioni per l'aggiunta della ridondanza in tutti i flussi critici a livelli di carico di lavoro diversi, che ottimizzano la resilienza. Soddisfare i requisiti degli obiettivi di affidabilità definiti applicando i livelli di ridondanza appropriati ai livelli di calcolo, dati, rete e altri livelli di infrastruttura. Applicare questa ridondanza per offrire al carico di lavoro una base solida e affidabile da sviluppare. Quando si compila il carico di lavoro senza ridondanza dell'infrastruttura, si verifica un rischio elevato di tempo di inattività prolungato a causa di potenziali errori.

Definizioni

Termine Definizione
Ridondanza Implementazione di più istanze identiche di un componente del carico di lavoro.
Persistenza poliglotta Il concetto di utilizzo di tecnologie di archiviazione diverse dalla stessa applicazione o soluzione per sfruttare le migliori funzionalità di ogni componente.
Coerenza dei dati La misura del modo in cui la sincronizzazione o la sincronizzazione di un determinato set di dati si trova in più archivi.
Partizionamento Processo di suddivisione fisica dei dati in archivi dati separati.
Partizione Strategia di partizionamento orizzontale del database che supporta più istanze di archiviazione con uno schema comune. I dati non vengono replicati in tutte le istanze.

Strategie di progettazione chiave

Nel contesto dell'affidabilità, usare la ridondanza per contenere problemi che interessano una singola risorsa e assicurarsi che tali problemi non influiscano sull'affidabilità dell'intero sistema. Usare le informazioni identificate sui flussi critici e sugli obiettivi di affidabilità per prendere decisioni informate necessarie per la ridondanza di ogni flusso.

Ad esempio, potrebbero essere presenti più nodi del server Web in esecuzione contemporaneamente. La criticità del flusso supportato potrebbe richiedere che tutte abbiano repliche pronte ad accettare il traffico se si verifica un problema che interessa l'intero pool, ad esempio un'interruzione a livello di area. In alternativa, poiché i problemi su larga scala sono rari ed è costoso distribuire un intero set di repliche, è possibile distribuire un numero limitato di repliche in modo che il flusso funzioni in uno stato danneggiato fino a quando non si risolve il problema.

Quando si progetta la ridondanza nel contesto dell'efficienza delle prestazioni, distribuire il carico tra più nodi ridondanti per garantire che ogni nodo funzioni in modo ottimale. Nel contesto dell'affidabilità, creare capacità di riserva per assorbire errori o malfunzionamenti che interessano uno o più nodi. Assicurarsi che la capacità di riserva possa assorbire gli errori per l'intero periodo di tempo necessario per ripristinare i nodi interessati. Tenendo presente questa distinzione, entrambe le strategie devono collaborare. Se si distribuisce il traffico tra due nodi per le prestazioni ed entrambi vengono eseguiti al 60% di utilizzo e un nodo ha esito negativo, il nodo rimanente rischia di diventare sovraccarico perché non può funzionare al 120%. Distribuire il carico con un altro nodo per garantire che gli obiettivi di prestazioni e affidabilità siano mantenuti.

Compromessi:

  • Maggiore ridondanza del carico di lavoro equivale a costi maggiori. Valutare attentamente l'aggiunta della ridondanza e rivedere regolarmente l'architettura per assicurarsi di gestire i costi, soprattutto quando si usa l'overprovisioning. Quando si usa l'overprovisioning come strategia di resilienza, bilanciarla con una strategia di scalabilità ben definita per ridurre al minimo le inefficienze dei costi.
  • Quando si crea un livello elevato di ridondanza, possono verificarsi compromessi per le prestazioni. Ad esempio, le risorse distribuite tra zone di disponibilità o aree possono influire sulle prestazioni perché è necessario inviare traffico su connessioni a latenza elevata tra risorse ridondanti, ad esempio server Web o istanze di database.
  • I diversi flussi all'interno dello stesso carico di lavoro potrebbero avere requisiti di affidabilità diversi. Le progettazioni di ridondanza specifiche del flusso possono potenzialmente introdurre complessità nella progettazione complessiva.

Progettazione dell'architettura ridondante

Quando si progetta un'architettura ridondante, si considerino due approcci: attivo-attivo o attivo-passivo. Scegliere l'approccio a seconda della criticità del flusso utente e del flusso di sistema supportati dai componenti dell'infrastruttura. In termini di affidabilità, una progettazione attiva-attiva in più aree consente di ottenere il massimo livello di affidabilità possibile, ma è molto più costoso di una progettazione attiva-passiva. Decidere le aree geografiche appropriate diventa la scelta critica successiva. È anche possibile usare questi approcci di progettazione per una singola area usando le zone di disponibilità. Per altre informazioni, vedere Raccomandazioni per la progettazione di più aree a disponibilità elevata.

Stamp di distribuzione e unità di scala

Indipendentemente dal fatto che si distribuisca in un modello attivo-attivo o attivo-passivo, seguire il modello di progettazione Deployment Stamps per assicurarsi di distribuire il carico di lavoro in modo ripetibile e scalabile. I timbri di distribuzione sono i raggruppamenti di risorse necessari per distribuire il carico di lavoro a un determinato subset dei clienti. Ad esempio, il subset potrebbe essere un subset a livello di area o un subset con tutti gli stessi requisiti di privacy dei dati del carico di lavoro. Si pensi a ogni timbro come a un'unità di scala che è possibile duplicare per ridimensionare il carico di lavoro orizzontalmente o per eseguire distribuzioni blu-verde. Progettare il carico di lavoro con indicatori di distribuzione per ottimizzare l'implementazione attiva-attiva o attiva-passiva per il carico di lavoro di resilienza e gestione. La pianificazione della scalabilità orizzontale in più aree è importante anche per superare i potenziali vincoli di capacità delle risorse temporanee in un'area.

Zone di disponibilità all'interno delle aree di Azure

Sia che si distribuisca una progettazione attiva-attiva o passiva attiva, sfruttare le zone di disponibilità all'interno delle aree attive per ottimizzare completamente la resilienza. Molte aree di Azure offrono più zone di disponibilità, che sono gruppi separati di data center all'interno di un'area. A seconda del servizio di Azure, è possibile sfruttare le zone di disponibilità distribuendo gli elementi del carico di lavoro in modo ridondante tra zone o aggiungendo elementi a zone specifiche. Per altre informazioni, vedere Raccomandazioni per l'uso di zone e aree di disponibilità.

Linee guida sul livello dell'infrastruttura

Risorse di calcolo

  • Scegliere il servizio di calcolo appropriato per il carico di lavoro. A seconda del tipo di carico di lavoro progettato, potrebbero essere disponibili diverse opzioni. Ricercare i servizi disponibili e comprendere quali tipi di carichi di lavoro funzionano meglio in un determinato servizio di calcolo. Ad esempio, i carichi di lavoro SAP sono in genere più adatti per i servizi di calcolo IaaS (Infrastructure as a Service). Per un'applicazione in contenitori, determinare le funzionalità specifiche necessarie per determinare se usare servizio Azure Kubernetes (AKS) o una soluzione PaaS (Platform as a Service). La piattaforma cloud gestisce completamente un servizio PaaS.

  • Se i requisiti lo consentono, usare le opzioni di calcolo PaaS. Azure gestisce completamente i servizi PaaS, riducendo il carico di gestione e un livello di ridondanza documentato è integrato.

  • Usare Azure set di scalabilità di macchine virtuali se è necessario distribuire macchine virtuali .Use Azure set di scalabilità di macchine virtuali if you need to deploy virtual machines (VM). Con set di scalabilità di macchine virtuali, è possibile distribuire automaticamente il calcolo in modo uniforme tra le zone di disponibilità.

  • Mantenere pulito il livello di calcolo di qualsiasi stato perché i singoli nodi che gestiscono le richieste potrebbero essere eliminati, difettosi o sostituiti in qualsiasi momento.

  • Usare i servizi con ridondanza della zona, dove possibile, per offrire maggiore resilienza senza aumentare il carico operativo.

  • Eseguire il overprovisioning delle risorse critiche per attenuare gli errori delle istanze ridondanti, anche prima dell'avvio delle operazioni di scalabilità automatica, in modo che il sistema continui a funzionare dopo un errore del componente. Calcolare l'effetto accettabile di un errore quando si incorpora l'overprovisioning nella progettazione della ridondanza. Come per il processo decisionale di ridondanza, gli obiettivi di affidabilità e le decisioni di compromesso finanziario determinano la misura in cui si aggiunge capacità di riserva con overprovisioning. L'overprovisioning si riferisce in modo specifico alla scalabilità orizzontale, il che significa aggiungere istanze aggiuntive di un determinato tipo di risorsa di calcolo, anziché aumentare le funzionalità di calcolo di qualsiasi singola istanza. Ad esempio, se si modifica una macchina virtuale da uno SKU di livello inferiore a uno SKU di livello superiore.

  • Distribuire i servizi IaaS manualmente o tramite automazione in ogni zona o area di disponibilità in cui si intende implementare la soluzione. Alcuni servizi PaaS hanno funzionalità predefinite che vengono replicate automaticamente tra zone di disponibilità e aree.

Risorse dati

  • Determinare se la replica dei dati sincrona o asincrona è necessaria per la funzionalità del carico di lavoro. Per facilitare questa determinazione, vedere Raccomandazioni per l'uso di zone e aree di disponibilità.

  • Prendere in considerazione il tasso di crescita dei dati. Per la pianificazione della capacità, pianificare la crescita dei dati, la conservazione dei dati e l'archiviazione per garantire che i requisiti di affidabilità vengano soddisfatti man mano che aumenta la quantità di dati nella soluzione.  

  • Distribuire i dati geograficamente, come supportato dal servizio, per ridurre al minimo l'effetto di errori localizzati geograficamente.

  • Replicare i dati tra aree geografiche per offrire resilienza alle interruzioni a livello di area e a errori irreversibili.

  • Automatizzare il failover dopo un errore dell'istanza del database. È possibile configurare il failover automatico in più servizi dati PaaS di Azure. Il failover automatizzato non è necessario per gli archivi dati che supportano scritture in più aree, ad esempio Azure Cosmos DB. Per altre informazioni, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.

  • Usare l'archivio dati migliore per i dati. Adottare la persistenza poliglotta o le soluzioni che usano una combinazione di tecnologie di archivio dati. I dati includono più di soli dati dell'applicazione persistenti. ma anche i log applicazioni, gli eventi, i messaggi e le cache.

  • Considerare i requisiti di coerenza dei dati e usare la coerenza finale quando i requisiti lo consentono. Quando i dati vengono distribuiti, usare il coordinamento appropriato per applicare garanzie di coerenza elevata. Il coordinamento può ridurre la velocità effettiva e rendere i sistemi strettamente associati, che possono renderli più fragili. Ad esempio, se un'operazione aggiorna due database, anziché inserirla in un singolo ambito di transazione, è preferibile se il sistema può supportare la coerenza finale.

  • Dati di partizione per la disponibilità. Il partizionamento del database migliora la scalabilità e può anche migliorare la disponibilità. Se una partizione scende, le altre partizioni sono comunque raggiungibili. Un errore in una partizione interrompe solo un subset delle transazioni totali.

  • Se il partizionamento non è un'opzione, è possibile usare il modello Command and Query Responsibility Segregation (CQRS) per separare i modelli di dati di sola lettura e di sola lettura. Aggiungere istanze di database di sola lettura più ridondanti per offrire maggiore resilienza.  

  • Comprendere le funzionalità di replica e ridondanza predefinite dei servizi della piattaforma con stato usati. Per funzionalità di ridondanza specifiche dei servizi dati con stato, vedere Collegamenti correlati.

Rete

  • Decidere una topologia di rete affidabile e scalabile. Usare un modello hub-spoke o un modello di rete WAN virtuale di Azure per organizzare l'infrastruttura cloud in modelli logici che semplificano la progettazione della ridondanza per la compilazione e la scalabilità.

  • Selezionare il servizio di rete appropriato per bilanciare e reindirizzare le richieste all'interno o all'interno di aree. Usare i servizi di bilanciamento del carico con ridondanza della zona o globale quando possibile per soddisfare le destinazioni di affidabilità.

  • Assicurarsi di aver allocato spazio indirizzi IP sufficienti nelle reti virtuali e nelle subnet per tenere conto dell'utilizzo pianificato, inclusi i requisiti di scalabilità orizzontale.

  • Assicurarsi che l'applicazione possa ridimensionare entro i limiti di porta della piattaforma di hosting dell'applicazione scelta. Se un'applicazione avvia diverse connessioni TCP o UDP in uscita, potrebbe esaurire tutte le porte disponibili e causare prestazioni dell'applicazione scarse.

  • Scegliere SKU e configurare i servizi di rete che possono soddisfare i requisiti di larghezza di banda e disponibilità. La velocità effettiva di un gateway VPN varia in base al relativo SKU. Il supporto per la ridondanza della zona è disponibile solo per alcuni SKU del servizio di bilanciamento del carico.

  • Assicurarsi che la progettazione per la gestione del DNS sia basata su resilienza e supporti l'infrastruttura ridondante.

Facilitazione di Azure

La piattaforma Azure consente di ottimizzare la resilienza del carico di lavoro e di aggiungere ridondanza in base a:

Facilitazione di Azure specifica del DNS

  • Per gli scenari di risoluzione dei nomi interni, usare zone private DNS di Azure, con ridondanza della zona predefinita e ridondanza geografica. Per altre informazioni, vedere Resilienza della zona privata DNS di Azure.

  • Per gli scenari di risoluzione dei nomi esterni, usare zone pubbliche DNS di Azure, con ridondanza della zona predefinita e ridondanza geografica.

  • I servizi DNS pubblici e privati di Azure sono servizi globali resilienti alle interruzioni a livello di area perché i dati della zona sono disponibili a livello globale.

  • Per scenari di risoluzione dei nomi ibridi tra ambienti locali e cloud, usare Il sistema di risoluzione privato DNS di Azure. Questo servizio supporta la ridondanza della zona se il carico di lavoro si trova in un'area che supporta le zone di disponibilità. Un'interruzione a livello di zona non richiede alcuna azione durante il ripristino della zona. Il servizio si riabilita automaticamente e si ribilancia per sfruttare la zona sana. Per altre informazioni, vedere Resilienza nel sistema di risoluzione privato DNS di Azure.

  • Per eliminare un singolo punto di errore e ottenere una risoluzione del nome ibrido più resiliente tra aree, distribuire due o più resolver privati DNS di Azure in aree diverse. Il failover DNS, in uno scenario di inoltro condizionale, viene ottenuto assegnando un resolver come server DNS primario. Assegnare l'altro resolver in un'area diversa come server DNS secondario. Per altre informazioni, vedere Configurare il failover DNS usando i resolver privati.

Esempio

Per un esempio di distribuzione con ridondanza multi-area, vedere Applicazione Web con ridondanza della zona a disponibilità elevata.

Il diagramma seguente mostra un altro esempio:

Diagramma che mostra l'architettura dell'implementazione di riferimento.

Per altre informazioni sulla ridondanza, vedere le risorse seguenti:

Elenco di controllo affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo affidabilità