Configurar um balanceador de carga do Azure para um ouvinte AG VNN - SQL Server em VMs do Azure

  • Artigo

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, os clusters usam um balanceador de carga para manter um endereço IP que precisa estar em um nó de cluster de cada vez. Nesta solução, o balanceador de carga mantém o endereço IP para o ouvinte de nome de rede virtual (VNN) para o grupo de disponibilidade Always On quando as VMs do SQL Server estão em uma única sub-rede.

Este artigo ensina a configurar um balanceador de carga usando o serviço Balanceador de Carga do Azure. O balanceador de carga encaminhará o tráfego para o ouvinte do grupo de disponibilidade com o SQL Server em VMs do Azure para alta disponibilidade e recuperação de desastres (HADR).

Para obter uma opção de conectividade alternativa para clientes que estão no SQL Server 2019 CU8 e posterior, considere um ouvinte DNN (nome de rede distribuído). Um ouvinte DNN oferece configuração simplificada e failover aprimorado.

Pré-requisitos

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

  • Decidiu que o Azure Load Balancer é a opção de conectividade apropriada para o seu grupo de disponibilidade.
  • Instalada a versão mais recente do PowerShell.

Criar um balanceador de carga

Você pode criar um destes tipos de balanceadores de carga:

  • Interno: um balanceador de carga interno só pode ser acessado a partir de recursos privados internos à rede. Ao configurar um balanceador de carga interno e suas regras, use o mesmo endereço IP que o ouvinte do grupo de disponibilidade para o endereço IP frontend.

  • Externo: um balanceador de carga externo pode rotear o tráfego do público para os recursos internos. Ao configurar um balanceador de carga externo, você não pode usar o mesmo endereço IP que o ouvinte do grupo de disponibilidade porque o endereço IP do ouvinte não pode ser um endereço IP público.

    Para usar um balanceador de carga externo, aloque logicamente um endereço IP na mesma sub-rede que o grupo de disponibilidade que não entre em conflito com nenhum outro endereço IP. Use esse endereço como o endereço IP do frontend para as regras de balanceamento de carga.

Importante

Em 30 de setembro de 2025, a SKU Básica para o Azure Load Balancer será desativada. Para obter mais informações, veja o anúncio oficial. Se você estiver usando o Basic Load Balancer, atualize para o Standard Load Balancer antes da data de desativação. Para obter orientações, consulte Upgrade Load Balancer.

Para criar o balanceador de carga:

  1. No portal do Azure, vá para o grupo de recursos que contém as máquinas virtuais.

  2. Selecione Adicionar. Pesquise o balanceador de carga do Azure Marketplace. Selecione Load Balancer.

  3. Selecione Criar.

  4. Em Criar balanceador de carga, na guia Noções básicas, configure o balanceador de carga usando os seguintes valores:

    • Assinatura: sua assinatura do Azure.
    • Grupo de recursos: o grupo de recursos que contém suas máquinas virtuais.
    • Nome: um nome que identifica o balanceador de carga.
    • Região: o local do Azure que contém suas máquinas virtuais.
    • SKU: Padrão.
    • Tipo: Público ou Interno. Um balanceador de carga interno pode ser acessado de dentro da rede virtual. A maioria dos aplicativos do Azure pode usar um balanceador de carga interno. Se seu aplicativo precisar de acesso ao SQL Server diretamente pela Internet, use um balanceador de carga público.
    • Nível: Regional.

    Screenshot of the Azure portal that shows the page for basic information about a load balancer.

  5. Selecione Next: Frontend IP configuration.

  6. Selecione Adicionar uma configuração de IP frontend.

    Screenshot of the Azure portal that shows the button for adding a frontend IP configuration.

  7. Configure o endereço IP frontend usando os seguintes valores:

    • Nome: um nome que identifica a configuração de IP frontend.
    • Rede virtual: a mesma rede que as máquinas virtuais.
    • Sub-rede: A mesma sub-rede que as máquinas virtuais.
    • Atribuição: Estática.
    • Endereço IP: o endereço IP que você atribuiu ao recurso de rede clusterizada.
    • Zona de disponibilidade: uma zona de disponibilidade opcional para implantar seu endereço IP.

    Screenshot of the Azure portal that shows the page for configuring a frontend IP address.

  8. Selecione Adicionar para criar o endereço IP frontend.

  9. Selecione Rever + Criar para criar o balanceador de carga.

Configurar um pool de back-end

  1. Retorne ao grupo de recursos do Azure que contém as máquinas virtuais e localize o novo balanceador de carga. Talvez seja necessário atualizar o modo de exibição no grupo de recursos. Selecione o balanceador de carga.

  2. Selecione Pools de back-end e, em seguida, selecione +Adicionar.

  3. Em Name, forneça um nome para o pool de back-end.

  4. Para Configuração do Pool de Back-end, selecione NIC.

  5. Selecione Adicionar para associar o pool de back-end ao conjunto de disponibilidade que contém as VMs.

  6. Em Máquina virtual, escolha as máquinas virtuais que participarão como nós de cluster. Certifique-se de incluir todas as máquinas virtuais que hospedarão o grupo de disponibilidade.

    Adicione apenas o endereço IP primário de cada VM. Não adicione endereços IP secundários.

  7. Selecione Adicionar para adicionar as máquinas virtuais ao pool de back-end.

  8. Selecione Salvar para criar o pool de back-end.

Configurar uma sonda de integridade

  1. No painel do balanceador de carga, selecione Sondas de integridade.

  2. No painel Adicionar sonda de integridade, defina os seguintes parâmetros:

    • Nome: um nome para a sonda de integridade.
    • Protocolo: TCP.
    • Porta: a porta que você criou no firewall para a sonda de integridade. Neste artigo, o exemplo usa a porta TCP 59999.
    • Intervalo: 5 segundos.

  3. Selecione Adicionar.

Definir regras de balanceamento de carga

  1. No painel do balanceador de carga, selecione Regras de balanceamento de carga.

  2. Selecione Adicionar.

  3. Defina estes parâmetros:

    • Nome: um nome para a regra de balanceamento de carga.
    • Endereço IP frontend: O endereço IP que você definiu quando configurou o frontend.
    • Pool de back-end: o pool de back-end que contém as máquinas virtuais destinadas ao balanceador de carga.
    • Portas HA: Permite o balanceamento de carga em todas as portas para protocolos TCP e UDP.
    • Protocolo: TCP.
    • Porta: A porta TCP do SQL Server. O padrão é 1433.
    • Porta de back-end: A mesma porta que o valor de Porta quando você habilita IP flutuante (retorno direto do servidor).
    • Sonda de integridade: a sonda de integridade que você configurou anteriormente.
    • Persistência da sessão: Nenhuma.
    • Tempo limite de inatividade (minutos): 4.
    • IP flutuante (retorno direto do servidor): Ativado.

  4. Selecione Guardar.

Configurar uma sonda de cluster

Defina o parâmetro de porta da sonda de cluster no PowerShell.

Atualize as variáveis no script a seguir com valores do seu ambiente. Remova os colchetes angulares (< e >) do script.

$ClusterNetworkName = "<Cluster Network Name>"
$IPResourceName = "<AG Listener IP Address Resource Name>" 
$ILBIP = "<n.n.n.n>" 
[int]$ProbePort = <nnnnn>

Import-Module FailoverClusters

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}

A tabela a seguir descreve os valores que você precisa atualizar:

Variável Valor
ClusterNetworkName O nome do cluster de failover do Windows Server para a rede. Em Redes do Gerenciador de Cluster de Failover, clique com o botão direito do>mouse na rede e selecione Propriedades. Poderá encontrar o valor correto em Nome no separador Geral.
IPResourceName O nome do recurso para o endereço IP do ouvinte AG. Em Funções do Gerenciador de>Cluster de Failover, na função de grupo de disponibilidade, em Nome do Servidor, clique com o botão direito do mouse no recurso de endereço IP e selecione Propriedades. Poderá encontrar o valor correto em Nome no separador Geral.
ILBIP O endereço IP do balanceador de carga interno. Esse endereço é configurado no portal do Azure como o endereço front-end do balanceador de carga interno. Este é o mesmo endereço IP que o ouvinte do grupo de disponibilidade. Você pode encontrá-lo no Gerenciador de Cluster de Failover, na mesma página de propriedades onde você localizou o valor para IPResourceName.
ProbePort A porta de teste que você configurou na sonda de integridade do balanceador de carga. Qualquer porta TCP não utilizada é válida.
SubnetMask A máscara de sub-rede para o parâmetro cluster. Deve ser o endereço de difusão TCP/IP: 255.255.255.255.

As alterações feitas não entram em vigor até que o recurso de endereço IP seja colocado offline e colocado online novamente. Execute um failover do grupo de disponibilidade para que essa alteração entre em vigor. Depois de definir a sonda de cluster, você pode ver todos os parâmetros de cluster no PowerShell. Execute este script:

Get-ClusterResource $IPResourceName | Get-ClusterParameter

Modificar a cadeia de conexão

Para clientes que oferecem suporte a ele, adicione MultiSubnetFailover=True à cadeia de conexão. Embora a MultiSubnetFailover opção de conexão não seja necessária, ela oferece o benefício de um failover de sub-rede mais rápido. Isso ocorre porque o driver do cliente tenta abrir um soquete TCP para cada endereço IP em paralelo. O driver do cliente aguarda o primeiro endereço IP para responder com sucesso. Após a resposta bem-sucedida, o driver do cliente usa esse endereço IP para a conexão.

Se o cliente não suportar o parâmetro, você poderá modificar as configurações e HostRecordTTL para evitar atrasos de conectividade após o MultiSubnetFailoverRegisterAllProvidersIP failover.

Use o PowerShell para modificar as RegisterAllProvidersIp configurações e HostRecordTTL :

Get-ClusterResource yourListenerName | Set-ClusterParameter RegisterAllProvidersIP 0  
Get-ClusterResource yourListenerName|Set-ClusterParameter HostRecordTTL 300

Para saber mais, consulte a documentação sobre o tempo limite de conexão do ouvinte no SQL Server.

Gorjeta

  • Defina o MultiSubnetFailover parameter como true na cadeia de conexão, mesmo para soluções HADR que abrangem uma única sub-rede. Essa configuração oferece suporte à abrangência futura de sub-redes sem a necessidade de atualizar cadeias de conexão.
  • Por padrão, os clientes armazenam em cache os registros DNS do cluster por 20 minutos. Ao reduzir HostRecordTTLo , você reduz o tempo de vida (TTL) do registro armazenado em cache. Os clientes legados podem então se reconectar mais rapidamente. Como tal, reduzir a configuração pode aumentar o HostRecordTTL tráfego para os servidores DNS.

Ativação pós-falha de teste

Teste o failover do recurso clusterizado para validar a funcionalidade do cluster:

  1. Abra o SQL Server Management Studio e conecte-se ao ouvinte do grupo de disponibilidade.
  2. No Pesquisador de Objetos, expanda Grupo de Disponibilidade Sempre Ativo.
  3. Clique com o botão direito do mouse no grupo de disponibilidade e selecione Failover.
  4. Siga as instruções do assistente para fazer failover do grupo de disponibilidade para uma réplica secundária.

O failover é bem-sucedido quando as réplicas alternam funções e são sincronizadas.

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 ao ouvinte do grupo de disponibilidade.

Nota

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

Próximos passos

Depois que a VNN for criada, considere otimizar as configurações de cluster para VMs do SQL Server.

Para saber mais, veja: