Architettura active-active multi-area

Anche con le zone di disponibilità, un carico di lavoro distribuito in una singola area geografica di Azure può essere interessato da un'interruzione a livello di area geografica: un evento raro ma possibile, causato da una grave calamità, una forte tempesta o un guasto dell'infrastruttura su larga scala. Per ottenere i massimi livelli di disponibilità, le aziende distribuiscono i carichi di lavoro in due o più aree geografiche di Azure, consentendo all'applicazione di continuare a servire gli utenti anche se un'intera area geografica diventa offline.

Esistono due modelli principali per la distribuzione in più aree geografiche:

• Active-active — le risorse di entrambe le aree geografiche gestiscono contemporaneamente il traffico reale. Questo massimizza la disponibilità e può anche ridurre la latenza indirizzando gli utenti verso l'area geografica più vicina.
• Active-passive — le risorse nell'area geografica secondaria sono in standby e ricevono traffico solo dopo un evento di failover. Questa soluzione costa meno, ma richiede più tempo per il ripristino.

Per ottenere la massima disponibilità, l'approccio preferito è active-active.

Azure Traffic Manager è un bilanciatore del carico globale basato su DNS che distribuisce il traffico tra endpoint in diverse aree geografiche di Azure (o in ambienti locali). Utilizza probe di integrità per monitorare ogni endpoint e metodi di routing (prestazioni, ponderato, priorità, geografico, a più valori) per decidere dove inviare il traffico. Per una configurazione active-active, utilizzi il metodo di routing basato sulle prestazioni per inviare gli utenti verso l'area geografica integra più vicina.

Traffic Manager supporta diversi metodi di routing, adatti a scenari differenti:

• Prestazioni — indirizza il traffico verso l'endpoint con la latenza più bassa (ideale per active-active)
• Ponderato — distribuisce il traffico in base a una percentuale di ponderazione (utile per distribuzioni graduali)
• Priorità — invia tutto il traffico all'endpoint primario, con fallback a quello secondario (active-passive)
• Geografico — indirizza gli utenti in base alla loro posizione geografica (sovranità dei dati)

In un'architettura active-active, i dati devono essere replicati tra le aree geografiche affinché gli utenti di entrambe possano leggere dati coerenti. Le opzioni includono:

• Azure SQL Database con replica geografica — replica secondaria leggibile in un'altra area geografica
• Azure Cosmos DB con scritture in più aree geografiche — tutte le aree geografiche accettano contemporaneamente le operazioni di scrittura
• Azure Storage con GRS — replica asincrona in un'area geografica secondaria

La scelta dipende dai requisiti di coerenza e disponibilità delle scritture.

Azure Cosmos DB è particolarmente adatto alle architetture active-active perché supporta le scritture in più aree geografiche: tutte le aree geografiche configurate possono accettare contemporaneamente le operazioni di scrittura. Cosmos DB utilizza livelli di coerenza configurabili (da forte a eventuale) per gestire la sincronizzazione delle repliche. Negli scenari active-active, la coerenza di sessione o la staleness limitata sono scelte comuni, perché bilanciano prestazioni e correttezza.

Sia Traffic Manager sia Azure Front Door forniscono il bilanciamento del carico globale, ma a livelli diversi:

• Traffic Manager è basato su DNS: reindirizza il client verso l'endpoint regionale corretto, ma la connessione passa direttamente a tale endpoint. Opera a livello DNS.
• Azure Front Door è un proxy anycast: termina la connessione del client in un PoP globale e inoltra la richiesta all'origine. Oltre al routing, fornisce WAF, SSL offload e memorizzazione nella cache.

Microsoft designa delle coppie di aree geografiche per ogni area geografica di Azure: un'area geografica secondaria nella stessa area geopolitica, sufficientemente distante per resistere alle calamità regionali. Quando progetta architetture distribuite in più aree geografiche, utilizzi ove possibile l'area geografica abbinata come area secondaria. Durante la manutenzione pianificata della piattaforma, viene aggiornata una sola area geografica della coppia alla volta, riducendo le interruzioni simultanee.

Nelle distribuzioni active-active, le richieste di un utente possono essere gestite da aree geografiche diverse. Se l'applicazione archivia lo stato della sessione in memoria sul server Web, si verificano problemi quando l'utente cambia area geografica. La soluzione consiste nell'utilizzare un archivio di sessione distribuito, ad esempio Azure Cache for Redis con replica geografica, in modo che i dati della sessione siano accessibili da qualsiasi area geografica.

Un'architettura active-active è più costosa di una distribuzione in una singola area geografica perché esegue una copia completa dell'infrastruttura in almeno due aree geografiche. I costi aggiuntivi includono il trasferimento dei dati tra aree geografiche, la replica geografica dei database e gli addebiti di Traffic Manager o Front Door. Esegua un'analisi costi-benefici: per i carichi di lavoro mission-critical, il costo dei tempi di inattività supera in genere di gran lunga quello della seconda area geografica.

Un'architettura active-active deve essere testata regolarmente per garantire che funzioni quando necessario. Gli strumenti di chaos engineering, come Azure Chaos Studio, consentono di simulare guasti, ad esempio arrestando tutte le VM in un'area geografica, e di osservare la risposta del sistema. I test regolari confermano che le probe di integrità di Traffic Manager rilevino i guasti, che il failover avvenga entro l'RTO e che i dati rimangano coerenti tra le aree geografiche.

Verifichi la sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) presentati in questa lezione.

In questa lezione ha imparato che l'architettura active-active distribuisce contemporaneamente risorse operative in più aree geografiche per ottenere la massima disponibilità; Azure Traffic Manager instrada il traffico utilizzando metodi basati su prestazioni, priorità, ponderazione o posizione geografica; e la replica dei dati (scritture in più aree geografiche di Cosmos DB, replica geografica SQL) è essenziale per mantenere la coerenza tra le aree geografiche. Nella prossima lezione analizzeremo le probe di integrità e i modelli di degradazione controllata.