Rendere ogni elemento ridondante

Applicare la ridondanza nell'applicazione per evitare singoli punti di guasto

Un'applicazione resiliente consente di risolvere più facilmente gli errori. È quindi opportuno identificare i percorsi critici nell'applicazione e verificare se in ogni punto del percorso sia prevista una certa ridondanza, In caso di errore di un sottosistema, l'applicazione eseguirà il failover in un altro elemento?

Consigli

Prendere in considerazione i requisiti aziendali. La ridondanza implementata in un sistema può influire sui costi e sulla complessità del sistema stesso. L'architettura deve essere informata dai requisiti aziendali, ad esempio l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO). È anche consigliabile considerare i requisiti di prestazioni e la capacità del team di gestire set complessi di risorse.

Prendere in considerazione architetture multi-zona e in più aree. Assicurarsi di comprendere in che modo le zone di disponibilità e le aree offrono resilienza e diversi set di compromessi architetturali.

Le zone di disponibilità di Azure sono set isolati di data center all'interno di un'area. Usando le zone di disponibilità, è possibile essere resilienti agli errori di un singolo data center o di un'intera zona di disponibilità. È possibile usare le zone di disponibilità per stabilire compromessi tra costi, mitigazione dei rischi, prestazioni e recuperabilità. Ad esempio, quando si usano servizi con ridondanza della zona nell'architettura, Azure offre la replica automatica dei dati e il failover tra istanze geograficamente separate, che riduce molti tipi diversi di rischi.

Se si dispone di un carico di lavoro mission-critical e si deve ridurre il rischio di interruzione a livello di area, prendere in considerazione una distribuzione in più aree. Anche se le distribuzioni in più aree isolano l'utente contro le emergenze a livello di area, vengono a un costo. Le distribuzioni in più aree sono più costose di una distribuzione a singola area e sono più complesse da gestire. Sono necessarie procedure operative per gestire il failover e il failback. A seconda dei requisiti RPO, potrebbe essere necessario accettare prestazioni leggermente inferiori per abilitare la replica dei dati tra aree. I costi e la complessità aggiuntivi potrebbero essere giustificati per alcuni scenari aziendali.

Suggerimento

Per molti carichi di lavoro, un'architettura con ridondanza della zona offre il miglior set di compromessi. Si consideri un'architettura in più aree se i requisiti aziendali indicano che è necessario attenuare il rischio improbabile di un'interruzione a livello di area e se si è pronti ad accettare i compromessi coinvolti in tale approccio.

Per altre informazioni su come progettare la soluzione per usare zone e aree di disponibilità, vedere Consigli per l'uso di zone e aree di disponibilità.

Prevedere un servizio di bilanciamento del carico prima delle macchine virtuali. Non usare una singola macchina virtuale per carichi di lavoro critici, ma prevedere un servizio di bilanciamento del carico da inserire prima delle macchine virtuali. In questo modo se una qualsiasi macchina virtuale non è più disponibile, il servizio di bilanciamento del carico distribuirà il traffico alle rimanenti macchine virtuali integre. Per informazioni su come distribuire questa configurazione, vedere [Più macchine virtuali per scalabilità e disponibilità][multi-vm-blueprint].

Replicare i database. database SQL di Azure e Azure Cosmos DB replicano automaticamente i dati all'interno di un'area e possono essere configurati per la replica tra zone di disponibilità per una maggiore resilienza. È anche possibile scegliere di abilitare la replica geografica tra aree. La replica geografica per database SQL di Azure e Azure Cosmos DB crea repliche leggibili secondarie dei dati in una o più aree secondarie. Se si verifica un'interruzione nell'area primaria, il database può eseguire il failover nell'area secondaria per le operazioni di scrittura. A seconda della configurazione di replica, è possibile che si verifichi una perdita di dati da transazioni non replicate.

Se si usa una soluzione di database IaaS, scegliere quella che supporta la replica e il failover, ad esempio i gruppi di disponibilità AlwaysOn di SQL Server.

Usare il partizionamento per garantire la disponibilità. Il partizionamento del database viene spesso usato per migliorare la scalabilità, ma può anche consentire di migliorare la disponibilità. In caso di malfunzionamento di una partizione, è comunque possibile raggiungere le altre. Un errore in una partizione danneggerà inoltre solo un subset delle transazioni totali.

Soluzioni in più aree

Il diagramma seguente mostra un'applicazione in più aree che usa Gestione traffico di Azure per gestire il failover.

Se si usa Gestione traffico in una soluzione in più aree, prendere in considerazione le raccomandazioni seguenti:

Sincronizzare il failover front-end e back-end. Usare Gestione traffico per eseguire il failover del front-end. Se il front-end diventa irraggiungibile in un'area, Gestione traffico inoltrerà le nuove richieste all'area secondaria. A seconda dei componenti back-end e della soluzione di database, potrebbe essere necessario coordinare il failover dei servizi back-end e dei database.

Usare il failover automatico e il failback manuale. Usare Gestione traffico per il failover automatico, ma non per il failback automatico. Il failback automatico è infatti rischioso perché il passaggio all'area primaria potrebbe avvenire prima che l'area sia completamente integra. Verificare invece che tutti i sottosistemi dell'applicazione siano integri prima di eseguire il failback manuale. A seconda del database, inoltre, potrebbe essere necessario verificare la coerenza dei dati prima del failback.

A tale scopo, disabilitare l'endpoint primario di Gestione traffico dopo il failover. Si noti che se l'intervallo di monitoraggio dei probe è breve e il numero tollerato di errori è ridotto, il failover e il failback verranno eseguiti in breve tempo. In alcuni casi, la disabilitazione non verrà completata in tempo. Per evitare il failback non confermato, è consigliabile implementare anche un endpoint di integrità in grado di verificare che tutti i sottosistemi siano integri. Vedere il modello di monitoraggio degli endpoint di integrità.

Includere la ridondanza per Gestione traffico. Gestione traffico costituisce un possibile punto di guasto. Rivedere il contratto di servizio di Gestione traffico e determinare se l'uso di Gestione traffico da solo soddisfa i requisiti aziendali per la disponibilità elevata. In caso contrario, provare ad aggiungere un'altra soluzione di gestione del traffico come failback. In caso di errore del servizio Gestione traffico di Azure, modificare i record CNAME in DNS in modo che puntino all'altro servizio di gestione del traffico.