Estamos usando o TCP Google Cloud Loadbalancer para um de nossos serviços.
A arquitetura é a seguinte: Existe um balanceador de carga TCP no qual um intervalo de portas é permitido no frontend e suas instâncias de backend estão conectadas e os serviços de instâncias estão rodando na mesma porta que está aberta no LB.
Por exemplo: LB IP -1.1.1.1:(100-200)ou seja, o intervalo de portas está aberto. Agora, no back-end, 3 instâncias estão em execução e os serviços estão em execução nas portas 100, 101 e 103.
Como usuário, se quiser acessar o serviço rodando na porta 100 você deve usar LB IP:100 para acessar os serviços. Mas nos últimos dias o pedido está diminuindo. No entanto, se você tentar se conectar diretamente na instância, o serviço IP:100 funcionará bem. portanto, não sou capaz de descobrir a causa exata. As solicitações também são baseadas em TCP, então por que LB as está descartando.
Por favor, sugira-me algumas contribuições. Obs: Existe alguma forma de verificar os logs do LB do GCloud ou Console???
Responder1
Publicando a resposta do próprio OP para melhor visibilidade:
Meu problema não foi devido ao LB.
Meu LB usa algoritmo round robin, apenas passando a solicitação sem verificar o status do servidor back-end. Apenas um dos meus servidores estava em execução, então metade das solicitações foram descartadas.
Acabei de configurar mais uma instância no mesmo LB e o problema foi resolvido.
Esse tipo de solução é a mais "grosseira" e não oferece nenhuma proteção contra falhas. Se algum servidor cair, algumas solicitações serão descartadas e o serviço será rebaixado.
A solução mais simples para evitar isso seria criar umgrupo de instâncias gerenciadasE useexames de saúdepara verificar se todas as VMs estão em execução e, em seguida, criar umBalanceador de carga.