Configurar um DNN para uma instância de cluster de failover
Aplica-se a: 
SQL Server na VM do Azure
Em Máquinas Virtuais do Azure, o DNN roteia o tráfego para o recurso clusterizado apropriado. Ele facilita mais a conexão à FCI do SQL Server do que o VNN (nome da rede virtual), sem a necessidade de um Azure Load Balancer.
Este artigo ensina a configurar um recurso de DNN para rotear o tráfego para a sua instância de cluster de failover com SQL Server em VMs do Azure para HADR (alta disponibilidade e recuperação de desastres).
Se desejar uma opção de conectividade alternativa, considere um nome de rede virtual e o Azure Load Balancer.
Visão geral
O DNN substitui o VNN como ponto de conexão quando usado com uma instância de cluster de failover Always On no VMs SQL Server. Isso elimina a necessidade de roteamento de tráfego do Azure Load Balancer para a VNN, simplificando a implantação, a manutenção e melhorando o failover.
Com uma implantação de FCI o VNN continua existindo, mas o cliente se conecta ao nome DNS do DNN, e não ao nome da VNN.
Dica
Simplifique sua implantação sem precisar usar o Azure Load Balancer ou um DNN (nome de rede distribuída) para a instância de cluster de failover criando suas máquinas virtuais (VMs) do SQL Server em várias sub-redes na mesma rede virtual do Azure.
Pré-requisitos
Para realizar as etapas deste artigo, você já deve ter:
- SQL Server a partir do SQL Server 2019 CU8 e posterior, SQL Server 2017 CU25 e posterior ou SQL Server 2016 SP3 e posterior no Windows Server 2016 e posterior.
- Decidido que o nome de rede distribuída é a melhor opção de conectividade para sua solução HADR.
- Configurado suas instâncias de cluster de failover.
- Instalado a versão mais recente do PowerShell.
Observação
Quando você tem vários AGs ou FCIs no mesmo cluster e usa um ouvinte DNN ou VNN, cada AG ou FCI precisa de seu próprio ponto de conexão independente.
Criar um recurso de DNN
O recurso de DNN e a FCI do SQL Server são criados no mesmo grupo de clusters. Use o PowerShell para criar o recurso de DNN no grupo de clusters FCI.
O comando do PowerShell a seguir adiciona um recurso de DNN ao grupo de clusters FCI do SQL Server com um nome de recurso do <dnnResourceName>. O nome do recurso é usado para identificá-lo de forma exclusiva. Escolha um que faça sentido para você e seja exclusivo em todo o cluster. O tipo de recurso deve ser o Distributed Network Name.
O valor -Group deve ser o nome do grupo de clusters correspondente à FCI do SQL Server em que você deseja adicionar o nome de rede distribuída. Em instâncias padrão, o formato típico é SQL Server (MSSQLSERVER).
Add-ClusterResource -Name <dnnResourceName> `
-ResourceType "Distributed Network Name" -Group "<WSFC role of SQL Server instance>"
Por exemplo, para criar o recurso de DNN dnn-demo para uma FCI padrão do SQL Server, use este comando do PowerShell:
Add-ClusterResource -Name dnn-demo `
-ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)"
Definir o nome DNS do cluster DNN
Defina o nome DNS do recurso de DNN no cluster. O cluster usa esse valor para rotear o tráfego para o nó que, no momento, hospeda a FCI do SQL Server.
Os clientes usam o nome DNS para fazer conexão com a FCI do SQL Server. Se preferir, escolha um valor exclusivo. Ou, se já houver uma FCI e você não quiser atualizar as cadeias de conexão do cliente, poderá configurar o DNN para usar o VNN já em uso pelos clientes. Para isso, você deverá renomear o VNN antes de definir o DNN no DNS.
Use este comando para definir o nome DNS para o seu DNN:
Get-ClusterResource -Name <dnnResourceName> | `
Set-ClusterParameter -Name DnsName -Value <DNSName>
O valor DNSName é o que os clientes usam para se conectar à FCI do SQL Server. Por exemplo, para que os clientes se conectem ao FCIDNN, use este comando do PowerShell:
Get-ClusterResource -Name dnn-demo | `
Set-ClusterParameter -Name DnsName -Value FCIDNN
Agora, os clientes digitarão FCIDNN em sua cadeia de conexão ao se conectarem à FCI do SQL Server.
Aviso
Não exclua o VNN atual, pois ele é um componente necessário da infraestrutura da FCI.
Renomear o VNN
Se você já tiver um nome de rede virtual e quiser que os clientes continuem usando esse valor para se conectarem à FCI do SQL Server, deverá renomear o VNN atual para um valor de espaço reservado. Após renomear o VNN atual, você poderá definir o valor do nome DNS para o DNN como o VNN.
Há algumas restrições para renomear o VNN. Para mais informações, consulte Renomear uma FCI.
Se não precisar usar o VNN atual, pule esta seção. Após mudar o VNN, defina o nome DNS do cluster DNN.
Definir um recurso de DNN online
Após nomear o recurso de DNN adequadamente e definir o valor do nome DNS no cluster, use o PowerShell para definir o recurso DNN online no cluster:
Start-ClusterResource -Name <dnnResourceName>
Por exemplo, para iniciar o recurso de DNN dnn-demo, use este comando do PowerShell:
Start-ClusterResource -Name dnn-demo
Configurar possíveis proprietários
Por padrão, o cluster associa o nome DNS do DNN a todos os nós no cluster. No entanto, os nós no cluster que não integram a FCI do SQL Server devem ser excluídos da lista de possíveis proprietários de DNN.
Para atualizar proprietários, siga estas etapas:
Acesse o recurso de DNN no Gerenciador de Cluster de Failover.
Clique com o botão direito do mouse no recurso de DNN e selecione Propriedades.
Desmarque a caixa de seleção para todos os nós que não participam da instância de cluster de failover. A lista de possíveis proprietários do recurso de DNN deve corresponder à de possíveis proprietários do recurso da instância do SQL Server. Por exemplo, supondo que Data3 não participe da FCI, a imagem a seguir exemplifica a remoção de Data3 da lista de possíveis proprietários do recurso de DNN:
Selecione OK para salvar as configurações.
Reinicie a Instância do SQL Server
Use o Gerenciador de Cluster de Failover para reiniciar a instância do SQL Server. Siga estas etapas:
- Acesse o recurso do SQL Server no Gerenciador de Cluster de Failover.
- Clique com o botão direito do mouse no recurso SQL Server e deixe-o offline.
- Após todos os recursos associados estarem offline, clique com o botão direito do mouse no recurso do SQL Server e recoloque-o online.
Atualizar cadeia de conexão
Atualize a cadeia de conexão de qualquer aplicativo que se conecta ao SQL Server FCI DNN e inclua MultiSubnetFailover=True na cadeia de conexão. Se o cliente não oferecer suporte ao parâmetro MultiSubnetFailover, ele não será compatível com um DNN.
Veja a seguir um exemplo de cadeia de conexão para um SQL FCI DNN com o nome DNS de FCIDNN:
Data Source=FCIDNN, MultiSubnetFailover=True
Além disso, se o DNN não estiver usando o VNN original, os clientes SQL que se conectarem à FCI do SQL Server deverão atualizar sua cadeia de conexão com o nome DNS do DNN. Para evitar essa exigência, você pode atualizar o valor do nome DNS para que seja o nome do VNN. Mas, para isso, deverá antes substituir o VNN existente por um espaço reservado.
Failover de Teste
Teste o failover do recurso clusterizado para verificar a funcionalidade do cluster.
Para testar o failover, siga estas etapas:
- Conecte-se a um dos nós de cluster da FCI do SQL Server usando o protocolo RDP ou Bastion.
- Abra o Gerenciador de Cluster de Failover. Selecione funções. Observe qual nó possui a função FCI do SQL Server.
- Clique com o botão direito do mouse na função FCI do SQL Server.
- Selecione Mover e O Melhor Nó Possível.
O Gerenciador de Cluster de Failover mostra a função e seus recursos ficam offline. Os recursos então são movidos e ficam online novamente no outro nó.
Testar a conectividade
Para testar a conectividade, entre em outra máquina virtual na mesma rede virtual. Abra o SQL Server Management Studio e conecte-se à FCI do SQL Server usando o nome DNS do DNN.
Se necessário, baixe o SQL Server Management Studio.
Evitar conflitos de IP
Esta é uma etapa opcional, para impedir que o mesmo VIP (endereço IP virtual) usado pelo recurso FCI seja atribuído a outro recurso no Azure.
Embora os clientes agora usem o DNN para se conectar à FCI do SQL Server, o VNN e o IP virtual não podem ser excluídos, pois são componentes necessários à infraestrutura da FCI. No entanto, como não há mais um balanceador de carga reservando o endereço IP virtual no Azure, há risco de que outro recurso na rede virtual receba o mesmo endereço IP que o endereço IP virtual usado pela FCI. Isso pode gerar um problema de conflito de IP duplicado.
Configure um endereço APIPA ou adaptador de rede dedicado para reservar o endereço IP.
Endereço APIPA
Para evitar o uso de endereços IP duplicados, configure um endereço APIPA (também conhecido como endereço local de link). Para fazer isso, execute o comando a seguir:
Get-ClusterResource "virtual IP address" | Set-ClusterParameter
–Multiple @{"Address"="169.254.1.1";"SubnetMask"="255.255.0.0";"OverrideAddressMatch"=1;"EnableDhcp"=0}
Nesse comando, "endereço IP virtual" é o nome do recurso de endereço VIP clusterizado e "169.254.1.1" é o endereço APIPA definido para o endereço VIP. Escolha o mais adequado à sua empresa. Defina OverrideAddressMatch=1 para permitir que o endereço IP esteja em qualquer rede, inclusive o espaço de endereço APIPA.
Adaptador de rede do tipo dedicado
Outra opção é configurar um adaptador de rede no Azure para reservar o endereço IP usado pelo recurso de endereço IP virtual. No entanto, isso consome o endereço no espaço de endereço da sub-rede e há a preocupação adicional de garantir que o adaptador de rede não seja usado para nenhuma outra finalidade.
Limitações
- O cliente que se conecta ao ouvinte DNN, deve dar suporte ao
MultiSubnetFailover=Trueparâ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 mais informações, consulte FCI com interoperabilidade de DNN.
Próximas etapas
Para obter mais informações, consulte: