Configurar um DNN para uma instância de cluster de failover

Aplica-se a:SQL Server na VM do Azure

Em VMs (Máquinas Virtuais) do Azure, o DNN (nome de rede distribuída) 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).

Para uma opção de conectividade alternativa, considere um VNN (nome de rede virtual) e um 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. Configurar um DNN nega a necessidade de um Azure Load Balancer rotear o tráfego para a VNN, simplificando a implantação, a manutenção e a melhoria do 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.

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.
• Configurou suas instâncias de cluster de failover.
• Instalado a versão mais recente do PowerShell.

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 do DNS (sistema de nomes de domínio) para o recurso 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 você já tiver uma FCI existente e não quiser atualizar as cadeias de conexão do cliente. Você pode configurar o DNN para utilizar a VNN atual que os clientes já estão utilizando. 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

Os clientes agora devem inserir FCIDNN na sua cadeia de conexão ao se conectarem à FCI do SQL Server.

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. Se o uso da VNN atual não for necessário para sua empresa, ignore esta seção.

Há algumas restrições para renomear o VNN. Para mais informações, consulte Renomear uma FCI.

Depois de renomear o VNN, defina o nome DNS DNN do cluster.

Definir um recurso de DNN online

Depois que o recurso DNN for nomeado adequadamente e você 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 fazem parte da FCI do SQL Server devem ser excluídos da lista de possíveis proprietários de DNN.

Para atualizar proprietários, siga estas etapas:

1. Acesse o recurso de DNN no Gerenciador de Cluster de Failover.

2. Clique com o botão direito do mouse no recurso de DNN e selecione Propriedades.

   

3. 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 o Data3 não participe da FCI, a imagem a seguir é um exemplo de remoção do Data3 da lista de possíveis proprietários para o recurso DNN:

   

4. 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:

1. Acesse o recurso do SQL Server no Gerenciador de Cluster de Failover.
2. Clique com o botão direito do mouse no recurso SQL Server e deixe-o offline.
3. Aguarde até que todos os recursos associados estejam offline. Em seguida, clique com o botão direito do mouse no recurso do SQL Server e coloque-o online novamente.

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 der 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 conectam à FCI do SQL Server precisarão atualizar sua cadeia de conexão para o nome DNS DNN. Para evitar essa exigência, você pode atualizar o valor do nome DNS para que seja o nome do VNN. Mas você precisa substituir a VNN existente por um marcador primeiro.

Failover de Teste

Teste o failover do recurso clusterizado para verificar a funcionalidade do cluster.

Para testar o failover, siga estas etapas:

1. Conecte-se a um dos nós de cluster do SQL Server usando o Bastion.
2. Abra o Gerenciador de Cluster de Failover. Selecione funções. Observe qual nó possui a função FCI do SQL Server.
3. Clique com o botão direito do mouse na função FCI do SQL Server.
4. 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.

Instale a versão mais recente do SSMS (SQL Server Management Studio).

Evitar conflitos de IP

Você pode executar essa etapa opcional para impedir que o endereço VIP (IP virtual) usado pelo recurso FCI seja atribuído a outro recurso no Azure.

Embora seus clientes agora usem a DNN para se conectar à FCI do SQL Server, você não pode excluir o nome da rede virtual (VNN) e o IP virtual porque eles são componentes necessários da infraestrutura fci. No entanto, não há mais um balanceador de carga reservando o endereço IP virtual no Azure. Portanto, há o risco de que outro recurso na rede virtual possa receber o mesmo endereço IP que o endereço IP virtual usado pela FCI. Essa situação pode potencialmente levar a 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

Como alternativa, você pode configurar um adaptador de rede no Azure para reservar o endereço IP usado pelo recurso de endereço IP virtual. No entanto, essa configuração consome o endereço no espaço de endereço da sub-rede e requer a sobrecarga adicional de garantir que o adaptador de rede não seja usado para qualquer outra finalidade.

Limitações

• 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 mais informações, consulte FCI com interoperabilidade de DNN.

Conteúdo relacionado

• Cluster de Failover do Windows Server com o SQL Server em VMs do Azure
• Instâncias de cluster de failover com SQL Server em Máquinas Virtuais do Azure
• Visão geral da instância de cluster de failover
• Práticas recomendadas de configuração do HADR (SQL Server em VMs do Azure)