Progettazione di servizi disponibili a livello globale con il database SQL di Azure

Si applica a: Database SQL di Azure

Quando si compilano e si distribuiscono servizi cloud con il database SQL di Azure, la replica geografica attiva o i gruppi di failover automatico consentono di garantire resilienza in caso di interruzioni a livello di area ed errori irreversibili. La stessa funzionalità consente di creare applicazioni distribuite a livello globale ottimizzate per l'accesso locale ai dati. Questo articolo illustra modelli di applicazione comuni, nonché i vantaggi e gli svantaggi di ogni opzione.

Nota

Se si usano pool elastici e database premium o business critical, è possibile renderli resistenti alle interruzioni a livello di area convertendoli in una configurazione di distribuzione con ridondanza della zona. Vedere Database con ridondanza della zona.

Scenario 1: Uso di due aree di Azure per la continuità aziendale con tempo di inattività minimo

In questo scenario le applicazioni presentano le caratteristiche seguenti:

  • L'applicazione è attiva in un'area di Azure
  • Tutte le sessioni del database richiedono l'accesso in lettura e scrittura ai dati
  • Il livello Web e il livello dati devono essere collocati in modo da ridurre la latenza e il costo del traffico
  • Essenzialmente, il tempo di inattività rappresenta per queste applicazioni un rischio aziendale più elevato rispetto alla perdita di dati

In questo caso, la topologia di distribuzione dell'applicazione è ottimizzata per gestire gli eventi di emergenza a livello di area quando tutti i componenti dell'applicazione devono eseguire il failover insieme. Il diagramma seguente illustra questa topologia. Per garantire la ridondanza geografica, le risorse dell'applicazione vengono distribuite nelle aree A e B. Le risorse nell'area B, tuttavia, non vengono utilizzate finché non si verifica un errore nell'area A. Tra le due aree viene configurato un gruppo di failover per gestire la connettività del database, la replica e il failover. Il servizio Web in entrambe le aree è configurato per accedere al database tramite il listener< di lettura-write failover-group-name.database.windows.net> (1). Gestione traffico di Azure è configurato per usare il metodo di routing con priorità (2).  

Nota

Gestione traffico di Azure viene usato in questo articolo solo per scopi di illustrazione. È possibile usare qualsiasi soluzione di bilanciamento del carico che supporti il metodo di routing per priorità.

Il diagramma seguente illustra questa configurazione prima di un'interruzione:

Scenario 1. Configurazione prima dell'interruzione.

Dopo un'interruzione nell'area primaria, database SQL rileva che il database primario non è accessibile e attiva il failover nell'area secondaria in base ai parametri dei criteri di failover automatico (1). A seconda del contratto di servizio dell'applicazione, è possibile configurare un periodo di tolleranza che controlla l'intervallo di tempo tra il rilevamento dell'interruzione e il failover stesso. È possibile che Gestione traffico di Azure avvia il failover dell'endpoint prima che il gruppo di failover attiva il failover del database. In tal caso, l'applicazione Web non può riconnettersi immediatamente al database. Le riconnessioni, tuttavia, avranno automaticamente esito positivo non appena verrà completato il failover del database. Quando l'area in cui si è verificato l'errore è ripristinata e di nuovo online, il database primario precedente si riconnette automaticamente come nuovo database secondario. Il diagramma seguente illustra la configurazione dopo il failover.

Nota

Tutte le transazioni di cui è stato eseguito il commit dopo il failover andranno perse durante la riconnessione. Dopo il completamento del failover, l'applicazione nell'area B può riconnettersi e riavviare l'elaborazione delle richieste utente. Sia l'applicazione Web che il database primario sono ora nell'area B e rimangono co-localizzati.

Scenario 1. Configurazione dopo il failover

In caso di interruzione nell'area B, il processo di replica tra il database primario e quello secondario viene sospeso ma il collegamento tra i due resta intatto (1). Gestione traffico rileva che la connettività all'area B viene interrotta e contrassegna l'app Web dell'endpoint 2 come degradata (2). Le prestazioni dell'applicazione non subiscono alcun impatto in questo caso, ma il database risulta esposto e quindi maggiormente a rischio di perdita di dati in caso di errore in successione nell'area A.

Nota

Per il ripristino di emergenza è consigliabile la configurazione con distribuzione dell'applicazione limitata a due aree. Infatti la maggior parte delle geografie di Azure ha solo due aree. Questa configurazione non protegge l'applicazione da un errore irreversibile simultaneo in entrambe le aree. Nell'improbabile eventualità di un errore di questo genere, è possibile recuperare i database in una terza area con un'operazione di ripristino geografico.

Dopo che l'interruzione è stata risolta, il database secondario viene automaticamente risincronizzato con quello primario. Durante la sincronizzazione, le prestazioni del database primario possono risultare peggiorate. L'impatto specifico dipende dalla quantità di dati acquisita dal nuovo database primario dal momento del failover.

Nota

Dopo aver risolto l'interruzione, Gestione traffico inizierà a instradare le connessioni all'applicazione in Area A come punto finale con priorità superiore. Se si intende mantenere il valore primario in Region B per un po', è necessario modificare la tabella di priorità nel profilo trafic Manager di conseguenza.

Il diagramma seguente illustra un'interruzione nell'area secondaria:

Scenario 1. Configurazione dopo un'interruzione nell'area secondaria.

I vantaggi chiave di questo modello di progettazione sono:

  • La stessa applicazione Web viene distribuita in entrambe le aree senza alcuna configurazione specifica dell'area e non richiede logica aggiuntiva per la gestione del failover.
  • Il failover non influisce sulle prestazioni dell'applicazione perché l'applicazione Web e il database condividono sempre lo stesso percorso.

Il principale svantaggio è rappresentato dal fatto che le risorse dell'applicazione nell'area B sono sottoutilizzate nella maggior parte dei casi.

Scenario 2: Aree di Azure per la continuità aziendale con mantenimento massimo dei dati

Questa opzione è particolarmente indicata per le applicazioni con le caratteristiche seguenti:

  • Qualsiasi perdita di dati rappresenta un rischio aziendale elevato. Il failover del database può essere usato solo come ultima soluzione se l'interruzione è causata da un errore irreversibile.
  • L'applicazione supporta le modalità di sola lettura e lettura/scrittura delle operazioni e può funzionare in "modalità di sola lettura" per un periodo di tempo.

In questo modello l'applicazione passa alla modalità di sola lettura quando le connessioni di lettura-scrittura iniziano a dare errori di timeout. L'applicazione Web viene distribuita in entrambe le aree e include una connessione all'endpoint listener di lettura-scrittura e una connessione diversa all'endpoint listener di sola lettura (1). Il profilo di Gestione traffico deve usare il routing con priorità. Il monitoraggio degli endpoint dovrà essere abilitato per l'endpoint applicazione in ogni area (2).

Il diagramma seguente illustra questa configurazione prima di un'interruzione:

Scenario 2. Configurazione prima dell'interruzione.

Quando Gestione traffico rileva un errore di connettività all'area A, passa automaticamente il traffico utente all'istanza dell'applicazione nell'area B. Con questo modello, è importante impostare il periodo di tolleranza con la perdita di dati su un valore sufficientemente elevato, ad esempio 24 ore. In questo modo si impedisce la perdita di dati se l'interruzione del servizio viene risolta entro tale intervallo di tempo. Quando l'applicazione Web nell'area B viene attivata le operazioni di lettura-scrittura hanno esito negativo. A questo punto, passerà alla modalità di sola lettura (1). In questa modalità, le richieste vengono instradate automaticamente al database secondario. Se l'interruzione è causata da un errore irreversibile, molto probabilmente non potrà essere risolta entro il periodo di tolleranza. Alla scadenza, il gruppo di failover attiva il failover. Il listener di lettura/scrittura diventa quindi disponibile e le connessioni non hanno più esito negativo (2). Il diagramma seguente illustra le due fasi del processo di ripristino.

Nota

Se l'interruzione nell'area primaria viene attenuata entro il periodo di tolleranza, Gestione traffico rileva il ripristino della connettività nell'area primaria e passa il traffico utente all'istanza dell'applicazione in A. L'istanza dell'applicazione riprende e opera in modalità di lettura-scrittura usando il database primario nell'area A, come illustrato dal diagramma precedente.

Scenario 2. Fasi di ripristino di emergenza.

