Condividi tramite

Panoramica e procedure consigliate per i gruppi di failover - Istanza gestita di SQL di Azure

  • Articolo

Si applica a: Istanza gestita di SQL di Azure SQL

La funzionalità gruppi di failover consente di gestire la replica e il failover di tutti i database utente in un'istanza gestita in un'altra area di Azure. Questo articolo offre una panoramica della funzionalità del gruppo di failover con procedure consigliate e consigli per l'uso con Istanza gestita di SQL di Azure.

Per iniziare a usare la funzionalità, vedere Configurare un gruppo di failover per Istanza gestita di SQL di Azure.

Panoramica

La funzionalità gruppi di failover automatico consente di gestire la replica e il failover di tutti i database utente in un'istanza gestita in un'istanza gestita di un’altra regione di Azure. I gruppi di failover sono progettati per semplificare la distribuzione e la gestione dei database con replica geografica su larga scala.

Per altre informazioni, vedere Disponibilità elevata di Istanza gestita di SQL di Azure. Per i dati RPO e RTO del failover geografico, vedere Panoramica 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à

  • Gruppo di failover (FOG)

    Un gruppo di failover permette a tutti i database dell’utente all’interno di un’istanza gestita di eseguire il fail over come unità in un’altra area di Azure nel caso in cui l’istanza gestita primaria non sia più disponibile a causa di un’interruzione nell’area primaria. Poiché i gruppi di failover per Istanza gestita di SQL contengono tutti i database utente all'interno dell'istanza, è possibile configurare un solo gruppo di failover in un'istanza di .

    Importante

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

  • Server/istanza primaria

    L'istanza gestita che ospita i database primari nel gruppo di failover.

  • Secondario

    L’istanza gestita che ospita i database secondari nel gruppo di failover. Il server secondario non può trovarsi nella stessa area di Azure del server primario.

    Importante

    Se un database contiene oggetti OLTP in memoria, l'istanza della replica geografica primaria e secondaria deve avere livelli di servizio corrispondenti, perché gli oggetti OLTP in memoria risiedono in memoria. Un livello di servizio inferiore nell'istanza di replica geografica può causare problemi di memoria insufficiente. In questo caso, la replica secondaria potrebbe non riuscire a recuperare il database, causando l'indisponibilità del database secondario insieme agli oggetti OLTP in memoria nel database geografico secondario. Questo, a sua volta, potrebbe impedire il failover. Per evitare questo problema, assicurarsi che il livello di servizio dell'istanza geografica secondaria corrisponda a quello del database primario. Gli aggiornamenti del livello di servizio possono essere operazioni di dimensioni dei dati e possono richiedere un po' di tempo.

  • 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 SQL di Azure attende prima di avviare un failover forzato, con conseguente perdita di dati.

  • Zona DNS

    ID univoco generato automaticamente quando viene creato un nuovo Istanza gestita di SQL. Viene effettuato il provisioning di un certificato multi-dominio per questa istanza per autenticare le connessioni client a qualsiasi istanza nella stessa zona DNS. Le due istanze gestite incluse nello stesso gruppo di failover devono condividere la zona DNS.

  • 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’Istanza gestita di SQL, il record CNAME DNS per l'URL del listener viene formato come <fog-name>.<zone_id>.database.windows.net.

  • 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 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’Istanza gestita di SQL, il record CNAME DNS per l'URL del listener viene formato come <fog-name>.secondary.<zone_id>.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.

Architettura del gruppo di failover

Il gruppo di failover deve essere configurato nell'istanza primaria e la connetterà all'istanza secondaria in un'altra area di Azure. Tutti i database dell’utente nell'istanza verranno replicati nell'istanza secondaria. I database di sistema come master e msdb non verranno replicati.

Il diagramma seguente illustra una configurazione tipica di un'applicazione cloud con ridondanza geografica con un'istanza gestita un gruppo di failover:

diagramma di un gruppo di failover per l'istanza gestita di SQL di Azure.

Se l'applicazione usa Istanza gestita come livello dati, seguire le linee guida generali e le procedure consigliate delineate all’interno di questo articolo durante la progettazione per la continuità aziendale.

Creare l'istanza geografica secondaria

Per garantire connettività ininterrotta all'Istanza gestita di SQL primaria dopo il failover, l'istanza primaria e l'istanza secondaria devono essere nella stessa zona DNS. Questa selezione host garantisce che lo stesso certificato multi-dominio possa essere utilizzato per l'autenticazione della connessione client tra una delle due istanze nello stesso gruppo di failover. Quando l'applicazione è pronta per la distribuzione in produzione, creare un'istanza gestita di SQL secondaria in un'area diversa e assicurarsi che condivida la zona DNS con l'istanza gestita di SQL primaria. È possibile farlo specificando un parametro facoltativo durante la creazione. Se si usa PowerShell o l'API REST, il nome del parametro opzionale è DNSZonePartner. Il nome del campo facoltativo corrispondente nel portale di Azure è Istanza gestita primaria.

Importante

La prima istanza gestita creata nella subnet determina la zona DNS per tutte le istanze successive nella stessa subnet. Ciò significa che due istanze della stessa subnet non possono appartenere a zone DNS diverse.

Per altre informazioni sulla creazione dell'istanza gestita di SQL secondaria nella stessa zona DNS dell'istanza primaria, vedere Configurare un gruppo di failover per Istanza gestita di SQL di Azure.

Usare aree associate

Distribuire entrambe le istanze gestite in aree associate per motivi di prestazioni. I gruppi di failover di istanza gestita di SQL nelle aree associate garantiscono prestazioni migliori rispetto alle aree non associate.

Istanza gestita di SQL di Azure segue una procedura di distribuzione sicura in cui le aree abbinate di Azure in genere non vengono distribuite contemporaneamente. Tuttavia, non è possibile prevedere quale area verrà aggiornata per prima, quindi l'ordine di distribuzione non è garantito. In alcuni casi, l'istanza primaria viene aggiornata per prima e talvolta l'istanza secondaria viene aggiornata per prima.

In situazioni in cui Istanza gestita di SQL di Azure fa parte di un gruppo di failover e le istanze nel gruppo non si trovano in aree abbinate di Azure, selezionare diverse pianificazioni della finestra di manutenzione per il database primario e secondario. Ad esempio, selezionare una finestra di manutenzione della settimana per il database geografico secondario e una finestra di manutenzione fine settimana per il database geo-primario.

Abilitare e ottimizzare il flusso del traffico di replica geografica tra le istanze

La connettività tra le subnet della rete virtuale che ospita l'istanza primaria e secondaria deve essere stabilita e mantenuta per il flusso ininterrotto del traffico di replica geografica. Esistono diversi modi per fornire la connettività tra le istanze tra cui è possibile scegliere in base alla topologia di rete e ai criteri:

Il peering di reti virtuali globale è il modo consigliato per stabilire la connettività tra due istanze in un gruppo di failover. Consente di avere una connessione privata a bassa latenza e con larghezza di banda elevata tra le reti virtuali con peering usando l'infrastruttura backbone di Microsoft. Nella comunicazione tra le reti virtuali con peering non sono necessari gateway, la rete Internet pubblica o una crittografia aggiuntiva.

Seeding iniziale

Quando si stabilisce un gruppo di failover tra istanze gestite, è presente una fase di seeding iniziale prima dell'avvio della replica dei dati. La fase iniziale del seeding è la parte più lunga e più costosa dell'operazione. Una volta completato il seeding iniziale, i dati vengono sincronizzati e vengono replicate solo le modifiche ai dati successive. Il tempo necessario per il completamento del seeding iniziale dipende dalle dimensioni dei dati, dal numero di database replicati, dall'intensità del carico di lavoro nei database primari e dalla velocità del collegamento tra le reti virtuali che ospitano istanze primarie e secondarie che dipendono principalmente dal modo in cui viene stabilita la connettività. In circostanze normali e quando viene stabilita la connettività usando il peering di reti virtuali globale consigliato, la velocità di seeding è fino a 360 GB all'ora per Istanza gestita di SQL. Il seeding viene eseguito per un batch di database utente in parallelo, non necessariamente per tutti i database contemporaneamente. Potrebbero essere necessari più batch se sono presenti molti database ospitati nell'istanza.

Se la velocità del collegamento tra le due istanze è più lenta rispetto a quella necessaria, è probabile che il tempo di inizializzazione sia notevolmente influenzato. È possibile usare la velocità di seeding dichiarata, il numero di database, le dimensioni totali dei dati e la velocità di collegamento per stimare il tempo necessario per la fase di seeding iniziale prima dell'avvio della replica dei dati. Ad esempio, per un singolo database da 100 GB, la fase di inizializzazione iniziale richiederà circa 1,2 ore se il collegamento è in grado di eseguire il push di 84 GB all'ora e se non sono presenti altri database di cui viene eseguito il seeding. Se il collegamento può trasferire solo 10 GB all'ora, il seeding di un database da 100 GB può richiedere circa 10 ore. Se sono presenti più database da replicare, il seeding verrà eseguito in parallelo e, in combinazione con una velocità di collegamento lenta, la fase di seeding iniziale potrebbe richiedere molto più tempo, soprattutto se il seeding parallelo dei dati di tutti i database supera la larghezza di banda del collegamento disponibile.

Importante

In caso di collegamento estremamente basso od occupato che causa il timeout della fase iniziale di seeding, la creazione di un gruppo di failover può venire sospesa. Il processo di creazione verrà annullato automaticamente dopo 6 giorni.

Gestire il failover geografico in un'istanza geografica secondaria

Il gruppo di failover gestisce il failover geografico di tutti i database nell’istanza gestita primaria. Quando viene creato un gruppo, ogni database nell'istanza sarà automaticamente sottoposto a replica geografica nell'istanza secondaria. Non è possibile usare gruppi di failover per avviare un failover parziale di un subset dei database.

Importante

Se un database viene rimosso dall'istanza primaria, l'operazione verrà automaticamente riflessa anche nell'istanza gestita geografica secondaria.

Usare il listener di lettura/scrittura (istanza gestita primaria)

Per i carichi di lavoro di lettura/scrittura, usare <fog-name>.zone_id.database.windows.net come nome del server. Le connessioni vengono indirizzate automaticamente al database primario. Questo nome non cambia dopo il failover. Il failover geografico comporta l'aggiornamento del record DNS in modo che le connessioni client vengano indirizzate al nuovo database primario solo dopo l'aggiornamento della cache DNS del client. Poiché l'istanza secondaria condivide la zona DNS con l'istanza primaria, l'applicazione client sarà in grado di riconnettervisi mediante lo stesso certificato SAN del lato server. Le connessioni client esistenti devono essere terminate e quindi ricreate per essere indirizzate al nuovo database primario. Non è possibile raggiungere il listener di sola lettura e il listener di lettura/scrittura tramite l'endpoint pubblico per l'istanza gestita.

Usare il listener di sola lettura (istanza gestita secondaria)

Se sono presenti carichi di lavoro di sola lettura isolati logicamente a tolleranza alla latenza dei dati, è possibile eseguirli nel database geografico secondario. Per connettersi direttamente alla replica geografica secondaria, usare <fog-name>.secondary.<zone_id>.database.windows.net come nome del server.

Nel livello Business critical, l’Istanza gestita di SQL supporta l'uso di repliche di sola lettura per bilanciare i carichi di lavoro di query di sola lettura 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 con replica geografica:

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

Non è possibile raggiungere il listener di sola lettura e il listener di lettura/scrittura tramite l'endpoint pubblico per l'istanza gestita.

Potenziale riduzione delle prestazioni dopo il failover

Un'applicazione Azure tipica usa più servizi di Azure ed è costituita da più componenti. Il failover geografico di un gruppo viene attivato in base allo stato dei componenti di Azure SQL. 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, la latenza tra i componenti dipendenti può aumentare. Assicurarsi che la ridondanza di tutti i componenti dell'applicazione nell'area secondaria e il failover dei componenti dell'applicazione insieme al database in modo che le prestazioni dell'applicazione non siano influenzate dalla latenza tra aree più elevata.

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.

Aggiornamento del DNS

Subito dopo l'avvio del failover si verificherà l'aggiornamento DNS del listener di lettura/scrittura. Questa operazione non comporterà la perdita di dati. Tuttavia, il processo di scambio dei ruoli del database può richiedere fino a 5 minuti in condizioni normali. Durante il processo alcuni database nella nuova istanza primaria rimarranno di sola lettura. Se un failover viene avviato tramite PowerShell, l'operazione per cambiare il ruolo di replica primaria è sincrona. Se viene avviato mediante il portale di Azure, l'interfaccia utente indicherà lo stato di completamento. Se viene avviato mediante l'API REST, usare il meccanismo di polling standard di Azure Resource Manager per il monitoraggio del completamento.

Importante

Usare il failover pianificato manuale per spostare nuovamente il database primario nella posizione originale dopo l'interruzione che ha causato il failover geografico.

Risparmiare sui costi con una replica di ripristino di emergenza senza licenza

È possibile risparmiare sui costi delle licenze di SQL Server configurando l'istanza gestita secondaria da usare solo per il ripristino di emergenza. Per configurare questa impostazione, vedere Configurare una replica standby senza licenza per Istanza gestita di SQL di Azure.

Se l'istanza secondaria non viene usata per i carichi di lavoro di lettura, Microsoft fornisce un numero gratuito di vCore per trovare la corrispondenza con l'istanza primaria. Viene comunque addebitato il costo per la risorsa di calcolo e quella di archiviazione usate dall'istanza secondaria. I gruppi di failover supportano una sola replica: la replica deve essere una replica leggibile o designata come replica di sola ripristino di emergenza.

Abilitare scenari dipendenti da oggetti dai database di sistema

I database di sistema non vengono replicati nell'istanza secondaria in un gruppo di failover. Per abilitare scenari che dipendono dagli oggetti dei database di sistema, assicurarsi di creare gli stessi oggetti nell'istanza secondaria e di mantenerli sincronizzati con l'istanza primaria.

Ad esempio, se si prevede di usare gli stessi account di accesso nell'istanza secondaria, assicurarsi di crearli con lo stesso SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Per altre informazioni, vedere Replica di account di accesso e processi dell'agente.

Sincronizzare le proprietà dell'istanza e le istanze dei criteri di conservazione

Le istanze in un gruppo di failover rimangono risorse di Azure separate e non verranno replicate automaticamente modifiche alla configurazione dell'istanza primaria nell'istanza secondaria. Assicurarsi di eseguire tutte le modifiche rilevanti sia nell'istanza primaria che secondaria. Ad esempio, se si modificano i criteri di ridondanza dell'archivio di backup o di conservazione dei backup a lungo termine nell'istanza primaria, assicurarsi di modificarlo anche nell'istanza secondaria.

Ridimensionamento delle istanze

È possibile aumentare o ridurre le prestazioni dell'istanza primaria e secondaria passando a dimensioni di calcolo diverse all'interno dello stesso livello di servizio o di un livello di servizio diverso. Quando si aumenta all’interno dello stesso livello di servizio, è consigliabile aumentare prima quelle del database secondario geografico e quindi quelle del database primario. Quando si effettua un ridimensionamento nello stesso livello di servizio, invertire l'ordine: ridurre prima le prestazioni del database primario e quindi ridurre le prestazioni di quello secondario. Quando si aumentano/riducono le prestazioni dell'istanza passando a un livello di servizio diverso, viene imposta questa raccomandazione. La sequenza di operazioni viene applicata nell'ambito del ridimensionamento del livello di servizio e vCore, nonché per lo spazio di archiviazione.

Questa sequenza è consigliata specificamente per evitare il problema in cui la replica geografica secondaria nell'SKU di una versione precedente è in rapporto di overload e richiede un nuovo processo di seeding durante la procedura di aggiornamento o downgrade.

Importante

  • Per le istanze all'interno di un gruppo di failover, la modifica del livello di servizio verso o dal livello Utilizzo generico di nuova generazione non è supportata. È necessario eliminare il gruppo di failover prima di modificare una delle repliche e poi ricreare il gruppo di failover dopo l'applicazione della modifica.
  • Si è verificato un problema noto che può influire sull'accessibilità dell'istanza ridimensionata usando il listener del gruppo di failover associato.

Evitare la perdita di dati critici

A causa della latenza elevata delle reti Wide Area Network, per la replica geografica viene usato un meccanismo di replica asincrona. La replica asincrona può comportare la perdita di dati nel caso in cui il database primario abbia esito negativo. Per proteggere questi aggiornamenti critici dalla perdita di dati, uno sviluppatore di applicazioni può richiamare la stored procedure sp_wait_for_database_copy_sync subito dopo il commit della transazione. La chiamata sp_wait_for_database_copy_sync blocca il thread chiamante fino a quando l'ultima transazione sottoposta a commit non viene trasmessa e sottoposta a protezione avanzata nel log delle transazioni del database secondario. Tuttavia, non attende che le transazioni trasmesse vengano riprodotta (eseguite nuovamente) nel database secondario. sp_wait_for_database_copy_sync è limitato a un collegamento di replica geografica specifico. La procedura può essere chiamata da qualsiasi utente che abbia diritti di connessione al database primario.

Per evitare la perdita di dati durante il failover geografico pianificato avviato dall'utente, la replica viene modificata automaticamente e temporaneamente alla replica sincrona, quindi esegue un failover. La replica torna quindi in modalità asincrona dopo il completamento del failover geografico.

Nota

sp_wait_for_database_copy_sync impedisce la perdita di dati dopo il failover geografico per transazioni specifiche, ma non garantisce la sincronizzazione completa per l'accesso in lettura. Il ritardo causato da una chiamata di procedura sp_wait_for_database_copy_sync può essere significativo e dipende dalle dimensioni del log delle transazioni non ancora trasmesso sul primario al momento della chiamata.

Stato del gruppo di failover

Il gruppo di failover segnala lo stato che descrive lo stato corrente della replica dei dati:

  • Seeding: il seeding iniziale viene eseguito dopo la creazione del gruppo di failover, fino a quando non vengono inizializzati tutti i database utente nell'istanza secondaria. Il processo di failover non può essere avviato mentre il gruppo di failover si trova nello stato seeding, perché i database utente non vengono ancora copiati nell'istanza secondaria.
  • Sincronizzazione: stato consueto del gruppo di failover. Ciò significa che le modifiche ai dati nell'istanza primaria vengono replicate in modo asincrono nell'istanza secondaria. Questo stato non garantisce che i dati siano completamente sincronizzati in ogni momento. Possono essere apportate modifiche ai dati dal database primario ancora da replicare al database secondario a causa della natura asincrona del processo di replica tra istanze nel gruppo di failover. I failover automatici e manuali possono essere avviati mentre il gruppo di failover si trova nello stato di sincronizzazione.
  • Failover in corso: questo stato indica che il processo di failover avviato automaticamente o manualmente è in corso. Non è possibile avviare modifiche al gruppo di failover o a failover aggiuntivi mentre il gruppo di failover è in questo stato.

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.

Interoperabilità delle funzionalità

Backup

Nei seguenti scenari viene eseguito un backup completo:

  • Prima dell'avvio del seeding iniziale quando si crea un gruppo di failover.
  • Dopo un failover.

Un backup completo è un'operazione che non può essere ignorata o differita e che può richiedere un certo tempo per essere completata. Il tempo necessario per il completamento dipende dalle dimensioni dei dati, dal numero di database e dall'intensità del carico di lavoro nei database primari. Un backup completo può ritardare notevolmente il seeding iniziale e può ritardare o impedire un'operazione di failover su una nuova istanza poco dopo un failover.

Servizio di riproduzione log

I database migrati all’istanza gestita di SQL di Azure usando il servizio di riproduzione log (LRS) non possono essere aggiunti a un gruppo di failover fino a quando non viene eseguito il passaggio di cutover. Un database migrato con archiviazione con ridondanza locale è in stato di ripristino fino al cutover e i database in stato di ripristino non possono essere aggiunti a un gruppo di failover. Il tentativo di creare un gruppo failover con un database in stato di ripristino ritarda la creazione del gruppo failover fino al completamento del ripristino del database.

Replica transazionale

È supportato l’uso della replica transazionale con istanze incluse in un gruppo di failover. Tuttavia, se si configura la replica prima di aggiungere l'istanza gestita di SQL in un gruppo di failover, la replica viene sospesa quando si inizia a creare il gruppo di failover, e il monitoraggio della replica mostra lo stato di Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. La replica riprende una volta completata la creazione del gruppo di failover.

Se un’istanza gestita di SQL di pubblicazione o distribuzione si trova in un gruppo di failover, l'amministratore dell'istanza gestita di SQL deve pulire tutte le pubblicazioni nel database primario precedente e riconfigurarle nel nuovo database primario dopo che si verifica un failover. Esaminare la guida alla replica transazionale per il passaggio delle attività necessarie in questo scenario.

Autorizzazioni e limitazioni

Prima di configurare un gruppo di failover, controllare l’elenco di autorizzazioni e limitazioni.

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 ulteriori informazioni, vedere configurare i gruppi di failover.

Analisi del ripristino di emergenza

Il modo consigliato per eseguire un drill di ripristino di emergenza consiste nell'usare il failover pianificato manuale, come illustrato nell'esercitazione seguente: Failover di test.

Non è consigliato eseguire un drill usando il failover forzato, perché questa operazione non fornisce protezioni dalla perdita di dati. Tuttavia, è possibile ottenere un failover forzato senza perdita di dati assicurandosi che vengano soddisfatte le condizioni seguenti prima di avviare il failover forzato:

  • Il carico di lavoro viene arrestato nell'istanza gestita primaria.
  • Tutte le transazioni a esecuzione prolungata sono state completate.
  • Tutte le connessioni client all'istanza gestita primaria sono state disconnesse.
  • Lo stato del gruppo di failover è “Sincronizzazione in corso”.

Assicurarsi che le due istanze gestite abbiano cambiato ruoli e che lo stato del gruppo di failover sia passato da "Failover in corso" a "Sincronizzazione in corso" prima di stabilire i collegamenti alla nuova istanza gestita primaria e avviare il carico di lavoro di lettura/scrittura.

Per eseguire un failback senza perdita di dati nei ruoli dell'istanza gestita originale, è fortemente consigliato usare il failover pianificato manuale anziché il failover forzato. Per procedere con il failback forzato:

  • Seguire gli stessi passaggi per il failover senza perdita di dati.
  • È previsto un tempo di esecuzione del failback più lungo se il failback forzato viene eseguito poco dopo il completamento del failover forzato iniziale, perché è necessario attendere il completamento di operazioni di backup automatico in sospeso nell'istanza gestita primaria precedente.

Contenuto correlato