Partilhar via


Configurar uma DNN para instância de cluster de failover

Aplica-se a:SQL Server na VM do Azure

Gorjeta

Há muitos métodos para implantar um grupo de disponibilidade. Simplifique sua implantação e elimine a necessidade de um Balanceador de Carga do Azure ou DNN (nome de rede distribuída) para seu grupo de disponibilidade Always On criando suas máquinas virtuais (VMs) do SQL Server em várias sub-redes dentro da mesma rede virtual do Azure. Se você já criou seu grupo de disponibilidade em uma única sub-rede, pode migrá-lo para um ambiente de várias sub-redes.

Nas Máquinas Virtuais do Azure, o DNN (nome da rede distribuída) roteia o tráfego para o recurso clusterizado apropriado. Ele fornece uma maneira mais fácil de se conectar à FCI (instância de cluster de failover) do SQL Server do que o nome da rede virtual (VNN), sem a necessidade de um Balanceador de Carga do Azure.

Este artigo ensina a configurar um recurso DNN para rotear o tráfego para sua instância de cluster de failover com o SQL Server em VMs do Azure para alta disponibilidade e recuperação de desastres (HADR).

Para uma opção de conectividade alternativa, considere um nome de rede virtual e o Azure Load Balancer .

Descrição geral

O DNN (nome de rede distribuída) substitui o nome da rede virtual (VNN) como o ponto de conexão quando usado com uma instância de cluster de failover Always On em VMs do SQL Server. Isso anula a necessidade de um tráfego de roteamento do Azure Load Balancer para a VNN, simplificando a implantação, a manutenção e melhorando o failover.

Com uma implantação FCI, a VNN ainda existe, mas o cliente se conecta ao nome DNS DNN em vez do nome VNN.

Pré-requisitos

Antes de concluir as etapas neste artigo, você já deve ter:

Criar recurso DNN

O recurso DNN é criado no mesmo grupo de clusters que a FCI do SQL Server. Use o PowerShell para criar o recurso DNN dentro do grupo de clusters FCI.

O comando PowerShell a seguir adiciona um recurso DNN ao grupo de clusters FCI do SQL Server com um nome de recurso de <dnnResourceName>. O nome do recurso é usado para identificar exclusivamente um recurso. Use um que faça sentido para você e seja exclusivo em todo o cluster. O tipo de recurso deve ser Distributed Network Name.

O -Group valor deve ser o nome do grupo de clusters que corresponde à FCI do SQL Server onde você deseja adicionar o nome da rede distribuída. Para uma instância 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 seu recurso dnn-demo DNN para uma FCI padrão do SQL Server, use o seguinte comando do PowerShell:

Add-ClusterResource -Name dnn-demo `
-ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)"

Definir nome DNS DNN do cluster

Defina o nome DNS para o recurso DNN no cluster. Em seguida, o cluster usa esse valor para rotear o tráfego para o nó que está hospedando atualmente a FCI do SQL Server.

Os clientes usam o nome DNS para se conectar à FCI do SQL Server. Você pode escolher um valor único. Ou, se você já tiver uma FCI existente e não quiser atualizar as cadeias de conexão do cliente, poderá configurar a DNN para usar a VNN atual que os clientes já estão usando. Para fazer isso, você precisa renomear a VNN antes de definir a DNN no DNS.

Use este comando para definir o nome DNS para sua DNN:

Get-ClusterResource -Name <dnnResourceName> | `
Set-ClusterParameter -Name DnsName -Value <DNSName>

O DNSName valor é o que os clientes usam para se conectar à FCI do SQL Server. Por exemplo, para que os clientes se conectem ao FCIDNN, use o seguinte comando do PowerShell:

