Resolva problemas com equilibradores de carga de aplicações internos

Este guia descreve como resolver problemas de configuração para um Cloud de Confiance by S3NS Application Load Balancer interno. Antes de seguir este guia, familiarize-se com o seguinte:

Os back-ends têm modos de balanceamento incompatíveis

Ao criar um equilibrador de carga, pode ver o erro:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Isto acontece quando tenta usar o mesmo back-end em dois balanceadores de carga diferentes e os back-ends não têm modos de balanceamento compatíveis.

Para mais informações, consulte o seguinte:

O tráfego com balanceamento de carga não tem o endereço de origem do cliente original

Este comportamento é o esperado. Um balanceador de carga de aplicações interno funciona como um proxy inverso(gateway) HTTP (S). Quando um programa cliente abre uma ligação ao endereço IP de uma regra de encaminhamento INTERNAL_MANAGED, a ligação termina num proxy. O proxy processa os pedidos que chegam através dessa ligação. Para cada pedido, o proxy seleciona um back-end para receber o pedido com base no mapa de URLs e noutros fatores. Em seguida, o proxy envia o pedido para o back-end selecionado. Como resultado, do ponto de vista do back-end, a origem de um pacote recebido é um endereço IP da sub-rede apenas de proxy da região.

Os pedidos são rejeitados pelo balanceador de carga

Para cada pedido, o proxy seleciona um back-end para receber o pedido com base num correspondente de caminho no mapa de URLs do equilibrador de carga. Se o mapa de URLs não tiver um matcher de caminhos definido para um pedido, não pode selecionar um serviço de back-end, pelo que devolve um código de resposta HTTP 404 (Não encontrado).

O balanceador de carga não se liga aos back-ends

As firewalls que protegem os seus servidores de back-end têm de ser configuradas para permitir o tráfego de entrada dos proxies no intervalo da sub-rede só de proxy que atribuiu à região do balanceador de carga de HTTP(S) interno.

Os proxies estabelecem ligação aos back-ends através das definições de ligação especificadas pela configuração do seu serviço de back-end. Se estes valores não corresponderem à configuração dos servidores em execução nos seus back-ends, o proxy não pode encaminhar pedidos para os back-ends.

As sondas de verificação de funcionamento não conseguem alcançar os back-ends

Para verificar se o tráfego de verificação de funcionamento chega às VMs de back-end, ative o registo da verificação de funcionamento e pesquise entradas de registo bem-sucedidas.

Os clientes não conseguem estabelecer ligação ao equilibrador de carga

Os proxies ouvem as ligações ao endereço IP e à porta do balanceador de carga configurados na regra de encaminhamento (por exemplo, 10.1.2.3:80) e com o protocolo especificado na regra de encaminhamento (HTTP ou HTTPS). Se os seus clientes não conseguirem estabelecer ligação, certifique-se de que estão a usar o endereço, a porta e o protocolo corretos.

Certifique-se de que uma firewall não está a bloquear o tráfego entre as instâncias do cliente e o endereço IP com balanceamento de carga.

Certifique-se de que os clientes estão na mesma região que o balanceador de carga. O balanceamento de carga HTTP(S) interno é um produto regional, pelo que todos os clientes (e back-ends) têm de estar na mesma região que o recurso do balanceador de carga.

Restrição da política organizacional para a VPC partilhada

Se estiver a usar a VPC partilhada e não conseguir criar um novo Application Load Balancer interno numa sub-rede específica, a causa pode ser uma política da organização. Na política da organização, adicione a sub-rede à lista de sub-redes permitidas ou contacte o administrador da organização. Para mais informações, consulte constraints/compute.restrictSharedVpcSubnetworks.

O balanceador de carga não distribui o tráfego uniformemente pelas zonas

Pode observar um desequilíbrio no tráfego do balanceador de carga da aplicação interno em várias zonas. Isto pode acontecer especialmente quando existe uma utilização baixa (< 10%) da capacidade do back-end.

Este comportamento pode afetar a latência geral, uma vez que o tráfego é enviado apenas para alguns servidores numa zona.

Para equilibrar a distribuição do tráfego entre zonas, pode fazer as seguintes alterações de configuração:

  • Use o RATE modo de equilíbrio com uma capacidade alvo max-rate-per-instance baixa.
  • Use a política de tráfego de back-end LocalityLbPolicy com um algoritmo de balanceamento de carga de LEAST_REQUEST.

5xx erros não explicados

Para condições de erro causadas por um problema de comunicações entre o proxy do balanceador de carga e os respetivos back-ends, o balanceador de carga gera um código de estado HTTP (5xx) e devolve esse código de estado ao cliente. Nem todos os erros de HTTP são gerados pelo balanceador de carga. Por exemplo, se um back-end enviar uma resposta HTTP 5xx ao balanceador de carga, o balanceador de carga retransmite essa resposta ao respetivo cliente.5xx Para determinar se uma resposta HTTP 5xx foi retransmitida a partir de um back-end ou se foi gerada pelo proxy do balanceador de carga, consulte o campo proxyStatus dos registos do balanceador de carga.

As alterações de configuração ao balanceador de carga de aplicações interno, como a adição ou a remoção de um serviço de back-end, podem resultar num breve período em que os utilizadores veem o código de estado HTTP 503. Embora estas alterações de configuração sejam propagadas para os Envoys a nível global, vê entradas de registo em que o campo proxyStatus corresponde à string de registo connection_refused.

Se os códigos de estado HTTP 5xx persistirem durante mais do que alguns minutos após concluir a configuração do balanceador de carga, siga estes passos para resolver problemas com as respostas HTTP 5xx:

  1. Verifique se existe uma regra de firewall configurada para permitir verificações de estado. Na ausência de um, os registos do balanceador de carga têm normalmente uma proxyStatuscorrespondênciadestination_unavailable, o que indica que o balanceador de carga considera que o back-end está indisponível.

  2. Verifique se o tráfego de verificação de estado atinge as VMs de back-end. Para tal, ative o registo de verificações de funcionamento e pesquise entradas de registo bem-sucedidas.

    Para novos equilibradores de carga, a ausência de entradas de registo de verificações de funcionamento bem-sucedidas não significa que o tráfego de verificações de funcionamento não esteja a chegar aos seus back-ends. Isto pode significar que o estado de funcionamento inicial do back-end ainda não foi alterado de UNHEALTHY para um estado diferente. Só vê entradas de registo de verificação de estado bem-sucedidas depois de o verificador de estado receber uma resposta HTTP 200 OK do back-end.

  3. Verifique se o parâmetro de configuração de keepalive para o software do servidor HTTP em execução na instância de back-end não é inferior ao limite de tempo de keepalive do balanceador de carga, cujo valor é fixo em 10 minutos (600 segundos) e não é configurável.

    O balanceador de carga gera um código de estado HTTP 5xx quando a ligação ao back-end é fechada inesperadamente durante o envio do pedido HTTP ou antes de receber a resposta HTTP completa. Isto pode acontecer porque o parâmetro de configuração keepalive para o software do servidor Web em execução na instância de back-end é inferior ao limite de tempo keepalive fixo do equilibrador de carga. Certifique-se de que a configuração do limite de tempo de keepalive para o software do servidor HTTP em cada back-end está definida para um valor ligeiramente superior a 10 minutos (o valor recomendado é de 620 segundos).

Limitações

Se tiver problemas ao usar um balanceador de carga de aplicações interno com outrasCloud de Confiance funcionalidades de rede, tenha em atenção as limitações de compatibilidade atuais.