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

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

As máquinas virtuais atrás de um balanceador de carga estão a receber uma distribuição desigual do tráfego

Se suspeitar que os membros do conjunto de back-end estão a receber tráfego, tal pode dever-se às seguintes causas. Balanceador de Carga do Azure distribui o tráfego com base nas ligações. Certifique-se de que verifica a distribuição de tráfego por ligação e não por pacote. Verifique com o separador Distribuição de Fluxos no dashboard do Balanceador de Carga Insights pré-configurado.

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

Causa 1: Tem a persistência da sessão configurada

A utilização do modo de distribuição de persistência de origem pode causar uma distribuição desigual do tráfego. Se esta distribuição não for pretendida, atualize a persistência da sessão como Nenhuma para que o tráfego seja distribuído por todas as instâncias em bom estado de funcionamento no conjunto de back-end. Saiba mais sobre os modos de distribuição para Balanceador de Carga do Azure.

Causa 2: tem um proxy configurado

Os clientes que são executados atrás de proxies podem ser vistos como uma aplicação cliente exclusiva do ponto de vista do balanceador de carga.

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

Se uma VM do conjunto de back-end estiver listada como estando em bom estado de funcionamento e responder às pesquisas de estado de funcionamento, mas ainda não estiver a participar no balanceamento de carga ou não estiver a responder ao tráfego de dados, tal poderá dever-se a qualquer um dos seguintes motivos:

  • Uma VM do conjunto de back-end do balanceador de carga não está a escutar na porta de dados

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

  • Aceder ao balanceador de carga a partir da mesma VM e NIC

  • Aceder ao front-end do balanceador de carga da Internet a partir da VM do conjunto de back-end do balanceador de carga participante

Causa 1: uma VM do conjunto de back-end do balanceador de carga não está a escutar na porta de dados

Se uma VM não responder ao tráfego de dados, poderá dever-se ao facto de a porta de destino não estar aberta na VM participante ou a VM não estar a escutar nessa porta.

Validação e resolução

  1. Inicie sessão na VM de back-end.

  2. Abra uma linha de comandos e execute o seguinte comando para validar que existe uma aplicação a escutar na porta de dados:

    netstat -an 
    
  3. Se a porta não estiver listada com o estado ESCUTAR, configure a porta do serviço de escuta adequada

  4. Se a porta estiver marcada como ESCUTA, verifique se existem possíveis problemas na aplicação de destino nessa porta.

Causa 2: um grupo de segurança de rede está a bloquear a porta na VM do conjunto 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 a bloquear 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á utilizado para a comunicação entre os clientes e as VMs de back-end do balanceador de carga. Confirme que 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, veja Gerir 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ências.

    • Uma regra negar todos os grupos de segurança de rede na NIC da VM ou da sub-rede que tem uma prioridade mais alta que a regra predefinida que permite as sondas e o tráfego do balanceador de carga (os grupos de segurança de rede têm de permitir o IP do balanceador de carga de 168.63.129.16, que é a porta de pesquisa)

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

  4. Teste se a VM começou agora a responder às pesquisas de estado de funcionamento.

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

Se a aplicação alojada na VM de back-end de um balanceador de carga interno estiver a tentar aceder a outra aplicação alojada na mesma VM de back-end na mesma interface de rede, será um cenário não suportado e falhará.

Resolução

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

  • Configurar VMs de conjuntos de back-end separadas por aplicação.

  • Configure a aplicação em VMs NIC duplas para que cada aplicação utilizasse a 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 conjunto 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 a tentar aceder ao front-end do balanceador de carga interno, podem ocorrer falhas quando o fluxo é mapeado para a VM de origem. Este cenário não é suportado.

Resolução

Existem várias formas de desbloquear este cenário, incluindo a utilização de um proxy. Avalie Gateway de Aplicação ou outros proxies de terceiros (por exemplo, nginx ou haproxy). Para obter mais informações sobre Gateway de Aplicação, consulte Descrição geral do Gateway de Aplicação

Detalhes

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

Um efeito secundário é que, se um fluxo de saída de uma VM no conjunto de back-end tentar um fluxo para o front-end do balanceador de carga interno no conjunto e for mapeado de volta para si mesmo, as duas pernas do fluxo não correspondem. Uma vez que não correspondem, o fluxo falha. O fluxo será bem-sucedido se o fluxo não tiver mapeado novamente para a mesma VM no conjunto de back-end que criou o fluxo para o front-end.

Quando o fluxo é mapeado para si próprio, o fluxo de saída parece ter origem na VM para o front-end e o fluxo de entrada correspondente parece ter origem na VM para a própria. Do ponto de vista do sistema operativo convidado, as partes de entrada e saída do mesmo fluxo não correspondem dentro da máquina virtual. A pilha TCP não reconhece estas metades do mesmo fluxo como fazendo parte do mesmo fluxo. A origem e o destino não correspondem. Quando o fluxo mapeia para qualquer outra VM no conjunto de back-end, as metades do fluxo correspondem e a VM pode responder ao fluxo.

O sintoma para este cenário são tempos limite de ligação intermitentes quando o fluxo regressa ao mesmo back-end que originou o fluxo. As soluções comuns incluem a inserção de uma camada de proxy por trás do balanceador de carga interno e a utilização de regras de estilo de Devolução do Servidor Direto (DSR). Para obter mais informações, veja Vários front-ends para Balanceador de Carga do Azure.

Pode combinar um balanceador de carga interno com qualquer proxy de terceiros ou utilizar Gateway de Aplicação internos para cenários de proxy com HTTP/HTTPS. Embora possa utilizar um balanceador de carga público para mitigar este problema, o cenário resultante é propenso ao esgotamento do SNAT. Evite esta segunda abordagem, a menos que seja cuidadosamente gerida.

Passos seguintes

Se os passos anteriores não resolverem o problema, abra um pedido de suporte.