Condividi tramite

Informazioni generali e procedure consigliate per i gruppi di failover - Database SQL di Azure

  • Articolo

Si applica a: Database SQL di Azure

La funzionalità dei gruppi di failover consente di gestire la replica e il failover di alcuni o tutti i database su un server logico a un server logico di un'altra area. Questo articolo offre informazioni generali della funzionalità del gruppo di failover con procedure consigliate e consigli per l'uso con database SQL di Azure.

Per iniziare ad usare la funzionalità, revisionare Configurare il gruppo di failover.

Nota

Questo articolo illustra i gruppi di failover per database SQL di Azure. Per Istanza gestita di SQL di Azure, vedere Gruppi di failover in Istanza gestita di SQL di Azure.

Per altre informazioni sul ripristino di emergenza database SQL di Azure, guardare questo video:

Informazioni generali

La funzionalità gruppi di failover consente di gestire la replica e il failover di tutti i database in un'altra area di Azure. È possibile scegliere tutti o un sottoinsieme di database utente in un server logico da replicare in un altro server logico. Si tratta di un'astrazione dichiarativa oltre alla funzionalità di replica geografica attiva esistente, progettata per semplificare la distribuzione e la gestione dei database con replica geografica su larga scala.

Per RPO di failover geografico e RTO, vedere informazioni generali della continuità aziendale.

Reindirizzamento dell'endpoint

I gruppi di failover offrono endpoint di listener di sola lettura e di sola scrittura che rimangono invariati durante i failover geografici. Non è necessario modificare la stringa di connessione per l'applicazione dopo un failover geografico, perché i collegamenti vengono indirizzati automaticamente al database primario corrente. Un failover geografico passa tutti i database secondari del gruppo al ruolo primario. Dopo aver completato il failover geografico, il record DNS viene automaticamente aggiornato per reindirizzare gli endpoint alla nuova area.

Offload dei carichi di lavoro di sola lettura

Per ridurre il traffico ai database primari, è anche possibile usare i database secondari in un gruppo di failover per eseguire l'offload dei carichi di lavoro di sola lettura. Usare il listener di sola lettura per indirizzare il traffico di sola lettura a un database secondario leggibile.

Ripristino di un'applicazione

Per ottenere una continuità aziendale completa, l'aggiunta di ridondanza dei database di area rappresenta solo una parte della soluzione. Per ripristinare un'applicazione (servizio) end-to-end dopo un problema grave, è necessario effettuare il ripristino di tutti i componenti del servizio e gli eventuali servizi dipendenti. Esempi di questi componenti includono il software client (ad esempio, un browser con JavaScript personalizzato), front-end Web, spazio di archiviazione e DNS. È di importanza cruciale che tutti i componenti siano resilienti agli stessi problemi e diventino disponibili entro l'obiettivo del tempo di ripristino (RTO) dell'applicazione. È perciò necessario identificare tutti i servizi dipendenti e comprendere quali garanzie e funzionalità vengono fornite. È quindi necessario intraprendere le azioni appropriate per assicurare il funzionamento del servizio durante il failover dei servizi da cui dipende.

Criteri di failover

I gruppi di failover supportano due criteri di failover:

  • Gestito dal cliente (scelta consigliata): i clienti possono eseguire un failover di un gruppo quando rilevano un'interruzione imprevista che influisce su uno o più database nel gruppo di failover. Quando si usano strumenti della riga di comando come PowerShell, l'interfaccia della riga di comando di Azure o l'API REST, il valore dei criteri di failover per la gestione del cliente è manual.
  • Gestito da Microsoft: in caso di un'interruzione diffusa che influisce su un'area primaria, Microsoft avvia il failover di tutti i gruppi di failover interessati con i relativi criteri configurati per la gestione da parte di Microsoft. Il failover gestito da Microsoft non verrà avviato per singoli gruppi o per un sottoinsieme di gruppi di failover in un'area. Quando si usano strumenti da riga di comando come PowerShell, l'interfaccia della riga di comando di Azure o l'API REST, il valore dei criteri di failover per Microsoft gestito è automatic.

Ogni criterio di failover ha un set univoco di casi d'uso e le aspettative corrispondenti sull'ambito di failover e sulla perdita di dati, come riepiloga la tabella seguente:

Criteri di failover Ambito di failover Caso d'uso Potenziale perdita di dati
Gestita dal cliente
(consigliato)		 Gruppo/i di failover Uno o più database in uno o più gruppi di failover sono interessati da un'interruzione e diventano non disponibili. È possibile scegliere di effettuare il failover. Sì
Gestita da Microsoft Tutti i gruppi di failover nell'area Un'interruzione diffusa in un data center, una zona di disponibilità o un'area causa l'indisponibilità dei database e il team del servizio SQL di Microsoft Azure decide di attivare un failover forzato.
Usare questa opzione solo quando si vuole delegare la responsabilità del ripristino di emergenza a Microsoft e l'applicazione è tollerante a RTO (tempo inattivo) di almeno un'ora o più.		 Sì

Gestita dal cliente

In rari casi, la disponibilità predefinita o la disponibilità elevata non sono sufficienti per attenuare un'interruzione e i database in un gruppo di failover potrebbero non essere disponibili per una durata non accettabile per il contratto di servizio delle applicazioni che usano i database. I database possono non essere disponibili a causa di un problema localizzato che influisce solo su alcuni database oppure a livello di data center, zona di disponibilità o area. In uno di questi casi, per ripristinare la continuità aziendale, è possibile avviare un failover forzato.

L'impostazione dei criteri di failover sul cliente gestito è altamente consigliata, in quanto consente di controllare quando avviare un failover e ripristinare la continuità aziendale. È possibile avviare un failover quando si nota un'interruzione imprevista che influisce su uno o più database nel gruppo di failover.

Gestita da Microsoft

Con un criterio di failover gestito da Microsoft, la responsabilità del ripristino di emergenza viene delegata al servizio Azure SQL. Affinché il servizio Azure SQL avvii un failover forzato, è necessario soddisfare le condizioni seguenti:

  • Data center, zona di disponibilità o interruzione a livello di area causata da un evento di emergenza naturale, modifiche alla configurazione, bug software o errori dei componenti hardware e molti database nell'area sono interessati.
  • Periodo di tolleranza scaduto. Poiché la verifica della scalabilità e la mitigazione dell'interruzione dipendono dalle azioni umane, il periodo di tolleranza non può essere impostato al di sotto di un'ora.

Quando queste condizioni vengono soddisfatte, il servizio Azure SQL avvia i failover forzati per tutti i gruppi di failover nell'area in cui i criteri di failover sono impostati su Microsoft gestito.

Importante

Usare il criterio di failover gestito dal cliente per sviluppare, testare e implementare i piani di ripristino di emergenza. Non basarsi sul failover gestito da Microsoft, che verrebbe eseguito da Microsoft solo in circostanze estreme. Un failover gestito da Microsoft verrà avviato per tutti i gruppi di failover nell'area con criteri di failover impostati su Microsoft gestito. Non può essere avviato per singoli gruppi di failover. Se è necessaria la possibilità di eseguire il failover selettivo del gruppo di failover, usare il criterio di failover gestito dal cliente.

Impostare i criteri di failover su Microsoft gestiti solo quando:

  • Si vuole delegare la responsabilità del ripristino di emergenza al servizio Azure SQL.
  • L'applicazione è tollerante per il database non disponibile per almeno un'ora o più.
  • È accettabile attivare i failover forzati qualche volta dopo la scadenza del periodo di tolleranza perché il tempo effettivo per il failover forzato può variare in modo significativo.
  • È accettabile che tutti i database all'interno del gruppo di failover eseguano il failover, indipendentemente dalla configurazione della ridondanza della zona o dallo stato di disponibilità. Anche se i database configurati per la ridondanza della zona sono resilienti agli errori di zona e potrebbero non essere interessati da un'interruzione, verranno comunque sottoposti a failover se fanno parte di un gruppo di failover con criteri di failover gestiti da Microsoft.
  • È accettabile avere failover forzati dei database nel gruppo di failover senza prendere in considerazione la dipendenza dell'applicazione da altri servizi o componenti di Azure usati dall'applicazione, che può causare una riduzione del livello delle prestazioni o un'indisponibilità dell'applicazione.
  • È accettabile incorrere in una quantità sconosciuta di perdita di dati, perché l'ora esatta del failover forzato non può essere controllata e ignora lo stato di sincronizzazione dei database secondari.
  • Tutti i database primari e secondari del gruppo di failover e tutte le relazioni di replica geografica hanno lo stesso livello di servizio, lo stesso livello di calcolo (con provisioning o serverless) e la stessa dimensione di calcolo (DTU o vCores). Se l'obiettivo del livello di servizio (SLO) di tutti i database non corrisponde, il criterio di failover verrà aggiornato da Gestito da Microsoft a Gestito dal cliente tramite il servizio Azure SQL.

Quando un failover viene attivato da Microsoft, al log attività di Monitoraggio di Azure viene aggiunta una voce per il nome dell'operazione Failover del gruppo di failover Azure SQL. La voce include il nome del gruppo di failover in Risorsa e l’Evento avviato da visualizza un solo trattino (-) per indicare che il failover è stato avviato da Microsoft. Queste informazioni sono disponibili anche nella pagina Log attività del nuovo server primario o dell'istanza del portale di Azure.

Terminologia e funzionalità

  • Set Failover Group

    Un gruppo di failover è un gruppo denominato di database gestiti da un singolo server logico in Azure che può eseguire il failover come unità in un'altra area di Azure nel caso in cui alcuni o tutti i database primari diventino non disponibili a causa di un'interruzione nell'area primaria.

    Importante

    Il nome del gruppo di failover deve essere univoco a livello globale all'interno del dominio .database.windows.net.

  • Server

    Con i server logici è possibile inserire alcuni o tutti i database utente in un gruppo di failover. Inoltre, un server è in grado di supportare anche più gruppi di failover in un singolo server.

  • Server/istanza primaria

    Il server logico che ospita i database primari nel gruppo di failover.

  • Secondario

    Un server logico che ospita i database secondari nel gruppo di failover. Il server secondario non può trovarsi nella stessa area di Azure del server primario.

  • Failover (nessuna perdita di dati)

    Il failover esegue la sincronizzazione dei dati completa tra il database primario e il database secondario prima che il database secondario passi al ruolo primario. In questo modo si esclude la perdita di dati. Il failover è possibile solo quando il database primario è accessibile. Il failover viene usato negli scenari seguenti:

    • Eseguire esplorazioni per il ripristino di emergenza in produzione quando la perdita di dati non è accettabile
    • Rilocare il carico di lavoro in un'area diversa
    • Restituire il carico di lavoro nell'area primaria dopo la risoluzione dell'interruzione (failback)

  • Failover forzato (potenziale perdita di dati)

    Con il failover forzato il database secondario passa immediatamente al ruolo primario senza dover aspettare che le modifiche recenti si propaghino dal database primario. Questa operazione può comportare la potenziale perdita di dati. Un failover forzato viene usato come metodo di ripristino durante le interruzioni quando non è accessibile il database primario. Quando l'interruzione viene prevenuta, il database primario precedente si riconnette automaticamente e diventa un nuovo database secondario. È possibile eseguire un failover per eseguire il failback, restituendo le repliche ai ruoli primari e secondari originali.

  • Periodo di tolleranza con perdita di dati

    Poiché i dati vengono replicati nel database secondario usando la replica asincrona, il failover forzato dei gruppi con i criteri di failover gestiti da Microsoft può comportare la perdita di dati. È possibile personalizzare i criteri di failover per riflettere la tolleranza dell'applicazione verso la perdita dei dati. Configurando GracePeriodWithDataLossHours, è possibile controllare per quanto tempo il servizio Azure SQL attende prima di avviare un failover forzato, con conseguente perdita di dati.

  • Aggiunta di database singoli al gruppo di failover

    È possibile inserire più database singoli nello stesso server logico all'interno dello stesso gruppo di failover. Se si aggiunge un database singolo al gruppo di failover, viene creato automaticamente un database secondario usando la stessa edizione e le stesse dimensioni di calcolo nel server secondario specificati quanto il gruppo di failover è stato creato. Se si aggiunge un database che ha già un database secondario nel server secondario, tale collegamento della replica geografica viene ereditato dal gruppo. Quando si aggiunge un database che dispone già di un database secondario in un server che non fa parte del gruppo di failover, viene creato un nuovo database secondario nel server secondario.

    Importante

    • Assicurarsi che il server logico secondario non abbia un database con lo stesso nome, a meno che non sia un database secondario esistente.
    • Se un database contiene oggetti OLTP in memoria, il database primario e il database secondario di replica geografica devono avere livelli di servizio corrispondenti, perché gli oggetti OLTP in memoria risiedono in memoria. Un livello di servizio inferiore nel database di replica geografica potrebbe comportare problemi di memoria insufficiente. In questo caso, la replica geografica potrebbe non riuscire a ripristinare il database, causando l'indisponibilità del database secondario insieme agli oggetti OLTP in memoria nel database geografico secondario. Questo, a sua volta, può causare anche errori nei failover. Per evitare questo problema, assicurarsi che il livello di servizio del database secondario geografico corrisponda a quello del database primario. Gli aggiornamenti del livello di servizio possono essere operazioni di dimensionamento dei dati e potrebbero richiedere un po' di tempo.

  • Aggiunta di database nel pool elastico al gruppo di failover

    È possibile inserire tutti o alcuni database all'interno di un pool elastico nello stesso gruppo di failover. Se il database primario si trova in un pool elastico, il database secondario viene creato automaticamente nel pool elastico con lo stesso nome (pool secondario). È necessario assicurarsi che il server secondario contenga un pool elastico con lo stesso identico nome e capacità sufficiente per ospitare i database secondari che verranno creati dal gruppo di failover. Se si aggiunge un database nel pool che ha già un database secondario nel pool secondario, tale collegamento della replica geografica viene ereditato dal gruppo. Quando si aggiunge un database che ha già un database secondario in un server che non fa parte del gruppo di failover, viene creato un nuovo database secondario nel pool secondario.

  • Listener di lettura/scrittura del gruppo di failover

    Un record CNAME DNS che punta all'istanza primaria corrente. Viene creato automaticamente al momento della creazione del gruppo di failover e consente ai carichi di lavoro di lettura-scrittura di riconnettersi in modo trasparente all'istanza primaria quando cambia dopo il failover. Quando il gruppo di failover viene creato in un server, il record CNAME DNS per l'URL del listener viene formato come <fog-name>.database.windows.net. Dopo aver completato il failover, il record DNS viene automaticamente aggiornato per reindirizzare i listener alla nuova istanza primaria.

  • Listener di sola lettura del gruppo di failover

    Un record CNAME DNS che punta all'istanza secondaria corrente. Viene creato automaticamente al momento della creazione del gruppo di failover e consente ai carichi di lavoro SQL di sola lettura di riconnettersi in modo trasparente all'istanza secondaria quando cambia dopo il failover. Quando il gruppo di failover viene creato in un server, il record CNAME DNS per l'URL del listener viene formato come <fog-name>.secondary.database.windows.net. Per impostazione predefinita, il failover del listener di sola lettura è disabilitato perché garantisce che le prestazioni del database primario non siano interessate quando il database secondario è offline. Ciò significa anche che le sessioni di sola lettura non sono in grado di connettersi fino a quando il database secondario non viene recuperato. Se non è possibile consentire alcun tempo inattivo per le sessioni di sola lettura ed è possibile usare il database primario sia per il traffico di sola lettura che per quello di lettura/scrittura a scapito della potenziale riduzione del livello delle prestazioni del database primario, è possibile abilitare il failover per il listener di sola lettura configurando la proprietà AllowReadOnlyFailoverToPrimary. In tal caso il traffico di sola lettura verrà reindirizzato automaticamente al database primario qualora il database secondario non sia disponibile.

    Nota

    La proprietà AllowReadOnlyFailoverToPrimary ha effetto solo se i criteri di failover gestiti da Microsoft sono abilitati e viene attivato un failover forzato. In tal caso, se la proprietà è impostata su True, la nuova replica primaria servirà sia sessioni di lettura/scrittura che di sola lettura.

  • Più gruppi di failover

    È possibile configurare più gruppi di failover per la stessa coppia di server per controllare la scalabilità dei failover geografici. Ogni gruppo esegue il failover in modo indipendente. Se l'applicazione tenant per database usa pool elastici in più aree, è possibile usare questa funzionalità per combinare i database primari e secondari in ogni pool. In questo modo è possibile ridurre l'impatto di un'interruzione solo in alcuni database tenant.

Architettura del gruppo di failover

Un gruppo di failover in database SQL di Azure può includere uno o più database, usati in genere dalla stessa applicazione. Un gruppo di failover automatico deve essere configurato nel Server primario e lo connetterà al server secondario in un'altra area di Azure. I gruppi di failover possono includere alcuni o tutti i database nei server primari. Il diagramma seguente illustra una configurazione tipica di un'applicazione cloud con ridondanza geografica con più database in un gruppo di failover:

Il diagramma illustra una configurazione tipica di un'applicazione cloud con ridondanza geografica che usa più database e un gruppo di failover.

Quando si progetta un servizio tenendo presente la continuità aziendale, seguire le linee guida generali e le procedure consigliate descritte in questo articolo. Quando si configura un gruppo di failover, assicurarsi che l'autenticazione e l'accesso alla rete sul database secondario siano configurati correttamente dopo il failover geografico, quando il database geografico secondario diventa il nuovo database primario. Per tutti i dettagli, vedere l'articolo sulla sicurezza del database SQL di Azure dopo il ripristino di emergenza. Per ulteriori informazioni, consultare Progettazione di soluzioni cloud per il ripristino di emergenza.

Usare aree associate

Quando si crea il gruppo di failover tra il server primario e quello secondario, usare le aree abbinatecome gruppi di failover in aree abbinate con prestazioni migliori rispetto alle aree non abbinate.

