Problemas conhecidos para balanceadores de carga de rede

Problemas conhecidos são bugs identificados ou comportamentos inesperados que não foram corrigidos antes do lançamento, mas não eram críticos o suficiente para atrasá-lo. Esses problemas são comunicados a você, geralmente com soluções alternativas, e são priorizados para resolução em curto prazo pela equipe de desenvolvimento.

As seções a seguir contêm problemas conhecidos para balanceadores de carga de rede (NLBs) públicos, privados e de caminho privado.

Problemas conhecidos para balanceadores de carga de rede pública e privada

  • Um NLB exige que cada combinação de membro e porta seja única.

  • A porta de uma instância de servidor virtual do membro NLB pode ser usada apenas para o tráfego NLB

  • Cada ouvinte é mapeado para um único pool (relação de um para um).

  • Um NLB utiliza as interfaces de rede primárias de seus membros associados para o tráfego de dados. Interfaces de rede não primárias não são compatíveis.

  • Para aumentar a disponibilidade, use uma sub-rede dedicada para NLBs. Coloque clientes e membros em sub-redes separadas, quando possível.

  • Dois membros com a mesma instância X e a mesma porta Y não podem existir ao mesmo tempo para um NLB. Por exemplo, não há suporte para dois membros que usam a mesma porta de servidor na mesma instância, e o roteamento do tráfego pode falhar. Para obter mais informações, consulte Por que não consigo adicionar membros com a mesma porta de servidor ao meu NLB?

  • Para um NLB com o modo de roteamento ativado:

    • Somente as instâncias de função de rede virtual (VNF) são compatíveis como alvos de back-end. Ao usar APIs, defina port_min como 1 e port_max como 65535; deixe port vazio.
    • Somente um listener é suportado.
    • O NLB e os destinos de back-end do VNF devem estar na mesma sub-rede.

  • Para obter informações sobre cotas e limites de serviço, consulte Cotas e limites de serviço para balanceadores de carga de rede. Para solicitar um aumento, crie um caso de suporte.

  • Ao criar um ouvinte para um NLB, você pode especificar um protocol de tcp ou udp. No entanto, cada ouvinte no NLB deve usar um port exclusivo.

  • [privado do NLB] O serviço NLB pode adicionar regras às tabelas de roteamento personalizadas para garantir a disponibilidade do serviço em determinadas condições de falha. Consequentemente, se o cliente estiver fora da zona e/ou da VPC do NLB, é necessário configurar uma tabela de roteamento personalizada de entrada na VPC que hospeda o NLB com a origem de tráfego apropriada.

  • Private NLB A tabela de roteamento de entrada necessária depende da localização do cliente:

    Fontes de tráfego que exigem tabelas de roteamento personalizadas de entrada.
    Local do cliente Tipo de tabela de roteamento Origem de tráfego
    No local Ingresso Direct Link
    Outra VPC ou infraestrutura clássica Ingresso Transit Gateway
    Outra Zona de Disponibilidade da mesma VPC Ingresso Zona da VPC

    Para obter mais informações, consulte Sobre tabelas de roteamento e rotas.

  • Você pode ter no máximo 128 configurações de retorno de servidor direto para cada instância de servidor virtual de membro de back-end.

  • Quando uma instância de destino de membro é excluída, o membro do pool NLB correspondente não é removido automaticamente.

Problemas conhecidos dos balanceadores de carga de rede Private Path

  • Quando você configura um ALB como membro do NLB de caminho privado, o status da verificação de integridade do NLB TCP sempre mostra OK, mesmo que os membros do pool do ALB não estejam saudáveis.

  • Os membros do pool do Private Path NLB devem ser instâncias de servidor virtual VPC ou IPs reservados na mesma VPC que o balanceador de carga. Para alcançar membros fora da VPC (por exemplo, membros no local), você pode configurar um ALB como membro do pool de NLB de caminho privado e definir os destinos remotos como membros do ALB. Para obter mais informações, consulte Conexão de um serviço local a um consumidor usando um ALB em um pool de NLB de caminho privado.

  • Não há suporte para o acesso a um caminho privado NLB de uma região diferente. O gateway VPE do consumidor e a instância do Private Path NLB devem estar na mesma região.

    Solução alternativa: Crie um gateway de trânsito para conectar a VPC do consumidor na região remota à VPC que hospeda o VPE de caminho privado. Em seguida, acesse o serviço por meio desse VPE. Para obter ajuda com a configuração, entre em contato com o Suporte da IBM.

  • Não há suporte para o acesso a NLBs de caminho privado a partir da infraestrutura clássica.

    Solução alternativa: Crie um gateway de trânsito do ambiente clássico para o VPC que hospeda o VPE de caminho privado. Em seguida, acesse o serviço por meio desse VPE.

  • O controle de acesso ao balanceador de carga é gerenciado por meio de um serviço de caminho privado. Não há suporte para grupos de segurança e listas de controle de acesso à rede (NACLs).

  • UDP não é compatível com o caminho de dados do balanceador de carga.

  • A integração do Autoscaler não é suportada

  • O MTU máximo para tráfego NLB de caminho privado é 8500.

  • Para obter informações sobre cotas e limites de serviço, consulte Cotas e limites de serviço para balanceadores de carga de rede de caminho privado. Para solicitar um aumento, crie um caso de suporte.

  • Ao criar um NLB de caminho privado, há um problema conhecido em que os campos de solicitação e resposta do monitor de integridade não são retornados na resposta da API GET.