Solucionar problemas de respostas de tráfego de back-end do Azure Load Balancer
Esta página fornece informações para solução de problemas do Azure Load Balancer.
Máquinas virtuais por trás de um balanceador de carga estão recebendo distribuição desigual de tráfego
Se você suspeitar que membros do pool de back-end estão recebendo tráfego, pode ser devido às seguintes causas. O Azure Load Balancer distribui o tráfego com base nas conexões. Verifique a distribuição de tráfego por conexão e não por pacote. Verifique usando a guia Distribuição de Fluxo no seu painel Insights do Balanceador de Carga pré-configurado.
O Azure Load Balancer não é compatível com o balanceamento de carga true round robin, mas é compatível com um modo de distribuição baseado em hash.
Causa 1: você tem uma persistência de sessão configurada
O uso do 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 como Nenhum 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 Azure Load Balancer.
Causa 2: você tem um proxy configurado
Os clientes que são executados atrás de proxies podem ser vistos como aplicativo cliente exclusivo do ponto de vista do balanceador de carga.
As VMs por trás do balanceador de carga não estão respondendo ao tráfego na porta de dados configurada
Se uma VM do pool de back-end estiver listada como íntegra e responder às investigações de integridade, mas ainda não estiver participando do balanceamento de carga, ou não estiver respondendo ao tráfego de dados, pode ser devido a um destes motivos:
A VM do pool de back-end do balanceamento 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 balanceamento de carga
Acessando o balanceamento de carga da mesma VM e NIC
Acessando o front-end do balanceamento de carga da Internet a partir da VM participante do pool de back-end do balanceamento de carga
Causa 1: a VM do pool de back-end do balanceamento 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
Entre na VM de back-end.
Abra um prompt de comando e execute o seguinte comando para verificar se existe um aplicativo escutando na porta de dados:
netstat -anSe a porta não estiver listada com o estado LISTENING, configure a porta de ouvinte apropriada
Se a porta estiver marcada como LISTENING, verifique se há algum problema no aplicativo de destino dessa porta.
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 de origem ou a porta, 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. Garanta que o endereço IP dos clientes é permitido no grupo de segurança de rede da VM de back-end.
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
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 do grupo de segurança de rede Negar Tudo na NIC da VM ou na sub-rede tem uma prioridade mais alta do que a regra padrão que permite as investigações e o tráfego do balanceador de carga (grupos de segurança de rede devem permitir o IP 168.63.129.16 do balanceador de carga, que é a porta de investigação)
Se qualquer uma dessas regras estiver bloqueando o tráfego, remova e reconfigure as regras para permitir o tráfego de dados.
Agora, verifique se a VM começou a responder às investigações 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, este é um cenário sem suporte e falhará.
Resolução
É possível resolver esse problema usando um dos seguintes métodos:
Configure VMs de pool de back-end separadas por aplicativo.
Configure o aplicativo em VMs de NIC dupla para que cada aplicativo use sua própria interface de rede e seu endereço IP.
Causa 4: acesso do front end interno do balanceador de carga a partir da VM participante do pool de back-end do balanceador de carga
Se um balanceador de carga interno estiver configurado dentro de uma rede virtual e uma das VMs de backend do participante estiver tentando acessar o frontend interno do balanceador de carga, poderão ocorrer falhas quando o fluxo for mapeado para a VM de origem. Não há suporte para esse cenário.
Resolução
Há várias maneiras para desbloquear este cenário, incluindo o uso de um proxy. Avalie o Gateway de Aplicativo ou outros proxies de terceiros (por exemplo, nginx ou haproxy). Para saber mais sobre o Gateway de Aplicativo, confira Visão geral do Gateway de Aplicativo
Detalhes
Os balanceadores de carga internos não movem conexões originadas pela saída para o front-end de um balanceador de carga interno porque ambos estão no espaço de endereços IP privado. Os balanceadores de carga públicos fornecem conexões de saída de endereços IP privados dentro da rede virtual para os endereços IP públicos. Para balanceadores de carga internos, essa abordagem evita possível esgotamento da porta SNAT em um espaço de endereços IP interno exclusivo, no qual a movimentação não é obrigatória.
O efeito colateral é que, se um fluxo de saída de uma VM no pool de back-end tentar estabelecer um fluxo para o front-end do Load Balancer interno em seu pool e for mapeado de volta para si mesmo, os dois lados do fluxo não serão correspondentes. Como eles não correspondem, o fluxo falha. O fluxo será bem-sucedido se 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 mesmo. Do ponto de vista do sistema operacional convidado, as partes de entrada e de saída do mesmo fluxo não são correspondentes dentro da máquina virtual. A pilha TCP não reconhece essas metades do mesmo fluxo como parte do mesmo fluxo. A origem e o destino não correspondem. Quando o fluxo é mapeado para qualquer outra VM no pool de back-end, as metades do fluxo são correspondentes e a VM pode responder ao fluxo.
O sintoma desse cenário é que a conexão intermitente se esgota quando o fluxo retorna para o mesmo back-end que originou o fluxo. Soluções alternativas comuns incluem a inserção de uma camada proxy por trás do balanceador de carga interno e o uso de regras de estilo DSR (Retorno de Servidor Direto). Para obter mais informações, consulte Vários front-ends para o Azure Load Balancer.
É possível combinar um balanceador de carga interno com qualquer proxy de terceiros ou usar o Gateway de Aplicativo interno para cenários de proxy com HTTP/HTTPS. Embora você possa usar um balanceador de carga público para atenuar esse problema, o cenário resultante estará propenso ao esgotamento de SNAT. Evite essa segunda abordagem, a menos que seja cuidadosamente gerenciada.
Próximas etapas
Se as etapas anteriores não resolverem o problema, abra um tíquete de suporte.