Configurare un gruppo di failover per il database SQL di Azure

Si applica a:Database SQL di Azure

• Database SQL di Azure
• Istanza gestita di database SQL di Azure

Questo articolo mostra come configurare un gruppo di failover per database singoli e in pool nel database SQL di Azure usando il portale di Azure, Azure PowerShell e l'interfaccia della riga di comando di Azure.

Per gli script end-to-end, vedere come aggiungere un singolo database a un gruppo di failover con Azure PowerShell o con l'interfaccia della riga di comando di Azure.

Prerequisiti

Prendere in considerazione i prerequisiti seguenti per la creazione del gruppo di failover per un database singolo:

• Le impostazioni di accesso del server e del firewall per il server secondario devono corrispondere a quelle del server primario.

Create failover group

Portale

Creare il gruppo di failover e aggiungervi il database singolo tramite 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 ad Azure SQL per aggiungerlo ai Preferiti e come elemento del riquadro di spostamento sinistro.

2. Selezionare il database da aggiungere al gruppo di failover.

3. In Nome del server selezionare il nome del server per aprire le impostazioni del server.

   

4. Nel riquadro Impostazioni selezionare Gruppi di failover e quindi selezionare Aggiungi gruppo per creare un nuovo gruppo di failover.

   

5. Nella pagina Gruppo di failover immettere o selezionare i valori richiesti e quindi selezionare Crea. Creare quindi un nuovo server secondario o selezionare un server secondario esistente. Il server secondario nel gruppo di failover deve trovarsi in un'area diversa rispetto al server primario.

   • Database all'interno del gruppo: scegliere il database da aggiungere al gruppo di failover. Aggiungendo il database al gruppo di failover viene avviato automaticamente il processo di replica geografica.

   

PowerShell

Creare il gruppo di failover e aggiungervi il database tramite PowerShell.

Usare il comando New-AzSqlDatabaseFailoverGroup per creare il gruppo di failover:

# Create a failover group between the servers
$failovergroup = Write-host "Creating a failover group between the primary and secondary server..."
New-AzSqlDatabaseFailoverGroup `
   –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
$failovergroup

Usare i comandi Get-AzSqlDatabase e Add-AzSqlDatabaseToFailoverGroup per aggiungere il database al gruppo di failover:

# Add the database to the failover group
Write-host "Adding the database to the failover group..." 
Get-AzSqlDatabase `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -DatabaseName $databaseName | `
Add-AzSqlDatabaseToFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Successfully added the database to the failover group..."

Nota

È possibile distribuire il gruppo di failover tra sottoscrizioni usando il parametro -PartnerSubscriptionId in Azure PowerShell a partire da Az.SQL 3.11.0. Per saperne di più, vedere il seguente Esempio.

Interfaccia della riga di comando di Azure

In questo passaggio, creare il gruppo di failover e aggiungervi il database tramite l'interfaccia della riga di comando di Azure.

Usare il comando az sql failover-group create per creare un gruppo di failover e aggiungere il database al gruppo di failover:

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2 --add-db $database

Testare un failover pianificato

Testare un failover del gruppo di failover senza perdita di dati usando il portale di Azure o PowerShell.

Portale

Testare il failover del gruppo di failover con 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 quindi 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.

2. Selezionare il database da aggiungere al gruppo di failover.

   

3. Selezionare Gruppi di failover dal riquadro Impostazioni e quindi scegliere il gruppo di failover appena creato.

   

4. Verificare qual è il server primario e quale quello secondario.

5. Selezionare Failover nel riquadro attività per eseguire il failover del gruppo di failover che contiene il database.

6. Selezionare Sì nella finestra dell'avviso che informa che le sessioni TDS verranno disconnesse.

   

7. Verificare quale server è ora il server primario e quale quello secondario. Se il failover è riuscito, i due server dovrebbero essersi scambiati i ruoli.

8. Selezionare di nuovo Failover per ripristinare i ruoli originali dei server.

PowerShell

Testare il failover del gruppo di failover con PowerShell.

Verificare i ruoli di ogni server

Usare il comando Get-AzSqlDatabaseFailoverGroup per confermare i ruoli di ogni server.

# Check role of secondary replica
Write-host "Confirming the secondary replica is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Effettuare il failover nel server secondario

Usare il comando Switch-AzSqlDatabaseFailoverGroup per eseguire il failover nel server secondario.

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully to" $drServerName 

Write-host "Confirming the secondary server is now primary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Ripristinare il gruppo di failover nel server primario

Usare il comando Switch-AzSqlDatabaseFailoverGroup per eseguire il failback nel server primario.

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully back to" $serverName

Interfaccia della riga di comando di Azure

Testare il failover con l'interfaccia della riga di comando di Azure.

Verificare i ruoli di ogni server

Usare il comando az sql failover-group show per confermare i ruoli di ogni server.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Effettuare il failover nel server secondario

Usare il comando az sql failover-group set-primary per effettuare il failover nel server secondario. Usare il comando az sql failover-group show per verificare un failover riuscito.

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Ripristinare il gruppo di failover nel server primario

Usare il comando az sql failover-group set-primary per eseguire nuovamente il failover nel server primario.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

Importante

Se è necessario eliminare il database secondario, rimuoverlo dal gruppo di failover prima di eliminarlo. L'eliminazione di un database secondario prima della rimozione dal gruppo di failover può causare comportamenti imprevisti.

Per gli script end-to-end, vedere come aggiungere un pool elastico a un gruppo di failover con Azure PowerShell o l'interfaccia della riga di comando di Azure.

Prerequisiti

Prendere in considerazione i seguenti prerequisiti per la creazione del gruppo di failover per un database in pool:

• Le impostazioni di accesso del server e del firewall per il server secondario devono corrispondere a quelle del server primario.

Create failover group

Creare il gruppo di failover per il pool elastico usando il portale di Azure o PowerShell.

Portale

Creare il gruppo di failover e aggiungervi il pool elastico tramite 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 quindi 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.

2. Selezionare il pool elastico che si desidera aggiungere al gruppo di failover.

3. Nel riquadro Panoramica selezionare il nome del server in Nome del server per aprire le impostazioni del server.

   

4. Nel riquadro Impostazioni selezionare Gruppi di failover e quindi selezionare Aggiungi gruppo per creare un nuovo gruppo di failover.

   

5. Nella pagina Gruppo di failover immettere o selezionare i valori richiesti e quindi selezionare Crea. Creare quindi un nuovo server secondario o selezionare un server secondario esistente.

6. Selezionare Database all'interno del gruppo e scegliere il pool elastico da aggiungere al gruppo di failover. Se nel server secondario non esiste già un pool elastico, viene visualizzato un avviso che richiede di creare un pool elastico nel server secondario. Selezionare l'avviso e quindi scegliere OK per creare il pool elastico nel server secondario.

   

7. Usare Seleziona per applicare le impostazioni del pool elastico al gruppo di failover, quindi selezionare Crea per creare il gruppo di failover. Aggiungendo il pool elastico al gruppo di failover viene avviato automaticamente il processo di replica geografica.

PowerShell

Creare il gruppo di failover e aggiungervi il pool elastico tramite PowerShell.

Usare il comando New-AzSqlDatabaseFailoverGroup per creare il gruppo di failover:

# Create a failover group between the servers
Write-host "Creating failover group..." 
New-AzSqlDatabaseFailoverGroup `
  –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
Write-host "Failover group created successfully."

Usare i comandi Get-AzSqlDatabaseFailoverGroup e Get-AzSqlElasticPoolDatabase per aggiungere il database al gruppo di failover:

# Add elastic pool to the failover group
Write-host "Enumerating databases in elastic pool...." 
$FailoverGroup = Get-AzSqlDatabaseFailoverGroup `
                 -ResourceGroupName $resourceGroupName `
                 -ServerName $serverName `
                 -FailoverGroupName $failoverGroupName
$databases = Get-AzSqlElasticPoolDatabase `
               -ResourceGroupName $resourceGroupName `
               -ServerName $serverName `
               -ElasticPoolName $poolName
Write-host "Adding databases to failover group..." 
$failoverGroup = $failoverGroup | Add-AzSqlDatabaseToFailoverGroup `
                                  -Database $databases 
$failoverGroup

Interfaccia della riga di comando di Azure

In questo passaggio, creare il gruppo di failover e aggiungervi il database tramite l'interfaccia della riga di comando di Azure.

Usare il comando az sql failover-group create per creare un gruppo di failover.

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2
databaseId=$(az sql elastic-pool list-dbs --name $pool --resource-group $resourceGroup --server $server --query [0].name -o json | tr -d '"')

Usare il comando az sql failover-group update per aggiungere un database al gruppo di failover.

echo "Adding $database to $failoverGroup..."
az sql failover-group update --name $failoverGroup --add-db $databaseId --resource-group $resourceGroup --server $server

Testare un failover pianificato

Testare un failover senza perdita di dati del pool elastico usando il portale di Azure o PowerShell.

Portale

Eseguire il failover del gruppo di failover sul server secondario e quindi eseguire il failback utilizzando 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 quindi 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.

2. Selezionare il pool elastico di cui si desidera eseguire il failover.

3. Nel riquadro Panoramica selezionare il nome del server in Nome del server per aprire le impostazioni del server.

   

4. Selezionare Gruppi di failover dal riquadro Impostazioni e quindi selezionare il gruppo di failover creato precedentemente.

   

5. Verificare qual è il server primario e quale quello secondario.

6. Selezionare Failover nel riquadro attività per eseguire il failover del gruppo di failover che contiene il pool elastico.

7. Selezionare Sì nella finestra dell'avviso che informa che le sessioni TDS verranno disconnesse.

   

8. Verificare qual è il server primario e quale quello secondario. Se il failover è riuscito, i due server dovrebbero essersi scambiati i ruoli.

9. Selezionare di nuovo Failover per ripristinare le impostazioni originali del gruppo di failover.

PowerShell

Testare il failover del gruppo di failover usando PowerShell usando i seguenti comandi di PowerShell:

Verificare i ruoli di ogni server

Usare il comando Get-AzSqlDatabaseFailoverGroup per confermare i ruoli di ogni server.

# Check role of secondary replica
Write-host "Confirming the secondary server is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Effettuare il failover nel server secondario

Usare il comando Switch-AzSqlDatabaseFailoverGroup per eseguire il failover nel server secondario.

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failover group failed over to" $drServerName 

# Check role of secondary replica
Write-host "Confirming the secondary server is now primary" 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Ripristinare il gruppo di failover nel server primario

Usare il comando Switch-AzSqlDatabaseFailoverGroup per eseguire il failback nel server primario.

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failover group failed over to" $serverName

Interfaccia della riga di comando di Azure

Testare il failover con l'interfaccia della riga di comando di Azure.

Verificare i ruoli di ogni server

Usare il comando az sql failover-group show per confermare i ruoli di ogni server nel gruppo di failover.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Effettuare il failover nel server secondario

Usare il comando az sql failover-group set-primary per eseguire il failover nel server secondario. Usare il comando az sql failover-group show per verificare un failover riuscito.

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Ripristinare il gruppo di failover nel server primario

Usare il comando az sql failover-group set-primary per eseguire nuovamente il failback nel server primario.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

Importante

Se è necessario eliminare il database secondario, rimuoverlo dal gruppo di failover prima di eliminarlo. L'eliminazione di un database secondario prima della rimozione dal gruppo di failover può causare comportamenti imprevisti.

Usare Collegamento privato

L'uso di un collegamento privato consente di associare un server logico a un indirizzo IP privato specifico all'interno della rete virtuale e della subnet.

Per usare un collegamento privato con il gruppo di failover, attenersi alla procedura seguente:

1. Assicurarsi che i server primario e secondario si trovino in un'area associata.
2. Creare la rete virtuale e la subnet in ogni area per ospitare gli endpoint privati per i server primari e secondari, in modo che gli spazi degli indirizzi IP non siano sovrapposti. Ad esempio l'intervallo di indirizzi della rete virtuale primaria di 10.0.0.0/16 e l'intervallo di indirizzi della rete virtuale secondario di 10.0.0.1/16 si sovrappongono. Per altre informazioni sugli intervalli di indirizzi di rete virtuale, vedere il blog sulla progettazione di reti virtuali di Azure.
3. Creare un endpoint privato e una zona di DNS privato di Azure per il server primario.
4. Creare un endpoint privato anche per il server secondario, ma questa volta scegliere di riutilizzare la stessa zona di DNS privato creata per il server primario.
5. Dopo aver stabilito il collegamento privato, è possibile creare il gruppo di failover seguendo i passaggi descritti in precedenza in questo articolo.

Individuare l'endpoint del listener

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

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

Dimensionare un database in un gruppo di failover

È possibile aumentare o ridurre un database primario a una dimensione di calcolo diversa (nello stesso livello di servizio) senza disconnettere i database secondari con replica geografica. Quando si aumentano le prestazioni, è consigliabile aumentare prima quelle del database secondario geografico e quindi quelle del database primario. In caso di riduzione delle prestazioni, invertire l'ordine: ridurre prima le prestazioni del database primario e quindi ridurre le prestazioni di quello secondario. Quando si aumenta/riduce un database passando a un livello di servizio diverso, viene imposta questa raccomandazione.

Questa sequenza è consigliata specificamente per evitare il problema in cui il geo-secondario con uno SKU inferiore viene sovraccaricato e deve essere eseguito un nuovo processo di seeding durante la procedura di aggiornamento o downgrade. È possibile evitare il problema anche rendendo la replica primaria di sola lettura, a scapito di tutti i carichi di lavoro di lettura/scrittura sul componente primario.

Nota

Se è stato creato un database secondario con replica geografica come parte della configurazione di un gruppo di failover, non è consigliabile ridurne le prestazioni. Ciò garantisce che il livello dati disponga della capacità sufficiente per elaborare il carico di lavoro normale dopo un failover geografico. Potrebbe non essere possibile dimensionare un database geografico secondario dopo un failover imprevisto quando il database geografico primario precedente non è disponibile a causa di un'interruzione. Si tratta di una limitazione nota.

Evitare la perdita di dati critici

A causa della latenza elevata delle wide area networks, la replica geografica usa un meccanismo di replica asincrona. La replica asincrona rende impossibile la perdita di dati se il database primario ha esito negativo. Per proteggere le transazioni critiche dalla perdita di dati, uno sviluppatore di applicazioni può chiamare la procedura di sistema sp_wait_for_database_copy_sync immediatamente dopo aver eseguito il commit della transazione. La chiamata sp_wait_for_database_copy_sync blocca il thread chiamante fino a quando l'ultima transazione sottoposta a protezione avanzata non viene trasmessa e rafforzata nel log delle transazioni del database secondario. Tuttavia, non attende che le transazioni trasmesse vengano riprodotte (rifatte) nel database secondario. sp_wait_for_database_copy_sync ha come ambito un collegamento specifico di replica geografica. 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

Per illustrare la sequenza di modifiche, si presuppone che il server A sia il server primario, il server B sia il server secondario esistente e il server C sia il nuovo secondario nella terza area. Per eseguire la transizione, seguire questi passaggi:

1. Creare repliche secondarie aggiuntive di ogni database nel server A al server C usando la replica geografica attiva. Ogni database nel server A avrà due database secondari, uno nel server B e uno nel server C. Ciò garantisce che i database primari rimangano protetti durante la transizione.
2. Eliminare il gruppo di failover. A questo punto, i tentativi di accesso che usano gli endpoint del gruppo di failover iniziano a fallire.
3. Ricreare il gruppo di failover con lo stesso nome tra i server A e C.
4. Aggiungere tutti i database primari nel server A al nuovo gruppo di failover. A questo punto, i tentativi di accesso smettono di fallire.
5. Eliminare il server B. Tutti i database in B verranno eliminati automaticamente.

Modificare l'area primaria

Per illustrare la sequenza di modifiche, si presuppone che il server A sia il server primario, il server B sia il server secondario esistente e il server C sia il nuovo server primario nella terza area. Per eseguire la transizione, seguire questi passaggi:

1. Eseguire un failover geografico pianificato per passare il server primario a B. Il server A diventa il nuovo server secondario. Il failover potrebbe comportare diversi minuti di inattività. Il tempo effettivo dipende dalle dimensioni del gruppo di failover.
2. Creare repliche secondarie aggiuntive di ogni database nel server B al server C usando la replica geografica attiva. Ogni database nel server B avrà due database secondari, uno nel server A e uno nel server C. Ciò garantisce che i database primari rimangano protetti durante la transizione.
3. Eliminare il gruppo di failover. A questo punto, i tentativi di accesso che usano gli endpoint del gruppo di failover iniziano a fallire.
4. Ricreare il gruppo di failover con lo stesso nome tra i server B e C.
5. Aggiungere tutti i database primari in B al nuovo gruppo di failover. A questo punto, i tentativi di accesso smettono di fallire.
6. Eseguire un failover geografico pianificato del gruppo di failover per passare da B a C. Il server C diventa ora primario e B il database secondario. Tutti i database secondari nel server A verranno collegati automaticamente a quelli primari in C. Come nel passaggio 1, il failover potrebbe comportare diversi minuti di inattività.
7. Eliminare il server A. Tutti i database in A verranno eliminati automaticamente.

Importante

Quando il gruppo di failover viene eliminato, vengono eliminati anche i record DNS per gli endpoint del listener. A quel punto, esiste una probabilità diversa da zero che qualcun altro crei un gruppo di failover o un alias DNS del server con lo stesso nome. Poiché i nomi dei gruppi di failover e gli alias DNS 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.

Gruppi di failover e sicurezza di rete

Per alcune applicazioni, le regole di sicurezza richiedono che l'accesso di rete al livello dati sia limitato a uno o più componenti specifici, come ad esempio una VM, un servizio web, e così via. Questo requisito presenta alcune sfide per la progettazione della continuità aziendale e l'utilizzo di gruppi di failover. Quando si implementa questo tipo di accesso con restrizioni, è necessario considerare le opzioni seguenti.

Usare i gruppi di failover e gli endpoint servizio di rete virtuale

Se si usano endpoint e regole servizio di rete virtuale per limitare l'accesso al database, tenere presente che ogni endpoint servizio di rete virtuale si applica a una sola area geografica di Azure. L'endpoint non consente ad altre aree di accettare le comunicazioni dalla subnet. Pertanto, solo le applicazioni client distribuite nella stessa area possono connettersi al database primario. Poiché un failover geografico comporta il reindirizzamento delle sessioni client del database SQL a un server in un'area diversa (secondaria), queste sessioni potrebbero avere esito negativo se originate da un client esterno a tale area. Per questo motivo, i criteri di failover gestito da Microsoft non possono essere abilitati se i server partecipanti sono inclusi nelle regole di rete virtuale. Per supportare il failover manuale, seguire questi passaggi:

1. Effettuare il provisioning delle copie ridondanti dei componenti front-end dell'applicazione (servizio web, macchine virtuali e così via) nell'area secondaria.
2. Configurare le regole di rete virtuale singolarmente per il server primario e per quello secondario.
3. Abilitare il failover front-end usando una configurazione di Gestione traffico.
4. Avviare il failover geografico manuale quando viene rilevata l'interruzione. Questa opzione è ottimizzata per le applicazioni che richiedono la latenza coerente tra il front-end e il livello dati e supporta il ripristino quando il front-end, il livello dati o entrambi sono interessati dall'interruzione del servizio.

Nota

Se si usa il listener di sola lettura per il bilanciamento di un carico di lavoro di sola lettura, assicurarsi che il carico di lavoro venga eseguito in una VM o in un'altra risorsa nell'area secondaria in modo da consentire la connessione al database secondario.

Usare gruppi di failover e regole del firewall

Se il piano di continuità aziendale richiede il failover tramite gruppi di failover, è possibile limitare l'accesso al database SQL utilizzando le regole del firewall IP pubblico. Questa configurazione garantisce che un failover geografico non blocchi le connessioni dai componenti front-end e presuppone che l'applicazione possa tollerare una latenza più lunga tra il front-end e il livello dati.

Per supportare il failover del gruppo, seguire questi passaggi:

1. Creare un IP pubblico.
2. Creare un servizio di bilanciamento del carico pubblico e assegnare l'indirizzo IP pubblico a tale servizio.
3. Creare una rete virtuale e le macchine virtuali per i componenti front-end.
4. Creare un gruppo di sicurezza di rete e configurare le connessioni in ingresso.
5. Assicurarsi che le connessioni in uscita siano aperte al database SQL di Azure usando il tag del servizioSql.<Region>.
6. Creare un regola del firewall del database SQL per consentire il traffico in ingresso dall'indirizzo IP pubblico creato nel passaggio 1.

Per maggiori informazioni su come configurare l'accesso in uscita e su quale indirizzo IP usare nelle regole del firewall, vedere Connessioni in uscita del servizio di bilanciamento del carico.

Importante

Per garantire la continuità aziendale durante le interruzioni regionali, è necessario garantire la ridondanza geografica sia per i componenti front-end che per i database.

Autorizzazioni

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

L'accesso in scrittura per Azure RBAC è necessario per creare e gestire i gruppi di failover. Il ruolo Collaboratore SQL Server dispone di tutte le autorizzazioni necessarie per gestire i gruppi di failover.

Nella tabella seguente sono elencati gli ambiti di autorizzazione specifici per il database SQL di Azure:

Azione	Autorizzazione	Scope
Create failover group	Accesso in scrittura per Azure RBAC	Server primario Server secondario Tutti i database nel gruppo di failover
Aggiornare il gruppo di failover	Accesso in scrittura per Azure RBAC	Gruppo di failover Tutti i database nel server primario corrente
Eseguire il failover del gruppo di failover	Accesso in scrittura per Azure RBAC	Gruppo di failover nel nuovo server

Limiti

Tenere presente le limitazioni seguenti:

• Non è possibile creare gruppi di failover tra due server nella stessa area di Azure.
• I gruppi di failover supportano la replica geografica di tutti i database nel gruppo in un solo server logico secondario in un'area diversa.
• I gruppi di failover non possono essere rinominati. Sarà necessario eliminare il gruppo e ricrearlo con un nome diverso.
• La ridenominazione del database non è supportata per i database inclusi in un gruppo di failover. Per rinominare un database sarà necessario eliminare temporaneamente il gruppo di failover o rimuovere il database dal gruppo di failover.
• La rimozione di un gruppo di failover per un database singolo o in pool non interrompe la replica e non elimina il database replicato. Sarà necessario arrestare manualmente la replica geografica ed eliminare il database dal server secondario se si vuole aggiungere di nuovo un database singolo o in pool a un gruppo di failover dopo averlo rimosso. In caso contrario, potrebbe verificarsi un errore simile a The operation cannot be performed due to multiple errors quando si tenta di aggiungere il database al gruppo di failover.
• Il nome del gruppo di failover è soggetto a restrizioni di denominazione.

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 maggiori informazioni su come implementare i ruoli di accesso, vedere Controllo degli accessi in base al ruolo di Azure (Azure RBAC).

PowerShell

Cmdlet	Descrizione
New-AzSqlDatabaseFailoverGroup	Questo comando crea un gruppo di failover e lo registra nei server primario e secondario
Remove-AzSqlDatabaseFailoverGroup	Rimuove un gruppo di failover dal server
Get-AzSqlDatabaseFailoverGroup	Recupera la configurazione di un gruppo di failover
Set-AzSqlDatabaseFailoverGroup	Modifica la configurazione di un gruppo di failover
Switch-AzSqlDatabaseFailoverGroup	Attiva il failover di un gruppo di failover per il server secondario
Add-AzSqlDatabaseToFailoverGroup	Aggiunge uno o più database a un gruppo di failover

Nota

È possibile distribuire il gruppo di failover tra sottoscrizioni usando il parametro -PartnerSubscriptionId in Azure PowerShell a partire da Az.SQL 3.11.0. Per saperne di più, vedere il seguente ‭Esempio‭‬.

Interfaccia della riga di comando di Azure

Comando	Descrizione
az sql failover-group create	Questo comando crea un gruppo di failover e lo registra nei server primario e secondario
az sql failover-group delete	Rimuove un gruppo di failover dal server
az sql failover-group show	Recupera la configurazione di un gruppo di failover
az sql 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 failover-group set-primary	Attiva il failover di un gruppo di failover per il server secondario

REST API

API	Descrizione
Create or Update Failover Group	Crea o aggiorna un gruppo di failover.
Delete Failover Group	Rimuove un gruppo di failover dal server
Failover (Planned)	Attiva il failover dal server primario corrente al server secondario con sincronizzazione completa dei dati.
Force Failover Allow Data Loss	Attiva il failover dal server primario corrente al server secondario senza sincronizzazione dei dati. Questa operazione può comportare la perdita di dati.
Get Failover Group	Recupera la configurazione di un gruppo di failover.
List Failover Groups By Server	Elenca i gruppi di failover in un server.
Update Failover Group	Aggiorna la configurazione di un gruppo di failover.

Passaggi successivi

Per una panoramica delle opzioni di disponibilità elevata del database SQL di Azure, vedere replica geografica e gruppi di failover.