Se si verifica un'interruzione nell'area B, Gestione traffico rileva l'errore del punto finale web-app-2 nell'area B e lo contrassegna (1). Nel frattempo, il gruppo di failover trasferisce il listener di sola lettura all'area A (2). Questa interruzione non influisce sull'esperienza utente finale, ma il database primario viene esposto durante l'interruzione. Il diagramma seguente illustra un errore nell'area secondaria:

Scenario 2. Interruzione dell'area secondaria.

Dopo che l'interruzione del servizio è stata risolta, il database secondario viene immediatamente sincronizzato con quello primario e il listener di sola lettura viene passato nuovamente al database secondario nell'area B. Durante la sincronizzazione, le prestazioni del database primario potrebbero essere leggermente influenzate a seconda della quantità di dati che deve essere sincronizzata.

Questo modello di progettazione presenta diversi vantaggi:

  • Impedisce la perdita dei dati durante le interruzioni temporanee.
  • Il tempo di inattività dipende solo dalla velocità con cui Gestione traffico rileva l'errore di connettività, configurabile.

Lo svantaggio è rappresentato dal fatto che l'applicazione deve poter funzionare in modalità di sola lettura.

Scenario 3: Spostare un'applicazione in aree geografiche diverse per seguire la domanda

In questo scenario l'applicazione presenta le caratteristiche seguenti:

  • Gli utenti finali accedono all'applicazione da aree geografiche diverse.
  • L'applicazione include carichi di lavoro di sola lettura che non dipendono dalla sincronizzazione completa con gli aggiornamenti più recenti.
  • L'accesso in scrittura ai dati deve essere supportato nella stessa area geografica per la maggior parte degli utenti.
  • La latenza di lettura è fondamentale per l'esperienza dell'utente finale.

Per soddisfare questi requisiti, è necessario garantire che il dispositivo utente si connetta sempre all'applicazione distribuita nella stessa area geografica per operazioni di sola lettura, ad esempio l'esplorazione dei dati, l'analisi e così via. Al contrario, le operazioni di elaborazione transazionale online (OLTP) vengono elaborate nella stessa area geografica nella maggior parte dei casi. Ad esempio, durante il giorno, le operazioni OLTP vengono elaborate nella stessa area geografica, ma possono essere elaborate in un'area geografica diversa durante gli orari di minore attività. Se l'attività dell'utente finale si verifica principalmente durante le ore lavorative tipiche, è possibile garantire prestazioni ottimali per la maggior parte degli utenti nella maggior parte dei casi. Il diagramma seguente illustra questa topologia.

Le risorse dell'applicazione dovranno essere distribuite in ogni area geografica in cui si ha un'elevata esigenza di utilizzo. Ad esempio, se l'applicazione viene usata attivamente nei Stati Uniti, Asia orientale ed Europa, l'applicazione deve essere distribuita in tutte queste aree geografiche ,ad esempio Stati Uniti occidentali, Giappone e Regno Unito. Il database primario deve essere spostato dinamicamente da un'area geografica alla successiva alla fine delle ore lavorative tipiche. Questo metodo è detto "follow the sun". Il carico di lavoro OLTP si connette sempre al database tramite il listener <di lettura/scrittura failover-group-name.database.windows.net> (1). Il carico di lavoro di sola lettura si connette direttamente al database locale usando il nome-server> dell'endpoint< server dei database.database.windows.net (2). Gestione traffico è configurato con il metodo di routing delle prestazioni. Garantisce che il dispositivo dell'utente finale sia connesso al servizio Web nell'area più vicina. Gestione traffico deve essere configurato con il monitoraggio del punto finale abilitato per ogni endpoint del servizio Web (3).

Nota

La configurazione del gruppo di failover definisce l'area usata per il failover. Poiché il nuovo database primario si trova in un'area geografica diversa, il failover comporta una latenza più lunga sia per i carichi di lavoro OLTP che per i carichi di lavoro di sola lettura fino a quando l'area interessata non torna online.

Diagramma della configurazione con primario negli Stati Uniti occidentali.

Al termine della giornata lavorativa negli Stati Uniti occidentali, ad esempio alle 14:00 ora locale, i database attivi devono essere passati all'area successiva, Asia orientale (Giappone), dove si trova alle 8:00. Quindi, alle 16:00 in Asia orientale, il primario dovrebbe passare all'Europa (Regno Unito) dove è alle 8:00. Questa attività può essere completamente automatizzata usando App per la logica di Azure. L'attività include i passaggi seguenti:

  • Cambiare il server primario nel gruppo di failover in Asia orientale usando il failover descrittivo (1).
  • Rimuovere il gruppo di failover tra Stati Uniti occidentali e Asia orientale.
  • Creare un nuovo gruppo di failover con lo stesso nome, ma tra Asia orientale ed Europa (2).
  • Aggiungere il database primario in Asia orientale e secondario in Europa a questo gruppo di failover (3).

Il diagramma seguente illustra la nuova configurazione dopo il failover pianificato:

Scenario 3. Transizione del primario all'Asia orientale.

Se si verifica un'interruzione in Asia orientale, ad esempio, il failover automatico del database viene avviato dal gruppo di failover, il che comporta effettivamente lo spostamento dell'applicazione nell'area successiva prima della pianificazione (1). In tal caso, Stati Uniti occidentali è l'unica area secondaria rimanente fino a quando l'Asia orientale non torna online. Le due aree rimanenti gestiscono i clienti in tutte e tre le aree geografiche cambiando i ruoli. App per la logica di Azure deve essere modificata di conseguenza. Poiché le aree rimanenti ottengono traffico utente aggiuntivo dall'Asia orientale, le prestazioni dell'applicazione sono influenzate non solo da una latenza aggiuntiva, ma anche da un maggior numero di connessioni degli utenti finali. Dopo aver risolto l'interruzione, il database secondario è immediatamente sincronizzato con il database primario corrente. Il diagramma seguente illustra un'interruzione del servizio in Asia orientale:

Scenario 3. Interruzione nell'Asia orientale.

Nota

È possibile ridurre il tempo in cui l'esperienza dell'utente finale in Asia orientale è ridotta dalla latenza prolungata. A tale scopo, è necessario distribuire in modo proattivo una copia di un'applicazione e creare uno o più database secondari in un'area vicina (ad esempio, il data center centrale di Azure Corea) come sostituzione dell'istanza dell'applicazione offline in Giappone. Quando quest'ultimo è tornato online, è possibile decidere se continuare a usare la Corea centrale o per rimuovere la copia dell'applicazione lì e tornare all'uso del Giappone.

I principali vantaggi di questa progettazione sono i seguenti:

  • Il carico di lavoro dell'applicazione di sola lettura accede ai dati nell'area più vicina in qualsiasi momento.
  • Il carico di lavoro dell'applicazione in lettura/scrittura accede ai dati nell'area più vicina durante il periodo dell'attività più elevata in ogni area geografica.
  • Dato che l'applicazione viene distribuita in più aree, può superare la perdita di una delle aree senza tempi di inattività significativi.

Esistono tuttavia alcuni svantaggi:

  • Un'interruzione a livello di area determina una latenza superiore nell'area geografica. I carichi di lavoro di sola lettura e di sola lettura vengono gestiti dall'applicazione in un'area geografica diversa.
  • I carichi di lavoro di sola lettura devono connettersi a un diverso endpoint in ogni area.

Pianificazione della continuità aziendale: Scegliere una progettazione di applicazioni per il ripristino di emergenza cloud

La strategia di ripristino di emergenza cloud specifica può combinare o estendere questi modelli di progettazione per soddisfare al meglio le esigenze dell'applicazione. Come accennato in precedenza, la strategia scelta si basa sul contratto di servizio che si vuole offrire ai clienti e sulla topologia di distribuzione dell'applicazione. Per facilitare la decisione, la tabella seguente confronta le opzioni in base all'obiettivo del punto di ripristino (RPO) e al tempo di recupero stimato (ERT).

Modello RPO ERT
Distribuzione attiva/passiva per il ripristino di emergenza con accesso al database con percorso condiviso Accesso in < lettura/scrittura 5 sec Ora di rilevamento dell'errore + DNS TTL
Distribuzione attiva/attiva per il bilanciamento del carico dell'applicazione Accesso in < lettura/scrittura 5 sec Ora di rilevamento dell'errore + DNS TTL
Distribuzione attiva/passiva per la conservazione dei dati Accesso in < sola lettura 5 sec Accesso in sola lettura = 0
Accesso in lettura/scrittura = zero Accesso in lettura-scrittura = ora di rilevamento dell'errore + periodo di tolleranza con perdita di dati

Passaggi successivi