Configurare un listener DNN per un gruppo di disponibilità

  • Articolo

Si applica a:SQL Server su VM di Azure

Suggerimento

Esistono molti metodi per distribuire un gruppo di disponibilità. Semplificare la distribuzione ed eliminare la necessità di un servizio di Azure Load Balancer o di un nome di rete distribuito (DNN) per il gruppo di disponibilità AlwaysOn creando le macchine virtuali (VM) di SQL Server in più subnet all'interno della stessa rete virtuale di Azure. Se il gruppo di disponibilità è già stato creato in una singola subnet, è possibile eseguirne la migrazione a un ambiente con più subnet.

Con SQL Server in macchine virtuali di Azure in una singola subnet, il nome di rete distribuita (DNN) instrada il traffico alla risorsa cluster appropriata. Offre un modo più semplice per connettersi a un gruppo di disponibilità AlwaysOn (AG) rispetto al listener del nome di rete virtuale (VNN), senza la necessità di un servizio di Azure Load Balancer.

Questo articolo illustra come configurare un listener DNN per sostituire il listener della rete virtuale e instradare il traffico al gruppo di disponibilità con SQL Server in macchine virtuali di Azure per la disponibilità elevata e il ripristino di emergenza (HADR).

Per un'opzione di connettività alternativa, prendere in considerazione un listener VNN e Azure Load Balancer.

Panoramica

Un listener DNN (Distributed Network Name) sostituisce il listener del gruppo di disponibilità VNN (Virtual Network Name) tradizionale quando usato con i gruppi di disponibilità AlwaysOn nelle macchine virtuali di SQL Server. Ciò nega la necessità di un'istanza di Azure Load Balancer per instradare il traffico, semplificando la distribuzione, la manutenzione e migliorando il failover.

Usare il listener di DNN per sostituire un listener di VNN esistente o in alternativa usarlo in combinazione con un listener di VNN esistente in modo che il gruppo di disponibilità abbia due punti di connessione distinti, uno che usa il nome del listener di VNN (e la porta se non predefinita) e l'altro che usa il nome e la porta del listener di DNN.

Attenzione

Il comportamento di routing quando si usa una DNN è diverso da quando si usa una VNN. Non usare la porta 1433. Per altre informazioni, vedere la sezione Considerazioni sulla porta più avanti in questo articolo.

Prerequisiti

Per poter completare la procedura descritta in questo articolo, sono necessari:

Crea script

Usare PowerShell per creare la risorsa DNN (Distributed Network Name) e associarla al gruppo di disponibilità.

A tale scopo, effettuare i passaggi seguenti:

  1. Aprire un editor di testo, come Blocco note.

  2. Copiare e incollare lo script seguente:

    param (
   [Parameter(Mandatory=$true)][string]$Ag,
   [Parameter(Mandatory=$true)][string]$Dns,
   [Parameter(Mandatory=$true)][string]$Port
)

Write-Host "Add a DNN listener for availability group $Ag with DNS name $Dns and port $Port"

$ErrorActionPreference = "Stop"

# create the DNN resource with the port as the resource name
Add-ClusterResource -Name $Port -ResourceType "Distributed Network Name" -Group $Ag 

# set the DNS name of the DNN resource
Get-ClusterResource -Name $Port | Set-ClusterParameter -Name DnsName -Value $Dns 

# start the DNN resource
Start-ClusterResource -Name $Port


$Dep = Get-ClusterResourceDependency -Resource $Ag
if ( $Dep.DependencyExpression -match '\s*\((.*)\)\s*' )
{
$DepStr = "$($Matches.1) or [$Port]"
}
else
{
$DepStr = "[$Port]"
}

Write-Host "$DepStr"

# add the Dependency from availability group resource to the DNN resource
Set-ClusterResourceDependency -Resource $Ag -Dependency "$DepStr"


#bounce the AG resource
Stop-ClusterResource -Name $Ag
Start-ClusterResource -Name $Ag

  3. Salvare lo script come .ps1 file, ad esempio add_dnn_listener.ps1.

Esecuzione dello script

Per creare il listener DNN, eseguire lo script passando parametri per il nome del gruppo di disponibilità, il nome del listener e la porta.

Supponendo, ad esempio, che il nome di un gruppo di disponibilità ag1, il nome del listener dnnlsnr e la porta del listener sia 6789, seguire questa procedura:

  1. Aprire uno strumento di interfaccia della riga di comando, ad esempio il prompt dei comandi o PowerShell.

  2. Passare alla posizione in cui è stato salvato lo .ps1 script, ad esempio c:\Documents.

  3. Eseguire lo script add_dnn_listener.ps1 <ag name> <listener-name> <listener port>. Ad esempio:

    c:\Documents> .\add_dnn_listener.ps1 ag1 dnnlsnr 6789

