Configurare un gruppo di failover per l'istanza gestita di SQL di Azure

Articolo
08/19/2024

Si applica a: Istanza gestita di SQL di Azure SQL

Questo articolo illustra come configurare un gruppo di failover per Istanza gestita di SQL di Azure usando il portale di Azure e Azure PowerShell.

Per uno script PowerShell end-to-end che crei entrambe le istanze all'interno di un gruppo di failover, consultare Aggiungere un'istanza a un gruppo di failover con PowerShell.

Prerequisiti

Per configurare un gruppo di failover, è necessario avere già un'istanza gestita di SQL che si intende usare come primaria. Per iniziare, vedere Crea istanza.

Requisiti di configurazione

Per configurare un gruppo di failover tra un'istanza gestita SQL primaria e una secondaria, considerare i seguenti requisiti:

L'istanza gestita secondaria deve essere vuota, ovvero non contenere database utente.
Le due istanze devono avere lo stesso livello di servizio e le stesse dimensioni di archiviazione. Sebbene non sia obbligatorio, è fortemente consigliato che entrambe le istanze abbiano le stesse dimensioni di calcolo, per garantire che l'istanza secondaria possa elaborare in modo sostenibile le modifiche replicate dall'istanza primaria, anche durante i periodi di attività di picco.
L’intervallo di indirizzi IP per la rete virtuale dell'istanza primaria non deve sovrapporsi all'intervallo di indirizzi della rete virtuale per l'istanza gestita secondaria o a qualsiasi altra rete virtuale con peering con la rete virtuale primaria o secondaria.
Entrambe le istanze devono trovarsi nella stessa zona DNS. Quando si crea l'istanza gestita secondaria, è necessario specificare l'ID della zona DNS dell'istanza primaria. In caso contrario, l'ID della zona viene generato come stringa casuale quando viene creata la prima istanza in ogni rete virtuale e lo stesso ID viene assegnato a tutte le altre istanze nella stessa subnet. Dopo l'assegnazione, la zona DNS non può essere modificata.
Le regole dei gruppi di sicurezza di rete (NSG) per le subnet di entrambe le istanze devono avere connessioni TCP in ingresso e in uscita aperte per la porta 5022 e l'intervallo di porte 11000-11999 per facilitare la comunicazione tra le due istanze.
Le istanze gestite dovrebbero essere implementate in aree associate per motivi di prestazioni. Le istanze gestite che risiedono in aree geografiche abbinate beneficiano di una velocità di replica geografica significativamente più elevata rispetto alle aree non abbinate.
Entrambe le istanze devono usare gli stessi criteri di aggiornamento.

Creare l'istanza secondaria

Quando si crea l'istanza secondaria, è necessario utilizzare una rete virtuale con uno spazio di indirizzi IP che non si sovrapponga all'intervallo di spazi di indirizzi IP dell'istanza primaria. Inoltre, quando si configura la nuova istanza secondaria, è necessario specificare l'ID dell zona dell'istanza primaria.

È possibile configurare la rete virtuale secondaria e creare l'istanza secondaria usando il portale di Azure e PowerShell.

Azure portal
PowerShell

Creare una rete virtuale

Per creare una rete virtuale per l'istanza secondaria nel portale di Azure, procedere come segue:

Controllare lo spazio indirizzi per l'istanza primaria. Accedere alla risorsa di rete virtuale per l'istanza primaria nel portale di Azure e in Impostazioni selezionare Spazio indirizzi. Controllare l'intervallo in Intervallo di indirizzi:
Creare una nuova rete virtuale che si prevede di usare per l'istanza secondaria passando alla pagina Crea rete virtuale.
Nella scheda Informazioni di base della pagina Crea rete virtuale:
1. Selezionare il gruppo di risorse che si intende usare per l'istanza secondaria. Crearne uno nuovo se non esiste ancora.
2. Specificare un nome per la rete virtuale, ad esempio vnet-sql-mi-secondary.
3. Selezionare un'area abbinata all'area in cui si trova l'istanza primaria.
Nella scheda Indirizzi IP della pagina Crea rete virtuale:
1. Usare Elimina spazio indirizzi per eliminare lo spazio indirizzi IPv4 esistente.
2. Dopo l'eliminazione dello spazio indirizzi, selezionare Aggiungi spazio indirizzi IPv4 per aggiungere un nuovo spazio e quindi specificare uno spazio indirizzi IP diverso dallo spazio indirizzi usato dalla rete virtuale dell'istanza primaria. Ad esempio, se l'istanza primaria corrente usa uno spazio indirizzi 10.0.0.16, immettere 10.1.0.0/16 per lo spazio indirizzi della rete virtuale che si intende usare per l'istanza secondaria.
3. Usare + Aggiungi una subnet per aggiungere una subnet predefinita con valori predefiniti.
4. Usare + Aggiungi una subnet per aggiungere una subnet vuota denominata ManagedInstance che verrà dedicata all'istanza secondaria, usando un intervallo di indirizzi diverso dalla subnet predefinita. Ad esempio, se l'istanza primaria usa un intervallo di indirizzi compreso tra 10.0.0.0 e 10.0.255.255, specificare un intervallo di subnet di 10.1.1.0 - 10.1.1.255 per la subnet dell'istanza secondaria.
Selezionare Rivedi e crea per verificare le impostazioni e quindi selezionare Crea per creare la nuova rete virtuale.

Creare un'istanza secondaria

Una volta che la rete virtuale è pronta, seguire questa procedura per creare l'istanza secondaria nel portale di Azure:

Accedere a Crea istanza gestita di SQL di Azure nel portale di Azure.
Nella scheda Dati generali della pagina Crea Istanza gestita di SQL di Azure:
1. Scegliere un'area per l'istanza secondaria abbinata all'istanza primaria.
2. Scegliere un livello di servizio corrispondente al livello di servizio dell'istanza primaria.
Nella scheda Rete della pagina Crea Istanza gestita di SQL di Azure usare l'elenco a discesa in Rete virtuale/subnet per selezionare la rete virtuale e la subnet create in precedenza:
Nella scheda Impostazioni aggiuntive della pagina Crea Istanza gestita di SQL di Azure selezionare Sì per Usa come istanza secondaria di failover e quindi scegliere l'istanza primaria appropriata dall'elenco a discesa.
Configurare il resto dell'istanza in base alle esigenze aziendali e quindi crearla usando Rivedi e crea.

È possibile creare sia la rete virtuale che l'istanza secondaria usando PowerShell. Per un esempio di script di PowerShell completo che esegue entrambe le operazioni, vedere Aggiungere un'istanza al gruppo di failover con PowerShell.

Se si sta creando l'istanza secondaria con Azure PowerShell, assicurarsi di specificare il valore DnsZonePartner con l'ID zona dell'istanza primaria.

È possibile usare il comando Get-AzSqlInstance per parametrizzare l'ID zona DNS dell'istanza primaria e quindi passarlo al DnsZonePartner parametro del comando New-AzSqlInstance:

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

Stabilire la connettività tra le istanze

Per un flusso ininterrotto del traffico di replica geografica, è necessario stabilire la connettività tra le subnet della rete virtuale che ospitano le istanze primaria e secondaria. Esistono diversi modi per connettere istanze gestite in aree di Azure diverse, tra cui:

Il peering di reti virtuali globale è il metodo consigliato più solido e performante per stabilire la connettività tra due istanze in un gruppo di failover. Il peering di reti virtuali globale 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.

Importante

I modi alternativi di connessione delle istanze che coinvolgono dispositivi di rete aggiuntivi potrebbero complicare la risoluzione dei problemi di connettività o velocità di replica, eventualmente richiedendo un coinvolgimento attivo degli amministratori di rete e prolungando in modo significativo i tempi di risoluzione.

Se si utilizza un meccanismo per stabilire la connettività tra le istanze diverso dal peering di reti virtuali globale consigliato, assicurarsi di quanto segue:

I dispositivi di rete, come firewall o appliance virtuali di rete, non bloccano il traffico sulle connessioni in ingresso e in uscita per la porta 5022 (TCP) e l'intervallo di porte 11000-11999.
Il routing è configurato correttamente e il routing asimmetrico viene evitato.
Se si distribuiscono gruppi di failover in una topologia di rete hub-and-spoke tra aree diverse, per evitare problemi di connettività e velocità di replica, il traffico di replica deve transitare direttamente tra le due subnet dell'istanza gestita anziché essere indirizzato attraverso le reti hub.

Questo articolo illustra come configurare il peering di reti virtuali globale tra le reti delle due istanze usando il portale di Azure e PowerShell.

Azure portal
PowerShell

Nel portale di Azure passare alla risorsa Rete virtuale per l'istanza gestita primaria.
Selezionare Peering in Impostazioni per aprire la pagina Peering e quindi usare + Aggiungi dalla barra dei comandi per aprire la pagina Aggiungi peering.

Nella pagina Aggiungi peering, immettere o selezionare i valori per le impostazioni seguenti:

Impostazioni	Descrizione
Riepilogo della rete virtuale remota
Nome del collegamento di peering	il nome per il peering deve essere univoco all'interno della rete virtuale. Questo articolo usa `Fog-peering`.
Modello di distribuzione della rete virtuale	Seleziona Gestione risorse.
Conosco l'ID della risorsa	È possibile lasciare deselezionata questa casella, a meno che non si conosca l'ID della risorsa.
Abbonamento	Selezionare la sottoscrizione dall'elenco a discesa.
Rete virtuale	Selezionare la rete virtuale per l'istanza secondaria dall'elenco a discesa.
Impostazioni del peering di reti virtuali remoto
Consentire alla "rete virtuale secondaria" di accedere alla "rete virtuale primaria"	Selezionare la casella per consentire la comunicazione tra le due reti. L'abilitazione della comunicazione tra reti virtuali consente alle risorse connesse a una o all'altra delle reti virtuali di comunicare tra loro con la stessa larghezza di banda e latenza che userebbero se fossero connesse alla stessa rete virtuale. Tutte le comunicazioni tra le risorse nelle due reti virtuali avvengono tramite la rete privata di Azure.
Consentire alla "rete virtuale secondaria" di ricevere traffico inoltrato dalla "rete virtuale primaria"	Ai fini della presente guida, è possibile selezionare o deselezionare questa casella. Per altre informazioni, vedere Creare un peering.
Consentire al gateway o al server di route nella "rete virtuale secondaria" di inoltrare il traffico alla "rete virtuale primaria"	Ai fini della presente guida, è possibile selezionare o deselezionare questa casella. Per altre informazioni, vedere Creare un peering.
Abilitare la "rete virtuale secondaria" per usare il gateway remoto o il server di route della "rete virtuale primaria"	Lasciare questa casella deselezionata. Per altre informazioni sulle altre opzioni disponibili, vedere Creare un peering.
Riepilogo della rete virtuale locale
Nome del collegamento di peering	Nome dello stesso peering utilizzato per la rete virtuale remota. Questo articolo usa `Fog-peering`.
Consentire alla "rete virtuale primaria" di accedere alla "rete virtuale secondaria"	Selezionare la casella per consentire la comunicazione tra le due reti. L'abilitazione della comunicazione tra reti virtuali consente alle risorse connesse a una o all'altra delle reti virtuali di comunicare tra loro con la stessa larghezza di banda e latenza che userebbero se fossero connesse alla stessa rete virtuale. Tutte le comunicazioni tra le risorse nelle due reti virtuali avvengono tramite la rete privata di Azure.
Consentire alla "rete virtuale primaria" di ricevere traffico inoltrato da "rete virtuale secondaria"	Ai fini della presente guida, è possibile selezionare o deselezionare questa casella. Per altre informazioni, vedere Creare un peering.
Consentire al gateway o al server di route nella "rete virtuale primaria" di inoltrare il traffico alla "rete virtuale secondaria"	Ai fini della presente guida, è possibile selezionare o deselezionare questa casella. Per altre informazioni, vedere Creare un peering.
Abilitare la "rete virtuale primaria" per usare il gateway remoto o il server di route della "rete virtuale secondaria"	Lasciare questa casella deselezionata. Per altre informazioni sulle altre opzioni disponibili, vedere Creare un peering.

Usare Aggiungi per configurare il peering con la rete virtuale selezionata e tornare automaticamente alla pagina Peering, che mostra che le due reti sono connesse:

Configurare il peering di reti virtuali globali tra le reti virtuali delle istanze gestite primarie e secondarie:


# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

Questo frammento di codice usa i comandi seguenti:

Comando	Note
1. Get-AzVirtualNetwork	Ottiene una rete virtuale in un gruppo di risorse.
2. Add-AzVirtualNetworkPeering	Aggiunge un peering a una rete virtuale.
3. Get-AzVirtualNetworkPeering	Ottiene il peering di rete virtuale.

Configurare porte e regole del gruppo di sicurezza di rete

Indipendentemente dal meccanismo di connettività scelto tra le due istanze, le reti devono soddisfare i requisiti seguenti per il flusso del traffico di replica geografica:

La tabella di route e i gruppi di sicurezza di rete assegnati alle subnet delle istanze gestite non vengono condivisi tra le due reti virtuali con peering.
Le regole del gruppo di sicurezza di rete (NSG) in entrambe le subnet che ospitano ogni istanza consentono il traffico in ingresso e in uscita verso l'altra istanza sulla porta 5022 e l'intervallo di porte 11000-11999.

È possibile configurare la comunicazione delle porte e le regole dei gruppi di sicurezza di rete usando il portale di Azure e PowerShell.

Azure portal
PowerShell

Per aprire le porte del gruppo di sicurezza di rete nel portale di Azure, seguire questa procedura:

Passare alla risorsa gruppo di sicurezza di rete per l'istanza primaria.
In Impostazioni selezionare Regole di sicurezza in ingresso. Controllare se sono già presenti regole che consentono il traffico per la porta 5022 e l'intervallo 11000-11999. In caso affermativo, e se l'origine soddisfa le esigenze aziendali, ignorare questo passaggio. Se le regole non esistono o se si vuole usare un'origine diversa, ad esempio l'indirizzo IP più sicuro, eliminare la regola esistente e quindi selezionare + Aggiungi dalla barra dei comandi per aprire la pagina Aggiungi regola di sicurezza in ingresso:

Nella pagina Aggiungi regola di sicurezza in ingresso, immettere o selezionare i valori per le seguenti impostazioni:

Impostazione	Valore consigliato	Descrizione
Origine	Indirizz IP o tag del servizio	Filtro per l'origine della comunicazione. L'indirizzo IP è il più sicuro e consigliato per gli ambienti di produzione. Il tag di servizio è appropriato per gli ambienti non di produzione.
Tag del servizio di origine	Se è stato selezionato Tag del servizio come origine, specificare `VirtualNetwork` come tag di origine.	I tag predefiniti sono identificatori predefiniti che rappresentano una categoria di indirizzi IP. Il tag VirtualNetwork indica tutti gli spazi di indirizzi di rete virtuale e locale.
Indirizzi IP di origine	Se sono stati selezionati indirizzi IP come origine, specificare l'indirizzo IP dell'istanza secondaria.	Specificare un intervallo di indirizzi usando la notazione CIDR (ad esempio 192.168.99.0/24 o 2001:1234::/64) o un indirizzo IP (ad esempio 192.168.99.0 o 2001:1234::). È anche possibile fornire un elenco delimitato da virgole di indirizzi IP o intervalli di indirizzi usando IPv4 o IPv6.
Intervalli porte di origine	5022	Specifica su quali porte il traffico sarà consentito da questa regola.
Servizioo	Personalizzazione	Il servizio specifica il protocollo di destinazione e l'intervallo di porte per questa regola.
Intervalli porte di destinazione	5022	Specifica su quali porte il traffico sarà consentito da questa regola. Questa porta deve corrispondere all'intervallo di porte di origine.
Azione	Consenti	Consentire la comunicazione sulla porta specificata.
Protocollo	TCP	Determina il protocollo per la comunicazione tra porte.
Priorità	1200	Le regole vengono elaborate in ordine di priorità; minore è il numero, maggiore è la priorità.
Nome	allow_geodr_inbound	Il nome della regola.
Descrizione	Facoltativo	È possibile scegliere di specificare una descrizione o lasciare vuoto questo campo.

Selezionare Aggiungi per salvare le impostazioni e aggiungere la nuova regola.