Seguendo le procedure di distribuzione sicure, database SQL di Azure in genere non aggiorna le aree abbinate contemporaneamente. Tuttavia, non è possibile prevedere quale area verrà aggiornata per prima, quindi l'ordine di distribuzione non è garantito. In alcuni casi, il server primario viene aggiornato per primo e a volte viene aggiornato successivamente.

Se sono configurati gruppi di replica geografica o di failover per i database che non sono allineati all'associazione di aree di Azure, usare diverse pianificazioni della finestra di manutenzione per i database primari e secondari. Ad esempio, selezionare una finestra di manutenzione Weekday per il database secondario e una finestra di manutenzione Weekend per il database primario.

Inserimento iniziale nel tabellone

Quando si aggiungono database o pool elastici a un gruppo di failover, è presente una fase di inserimento iniziale nel tabellone prima dell'avvio della replica dei dati. La fase iniziale dell'inserimento nel tabellone è l'operazione più lunga e più costosa. Al termine dell'inserimento iniziale nel tabellone, i dati vengono sincronizzati e quindi vengono replicate solo le modifiche ai dati successive. Il tempo necessario per il completamento dell'inserimento iniziale nel tabellone dipende dalle dimensioni dei dati, dal numero di database replicati, dal carico sui database primari e dalla velocità del collegamento di rete tra il database primario e quello secondario. In circostanze normali, la velocità di inserimento nel tabellone possibile è fino a 500 GB all'ora per database SQL. Il seeding viene eseguito per tutti i database in parallelo.

Numero di database in un gruppo di failover

Il numero di database all'interno di un gruppo di failover influisce direttamente sulla durata delle operazioni di failover e failover forzato.

  • Durante un failover (noto anche come failover pianificato), si garantisce che tutti i database primari siano completamente sincronizzati con il database secondario e raggiungano uno stato di prontezza. Per evitare di sovraccaricare il piano di controllo, i database vengono preparati in batch. È pertanto consigliabile limitare il numero di database in un gruppo di failover.
  • Nel caso di un failover forzato, la fase di preparazione viene accelerata perché la sincronizzazione dei dati non viene avviata. Per ottenere durate di failover più rapide e prevedibili, può essere utile mantenere il numero di database nel gruppo di failover a un numero minore.

Usare più gruppi di failover per eseguire il failover di più database

È possibile creare uno o più gruppi di failover tra due server in aree diverse (server primario e secondario). Ogni gruppo può includere uno o più database che vengono ripristinati come unità nel caso in cui tutti o alcuni database primari diventino non disponibili a causa di un'interruzione nell'area primaria. Impostare un gruppo di failover crea un database geografico secondario con lo stesso obiettivo di servizio di quello primario. Se si aggiunge una relazione di replica geografica esistente al gruppo di failover, verificare che il database di replica geografica secondario sia configurato con lo stesso livello di servizio e le stesse dimensioni di calcolo del database primario.

Usare il listener in lettura/scrittura (primario)

