Solucionar problemas de respostas de tráfego de back-end do Balanceador de Carga do Azure

  • Artigo

Esta página fornece informações de solução de problemas para perguntas sobre o Balanceador de Carga do Azure.

As máquinas virtuais por trás de um balanceador de carga estão recebendo distribuição desigual de tráfego

Se você suspeitar que os membros do pool de back-end estão recebendo tráfego, isso pode ser devido às seguintes causas. O Azure Load Balancer distribui o tráfego com base em conexões. Certifique-se de verificar a distribuição de tráfego por conexão e não por pacote. Verifique usando a guia Distribuição de fluxo no painel pré-configurado do Load Balancer Insights.

O Azure Load Balancer não suporta o verdadeiro balanceamento de carga round robin, mas suporta um modo de distribuição baseado em hash.

Causa 1: Você tem persistência de sessão configurada

Usar o modo de distribuição de persistência de origem pode causar uma distribuição desigual do tráfego. Se essa distribuição não for desejada, atualize a persistência da sessão para None para que o tráfego seja distribuído em todas as instâncias íntegras no pool de back-end. Saiba mais sobre os modos de distribuição para o Azure Load Balancer.

Causa 2: Você tem um proxy configurado

Os clientes que são executados atrás de proxies podem ser vistos como um aplicativo cliente exclusivo do ponto de vista do balanceador de carga.

As VMs atrás de um balanceador de carga não estão respondendo ao tráfego na porta de dados configurada

Se uma VM de pool de back-end estiver listada como íntegra e responder aos testes de integridade, mas ainda não estiver participando do balanceamento de carga ou não estiver respondendo ao tráfego de dados, isso pode ser devido a qualquer um dos seguintes motivos:

  • Uma VM do pool de back-end do balanceador de carga não está escutando na porta de dados

  • O grupo de segurança de rede está bloqueando a porta na VM do pool de back-end do balanceador de carga

  • Acessando o balanceador de carga da mesma VM e NIC

  • Acessando o front-end do balanceador de carga da Internet a partir da VM do pool de back-end do balanceador de carga participante

Causa 1: Uma VM do pool de back-end do balanceador de carga não está escutando na porta de dados

Se uma VM não responder ao tráfego de dados, pode ser porque a porta de destino não está aberta na VM participante ou porque a VM não está escutando nessa porta.

Validação e resolução

  1. Entre na VM de back-end.

  2. Abra um prompt de comando e execute o seguinte comando para validar que há um aplicativo escutando na porta de dados: 

    netstat -an

  3. Se a porta não estiver listada com o estado LISTENING, configure a porta de ouvinte adequada

  4. Se a porta estiver marcada como LISTENING, verifique o aplicativo de destino nessa porta para quaisquer possíveis problemas.

Causa 2: Um grupo de segurança de rede está bloqueando a porta na VM do pool de back-end do balanceador de carga

Se um ou mais grupos de segurança de rede configurados na sub-rede ou na VM estiverem bloqueando o IP ou a porta de origem, a VM não poderá responder.

Para o balanceador de carga público, o endereço IP dos clientes da Internet será usado para comunicação entre os clientes e as VMs de back-end do balanceador de carga. Verifique se o endereço IP dos clientes é permitido no grupo de segurança de rede da VM de back-end.

  1. Liste os grupos de segurança de rede configurados na VM de back-end. Para obter mais informações, consulte Gerenciar grupos de segurança de rede

  2. Na lista de grupos de segurança de rede, verifique se:

    • O tráfego de entrada ou saída na porta de dados tem interferência.

    • Uma regra de grupo de segurança de rede Negar Tudo na NIC da VM ou da sub-rede que tem uma prioridade maior do que a regra padrão que permite as sondas e o tráfego do balanceador de carga (os grupos de segurança de rede devem permitir o IP do balanceador de carga 168.63.129.16, ou seja, a porta de teste)

  3. Se alguma das regras estiver bloqueando o tráfego, remova e reconfigure essas regras para permitir o tráfego de dados. 

  4. Teste se a VM já começou a responder às sondas de integridade.

Causa 3: Acesso do balanceador de carga interno da mesma VM e interface de rede

Se seu aplicativo hospedado na VM de back-end de um balanceador de carga interno estiver tentando acessar outro aplicativo hospedado na mesma VM de back-end pela mesma interface de rede, é um cenário sem suporte e falhará.

Resolução

Pode resolver este problema através de um dos seguintes métodos:

  • Configure VMs de pool de back-end separadas por aplicativo.

  • Configure o aplicativo em VMs NIC duplas para que cada aplicativo estivesse usando sua própria interface de rede e endereço IP.

Causa 4: Acesso do front-end do balanceador de carga interno a partir da VM do pool de back-end do balanceador de carga participante

Se um balanceador de carga interno estiver configurado dentro de uma rede virtual e uma das VMs de back-end participante estiver tentando acessar o front-end do balanceador de carga interno, poderão ocorrer falhas quando o fluxo for mapeado para a VM de origem. Este cenário não é suportado.

Resolução

Há várias maneiras de desbloquear esse cenário, incluindo o uso de um proxy. Avalie o Application Gateway ou outros proxies de terceiros (por exemplo, nginx ou haproxy). Para obter mais informações sobre o Application Gateway, consulte Visão geral do Application Gateway

Detalhes

Os balanceadores de carga internos não traduzem conexões originadas de saída para o front-end de um balanceador de carga interno porque ambos estão no espaço de endereço IP privado. Os balanceadores de carga públicos fornecem conexões de saída de endereços IP privados dentro da rede virtual para endereços IP públicos. Para balanceadores de carga internos, essa abordagem evita o possível esgotamento da porta SNAT dentro de um espaço de endereço IP interno exclusivo, onde a tradução não é necessária.

Um efeito colateral é que, se um fluxo de saída de uma VM no pool de back-end tentar um fluxo para o front-end do balanceador de carga interno em seu pool e for mapeado de volta para si mesmo, as duas pernas do fluxo não coincidem. Como eles não correspondem, o fluxo falha. O fluxo será bem-sucedido se o fluxo não for mapeado de volta para a mesma VM no pool de back-end que criou o fluxo para o front-end.

Quando o fluxo é mapeado de volta para si mesmo, o fluxo de saída parece se originar da VM para o front-end, e o fluxo de entrada correspondente parece se originar da VM para si mesma. Do ponto de vista do sistema operacional convidado, as partes de entrada e saída do mesmo fluxo não correspondem dentro da máquina virtual. A pilha TCP não reconhecerá essas metades do mesmo fluxo como sendo parte do mesmo fluxo. A origem e o destino não coincidem. Quando o fluxo é mapeado para qualquer outra VM no pool de back-end, as metades do fluxo correspondem e a VM pode responder ao fluxo.

O sintoma para esse cenário é o tempo limite de conexão intermitente quando o fluxo retorna ao mesmo back-end que originou o fluxo. As soluções alternativas comuns incluem a inserção de uma camada de proxy atrás do balanceador de carga interno e o uso de regras de estilo DSR (Direct Server Return). Para obter mais informações, consulte Vários frontends para o Azure Load Balancer.

Você pode combinar um balanceador de carga interno com qualquer proxy de terceiros ou usar o Application Gateway interno para cenários de proxy com HTTP/HTTPS. Embora você possa usar um balanceador de carga público para mitigar esse problema, o cenário resultante é propenso ao esgotamento do SNAT. Evite esta segunda abordagem, a menos que seja cuidadosamente gerida.

Próximos passos

Se as etapas anteriores não resolverem o problema, abra um tíquete de suporte.