Ripetere questi passaggi per aggiungere un'altra regola di sicurezza in ingresso per l'intervallo di porte 11000-11999 con un nome, ad esempio allow_redirect_inbound e una priorità leggermente superiore alla regola 5022, ad esempio 1100.
In Impostazioni selezionare Regole di sicurezza in uscita. Controllare se sono già presenti regole che consentono il traffico per la porta 5022 e l'intervallo 11000-11999. In caso affermativo, e se l'origine soddisfa le esigenze aziendali, ignorare questo passaggio. Se le regole non esistono o se si vuole usare un'origine diversa, ad esempio l'indirizzo IP più sicuro, eliminare la regola esistente e quindi selezionare + Aggiungi dalla barra dei comandi per aprire la pagina Aggiungi regola di sicurezza in uscita.
Nella pagina Aggiungi regola di sicurezza in uscita usare la stessa configurazione per la porta 5022 e l'intervallo 11000-11999 usato per le porte in ingresso.
Passare al gruppo di sicurezza di rete per l'istanza secondaria e ripetere questi passaggi in modo che entrambi i gruppi di sicurezza di rete abbiano le regole seguenti:
- Consentire il traffico in ingresso sulla porta 5022
- Consentire il traffico in ingresso sull'intervallo di porte 11000-11999
- Consentire il traffico in uscita sulla porta 5022
- Consentire il traffico in uscita sull'intervallo di porte 11000-11999

Creare il gruppo di failover

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

Portale
PowerShell

Creare il gruppo di failover per i Istanza gestita di SQL usando il portale di Azure.

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 ad Azure SQL per aggiungerlo ai Preferiti e come elemento del riquadro di spostamento sinistro.
Selezionare l'istanza gestita primaria da aggiungere al gruppo di failover.
In Gestione dei dati, selezionare Gruppi di failover e quindi usare Aggiungi gruppo per aprire la pagina Gruppo di failover dell'istanza:
Nella pagina Gruppo di failover dell'istanza:
1. L'istanza gestita primaria è preselezionata.
2. In Nome gruppo di failover immettere un nome per il gruppo di failover.
3. In Istanza gestita secondaria selezionare l'istanza gestita che si vuole usare come secondaria nel gruppo di failover.
4. Scegliere un criterio di failover di lettura/scrittura dall'elenco a discesa. Si consiglia l'opzione manuale per avere il controllo sul failover.
5. Lasciare Abilita diritti di failover su Disattivato, a meno che non si intenda usare questa replica solo per il ripristino di emergenza.
6. Usare Crea per salvare le impostazioni e creare il gruppo di failover.
Al termine della distribuzione del gruppo di failover, si torna alla pagina Gruppi di failover. La pagina viene aggiornata per visualizzare il nuovo gruppo di failover al termine della distribuzione.

Usare New-AzSqlDatabaseInstanceFailoverGroup per creare il gruppo di failover per le istanze gestite usando PowerShell.


# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

Failover di test

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

Nota

Se le istanze si trovano in sottoscrizioni o gruppi di risorse diversi, avviare il failover dall'istanza secondaria.

Azure portal
PowerShell

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

Passare all'istanza gestita primaria o secondaria all'interno del portale di Azure.
In Gestione dei dati, selezionare Gruppi di failover.
Nella pagina Gruppi di failover annotare quale istanza è l'istanza primaria e quale istanza è l'istanza secondaria.
Nella pagina Gruppi di failover selezionare Failover dalla barra dei comandi. Selezionare Sì sull'avviso relativo alla disconnessione delle sessioni TDS e prendere nota delle implicazioni per le licenze.
Nella pagina Gruppi di failover, una volta completato il failover, le istanze si scambiano i ruoli in modo che l'istanza secondaria precedente diventi la nuova istanza primaria e l'istanza primaria precedente diventi la nuova istanza secondaria.

Importante

Se i ruoli non sono stati scambiati, verificare la connettività tra le istanze e le relative regole NSG e del firewall. Procedere con il passaggio successivo solo dopo il cambio di ruolo.
(Facoltativo) Nella pagina Gruppi di failover usare Failover per invertire i ruoli in modo che l'istanza primaria originale torni a essere primaria.

Testare il failover pianificato eseguendo il failover sulla replica secondaria con PowerShell, quindi eseguendo il failback.

Verificare i ruoli di ogni istanza

Usare il comando Get-AzSqlDatabaseInstanceFailoverGroup per confermare i ruoli di ogni istanza:


# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Effettuare il failover sull'istanza secondaria

Usare Switch-AzSqlDatabaseFailoverGroup per effettuare il failover sull'istanza secondaria.

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

Verificare i ruoli di ogni istanza

Usare il comando Get-AzSqlDatabaseInstanceFailoverGroup per confermare i ruoli di ogni istanza:


# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Ripristinare il gruppo di failover nel server primario

Facoltativamente, usare il comando Switch-AzSqlDatabaseFailoverGroup per eseguire il failback nell'istanza primaria.


# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Individuare l'endpoint del listener

Dopo aver configurato il gruppo di failover, aggiornare la stringa di connessione dell'applicazione per puntare all'endpoint del listener di lettura/scrittura in modo che l'applicazione continui a connettersi all'istanza primaria dopo il failover. Usando l'endpoint del listener, non è necessario aggiornare manualmente la stringa di connessione ogni volta che il gruppo di failover esegue il failover perché il traffico viene sempre indirizzato all'istanza primaria corrente. È anche possibile indirizzare il carico di lavoro di sola lettura all'endpoint del listener di sola lettura.

Per ricercare l'endpoint del listener nel portale di Azure, passare all'istanza gestita di SQL e in Gestione dati selezionare Gruppi di failover.

Scorrere verso il basso per trovare gli endpoint del listener:

L'endpoint del listener di lettura/scrittura, sotto forma di fog-name.dns-zone.database.windows.net, instrada il traffico all'istanza primaria.
L'endpoint del listener di sola lettura, sotto forma di fog-name.secondary.dns-zone.database.windows.net, instrada il traffico all'istanza secondaria.

Creare un gruppo di failover tra le 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 Microsoft Entra.

Quando si usa l'API di PowerShell, è possibile farlo specificando il parametro PartnerSubscriptionId per l’Istanza gestita di SQL secondaria.
Quando si usa l'API REST, ogni ID istanza incluso nel parametro properties.managedInstancePairs può avere il proprio ID sottoscrizione.
Il portale di Azure non supporta la creazione di gruppi di failover tra sottoscrizioni diverse.

Importante

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

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.

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 al database primario al momento della chiamata.

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:

Creare l'istanza C con le stesse dimensioni di A e nella stessa zona DNS.
Eliminare il gruppo di failover tra le istanze A e B. A questo punto, i tentativi di accesso iniziano a non riuscire 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 vengono disconnessi da quelli primari e diventano database di lettura/scrittura.
Creare un gruppo di failover con lo stesso nome tra l'istanza A e C. Seguire le istruzioni riportate nella guida alla configurazione del gruppo di failover. Si tratta di un'operazione di dimensioni dei dati e viene completata quando tutti i database dell'istanza A vengono inizializzati e sincronizzati.
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.

Cambiare 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:

Creare l'istanza C con le stesse dimensioni di B e nella stessa zona DNS.
Avviare un failover manuale dall'istanza B per renderla la nuova istanza primaria. L'istanza A diventa automaticamente la nuova istanza secondaria.
Eliminare il gruppo di failover tra le istanze A e B. A questo punto, i tentativi di accesso che usano gli endpoint del gruppo di failover iniziano a non riuscire. I database secondari in A vengono disconnessi dalle primarie e diventano database di lettura/scrittura.
Creare un gruppo di failover con lo stesso nome tra l'istanza B e C. Si tratta di un'operazione di dimensionamento dei dati e viene completata quando tutti i database dell'istanza B vengono inizializzati e sincronizzati con l'istanza C. A questo punto, i tentativi di accesso cessano di fallire.
Eseguire manualmente il failover per passare l'istanza C al ruolo primario. L'istanza B diventa automaticamente la nuova istanza secondaria.
Eliminare l'istanza A se non è necessario per evitare addebiti non necessari.

Attenzione

Dopo il passaggio 3 e fino al completamento del 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à diversa da zero che qualcun altro crei un gruppo di failover con lo stesso nome. Poiché i nomi dei gruppi di failover devono essere univoci a livello globale, ciò impedirà di usare di nuovo lo stesso nome. Per ridurre al minimo questo rischio, non usare nomi di gruppo di failover generici.

Modificare i criteri di aggiornamento

Le istanze in un gruppo di failover devono avere criteri di aggiornamento corrispondenti. Per abilitare i criteri di aggiornamento sempre aggiornati nelle istanze che fanno parte di un gruppo di failover, abilitare prima di tutto i criteri di aggiornamento sempre aggiornati nell'istanza secondaria, attendere che la modifica venga applicata e quindi aggiornare i criteri per l'istanza primaria.

Anche se la modifica dei criteri di aggiornamento sull'istanza primaria nel gruppo di failover determina il failover dell'istanza su un altro nodo locale (in modo analogo alle operazioni di gestione sulle istanze che non fanno parte di un gruppo di failover), non provoca il failover del gruppo di failover, mantenendo l'istanza primaria nel ruolo primario.

Attenzione

Una volta modificati i criteri di aggiornamento in sempre aggiornati, non è più possibile modificarli in criteri di aggiornamento di SQL Server 2022.

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, prima aumentare 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. Seguire la stessa sequenza quando si ridimensiona un'istanza in un livello di servizio diverso.

Questa sequenza è consigliata per evitare problemi dall’elemento geografico secondario, con SKU di una versione precedente, raggiungendo un overload e richiedendo un nuovo processo di seeding durante la procedura di aggiornamento o downgrade.

Autorizzazioni

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

Il ruolo collaboratore di Istanza gestita di SQL, con ambito per i gruppi di risorse dell'istanza gestita primaria e secondaria, è sufficiente per eseguire tutte le operazioni di gestione sui gruppi di failover.

La tabella seguente offre una visualizzazione granulare delle autorizzazioni minime necessarie e dei rispettivi livelli di ambito minimi necessari per le operazioni di gestione sui gruppi di failover:

Operazione di gestione	Autorizzazione	Scope
Creare/Aggiornare il gruppo di failover	`Microsoft.Sql/locations/instanceFailoverGroups/write`	Gruppi di risorse dell'istanza gestita primaria e secondaria
Creare/Aggiornare il gruppo di failover	`Microsoft.Sql/managedInstances/write`	Istanza gestita primaria e secondaria
Eseguire il failover del gruppo di failover	`Microsoft.Sql/locations/instanceFailoverGroups/failover/action`	Gruppi di risorse dell'istanza gestita primaria e secondaria
Forzare il failover del gruppo di failover	`Microsoft.Sql/locations/instanceFailoverGroups/forceFailoverAllowDataLoss/action`	Gruppi di risorse dell'istanza gestita primaria e secondaria
Eliminare un gruppo di failover	`Microsoft.Sql/locations/instanceFailoverGroups/delete`	Gruppi di risorse dell'istanza gestita primaria e secondaria

Limiti

Tenere presente le limitazioni seguenti:

Non è possibile creare gruppi di failover tra due istanze nella stessa area di Azure.
I gruppi di failover non possono essere rinominati. Sarà necessario eliminare il gruppo e ricrearlo con un nome diverso.
Un gruppo di failover contiene esattamente due istanze gestite. L'aggiunta di istanze aggiuntive al gruppo di failover non è supportata.
Un'istanza può partecipare a un solo gruppo di failover alla volta.
Non è possibile creare un gruppo di failover tra due istanze appartenenti a tenant di Azure diversi.
La creazione di un gruppo di failover tra due istanze in gruppi di risorse o sottoscrizioni diversi è supportata solo con Azure PowerShell o con l'API REST e non nel portale di Azure o con l'interfaccia della riga di comando di Azure. Una volta creato, il gruppo di failover è visibile nel portale di Azure e tutte le operazioni sono supportate nel portale di Azure o tramite l'interfaccia della riga di comando di Azure. Il failover deve essere avviato dall'istanza secondaria.
La creazione di un gruppo di failover con un'istanza configurata con un collegamento a un'istanza gestita non è attualmente supportata.
La ridenominazione del database non è supportata per i database inclusi in un gruppo di failover. Per poter rinominare un database sarà necessario eliminare temporaneamente il gruppo di failover.
I database di sistema non vengono replicati nell'istanza secondaria in un gruppo di failover. Di conseguenza, gli scenari che dipendono da oggetti dei database di sistema, ad esempio gli accessi al server e i processi degli agenti, richiedono la creazione manuale degli oggetti nelle istanze secondarie che devono essere sincronizzati manualmente quando vengono apportate eventuali modifiche nell'istanza primaria. L'unica eccezione è la chiave master del servizio per un'istanza gestita di SQL replicata automaticamente nell’istanza secondaria durante la creazione di un gruppo di failover. Tutte le modifiche successive della chiave master del servizio nell'istanza primaria, tuttavia, non verranno replicate nell'istanza secondaria. Per altre informazioni, vedere Come abilitare scenari dipendenti da oggetti dai database di sistema.
Non è possibile creare gruppi di failover tra istanze se presenti in un pool di istanze.
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.
Le istanze gestite di SQL in un gruppo di failover devono avere gli stessi criteri di aggiornamento, anche se è possibile modificare i criteri di aggiornamento per le istanze all'interno di un 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. Le tabelle seguenti descrivono il set di comandi disponibili. I gruppi di failover includono un set di API di Azure Resource Manager per la gestione, compresa l'API REST del database SQL di Azure e i cmdlet di Azure PowerShell. Queste API richiedono l'uso di gruppi di risorse e supportano la sicurezza basata sui ruoli (Azure RBAC). Per ulteriori informazioni su come implementare i ruoli di accesso, vedere Controllo degli accessi in base al ruolo di Azure (Azure RBAC).

Cmdlet	Descrizione
New-AzSqlDatabaseInstanceFailoverGroup	Questo comando crea un gruppo di failover e lo registra nell’istanza primaria e secondaria
Set-AzSqlDatabaseInstanceFailoverGroup	Modifica la configurazione di un gruppo di failover
Get-AzSqlDatabaseInstanceFailoverGroup	Recupera la configurazione di un gruppo di failover
Switch-AzSqlDatabaseInstanceFailoverGroup	Attiva il failover del gruppo di failover per l’istanza secondaria
Remove-AzSqlDatabaseInstanceFailoverGroup	Rimuove un gruppo di failover

Comando	Descrizione
az sql instance-failover-group create	Questo comando crea un gruppo di failover e lo registra nei server primario e secondario
az sql instance-failover-group delete	Rimuove un gruppo di failover dal server
az sql instance-failover-group show	Recupera la configurazione di un gruppo di failover
az sql instance-failover-group update	Modifica la configurazione di un gruppo di failover e/o aggiunge uno o più database a un gruppo di failover
az sql instance-failover-group set-primary	Attiva il failover di un gruppo di failover per il server secondario

API	Descrizione
Create or Update Failover Group	Crea o aggiorna la configurazione di un gruppo di failover
Delete Failover Group	Rimuove un gruppo di failover dall'istanza
Failover (Pianificato)	Attiva il failover dall'istanza primaria corrente a questa istanza con sincronizzazione dei dati completa.
Force Failover Allow Data Loss	Attiva il failover dall'istanza primaria corrente all'istanza secondaria senza sincronizzare i dati. Questa operazione potrebbe comportare la perdita di dati.
Get Failover Group	Recupera la configurazione di un gruppo di failover.
List Failover Groups - List By Location	Elenca i gruppi di failover in una posizione.

Condividi tramite

Configurare un gruppo di failover per l'istanza gestita di SQL di Azure

Prerequisiti

Requisiti di configurazione

Creare l'istanza secondaria

Creare una rete virtuale

Creare un'istanza secondaria

Stabilire la connettività tra le istanze

Configurare porte e regole del gruppo di sicurezza di rete

Creare il gruppo di failover

Failover di test

Verificare i ruoli di ogni istanza

Effettuare il failover sull'istanza secondaria

Verificare i ruoli di ogni istanza

Ripristinare il gruppo di failover nel server primario

Individuare l'endpoint del listener

Creare un gruppo di failover tra le istanze in sottoscrizioni diverse

Evitare la perdita di dati critici

Modificare l'area secondaria

Cambiare l'area primaria

Modificare i criteri di aggiornamento

Abilitare scenari dipendenti da oggetti dai database di sistema

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

Ridimensionamento delle istanze

Autorizzazioni

Limiti

Gestione programmatica di gruppi di failover

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Configurare un gruppo di failover per l'istanza gestita di SQL di Azure

Prerequisiti

Requisiti di configurazione

Creare l'istanza secondaria

Creare una rete virtuale

Creare un'istanza secondaria

Stabilire la connettività tra le istanze

Configurare porte e regole del gruppo di sicurezza di rete

Creare il gruppo di failover

Failover di test

Individuare l'endpoint del listener

Creare un gruppo di failover tra le istanze in sottoscrizioni diverse

Evitare la perdita di dati critici

Modificare l'area secondaria

Cambiare l'area primaria

Modificare i criteri di aggiornamento

Abilitare scenari dipendenti da oggetti dai database di sistema

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

Ridimensionamento delle istanze

Autorizzazioni

Limiti

Gestione programmatica di gruppi di failover

Contenuto correlato

Commenti e suggerimenti

Risorse aggiuntive