Solucionar problemas do Network Load Balancer

As informações a seguir podem ajudar na solução de problemas com o Network Load Balancer.

Um destino registrado não está em serviço

Se um destino estiver levando mais tempo que o esperado para entrar no estado InService, ele pode estar falhando nas verificações de integridade. O destino não entrará em serviço até ser aprovado em uma verificação de integridade. Para obter mais informações, consulte Verificações de integridade para grupos de destino do Network Load Balancer.

Verifique se a sua instância está falhando nas verificações de integridade e verifique o seguinte:

Um security group não permite o tráfego

Os security groups associados a uma instância devem permitir tráfego do load balancer usando a porta de verificação de integridade e o protocolo de verificação de integridade. Para obter mais informações, consulte Grupos de segurança de destino. Além disso, o security group para seu load balancer deve permitir o tráfego para as instâncias. Para obter mais informações, consulte Atualizar os grupos de segurança para o Network Load Balancer.

Uma lista de controle de acesso (ACL) à rede não permite o tráfego

A ACL da rede associada às sub-redes das instâncias e as sub-redes do balanceador de carga devem permitir tráfego e verificações de integridade do balanceador de carga. Para obter mais informações, consulte Network ACLs.

As solicitações não são roteadas para os destinos

Verifique o seguinte:

Um security group não permite o tráfego

Os security groups associados às instâncias devem permitir tráfego na porta do listener de endereços IP do cliente (se os destinos são especificados por ID de instância) ou nós do load balancer (se os destinos são especificados por endereço IP). Para obter mais informações, consulte Grupos de segurança de destino. Além disso, o security group para seu load balancer deve permitir o tráfego para as instâncias. Para obter mais informações, consulte Atualizar os grupos de segurança para o Network Load Balancer.

Uma lista de controle de acesso (ACL) à rede não permite o tráfego

As ACLs à redes associadas às sub-redes para a VPC devem permitir que o load balancer e os destinos se comuniquem nas duas direções da porta do listener. Para obter mais informações, consulte Network ACLs.

Os destinos estão em uma zona de disponibilidade que não está habilitada

Se você registrar destinos em uma zona de disponibilidade, mas não habilitá-la, esses destinos registrados não receberão tráfego do load balancer.

A instância está em uma VPC emparelhada

Se você tiver instâncias em uma VPC emparelhada com a VPC do load balancer, será necessário registrá-las no load balancer por endereço IP, não por ID de instância.

A ID do servidor configurada não corresponde à ID configurada no destino

Se você estiver usando receptores QUIC, a ID configurada no destino precisa corresponder à ID configurada com o grupo de destino do Network Load Balancer.

Os destinos recebem mais solicitações de verificação de integridade do que o esperado

As verificações de integridade de um Network Load Balancer são distribuídas e usam um mecanismo de consenso para determinar a integridade do destino. Portanto, os destinos recebem mais do que o número configurado de verificações de integridade por meio da configuração HealthCheckIntervalSeconds.

Os destinos recebem menos solicitações de verificação de integridade do que o esperado

Verifique se net.ipv4.tcp_tw_recycle está habilitado. Essa configuração é conhecida por causar problemas com load balancers. A configuração net.ipv4.tcp_tw_reuse é considerada uma alternativa mais segura.

Destinos não íntegros recebem solicitações do load balancer

Isso ocorre quando todos os destinos registrados não são íntegros. Se houver pelo menos um destino registrado íntegro, o Network Load Balancer roteará solicitações somente aos destinos registrados íntegros.

Quando houver apenas destinos registrados não íntegros, o Network Load Balancer roteará solicitações para todos os destinos registrados, o que é conhecido como modo de falha na abertura. O Network Load Balancer faz isso em vez de remover todos os endereços IP do DNS quando nenhum destino está íntegro e as respectivas zonas de disponibilidade não têm um destino íntegro para o qual enviar a solicitação.

As verificações de integridade HTTP ou HTTPS falham no destino devido à incompatibilidade do cabeçalho de host

O cabeçalho de host HTTP na solicitação de verificação de integridade contém o endereço IP do nó do load balancer e a porta do listener, não o endereço IP do destino e a porta de verificação de integridade. Se você estiver mapeando solicitações de entrada por cabeçalho de host, deverá garantir que as verificações de integridade correspondam a qualquer cabeçalho de host HTTP. Outra opção é adicionar um serviço HTTP separado em uma porta diferente e configurar o grupo de destino para usar essa porta para verificações de integridade. Como alternativa, considere usar verificações de integridade TCP.

Não é possível associar um grupo de segurança a um balanceador de carga

Se o Network Load Balancer foi criado sem grupos de segurança, ele não é compatível com grupos de segurança após a criação. Você só pode associar um grupo de segurança a um balanceador de carga durante a criação ou a um balanceador de carga existente que foi originalmente criado com grupos de segurança.

Não é possível remover todos os grupos de segurança

Se o Network Load Balancer foi criado com grupos de segurança, deve haver pelo menos um grupo de segurança associado a ele o tempo todo. Você não pode remover todos os grupos de segurança do balanceador de carga ao mesmo tempo.

Aumento na métrica TCP_ELB_Reset_Count

Para cada solicitação de TCP que um cliente faz por meio de um Network Load Balancer, o estado da conexão é rastreado. Se nenhum dado é enviado por meio da conexão pelo cliente ou pelo destino por um período que ultrapasse o tempo limite de inatividade, a conexão é fechada. Se um cliente envia dados depois do tempo limite de inatividade, ele recebe um pacote TCP RST para indicar que a conexão não é mais válida. Além disso. se um destino se tornar não íntegro, o balanceador de carga enviará um TCP RST para pacotes recebidos nas conexões de cliente associadas ao destino, a menos que o destino não íntegro acione o balanceador de carga para apresentar falha na abertura.

Se você observar um pico na métrica TCP_ELB_Reset_Count pouco antes ou logo após o aumento da métrica UnhealthyHostCount, provavelmente os pacotes TCP RST foram enviados porque o destino estava começando a falhar, mas não estava marcado como não íntegro. Se você observar aumentos persistentes em TCP_ELB_Reset_Count sem que as metas sejam marcadas como não íntegras, verifique os logs de fluxo da VPC para clientes que enviam dados em fluxos expirados.

As conexões expiram para solicitações de um destino para o load balancer

Verifique se a preservação de IP do cliente está habilitada no grupo de destino. O loopback NAT, também conhecido como hairpinning, não é compatível quando a preservação do IP do cliente está habilitada.

Se uma instância é um cliente de um balanceador de carga no qual está registrada e ela tem a preservação do IP do cliente habilitada, a conexão só é bem-sucedida se a solicitação é roteada para uma instância diferente. Se a solicitação for roteada para a mesma instância da qual foi enviada, a conexão expirará porque os endereços IP de origem e destino são os mesmos. Observe que isso se aplica aos pods do Amazon EKS executados na mesma instância de nó de processamento do EC2, mesmo que tenham endereços IP diferentes.

Se uma instância deve enviar solicitações para um load balancer com o qual está registrada, siga um destes procedimentos:

• Desabilite a preservação do IP do cliente. Em vez disso, use o Proxy Protocol v2 para obter o endereço IP do cliente.

• Certifique-se de que os contêineres que devem se comunicar estão em diferentes instâncias de contêiner.

O desempenho diminui ao mover destinos para um Network Load Balancer

Tanto os Classic Load Balancers quanto os Application Load Balancers usam multiplexação de conexão, mas os Network Load Balancers, não. Portanto, os destinos podem receber mais conexões TCP atrás de um Network Load Balancer. Certifique-se de que os destinos estejam preparados para lidar com o volume de solicitações de conexão que possam receber.

Erros de alocação de porta para fluxos de backend

Com o tráfego do PrivateLink ou quando a preservação do IP do cliente está desabilitada, o Network Load Balancer oferece suporte a 55 mil conexões simultâneas ou a cerca de 55 mil conexões por minuto para cada destino exclusivo (endereço IP e porta). Se você exceder esses limites, há uma chance maior de erros de alocação de porta. É possível rastrear os erros na alocação de portas por meio da métrica PortAllocationErrorCount. Você pode rastrear as conexões ativas usando a métrica ActiveFlowCount. Para obter mais informações, consulte Métricas do CloudWatch para o Network Load Balancer.

Para corrigir erros na alocação de portas, é recomendável adicionar destinos ao grupo de destino.

Como alternativa, se não puder adicionar destinos ao grupo de destino, você poderá adicionar até 7 endereços IP secundários às interfaces de rede do balanceador de carga. Os endereços IP secundários são alocados automaticamente a partir dos blocos CIDR IPv4 das sub-redes correspondentes. Cada endereço IP secundário consome 6 unidades de endereçamento de rede. Após adicionar um endereço IP secundário, você não poderá removê-lo. A única maneira de liberar os endereços IP secundários é excluir o balanceador de carga.

Falha intermitente no estabelecimento da conexão TCP ou atrasos no estabelecimento da conexão TCP

Quando a preservação do endereço IP do cliente estiver habilitada, ele poderá se conectar a um endereço IP de destino diferente usando a mesma porta de origem temporária. Esses endereços IP de destino podem ser do mesmo balanceador de carga (em diferentes zonas de disponibilidade) quando o balanceamento de carga entre zonas estiver habilitado ou balanceadores de carga de rede diferentes, que usem o mesmo endereço IP de destino e porta, estiverem registrados. Nesse caso, se essas conexões forem roteadas para o mesmo endereço IP e porta de destino, haverá uma conexão duplicada no destino, pois as conexões tiveram como origem o mesmo endereço IP e porta do cliente. Isso leva a erros de conexão e atrasos ao estabelecer uma dessas conexões. Isso ocorre com frequência quando um dispositivo NAT na frente do cliente e o mesmo endereço IP e porta de origem são alocados para a conexão a vários endereços IP do Network Load Balancer simultaneamente.

Você pode reduzir esse tipo de erro de conexão aumentando o número de portas de origem temporárias alocadas pelo cliente ou dispositivo NAT ou aumentando o número de destinos para o balanceador de carga. Recomendamos que os clientes alterem a porta de origem usada ao se reconectar após essas falhas de conexão. Para evitar esse tipo de erro de conexão, se você estiver usando um único Network Load Balancer, considere desabilitar o balanceamento de carga entre zonas ou, se estiver usando vários Network Load Balancers, considere não usar o mesmo endereço IP e porta de destino registrados em vários grupos de destino. Como alternativa, você pode desabilitar a preservação do IP do cliente. Se precisar do IP do cliente, você poderá recuperá-lo usando o Proxy Protocol v2. Para saber mais sobre o Proxy Protocol v2, consulte Proxy Protocol.

Possível falha quando o balanceador de carga está sendo provisionado

Um dos motivos pelos quais um Network Load Balancer poderá falhar quando estiver sendo provisionado é se você usar um endereço IP que já está atribuído ou alocado em outro lugar (por exemplo, atribuído como endereço IP secundário para uma instância do EC2). Esse endereço IP impede que o balanceador de carga seja configurado e seu estado é failed. Você pode resolver isso ao remover a alocação do endereço IP associado e tentando novamente o processo de criação.

O tráfego é distribuído de forma desigual entre os destinos

Os receptores TCP e TLS fazem o roteamento de conexões TCP, ao passo que os receptores UDP fazem o roteamento de fluxos UDP. O balanceador de carga seleciona os destinos usando um algoritmo de hash de fluxo. Uma única conexão de um cliente é inerentemente fixa.

Se você perceber que alguns destinos parecem receber mais tráfego do que outros, recomendamos que você analise os logs de fluxo da VPC. Compare o número de conexões exclusivas para cada endereço IP de destino. Mantenha o período o mais curto possível, pois o registro, o cancelamento do registro e os destinos não íntegros influenciam esses números de conexão.

A seguir, possíveis cenários em que as conexões podem ser distribuídas de forma desigual:

• Se você começar com um pequeno número de destinos e depois registrar destinos adicionais posteriormente, os destinos originais ainda terão conexões com os clientes. Com uma workload HTTP, os keepalives garantem que os clientes reutilizem as conexões. Se você diminuir o número máximo de keepalives em sua aplicação da Web, os clientes abrirão novas conexões com mais frequência.

• Se a aderência do grupo de destino estiver habilitada, se houver um pequeno número de clientes e os clientes se comunicarem por meio de um dispositivo NAT com um único endereço IP de origem, as conexões desses clientes serão roteadas para o mesmo destino.

• Se o balanceamento de carga entre zonas estiver desabilitado e os clientes preferirem o endereço IP do balanceador de carga de uma das zonas do balanceador de carga, as conexões serão distribuídas de forma desigual entre as zonas do balanceador de carga.

A resolução de nomes de DNS contém menos endereços IP do que as zonas de disponibilidade habilitadas

Idealmente, seu Network Load Balancer fornece um endereço IP por zona de disponibilidade habilitada quando ele têm pelo menos um host íntegro na zona de disponibilidade. Quando não houver um host íntegro em uma zona de disponibilidade específica e o balanceamento de carga entre zonas estiver desativado, o endereço IP do Network Load Balancer respectivo a essa AZ será removido do DNS.

Por exemplo, suponha que o Network Load Balancer tenha três zonas de disponibilidade habilitadas, todas com pelo menos uma instância de destino registrada íntegra.

• Se as instâncias de destino registradas na zona de disponibilidade A se tornarem não íntegras, o endereço IP correspondente da zona de disponibilidade A para o Network Load Balancer será removido do DNS.

• Se duas das zonas de disponibilidade habilitadas não tiverem instâncias de destino registradas íntegras, os respectivos dois endereços IP do Network Load Balancer serão removidos do DNS.

• Se não houver instâncias de destino registradas íntegras em todas as zonas de disponibilidade habilitadas, o modo de falha na abertura será habilitado e o DNS fornecerá todos os endereços IP das três AZs habilitadas no resultado.

Pacotes IP fragmentados não são roteados para os destinos

Os Network Load Balancers não são compatíveis com pacotes IP fragmentados para tráfego não UDP.

Solucionar problemas de destinos não íntegros usando o mapa de recursos

Se suas metas do Network Load Balancer estiverem falhando nas verificações de integridade, você poderá usar o mapa de recursos para encontrar destinos não íntegros e realizar ações com base no código do motivo da falha. Para obter mais informações, consulte Visualizar o mapa de recursos do Network Load Balancer.

O mapa de recursos fornece duas exibições: Visão geral e Mapa de destino não íntegro. A opção Visão geral é selecionada por padrão e exibe todos os recursos do seu balanceador de carga. Selecionar a visualização Mapa de destinos não íntegros exibirá somente os destinos não íntegros em cada grupo de destino associado ao Network Load Balancer.

nota

A opção Mostrar detalhes do recurso deverá estar ativada para que seja possível visualizar o resumo da verificação de integridade e as mensagens de erro de todos os recursos aplicáveis no mapa de recursos. Se não estiver habilitada, será necessário selecionar cada recurso para visualizar seus detalhes.

A coluna Grupos de destino exibe um resumo dos destinos íntegros e não íntegros de cada grupo de destino. Isso pode ajudar a determinar se todos os destinos estão falhando nas verificações de integridade ou se somente destinos específicos estão falhando. Se todos os destinos em um grupo de destino falharem nas verificações de integridade, verifique as configurações da verificação de integridade do grupo de destino. Selecione o nome de um grupo de destino para abrir sua página de detalhes em uma nova guia.

A coluna Destinos exibe o TargetID e o status atual da verificação de integridade de cada destino. Quando um destino não está íntegro, o código do motivo da falha da verificação de integridade é exibido. Quando um único destino está falhando em uma verificação de integridade, verifique se o destino tem recursos suficientes. Selecione um ID de destino para abrir sua página de detalhes em uma nova guia.

Selecionar Exportar oferece a você a opção de exportar a visualização atual do mapa de recursos do seu Network Load Balancer como PDF.

Verifique se a sua instância está falhando nas verificações de integridade e, com base no código de motivo da falha, verifique os seguintes problemas:

• Não íntegro: a solicitação excedeu o tempo limite

  • Verifique se os grupos de segurança e as listas de controle de acesso (ACL) à rede associados aos seus destinos e ao Network Load Balancer não estão bloqueando a conectividade.

  • Verifique se o destino tem capacidade suficiente disponível para aceitar conexões do Network Load Balancer.

  • As respostas da verificação de integridade do Network Load Balancer podem ser visualizadas nos registros de aplicações de cada destino. Para obter mais informações, consulte Códigos de motivo da verificação de integridade.

• Não íntegro: falhas nas verificações de integridade

  • Verifique se o destino está escutando tráfego na porta de verificação de integridade.

    Ao usar um receptor TLS

    Você escolhe qual política de segurança é usada para conexões de frontend. A política de segurança usada para conexões de backend é selecionada automaticamente com base na política de segurança de frontend em uso.

    • Se seu receptor TLS estiver usando uma política de segurança TLS 1.3 para conexões de frontend, a política de segurança ELBSecurityPolicy-TLS13-1-0-2021-06 será usada para conexões de backend.

    • Se seu receptor TLS não estiver usando uma política de segurança TLS 1.3 para conexões de frontend, a política de segurança ELBSecurityPolicy-2016-08 será usada para conexões de backend.

    Para obter mais informações, consulte Políticas de segurança.

  • Verifique se o destino está fornecendo um certificado e uma chave de servidor no formato correto especificado pela política de segurança.

  • Verifique se o destino oferece suporte uma ou mais cifras correspondentes e a um protocolo fornecido pelo Network Load Balancer para estabelecer handshakes TLS.