As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

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 grupos de destino do Network Load Balancer.

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

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

Verifique o seguinte:

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:

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.

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 ter mais informações, consulte Visualizar o mapa de recursos do Network Load Balancer.

O mapa de recursos fornece duas visualizações: Visão geral e Mapa de destinos não íntegros. 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.

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: