Configurar um ouvinte DNN para um grupo de disponibilidade

  • Artigo

Aplica-se a:SQL Server na VM do Azure

Dica

Há vários métodos de implantação de um grupo de disponibilidade. Simplifique sua implantação sem precisar usar o Azure Load Balancer ou DNN (nome de rede distribuída) para seu grupo de disponibilidade Always On criando suas VMs (máquinas virtuais) do SQL Server em várias sub-redes dentro da mesma rede virtual do Azure. Se você já tiver criado seu grupo de disponibilidade em uma única sub-rede, poderá migrá-lo para um ambiente de várias sub-redes.

Com o SQL Server em VMs do Azure, o DNN (nome de rede distribuída) encaminha o tráfego para o recurso clusterizado apropriado. Ele fornece uma maneira mais fácil de se conectar a um AG (grupo de disponibilidade Always On) do que o ouvinte VNN (nome de rede virtual), sem a necessidade de um Azure Load Balancer.

Este artigo ensina a configurar um ouvinte de DNN para substituir o ouvinte VNN e rotear o tráfego para seu grupo de disponibilidade com SQL Server em VMs do Azure para alta disponibilidade e recuperação de desastres (HADR).

Para obter uma opção de conectividade alternativa, considere um ouvinte VNN e Azure Load Balancer em vez disso.

Visão geral

Um ouvinte DNN (nome de rede distribuída) substitui o ouvinte do grupo de disponibilidade VNN (nome de rede virtual) tradicional quando usado com grupos de disponibilidade Always on em VMs SQL Server. Isso nega a necessidade de um Azure Load Balancer rotear o tráfego, simplificar a implantação, a manutenção e melhorar o failover.

Use o ouvinte DNN para substituir um ouvinte VNN existente ou, como alternativa, use-o em conjunto com um ouvinte VNN existente para que o seu grupo de disponibilidade tenha dois pontos de conexão distintos: um que usa o nome do ouvinte VNN (e a porta, se ela não for padrão) e outro que usa o nome e a porta do ouvinte DNN.

Cuidado

O comportamento de roteamento ao usar um DNN difere ao usar um VNN. Não use a porta 1433. Para saber mais, confira a seção Consideração sobre portas posteriormente neste artigo.

Pré-requisitos

Para realizar as etapas deste artigo, você já deve ter:

Criar script

Use o PowerShell para criar o recurso DNN (nome de rede distribuída) e associá-lo ao seu grupo de disponibilidade.

Para fazer isso, siga estas etapas:

  1. Abra um editor de texto, como o Bloco de Notas.

  2. Copie e cole o seguinte script:

    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. Salve o script como um arquivo .ps1, por exemplo add_dnn_listener.ps1.

Executar script

Para criar o ouvinte DNN, execute o script passando parâmetros para o nome do grupo de disponibilidade, o nome do ouvinte e a porta.

Por exemplo, supondo que um nome de grupo de disponibilidade ag1, o nome do ouvinte dnnlsnr e a porta do ouvinte como 6789, siga estas etapas:

  1. Abra uma ferramenta de interface de linha de comando, como o prompt de comando ou o PowerShell.

  2. Navegue até onde você salvou o .ps1 script, como c:\Documents.

  3. Execute o script: add_dnn_listener.ps1 <ag name> <listener-name> <listener port>. Por exemplo:

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

Verificar ouvinte

Use o SQL Server Management Studio ou o Transact-SQL para confirmar se o ouvinte do DNN foi criado com êxito.

SQL Server Management Studio

Expanda os ouvintes do grupo de disponibilidade no SQL Server Management Studio (SSMS) para exibir o ouvinte de DNN:

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

Transact-SQL

Use o Transact-SQL para exibir o status do ouvinte DNN:

SELECT * FROM SYS.AVAILABILITY_GROUP_LISTENERS

Um valor de 1 para is_distributed_network_name indica que o ouvinte é um ouvinte de DNN (nome de rede distribuída):

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

Atualizar cadeia de conexão

Atualize a cadeia de conexão para qualquer aplicativo que precise se conectar ao ouvinte DNN. A cadeia de conexão para o ouvinte DNN deve fornecer o número da porta DNN e especificar MultiSubnetFailover=True na cadeia de conexão. Se o SQL cliente não for compatível com o parâmetro MultiSubnetFailover=True, ele não será compatível com um ouvinte DNN.

Veja o seguinte exemplo de uma cadeia de conexão para o nome de ouvinte DNN_Listener e porta 6789:

DataSource=DNN_Listener,6789;MultiSubnetFailover=True

Failover de Teste

Teste o failover do grupo de disponibilidade para garantir a funcionalidade.

Para testar o failover, siga estas etapas:

  1. Conecte-se ao ouvinte DNN ou a uma das réplicas usando SQL Server Management Studio (SSMS).
  2. Expanda Grupos de Disponibilidade Always On no Pesquisador de Objetos.
  3. Clique com o botão direito do mouse no grupo de disponibilidade e escolha Failover para abrir o Assistente de Failover.
  4. Siga os prompts para escolher um destino de failover e fazer failover do grupo de disponibilidade para uma réplica secundária.
  5. Confirme se o banco de dados está em um estado sincronizado na nova réplica primária.
  6. (Opcional) Fail back para o primário original ou outra réplica secundária.

Testar a conectividade

Teste a conectividade com o ouvinte DNN com estas etapas:

  1. Abra o SQL Server Management Studio.
  2. Conecte-se ao ouvinte DNN.
  3. Abra uma nova janela de consulta e verifique a qual réplica você está conectado executando SELECT @@SERVERNAME.
  4. Fazer fail do grupo de disponibilidade para outra réplica.
  5. Após um período razoável, execute para SELECT @@SERVERNAME confirmar se o grupo de disponibilidade agora está hospedado em outra réplica.

Limitações

  • Ouvintes DNN DEVEM ser configurados com uma porta exclusiva. A porta não pode ser compartilhada com nenhuma outra conexão em nenhuma réplica.
  • O cliente que se conecta ao ouvinte DNN, deve dar suporte ao MultiSubnetFailover=True parâmetro na cadeia de conexão.
  • Pode haver novas questões quando você estiver trabalhando com outros recursos do SQL Server e uma FCI com um DNN. Para obter mais informações, consulte AG com interoperabilidade do DNN.

Considerações sobre potras

Os ouvintes DNN são projetados para escutar em todos os endereços IP, mas em uma porta específica e exclusiva. A entrada DNS para o nome do ouvinte deve ser resolvida para os endereços de todas as réplicas no grupo de disponibilidade. Isso é feito automaticamente com o script do PowerShell fornecido na seção Criar script. Como os ouvintes DNN aceitam conexões em todos os endereços IP, é essencial que a porta do ouvinte seja exclusiva e não seja usada por nenhuma outra réplica no grupo de disponibilidade. Como o SQL Server escuta na porta 1433 por padrão, diretamente ou por meio do serviço SQL Browser, não é recomendado usar essa porta para o ouvinte DNN.

Se a porta do ouvinte escolhida para o ouvinte VNN estiver entre 49.152 e 65.536 (o intervalo de porta dinâmica padrão para TCP/IP, adicione uma exclusão para isso. Isso impedirá que outros sistemas sejam atribuídos dinamicamente à mesma porta.

Você pode adicionar uma exclusão de porta com o seguinte comando: netsh int ipv4 add excludedportrange tcp startport=<Listener Port> numberofports=1 store=persistent

Próximas etapas

Depois que o grupo de disponibilidade for implantado, considere otimizar as Configurações de HADR para o SQL Server em VMs do Azure.

Para obter mais informações, consulte: