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?

In un'implementazione perfetta, l'aggiunta di ridondanza uniforme potrebbe aumentare in modo esponenziale la disponibilità del sistema. Si supponga, ad esempio, di avere N componenti equivalenti e equilibrati che:

• può funzionare in modo indipendente e rimosso simultaneamente dal pool
• hanno uno stato identico o nessuno stato
• non hanno lavoro in corso che viene perso definitivamente durante il malfunzionamento
• sono identici nelle funzionalità
• non hanno dipendenze l'una dall'altra
• gestisce la riduzione della capacità senza malfunzionamenti aggiuntivi

Se ogni singolo componente ha una disponibilità di A, la disponibilità complessiva del sistema può essere calcolata usando la formula 1 - (1 - A)^N.

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 l'uso di zone e di disponibilità e aree, vedere Raccomandazioni per l'uso di zone di disponibilità e aree.

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.

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.

Testare e convalidare i componenti ridondanti. I vantaggi dell'affidabilità in molti modi dalla semplicità e dall'aggiunta di ridondanza possono aumentare la complessità. Per assicurarsi che l'aggiunta della ridondanza comporti effettivamente una maggiore disponibilità, è necessario convalidare quanto segue:

• Il sistema può rilevare in modo affidabile componenti ridondanti integri e non integri e rimuoverli in modo sicuro e rapido dal pool di componenti?
• Il sistema può aumentare in modo affidabile il numero di istanze e nei componenti ridondanti?
• Le operazioni di routine, ad hoc e di carico di lavoro di emergenza possono gestire la ridondanza?

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 o Frontdoor di Azure in una soluzione in più aree come meccanismo di routing del failover, prendere in considerazione le raccomandazioni seguenti:

Sincronizzare il failover front-end e back-end. Usare il meccanismo di routing per eseguire il failover del front-end. Se il front-end non è raggiungibile in un'area, il failover instrada 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 l'automazione per il failover, ma non per il failback. 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. È anche consigliabile verificare la coerenza dei dati prima del failback.

A tale scopo, disabilitare l'endpoint primario 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 la soluzione di routing. Valutare la possibilità di progettare una soluzione di ridondanza del routing globale per applicazioni Web cruciali.