Per i carichi di lavoro di lettura/scrittura, usare <fog-name>.database.windows.net come nome del server nella stringa di connessione. Le connessioni vengono indirizzate automaticamente al database primario. Questo nome non cambia dopo il failover. Si noti che il failover comporta l'aggiornamento del record DNS in modo che le connessioni client vengano reindirizzate al nuovo database primario solo dopo l'aggiornamento della cache DNS del client. Il TTL del record DNS del listener primario e secondario è di 30 secondi.

Usare il listener di sola lettura (secondario)

Se sono presenti carichi di lavoro di sola lettura isolati logicamente con tolleranza alla latenza dei dati, è possibile eseguirli nel database geografico secondario. Per le sessioni di lettura, usare <fog-name>.secondary.database.windows.net come nome del server nella stringa di connessione. I collegamenti verranno indirizzati automaticamente al database geografico secondario. È consigliabile anche indicare l’intento di lettura nella stringa di connessione usando ApplicationIntent=ReadOnly.

Nei livelli di servizio Premium, Business Critical e Hyperscale, il database SQL supporta l'uso di repliche di sola lettura per bilanciare i carichi di lavoro di query di sola lettura usando il parametro ApplicationIntent=ReadOnly nella stringa di connessione. Dopo aver configurato un database secondario con replica geografica, sarà possibile usare questa funzionalità per connettersi a una replica di sola lettura nella posizione primaria o nella posizione secondaria con replica geografica:

Per connettersi a una replica di sola lettura nella posizione secondaria, usare ApplicationIntent=ReadOnly e <fog-name>.secondary.database.windows.net.

Potenziale riduzione delle prestazioni dopo il failover

Un'applicazione Azure tipica usa più servizi di Azure ed è costituita da più componenti. Il failover di un gruppo viene attivato in base allo stato di database SQL di Azure solo. Altri servizi di Azure nell'area primaria potrebbero non essere interessati dall'interruzione e i relativi componenti potrebbero essere ancora disponibili in tale area. Quando i database primari passano all'area secondaria (Ripristino di emergenza), la latenza tra i componenti dipendenti può aumentare. Per evitare l'impatto di una latenza più elevata sulle prestazioni dell'applicazione, verificare la ridondanza di tutti i componenti dell'applicazione nell'area di ripristino di emergenza, seguire queste linee guida per la sicurezza di rete e orchestrare il failover geografico dei componenti dell'applicazione pertinenti insieme al database.

Potenziale perdita di dati dopo il failover forzato

Se si verifica un'interruzione nell'area primaria, le transazioni recenti potrebbero non essere state replicate nella replica geografica secondaria e potrebbero verificarsi perdite di dati se viene eseguito un failover forzato.

Importante

I pool elastici con 800 o meno DTU o 8 o meno vCore e più di 250 database possono riscontrare problemi quali failover geografici pianificati più lunghi e una riduzione delle prestazioni. Questi problemi si verificano con maggiore probabilità nella scrittura di carichi di lavoro con utilizzo intensivo, quando gli endpoint con replica geografica sono ampiamente separati per area geografica o quando vengono utilizzati più endpoint secondari per ogni database. Un sintomo di questi problemi è un aumento del ritardo della replica geografica nel tempo, che può potenzialmente causare una perdita di dati più estesa in un'interruzione. Questo ritardo può essere monitorato mediante sys.dm_geo_replication_link_status. Se si riscontrano tali problemi, allora la mitigazione di questo problema include il ridimensionamento del pool per aumentare DTU o vCore o la riduzione del numero di database con replica geografica nel pool.

Failback

Quando i gruppi di failover vengono configurati con criteri di failover gestiti da Microsoft, il failover forzato nel server secondario geografico viene avviato durante uno scenario di emergenza in base al periodo di tolleranza definito. Il failback nel database primario precedente deve essere avviato manualmente.

Autorizzazioni e limitazioni

Per un elenco di autorizzazioni e limitazioni, vedere la guida alla configurazione del gruppo di failover.

Gestione programmatica di gruppi di failover

I gruppi di failover possono anche essere gestiti a livello di codice usando Azure PowerShell, l'interfaccia della riga di comando di Azure e l'API REST. Per altre informazioni, vedere Configurare un gruppo di failover.

Contenuto correlato