Get-ClusterResource -Name dnn-demo | `
Set-ClusterParameter -Name DnsName -Value FCIDNN

Agora, os clientes entrarão FCIDNN em sua cadeia de conexão ao se conectarem à FCI do SQL Server.

Aviso

Não exclua o nome da rede virtual (VNN) atual, pois é um componente necessário da infraestrutura FCI.

Renomeie a VNN

Se você tiver um nome de rede virtual existente e quiser que os clientes continuem usando esse valor para se conectar à FCI do SQL Server, deverá renomear a VNN atual para um valor de espaço reservado. Depois que a VNN atual for renomeada, você poderá definir o valor do nome DNS para a DNN como VNN.

Algumas restrições se aplicam para renomear a VNN. Para obter mais informações, consulte Renomeando uma FCI.

Se o uso da VNN atual não for necessário para sua empresa, ignore esta seção. Depois de renomear a VNN, defina o nome DNS DNN do cluster.

Definir recurso DNN online

Depois que o recurso DNN for nomeado adequadamente e você tiver definido 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 seu recurso dnn-demoDNN, use o seguinte comando do PowerShell:

Start-ClusterResource -Name dnn-demo

Configurar possíveis proprietários

Por padrão, o cluster vincula o nome DNS DNN a todos os nós do 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 da DNN.

Para atualizar possíveis proprietários, siga estas etapas:

  1. Vá para o recurso DNN no Gerenciador de Cluster de Failover.

  2. Clique com o botão direito do mouse no recurso 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 para o recurso DNN deve corresponder à lista de possíveis proprietários para o recurso de instância do SQL Server. Por exemplo, supondo que Data3 não participa da FCI, a imagem a seguir é um exemplo de remoção de Data3 da lista de possíveis proprietários para o recurso 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 guardar as definições.

Reiniciar instância do SQL Server

Use o Gerenciador de Cluster de Failover para reiniciar a instância do SQL Server. Siga estes passos:

  1. Vá para o recurso do SQL Server no Gerenciador de Cluster de Failover.
  2. Clique com o botão direito do mouse no recurso do SQL Server e coloque-o offline.
  3. Depois que todos os recursos associados estiverem offline, 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 conecte à DNN FCI do SQL Server e inclua MultiSubnetFailover=True na cadeia de conexão. Se o cliente não suportar o parâmetro MultiSubnetFailover, não será compatível com um DNN.

A seguir está 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 a DNN não estiver usando a VNN original, os clientes SQL que se conectarem à FCI do SQL Server precisarão atualizar sua cadeia de conexão para o nome DNS da DNN. Para evitar esse requisito, você pode atualizar o valor do nome DNS para ser o nome da VNN. Mas você precisará substituir a VNN existente por um espaço reservado primeiro.

Teste de ativação pós-falha

Teste o failover do recurso clusterizado para validar 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 RDP.
  2. Abra o Gestor de Clusters de Ativação Pós-falha. 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, em seguida, selecione Melhor nó possível.

O Gerenciador de Cluster de Failover mostra a função e seus recursos ficam offline. Em seguida, os recursos são movidos e ficam online novamente no outro nó.

Testar 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 DNN.

Se precisar, você pode baixar o SQL Server Management Studio.

Evitar conflitos de IP

Esta é uma etapa opcional para impedir que o endereço IP virtual (VIP) usado pelo recurso FCI seja atribuído a outro recurso no Azure como uma duplicata.

Embora os clientes agora usem a DNN para se conectar à FCI do SQL Server, o nome da rede virtual (VNN) e o IP virtual não podem ser excluídos, pois são componentes necessários da infraestrutura FCI. No entanto, como não há mais um balanceador de carga reservando o endereço IP virtual no Azure, há um 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 potencialmente levar a um problema de conflito de IP duplicado.

Configure um endereço APIPA ou um 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 link-local). Para fazer isso, execute o seguinte comando:

Get-ClusterResource "virtual IP address" | Set-ClusterParameter 
    –Multiple @{"Address"="169.254.1.1";"SubnetMask"="255.255.0.0";"OverrideAddressMatch"=1;"EnableDhcp"=0}

Neste comando, "endereço IP virtual" é o nome do recurso de endereço VIP clusterizado e "169.254.1.1" é o endereço APIPA escolhido para o endereço VIP. Escolha a morada que melhor se adequa ao seu negócio. Definido OverrideAddressMatch=1 para permitir que o endereço IP esteja em qualquer rede, incluindo o espaço de endereço APIPA.

Adaptador de rede dedicado

Como alternativa, configure 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 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 suportar o MultiSubnetFailover=True parâmetro na cadeia de conexão.
  • Pode haver mais considerações quando você estiver trabalhando com outros recursos do SQL Server e uma FCI com uma DNN. Para obter mais informações, consulte FCI com interoperabilidade DNN.

Próximos passos

Para saber mais, consulte: