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

  • 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.

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.

Pré-requisitos

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

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:

  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.

    Shortcut menu for the DNN resource, with the Properties command highlighted.

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

    Clear the check box next to the nodes that do not participate in the FCI for possible owners of the DNN resource

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

  1. Conecte-se a um dos nós de cluster da FCI do SQL Server usando o protocolo RDP.
  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.

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=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.

Próximas etapas

Para obter mais informações, consulte: