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 ter mais informações, consulte Verificações de integridade para os grupos de destino.

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 ter mais informações, consulte Grupos de segurança de destino.

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 ter 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 ter mais informações, consulte Grupos de segurança de destino.

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 ter 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.

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.

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.

• 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 ao conectar-se por meio do AWS PrivateLink

Se o Network Load Balancer estiver associado a um serviço de endpoint da VPC, ele oferecerá 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 essas conexões, há uma chance maior de erros de alocação de porta. Os erros na alocação de portas podem ser rastreados por meio da métrica PortAllocationErrorCount. Para corrigir erros na alocação de portas, adicione mais destinos ao grupo de destino. Para ter mais informações, consulte CloudWatch métricas para seu Network Load Balancer.

Falha intermitente de conexão quando a preservação do IP do cliente está habilitada

Quando a preservação do IP do cliente está habilitada, você pode encontrar limitações de conexão TCP/IP relacionadas à reutilização observada de soquetes nos destinos. Essas limitações de conexão podem ocorrer quando um cliente ou um dispositivo NAT na frente do cliente usa o mesmo endereço IP de origem e porta de origem ao se conectar a vários nós do balanceador de carga simultaneamente. Se o balanceador de carga rotear essas conexões para o mesmo destino, as conexões aparecerão no destino como se viessem do mesmo soquete de origem, o que resultará em erros de conexão. Se isso acontecer, os clientes poderão tentar novamente (se a conexão falhar) ou se reconectar (se a conexão for interrompida). Você pode reduzir esse tipo de erro de conexão aumentando o número de portas temporárias de origem ou aumentando o número de destinos para o balanceador de carga. Você pode evitar esse tipo de erro de conexão desabilitando a preservação do IP do cliente ou desabilitando o balanceamento de carga entre zonas.

Além disso, quando a preservação do IP do cliente está habilitada, a conectividade poderá falhar se os clientes que estiverem se conectando ao Network Load Balancer também estiverem conectados a destinos atrás do balanceador de carga. Para resolver isso, você pode desabilitar a preservação do IP do cliente nos grupos de destino afetados. Como alternativa, faça com que seus clientes se conectem somente ao Network Load Balancer ou somente aos destinos, mas não a ambos.

Atrasos na conexão TCP

Quando o balanceamento de carga entre zonas e a preservação do IP do cliente estão habilitados, um cliente conectado a diferentes IPs no mesmo balanceador de carga pode ser roteado para o mesmo destino. Se o cliente usar a mesma porta de origem para essas duas conexões, o destino receberá o que aparentemente é uma conexão duplicada, o que poderá levar a erros de conexão e atrasos de TCP no estabelecimento de novas conexões. Você pode evitar esse tipo de erro de conexão desabilitando o balanceamento de carga entre zonas. Para ter mais informações, consulte Balanceamento de carga entre zonas.

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.

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.