Configurare un gruppo di failover automatico per Istanza gestita di SQL di Azure

Si applica a: Istanza gestita di SQL di Azure

Questo articolo illustra come configurare un gruppo di failover automatico per Istanza gestita di SQL di Azure usando il portale di Azure e il Azure PowerShell. Per un'esperienza end-to-end, vedere l'esercitazione sul gruppo di failover automatico.

Nota

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

Prerequisiti

Prendere in considerazione i prerequisiti seguenti:

  • L'istanza gestita secondaria deve essere vuota, ovvero non contiene database utente.
  • Le due istanze di Istanza gestita di SQL devono trovarsi nello stesso livello di servizio e avere le stesse dimensioni di archiviazione. Sebbene non sia necessario, è consigliabile che due istanze abbiano dimensioni di calcolo uguali, per assicurarsi che l'istanza secondaria possa elaborare in modo sostenibile le modifiche replicate dall'istanza primaria, inclusi i periodi di attività di picco.
  • Gli intervalli di indirizzi IP della rete virtuale che ospitano l'istanza primaria non devono sovrapporsi agli intervalli di indirizzi IP della rete virtuale che ospita l'istanza secondaria.
  • Le regole NSG (Network Security Groups) nell'istanza di hosting della subnet devono avere la porta 5022 (TCP) e l'intervallo di porte 11000-11999 (TCP) aperto in ingresso e in uscita per le connessioni da e verso la subnet che ospita l'altra istanza gestita. Questo vale per entrambe le subnet, l'hosting di istanze primarie e secondarie.
  • Il Istanza gestita di SQL secondario viene configurato durante la creazione con l'ID della zona DNS corretto. Viene eseguita passando l'ID zona dell'istanza primaria come valore del parametro DnsZonePartner durante la creazione dell'istanza secondaria. Se non viene passato come parametro, l'ID zona viene generato come stringa casuale quando la prima istanza viene creata in ogni rete virtuale e lo stesso ID viene assegnato a tutte le altre istanze della stessa subnet. Una volta assegnata, la zona DNS non può essere modificata.
  • Le regole di confronto e il fuso orario dell'istanza gestita secondaria devono corrispondere a quella dell'istanza gestita primaria.
  • Le istanze gestite devono essere distribuite in aree associate per motivi di prestazioni. Le istanze gestite che risiedono in aree geografiche con associazione geografica offrono una velocità di replica geografica significativamente superiore rispetto alle aree non abbinate.

Abilitazione della connettività tra le istanze

La connettività tra le subnet di rete virtuale che ospitano l'istanza primaria e secondaria deve essere stabilita per il flusso di traffico di replica geografica senza interruzioni. Il peering di rete virtuale globale è consigliato come modo più efficiente e affidabile per stabilire la connettività. Fornisce una connessione privata a bassa latenza e larghezza di banda elevata tra le reti virtuali con peering usando l'infrastruttura backbone Microsoft. Non è necessaria alcuna crittografia internet, gateway o crittografia aggiuntiva nella comunicazione tra le reti virtuali con peering. Per informazioni sui modi alternativi per stabilire la connettività, vedere Abilitazione del traffico di replica tra istanze.

Importante

Modi alternativi per fornire la connettività tra le istanze che coinvolgono dispositivi di rete aggiuntivi possono rendere il processo di risoluzione dei problemi di connettività o velocità di replica molto difficili e richiedere il coinvolgimento attivo degli amministratori di rete e prolungare significativamente il tempo di risoluzione.

  1. Nella portale di Azure passare alla risorsa di rete virtuale per l'istanza gestita primaria.
  2. Selezionare Peering inImpostazioni e quindi selezionare + Aggiungi.

Screenshot della pagina peering per la rete virtuale

  1. Immettere o selezionare i valori per le impostazioni seguenti:

    Impostazioni Descrizione
    Questa rete virtuale
    Nome del collegamento di peering il nome per il peering deve essere univoco all'interno della rete virtuale.
    Traffico verso la rete virtuale remota Selezionare Consenti (impostazione predefinita) per abilitare la comunicazione tra le due reti virtuali tramite il flusso predefinito VirtualNetwork . L'abilitazione della comunicazione tra reti virtuali consente alle risorse connesse a una rete virtuale di comunicare tra loro con la stessa larghezza di banda e latenza come se fossero connesse alla stessa rete virtuale. Tutte le comunicazioni tra le risorse nelle due reti virtuali avvengono tramite la rete privata di Azure.
    Traffico inoltrato dalla rete virtuale remota L'opzione Consenti (impostazione predefinita) e Blocca funzionerà per questa esercitazione. Per altre informazioni, vedere Creare un peering
    Gateway di rete virtuale o server di route Selezionare Nessuno. Per altre informazioni sulle altre opzioni disponibili, vedere Creare un peering.
    Rete virtuale remota
    Nome del collegamento di peering Nome dello stesso peering da usare nell'istanza secondaria della rete virtuale.
    Modello di distribuzione della rete virtuale Selezionare Gestione risorse.
    Conosco l'ID della risorsa Lasciare deselezionata questa casella di controllo.
    Subscription Selezionare la sottoscrizione di Azure della rete virtuale che ospita l'istanza secondaria con cui si vuole eseguire il peering.
    Rete virtuale Selezionare la rete virtuale che ospita l'istanza secondaria con cui si vuole eseguire il peering. Se la rete virtuale è elencata, ma disattivata, potrebbe essere perché lo spazio indirizzi per la rete virtuale si sovrappone allo spazio indirizzi per questa rete virtuale. Se gli spazi indirizzi delle reti virtuali si sovrappongono, non è possibile eseguire il peering.
    Traffico verso la rete virtuale remota Selezionare Consenti (impostazione predefinita)
    Traffico inoltrato dalla rete virtuale remota L'opzione Consenti (impostazione predefinita) e Blocca funzionerà per questa esercitazione. Per altre informazioni, vedere Creare un peering.
    Gateway di rete virtuale o server di route Selezionare Nessuno. Per altre informazioni sulle altre opzioni disponibili, vedere Creare un peering.
  2. Selezionare Aggiungi per configurare il peering con la rete virtuale selezionata. Dopo alcuni secondi, selezionare il pulsante Aggiorna e lo stato del peering cambierà da Aggiornamento a Connesso.

    Stato del peering di rete virtuale nella pagina peering

Creare il gruppo di failover

Creare il gruppo di failover per le istanze gestite usando il portale di Azure o PowerShell.

Creare il gruppo di failover per le istanze gestite da SQL usando il portale di Azure.

  1. Selezionare Azure SQL nel menu a sinistra nel portale di Azure. Se Azure SQL non è presente nell'elenco, selezionare Tutti i servizi e digitare Azure SQL nella casella di ricerca. (Facoltativo) Selezionare la stella accanto a Azure SQL per aggiungerla come elemento preferito alla navigazione a sinistra.

  2. Selezionare l'istanza gestita primaria da aggiungere al gruppo di failover.

  3. In Impostazioni passare a Gruppi di failover dell'istanza e quindi scegliere Aggiungi gruppo per aprire la pagina di creazione del gruppo di failover dell'istanza.

    Aggiungere un gruppo di failover

  4. Nella pagina Gruppo di failover dell'istanza digitare il nome del gruppo di failover e quindi scegliere l'istanza gestita secondaria dall'elenco a discesa. Fare clic su Crea per creare il gruppo di failover.

    Create failover group

  5. Al termine della distribuzione del gruppo di failover, verrà eseguito il ripristino nella pagina Gruppo di failover .

Failover di test

Testare il failover del gruppo di failover usando il portale di Azure o PowerShell.

Testare il failover del gruppo di failover con il portale di Azure.

  1. Passare all'istanza gestita secondaria con il portale di Azure e selezionare Gruppi di failover dell'istanza nelle impostazioni.

  2. Prendere nota delle istanze gestite nel ruolo primario e nel ruolo secondario.

  3. Selezionare Failover e quindi selezionare nell'avviso relativo alla disconnessione delle sessioni TDS.

    Eseguire il failover del gruppo di failover

  4. Prendere nota delle istanze gestite nel ruolo primario e nel ruolo secondario. Se il failover è riuscito, le due istanze dovrebbero essersi scambiate i ruoli.

    Le istanze gestite si sono scambiate i ruoli dopo il failover

Importante

Se i ruoli non sono cambiati, controllare la connettività tra le istanze e le regole del gruppo di sicurezza di rete e del firewall correlate. Procedere con il passaggio successivo solo dopo l'opzione ruoli.

  1. Passare alla nuova istanza gestita secondaria e selezionare Failover ancora una volta per eseguire il failback dell'istanza primaria al ruolo primario.

Individuare l'endpoint del listener

Dopo aver configurato il gruppo di failover, aggiornare la stringa di connessione per l'applicazione all'endpoint del listener. Mantiene l'applicazione connessa al listener del gruppo di failover, anziché al database primario, al pool elastico o al database dell'istanza. In questo modo, non è necessario aggiornare manualmente la stringa di connessione ogni volta che l'entità di database ha esito negativo e il traffico viene instradato a qualsiasi entità attualmente primaria.

L'endpoint del listener è sotto forma di e è visibile nella portale di Azure, quando si visualizza il gruppo di fog-name.database.windows.netfailover:

Stringa di connessione del gruppo di failover

Creare un gruppo tra istanze in sottoscrizioni diverse

È possibile creare un gruppo di failover tra istanze gestite di SQL in due sottoscrizioni diverse, purché le sottoscrizioni siano associate allo stesso tenant di Azure Active Directory. Quando si usa l'API PowerShell, è possibile eseguirla specificando il parametro per la PartnerSubscriptionId Istanza gestita di SQL secondaria. Quando si usa l'API REST, ogni ID istanza incluso nel properties.managedInstancePairs parametro può avere il proprio ID sottoscrizione.

Importante

portale di Azure non supporta la creazione di gruppi di failover tra sottoscrizioni diverse. Inoltre, per i gruppi di failover esistenti in sottoscrizioni e/o gruppi di risorse diversi, il failover non può essere avviato manualmente tramite il portale dal Istanza gestita di SQL primario. È quindi necessario avviarlo dall'istanza geografica secondaria.

Modificare l'area secondaria

Si supponga che l'istanza A sia l'istanza primaria, l'istanza B sia l'istanza secondaria esistente e L'istanza C sia la nuova istanza secondaria nella terza area. Per eseguire la transizione, seguire questa procedura:

  1. Creare l'istanza C con le stesse dimensioni di A e nella stessa zona DNS.
  2. Eliminare il gruppo di failover tra istanze A e B. A questo punto, gli account di accesso avranno esito negativo perché gli alias SQL per i listener del gruppo di failover sono stati eliminati e il gateway non riconoscerà il nome del gruppo di failover. I database secondari verranno disconnessi dalle primarie e diventeranno database di lettura-scrittura.
  3. Creare un gruppo di failover con lo stesso nome tra istanza A e C. Seguire le istruzioni nel gruppo di failover con Istanza gestita di SQL esercitazione. Si tratta di un'operazione di dimensioni dei dati e verrà completata quando tutti i database dell'istanza A vengono inizializzato e sincronizzato.
  4. Eliminare l'istanza B se non necessario per evitare addebiti non necessari.

Nota

Dopo il passaggio 2 e fino al passaggio 3 i database nell'istanza A rimarranno non protetti da un errore irreversibile dell'istanza A.

Modificare l'area primaria

Si supponga che L'istanza A sia l'istanza primaria, l'istanza B sia l'istanza secondaria esistente e L'istanza C sia la nuova istanza primaria nella terza area. Per eseguire la transizione, seguire questa procedura:

  1. Creare l'istanza C con le stesse dimensioni di B e nella stessa zona DNS.
  2. Connettersi all'istanza B e eseguire manualmente il failover per passare l'istanza primaria a B. Istanza A diventerà automaticamente la nuova istanza secondaria.
  3. Eliminare il gruppo di failover tra istanze A e B. A questo punto, i tentativi di accesso tramite gli endpoint del gruppo di failover avranno esito negativo. I database secondari in A verranno disconnessi dalle primarie e diventeranno database di lettura-scrittura.
  4. Creare un gruppo di failover con lo stesso nome tra istanza B e C. Seguire le istruzioni nel gruppo di failover con l'esercitazione sull'istanza gestita. Si tratta di un'operazione di dimensioni dei dati e verrà completata quando tutti i database dell'istanza A vengono inizializzato e sincronizzato. A questo punto i tentativi di accesso non riusciranno.
  5. Failover manuale per passare l'istanza C al ruolo primario. Istanza B diventerà automaticamente la nuova istanza secondaria.
  6. Eliminare istanza A se non necessario per evitare addebiti non necessari.

Attenzione

Dopo il passaggio 3 e fino al passaggio 4 i database nell'istanza A rimarranno non protetti da un errore irreversibile dell'istanza A.

Importante

Quando il gruppo di failover viene eliminato, vengono eliminati anche i record DNS per gli endpoint del listener. A questo punto, esiste una probabilità non zero di qualcun altro che crea un gruppo di failover con lo stesso nome. Poiché i nomi dei gruppi di failover devono essere univoci a livello globale, questo impedisce di usare di nuovo lo stesso nome. Per ridurre al minimo questo rischio, non usare nomi di gruppo di failover generici.

Autorizzazioni

Le autorizzazioni per un gruppo di failover vengono gestite tramite il controllo degli accessi in base al ruolo di Azure (Controllo degli accessi in base al ruolo) di Azure.

L'accesso in scrittura degli accessi in base al ruolo di Azure è necessario per creare e gestire i gruppi di failover. Il ruolo collaboratore Istanza gestita di SQL dispone di tutte le autorizzazioni necessarie per gestire i gruppi di failover.

Nella tabella seguente sono elencati ambiti di autorizzazione specifici per Istanza gestita di SQL di Azure:

Azione Autorizzazione Ambito
Create failover group Accesso in scrittura degli accessi in base al ruolo di Azure Istanza gestita primaria Istanza
gestita Secondaria
Aggiornare il gruppo di failover Accesso in scrittura degli accessi in base al ruolo di Azure Gruppo
di failover Tutti i database all'interno dell'istanza gestita
Failover del gruppo di failover Accesso in scrittura degli accessi in base al ruolo di Azure Gruppo di failover in una nuova istanza gestita primaria

Passaggi successivi

Per informazioni dettagliate sulla configurazione di un gruppo di failover, vedere l'esercitazione Aggiungere un'istanza gestita a un gruppo di failover

Per una panoramica della funzionalità, vedere Gruppi di failover automatico.