Suggerimenti per la progettazione per la ridondanza
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: progettazione | multimultidimensionale a disponibilità elevata Con zone e aree di disponibilità
Questa guida descrive le raccomandazioni per l'aggiunta della ridondanza in tutti i flussi critici a diversi livelli di carico di lavoro, 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 uso di tecnologie di archiviazione diverse dalla stessa applicazione o soluzione per sfruttare le migliori funzionalità di ogni componente. |
| Coerenza dei dati | La misura di come la sincronizzazione o la sincronizzazione di un determinato set di dati si trova in più archivi. |
| Partizionamento | Processo di divisione 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 le repliche siano 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à, compilare in 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 tutto il 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 con un utilizzo del 60% 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 il provisioning eccessivo come strategia di resilienza, bilanciarlo con una strategia di scalabilità ben definita per ridurre al minimo le inefficienze dei costi.
- Quando si crea un livello elevato di ridondanza, è possibile che si verifichino compromessi in caso di 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
Si considerino due approcci quando si progetta un'architettura ridondante: attivo-attivo o attivo-passivo. Scegliere l'approccio in base alla 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 è notevolmente 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 a più aree a disponibilità elevata.
Indicatori 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. Gli indicatori di distribuzione sono i raggruppamenti di risorse necessarie 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 consideri ogni timbro come 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 passiva attiva per la resilienza e il carico di gestione. Anche la pianificazione della scalabilità orizzontale in più aree è importante 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 attiva-passiva, 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à.
Implementare la ridondanza della zona per le 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. Cercare 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 di cui è necessario avere il controllo per determinare se usare servizio Azure Kubernetes (servizio Azure Kubernetes) 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 grado 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 il livello di calcolo pulito di qualsiasi stato perché i singoli nodi che gestiscono le richieste potrebbero essere eliminati, con errori o sostituiti in qualsiasi momento.
Usare i servizi con ridondanza della zona, se possibile, per offrire maggiore resilienza senza aumentare il carico operativo.
Eseguire l'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 il provisioning eccessivo 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 il provisioning eccessivo. L'overprovisioning si riferisce in modo specifico all'aumento del numero di istanze, ovvero all'aggiunta di istanze aggiuntive di un determinato tipo di risorsa di calcolo, invece di 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 e aree di disponibilità.
Implementare la ridondanza della zona per le 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 garantire 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 automatico 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ù dati dell'applicazione persistenti. ma anche i log applicazioni, gli eventi, i messaggi e le cache.
Prendere in considerazione 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 assoluta. 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é inserirli in un singolo ambito di transazione, è preferibile se il sistema può soddisfare 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 si arresta, le altre partizioni sono ancora raggiungibili. Un errore in una partizione interrompe solo un subset delle transazioni totali.
Se il partizionamento orizzontale non è un'opzione, è possibile usare il modello CQRS (Command and Query Responsibility Segregation) per separare i modelli di dati di lettura/scrittura e di sola lettura. Aggiungere altre istanze di database di sola lettura 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.
Implementare la ridondanza della zona per le risorse di rete
Scegliere 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 compilazione e la scalabilità della ridondanza.
Selezionare il servizio di rete appropriato per bilanciare e reindirizzare le richieste all'interno o tra aree. Usare servizi di bilanciamento del carico globali o con ridondanza della zona quando possibile per soddisfare le destinazioni di affidabilità.
Assicurarsi di aver allocato spazio di indirizzi IP sufficiente nelle reti virtuali e nelle subnet per tenere conto dell'utilizzo pianificato, inclusi i requisiti di scalabilità orizzontale.
Assicurarsi che l'applicazione possa essere ridimensionata entro i limiti delle porte 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 GLI SKU e configurare i servizi di rete in grado di 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 compilata con particolare attenzione alla 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:
Fornire ridondanza predefinita con molte soluzioni PaaS e Software as a Service (SaaS), alcune delle quali configurabili.
Consente di progettare e implementare la ridondanza all'interno dell'area usando le zone di disponibilità e la ridondanza tra aree.
Offerta di servizi di bilanciamento del carico in grado di supportare la replica, ad esempio gateway app Azure lication, Frontdoor di Azure e Azure Load Balancer.
Offerta di soluzioni di replica geografica facilmente implementate, ad esempio la replica geografica attiva per database SQL di Azure. Implementare la distribuzione globale e la replica trasparente usando Azure Cosmos DB. Azure Cosmos DB offre due opzioni per la gestione delle scritture in conflitto. Scegliere l'opzione migliore per il carico di lavoro.
Offerta di funzionalità di ripristino temporizzato per molti servizi dati PaaS.
Riduzione dell'esaurimento delle porte tramite gateway NAT di Azure o Firewall di Azure.
Facilitazione di Azure specifica di DNS
Per gli scenari di risoluzione dei nomi interni, usare le 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 le zone pubbliche DNS di Azure, con ridondanza della zona predefinita e ridondanza geografica.
I servizi DNS di Azure pubblici e privati sono servizi globali resilienti alle interruzioni a livello di area perché i dati della zona sono disponibili a livello globale.
Per gli scenari di risoluzione dei nomi ibridi tra ambienti locali e cloud, usare il resolver 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 auto-guarisce e ribilancia automaticamente per sfruttare la zona integra. Per altre informazioni, vedere Resilienza nel resolver privato DNS di Azure.
Per eliminare un singolo punto di errore e ottenere una risoluzione dei nomi ibrida 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 in più aree, vedere Applicazione Web con ridondanza della zona a disponibilità elevata di base.
Il diagramma seguente mostra un altro esempio:
Collegamenti correlati
Per altre informazioni sulla ridondanza, vedere le risorse seguenti:
- Guida alle aree di Azure
- Azure Storage redundancy (Ridondanza di Archiviazione di Azure)
- Archiviazione con ridondanza della zona
- database SQL di Azure replica geografica attiva
- Configurare la replica tra due istanze gestite
Elenco di controllo per l'affidabilità
Fare riferimento al set completo di raccomandazioni.