Progettare un'architettura dei dati distribuita a livello geografico
La parte finale della progettazione dell'architettura dell'applicazione da considerare è il livello di archiviazione dati. Si vuole fare in modo che i dati possano essere sia letti che scritti con funzionalità complete dopo un errore a livello di area.
Nel portale di monitoraggio delle spedizioni si è scelto di usare Frontdoor di Azure per inviare tutte le richieste ai servizi app nell'area Stati Uniti orientali. In caso di errore nell'area Stati Uniti orientali, Frontdoor rileva il problema e invia le richieste ai componenti duplicati dei servizi app nell'area Stati Uniti occidentali. Nell'architettura a singola area originale i dati relazionali sono stati archiviati nel database SQL di Azure e i dati semistrutturati in Cosmos DB. Si vuole ora capire come garantire che entrambi i database rimangano disponibili in caso di errore nell'area Stati Uniti orientali.
In questa unità viene illustrato come replicare i dati tra le aree e come verificare che il failover possa essere eseguito rapidamente, se necessario.
Database SQL di Microsoft Azure
Per creare un'implementazione in più aree del database SQL di Azure per archiviare i dati relazionali, è possibile usare:
- Replica geografica attiva
- Gruppi di failover automatico
Replica geografica attiva
Il database SQL di Azure può replicare automaticamente un database e tutte le relative modifiche da un database a un altro con la funzionalità di replica geografica attiva. Solo il server logico primario ospita una copia scrivibile del database. È possibile creare fino a quattro altri server logici che ospitano copie di sola lettura del database.
Per il portale di monitoraggio delle spedizioni, creare un database secondario nell'area Stati Uniti occidentali e configurare la replica geografica dall'area Stati Uniti orientali. Quando si verifica un errore a livello di area, Frontdoor reindirizza le richieste degli utenti ai servizi app nell'area Stati Uniti occidentali. I servizi app e Funzioni di Azure possono accedere ai dati relazionali perché una copia è già stata replicata nell'area Stati Uniti occidentali.
Questa modifica è automatica, ma tenere presente che il database secondario nell'area Stati Uniti occidentali è di sola lettura. Se un utente cerca di modificare i dati, ad esempio creando una nuova spedizione, possono verificarsi errori. È possibile avviare manualmente un failover nell'area Stati Uniti occidentali non appena si nota il problema nel portale di Azure. Se si vuole automatizzare questo processo, gli sviluppatori possono scrivere codice che chiama il metodo failover nell'API REST del database SQL di Azure.
Nota
Le istanze gestite del database SQL di Azure non supportano la replica geografica attiva. Le istanze gestite sono progettate per semplificare la migrazione dei dati da un'istanza di SQL Server locale, mantenendo al tempo stesso la sicurezza. Se si usa un'istanza gestita, prendere invece in considerazione i gruppi di failover.
Gruppi di failover automatico
Un gruppo di failover automatico è un gruppo di database in cui i dati vengono replicati automaticamente da un server primario a uno o più server secondari. Questa progettazione è analoga alla replica geografica attiva e usa lo stesso metodo di replica dei dati. È tuttavia possibile automatizzare la risposta a un errore definendo un criterio.
Per il portale di spedizione viene creato un database secondario nell'area Stati Uniti occidentali. Si aggiunge quindi un criterio che esegue il failover della replica primaria del database nell'area Stati Uniti occidentali in caso di errore irreversibile nell'area Stati Uniti orientali. Se ciò si verifica, la replica nell'area Stati Uniti occidentali diventa automaticamente il database primario scrivibile e vengono mantenute tutte le funzionalità.
Se si vuole automatizzare il failover del database scrivibile senza scrivere codice personalizzato per attivarlo, prendere in considerazione l'uso di un gruppo di failover automatico. Usare inoltre i gruppi di failover automatico se il database è in esecuzione in un'istanza gestita del database SQL di Azure.
Importante
Sia nel caso della replica geografica attiva che dei gruppi di failover automatico, la replica viene eseguita in modo asincrono. Viene inviato un acknowledgment al client quando viene applicata una modifica alla replica primaria. A questo punto, la transazione viene considerata completa e viene eseguita la replica. Se si verifica un errore, è possibile che le modifiche più recenti apportate nel database primario non vengano replicate nel database secondario. Tenere presente che, dopo un'emergenza, le modifiche al database più recenti possono andare perse.
Azure Cosmos DB
La configurazione è meno complessa con Azure Cosmos DB perché è progettata come sistema di database cloud a più aree. Cosmos DB è un database multimodello in grado di archiviare dati relazionali, dati semi-strutturati e altre forme di dati. Anche se si esegue Cosmos DB in una singola area, i dati vengono replicati in più istanze in domini di errore diversi per garantire una disponibilità ottimale.
Quando si crea un account Cosmos DB in più aree, è possibile scegliere una delle modalità seguenti:
Account in più aree con più aree di scrittura.
In questa modalità tutte le copie del database sono sempre scrivibili. In caso di errore in un'area, non è necessario alcun failover.
Account in più aree con una singola area di scrittura.
In questa modalità, solo l'area primaria contiene database scrivibili. I dati replicati nelle aree secondarie sono di sola lettura. Gli aggiornamenti sono disabilitati per impostazione predefinita quando si verifica un errore nell'area primaria. È tuttavia possibile selezionare l'opzione Abilita failover automatico in modo che Cosmos DB esegua automaticamente il failover della copia primaria scrivibile del database in un'altra area.
Importante
In Cosmos DB la replica dei dati è sincrona. Quando viene applicata una modifica, la transazione non viene considerata completa finché non viene replicata in un quorum di repliche. Viene quindi inviato un acknowledgment al client. Quando si verifica un errore, le modifiche recenti non vengono perse perché la replica è già stata eseguita.