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

Si applica a: Database SQL di Azure

Nella creazione e distribuzione di servizi cloud con il database SQL di Azure, la replica geografica attiva o i gruppi di failover forniscono 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.

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 la gestione delle emergenze a livello di area quando tutti i componenti devono essere sottoposti a failover contemporaneamente. Il diagramma seguente illustra questa topologia. Per garantire la ridondanza geografica, le risorse dell'applicazione vengono distribuite nelle aree A e B. Tuttavia, le risorse nell'area B 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/scrittura <nome-gruppo-failover>.database.windows.net (1). La Gestione traffico di Azure è configurata per usare il metodo di routing per priorità (2).

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

Dopo un'interruzione nell'area primaria, il 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. La Gestione traffico di Azure potrebbe avviare il failover degli endpoint prima che il gruppo di failover attivi 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.

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). La Gestione traffico rileva l'interruzione della connettività all'area B e contrassegna l'endpoint web-app-2 come danneggiato (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.

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.

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

I vantaggi chiave di questo modello di progettazione sono:

• La stessa applicazione Web viene implementata 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 implementata in entrambe le aree e include una connessione all'endpoint listener di lettura/scrittura e una diversa connessione all'endpoint listener di sola lettura (1). Il profilo della Gestione traffico dovrebbe usare il routing per 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:

Quando la Gestione traffico rileva un errore di connettività all'area A, trasferisce automaticamente il traffico utente all'istanza dell'applicazione nell'area B. Con questo criterio, è importante impostare il periodo di tolleranza con 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 iniziano ad avere 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.

In caso di interruzione nell'area B, la Gestione traffico rileva l'errore dell'endpoint web-app-2 nell'area B e lo contrassegna come danneggiato (1). Nel frattempo, il gruppo di failover trasferisce il listener di sola lettura all'area A (2). L'interruzione non influisce sull'esperienza degli utenti finali, ma il database primario viene esposto durante l'interruzione. Il diagramma seguente illustra un errore nell'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 la Gestione traffico rileva l'errore di connettività, che è configurabile.

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

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).

Passaggi successivi

• Per le informazioni generali e gli scenari della continuità aziendale, vedere Continuità aziendale del database SQL di Azure
• Per informazioni sulla replica geografica attiva, vedere Replica geografica attiva.
• Per informazioni sui gruppi di failover, vedere Gruppi di failover.
• Per informazioni sulla replica geografica attiva con i pool elastici, vedere Strategie di ripristino di emergenza per i pool elastici.