Verificare il listener

Usare SQL Server Management Studio o Transact-SQL per verificare che il listener DNN sia stato creato correttamente.

SQL Server Management Studio

Espandere Listener del gruppo di disponibilità in SQL Server Management Studio (SSMS) per visualizzare il listener DNN:

View the DNN listener under availability group listeners in SQL Server Management Studio (SSMS)

Transact-SQL

Usare Transact-SQL per visualizzare lo stato del listener DNN:

SELECT * FROM SYS.AVAILABILITY_GROUP_LISTENERS

Un valore di 1 per is_distributed_network_name indica che il listener è un listener DNN (Distributed Network Name):

Use sys.availability_group_listeners to identify DNN listeners that have a value of 1 in is_distributed_network_name

Aggiornare la stringa di connessione

Aggiornare il stringa di connessione per qualsiasi applicazione che deve connettersi al listener DNN. Il stringa di connessione al listener DNN deve fornire il numero di porta DNN e specificare MultiSubnetFailover=True nella stringa di connessione. Se il client SQL non supporta il MultiSubnetFailover=True parametro, non è compatibile con listener DNN.

Di seguito è riportato un esempio di stringa di connessione per il nome del listener DNN_Listener e la porta 6789:

DataSource=DNN_Listener,6789;MultiSubnetFailover=True

Failover di test

Failover di test del gruppo di disponibilità per garantire la funzionalità.

Per testare un failover, effettuare le seguenti operazioni:

  1. Connettersi al listener DNN o a una delle repliche usando SQL Server Management Studio (SSMS).
  2. Espandere Gruppo di disponibilità AlwaysOn in Esplora oggetti.
  3. Fare clic con il pulsante destro del mouse sul gruppo di disponibilità e scegliere Failover per aprire la Procedura guidata failover.
  4. Seguire le istruzioni per scegliere una destinazione di failover ed eseguire il failover del gruppo di disponibilità in una replica secondaria.
  5. Verificare che il database sia sincronizzato nella nuova replica primaria.
  6. (Facoltativo) Eseguire il failback alla replica primaria originale o a un'altra replica secondaria.

Testare la connettività

Testare la connettività al listener DNN con questa procedura:

  1. Aprire SQL Server Management Studio.
  2. Connettersi al listener DNN.
  3. Aprire una nuova finestra di query e verificare la replica a cui si è connessi eseguendo SELECT @@SERVERNAME.
  4. Effettuare il failover del gruppo di disponibilità a un'altra replica.
  5. Dopo un periodo di tempo ragionevole, eseguire SELECT @@SERVERNAME per verificare che il gruppo di disponibilità sia ora ospitato in un'altra replica.

Limiti

  • I listener DNN DEVONO essere configurati con una porta univoca. La porta non può essere condivisa con altre connessioni in qualsiasi replica.
  • Il client che si connette al listener DNN deve supportare il MultiSubnetFailover=True parametro nella stringa di connessione.
  • Quando si usano altre funzionalità di SQL Server e un gruppo di disponibilità con un DNN, potrebbero essere presenti considerazioni aggiuntive. Per altre informazioni, vedere AG con interoperabilità DNN.

Considerazioni per la porta

I listener DNN sono progettati per l'ascolto su tutti gli indirizzi IP, ma su una porta specifica e univoca. La voce DNS per il nome del listener deve essere risolta negli indirizzi di tutte le repliche nel gruppo di disponibilità. Questa operazione viene eseguita automaticamente con lo script di PowerShell fornito nella sezione Crea script. Poiché i listener DNN accettano connessioni su tutti gli indirizzi IP, è fondamentale che la porta del listener sia univoca e non in uso da altre repliche nel gruppo di disponibilità. Poiché SQL Server è in ascolto sulla porta 1433 per impostazione predefinita, direttamente o tramite il servizio SQL Browser, l'uso della porta 1433 per il listener DNN è fortemente sconsigliato.

Se la porta del listener scelta per il listener VNN è compresa tra 49.152 e 65.536 (intervallo di porte dinamiche predefinito per TCP/IP, aggiungere un'esclusione per questa opzione. In questo modo, gli altri sistemi non potranno assegnare dinamicamente la stessa porta.

È possibile aggiungere un'esclusione di porta con il comando seguente: netsh int ipv4 add excludedportrange tcp startport=<Listener Port> numberofports=1 store=persistent

Passaggi successivi

Dopo aver distribuito il gruppo di disponibilità, prendere in considerazione l'ottimizzazione delle impostazioni HADR per SQL Server nelle VM di Azure‭.

Per altre informazioni, vedere: