Distribuição de tráfego para balanceadores de carga de rede de passagem interna

Esta página descreve os seguintes conceitos para ajudar você a entender melhor e personalizar como os balanceadores de carga de rede de passagem interna distribuem o tráfego: afinidade da sessão, rastreamento de conexão, fragmentação UDP e failover.

A maneira como um balanceador de carga de rede de passagem interna distribui novas conexões depende de você ter configurado o failover:

  • Se você não tiver configurado o failover, um balanceador de carga de rede de passagem interno distribuirá novas conexões com as VMs de back-end íntegras se pelo menos uma VM de back-end estiver nesse estado. Quando todas as VMs de back-end não estiverem íntegras, o balanceador de carga distribuirá novas conexões entre todos os back-ends como última alternativa. Nessa situação, o balanceador de carga roteia cada nova conexão para uma VM de back-end não íntegra.

  • Se tiver configurado o failover, um balanceador de carga de rede de passagem interno distribuirá novas conexões entre VMs no pool ativo, de acordo com uma política de failover que pode ser configurada. Quando todas as VMs de back-end não estiverem íntegras, poderá escolher um dos seguintes comportamentos:

    • (Padrão) O balanceador de carga distribui o tráfego apenas para as VMs primárias. Isso é feito como último recurso. As VMs de backup são excluídas dessa distribuição de conexões mais recente.
    • O balanceador de carga está configurado para descartar o tráfego.

O método de distribuição de novas conexões depende da configuração da afinidade de sessão do balanceador de carga.

O estado da verificação de integridade controla a distribuição de novas conexões. Por padrão, as conexões TCP persistem em back-ends não íntegros. Para mais detalhes e como alterar esse comportamento, consulte Persistência de conexão em back-ends não íntegros.

Seleção de back-ends e rastreamento de conexão

Os balanceadores de carga de rede usam seleção configurável de back-end e algoritmos de rastreamento de conexão para determinar como o tráfego é distribuído para as VMs de back-end. Os balanceadores de carga de rede de passagem usam o algoritmo a seguir para distribuir pacotes entre as VMs de back-end (no pool ativo, se você tiver configurado o failover):

  1. Se o balanceador de carga tiver uma entrada na tabela de rastreamento de conexão correspondente às características de um pacote de entrada, o pacote será enviado ao back-end especificado pela entrada da tabela de rastreamento de conexão. O pacote é considerado como parte de uma conexão estabelecida anteriormente. Portanto, o pacote é enviado à VM de back-end que o balanceador de carga determinou e registrou anteriormente na tabela de rastreamento de conexão.

  2. Quando o balanceador de carga recebe um pacote que não tem uma entrada de rastreamento de conexão, o balanceador de carga faz o seguinte:

    1. O balanceador de carga seleciona um back-end. O balanceador de carga calcula um hash com base na afinidade da sessão configurada. Ele usa esse hash para selecionar um back-end:

      • Se pelo menos um back-end estiver íntegro, o hash selecionará um dos back-ends íntegros.
      • Se nenhum back-end estiver íntegro e não houver uma política de failover configurada, o hash selecionará um dos back-ends.
      • Se nenhum back-end estiver íntegro, haverá uma política de failover configurada e a política de failover não estará configurada para descartar o tráfego nessa situação, o hash selecionará um dos back-ends da VM principal.

      A afinidade da sessão padrão, NONE, usa um hash de cinco tuplas do endereço IP de origem, da porta de origem, do endereço IP de destino, da porta de destino e do protocolo do pacote.

      A seleção de back-end pode ser personalizada com o uso de um algoritmo de hash que usa menos informações. Para todas as opções compatíveis, consulte opções de afinidade da sessão.

    2. O balanceador de carga adiciona uma entrada à tabela de rastreamento de conexão. Essa entrada registra o back-end selecionado para a conexão do pacote, de modo que todos os pacotes futuros dessa conexão sejam enviados para o mesmo back-end. O uso do rastreamento de conexão depende do protocolo:

      Para pacotes TCP e UDP, o rastreamento de conexão está sempre ativado e não pode ser desativado. Por padrão, o rastreamento de conexão é de cinco tuplas, mas pode ser configurado para ser menor que cinco tuplas.

      Quando o hash de rastreamento de conexão é de cinco tuplas, os pacotes TCP SYN sempre criam uma nova entrada na tabela de rastreamento de conexão.

      O rastreamento de conexão padrão de cinco tuplas é usado quando:

      • o modo de acompanhamento é PER_CONNECTION (todas as afinidades da sessão), ou,
      • o modo de acompanhamento é PER_SESSION e a afinidade da sessão é NONE, ou,
      • o modo de acompanhamento é PER_SESSION e a afinidade da sessão é CLIENT_IP_PORT_PROTO.

      Para mais detalhes sobre quando o acompanhamento de conexão é ativado e qual método de acompanhamento é usado, consulte Modo de rastreamento de conexão.

      Além disso, observe o seguinte:

      • Por padrão, uma entrada na tabela de rastreamento de conexão expira 600 segundos depois que o balanceador de carga processa o último pacote que correspondeu à entrada. Para detalhes sobre como personalizar o tempo limite de inatividade, consulte Tempo limite de inatividade.
      • Dependendo do protocolo, o balanceador de carga pode remover entradas da tabela de rastreamento de conexão quando os back-ends não estiverem íntegros. Para detalhes e como personalizar esse comportamento, consulte Persistência de conexão em back-ends não íntegros.

Opções de afinidade de sessão

A afinidade de sessão controla a distribuição de novas conexões de clientes para as VMs de back-end do balanceador de carga. Você define a afinidade de sessão quando as VMs de back-end precisam acompanhar as informações de estado dos clientes. Esse é um requisito comum para aplicativos da Web.

A afinidade de sessão funciona com base no melhor esforço.

Os balanceadores de carga de rede de passagem internos são compatíveis com as seguintes opções de afinidade de sessão, que você especifica para todo o serviço interno de back-end e não por grupo de instâncias de back-end:

  • Nenhum (NONE). Hash de cinco tuplas do endereço IP de origem, porta de origem, protocolo, endereço IP de destino e porta de destino
  • IP do cliente, sem destino (CLIENT_IP_NO_DESTINATION). Hash de uma tupla criado apenas do endereço IP de origem.
  • IP do cliente (CLIENT_IP). Hash de duas tuplas do endereço IP de origem e do destino. Os balanceadores de carga de rede de passagem externa chamam essa opção de afinidade de sessão de IP do cliente, IP de destino.
  • IP do cliente, IP de destino, protocolo (CLIENT_IP_PROTO). Hash de três tuplas do endereço IP de origem, do endereço IP de destino e do protocolo
  • IP do cliente, Porta do cliente, IP de destino, Porta de destino, Protocolo (CLIENT_IP_PORT_PROTO). Hash de cinco tuplas do endereço IP de origem, porta de origem, protocolo, endereço IP de destino e a porta de destino

A menos que você use o balanceador de carga como próximo salto para uma rota estática personalizada, o endereço IP de destino de um pacote precisa corresponder ao endereço IP da regra de encaminhamento do balanceador de carga para que o pacote seja entregue ao balanceador de carga. Para considerações ao usar o balanceador de carga como próximo salto para uma rota estática personalizada, veja Afinidade da sessão e balanceador de carga de rede de passagem interno do próximo salto.

Afinidade da sessão e passagem do balanceador de carga interno de rede

Quando você configura uma rota estática para usar um balanceador de carga de rede de passagem interna de próximo salto, o balanceador usa o mesmo método de seleção de back-end e rastreamento de conexão discutido anteriormente. A seleção de back-end ainda é feita calculando um hash de acordo com a afinidade de sessão configurada. Exceto a afinidade da sessão CLIENT_IP_NO_DESTINATION, o hash de seleção do back-end depende, em parte, do endereço IP de destino do pacote.

Quando um balanceador de carga de rede de passagem interna é o próximo salto de uma rota estática, o endereço IP de destino não é limitado ao endereço IP da regra de encaminhamento do balanceador de carga. Em vez disso, o endereço IP de destino do pacote pode ser qualquer endereço IP que se encaixe no intervalo de destino da rota estática.

Se o número de VMs de back-end configuradas e íntegras for constante (quando o failover não estiver configurado ou quando o failover estiver configurado, mas nenhum evento de failover ou failback ocorrer), o balanceador de carga vai se comportar da seguinte maneira:

  • Se houver apenas uma VM de back-end configurada e íntegra (no pool ativo, se o failover estiver configurado), não importa qual afinidade da sessão você usar, porque todos os hashes são mapeados para a VM de back-end.

  • Se houver duas ou mais VMs de back-end configuradas e íntegras (no pool ativo, se o failover estiver configurado), sua escolha de afinidade da sessão será importante:

    • Se você precisar que a mesma VM de back-end processe todos os pacotes de um cliente, com base apenas no endereço IP de origem do pacote, independentemente dos endereços IP de destino do pacote, use a afinidade da sessão CLIENT_IP_NO_DESTINATION. Dependendo dos padrões de tráfego, algumas VMs de back-end podem receber mais pacotes ou mais conexões do que outras VMs de back-end.

    • Se você usar uma opção de afinidade da sessão que não seja CLIENT_IP_NO_DESTINATION, o balanceador de carga vai selecionar uma VM de back-end com base em informações que incluam pelo menos ambos o endereço IP de origem e o endereço IP de destino do pacote. Os pacotes enviados pelo mesmo cliente, usando o mesmo endereço IP de origem, mas diferentes endereços IP de destino, podem ser roteados para diferentes VMs de back-end.

Política de rastreamento da conexão

Esta seção descreve as configurações que controlam o comportamento de rastreamento de conexão dos balanceadores de carga de rede de passagem interna. Uma política de rastreamento de conexão inclui as seguintes configurações:

Modo de rastreamento de conexão

O modo de acompanhamento especifica o algoritmo de rastreamento de conexão a ser usado. Há dois modos de rastreamento: PER_CONNECTION (padrão) e PER_SESSION.

  • PER_CONNECTION (padrão). Nesse modo, o tráfego TCP e UDP é sempre rastreado por cinco tuplas, independentemente da configuração de afinidade da sessão. Isso significa que a chave para o rastreamento de conexão (5 tuplas) pode ser diferente da configuração de afinidade da sessão definida, por exemplo, 3 tuplas com a configuração CLIENT_IP_PROTO. Como resultado, a afinidade da sessão pode ser dividida, e novas conexões para uma sessão podem selecionar um back-end diferente se o conjunto de back-ends ou as alterações de integridade forem alterados.

  • PER_SESSION. Nesse modo, o tráfego TCP e UDP é rastreado de acordo com a afinidade de sessão configurada. Ou seja, se a afinidade da sessão for CLIENT_IP ou CLIENT_IP_PROTO, a configuração desse modo resultará no rastreamento de conexões de duas e três tuplas, respectivamente. Isso pode ser desejável em cenários em que a interrupção da afinidade é cara e precisa ser evitada mesmo que mais back-ends sejam adicionados.

A configuração do modo de rastreamento de conexão será redundante se a afinidade da sessão estiver definida como NONE ou CLIENT_IP_PORT_PROTO. Para saber como esses modos de rastreamento funcionam com diferentes configurações de afinidade de sessão para cada protocolo, consulte a tabela a seguir.

Seleção de back-end Modo de rastreamento de conexão
Configuração de afinidade da sessão Método de hash para seleção de back-end PER_CONNECTION (padrão) PER_SESSION
Padrão: sem afinidade da sessão

NONE

 Hash de cinco tuplas Acompanhamento de conexão de cinco tuplas Acompanhamento de conexão de cinco tuplas

IP do cliente, sem destino

CLIENT_IP_NO_DESTINATION

 Hash de uma tupla Acompanhamento de conexão de cinco tuplas Acompanhamento de conexão de uma tupla

IP do cliente

CLIENT_IP

(igual ao IP do cliente, IP de destino para balanceadores de carga de rede de passagem externa)

 Hash de duas tuplas Acompanhamento de conexão de cinco tuplas Acompanhamento de conexão de duas tuplas

IP do cliente, IP de destino, protocolo

CLIENT_IP_PROTO

 Hash de três tuplas Acompanhamento de conexão de cinco tuplas Acompanhamento de conexão de três tuplas

IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo

CLIENT_IP_PORT_PROTO

 Hash de cinco tuplas Acompanhamento de conexão de cinco tuplas Acompanhamento de conexão de cinco tuplas

Para saber como alterar o modo de rastreamento de conexão, consulte Configurar uma política de rastreamento de conexão.

Persistência de conexão em back-ends não íntegros

A persistência de conexões em configurações de back-ends não íntegras controla se uma conexão existente persiste em um back-end selecionado após esse back-end se tornar não íntegro, desde que o back-end permaneça no grupo de instâncias de back-end configuradas do balanceador de carga.

O comportamento descrito nesta seção não se aplica aos casos em que você remove uma VM de back-end do grupo de instâncias ou remove o grupo de instâncias do serviço de back-end. Nesses casos, as conexões estabelecidas persistem apenas conforme descrito na diminuição de conexão.

As seguintes opções de persistência de conexão estão disponíveis:

  • DEFAULT_FOR_PROTOCOL (padrão)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

A tabela a seguir resume as opções de persistência de conexão e como as conexões persistem para diferentes protocolos, opções de afinidade da sessão e modos de rastreamento.

Persistência de conexão em back-ends não íntegros Modo de rastreamento de conexão
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão)

UDP: as conexões nunca persistem em back-ends não íntegros

TCP: conexões persistem em back-ends não íntegros se a afinidade da sessão é NONE ou CLIENT_IP_PORT_PROTO

UDP: as conexões nunca persistem em back-ends não íntegros
NEVER_PERSIST TCP, UDP: as conexões nunca persistem em back-ends não íntegros
ALWAYS_PERSIST

TCP: as conexões permanecem em back-ends não íntegros (todas as afinidades da sessão)

Essa opção só deve ser usada para casos de uso avançados.

 Não é possível configurar

Para saber como alterar o comportamento de persistência de conexão, consulte Configurar uma política de rastreamento de conexão.

Tempo limite de inatividade

Por padrão, uma entrada na tabela de rastreamento de conexão expira 600 segundos após o balanceador de carga processar o último pacote que correspondeu à entrada. Esse valor de tempo limite padrão inativo pode ser modificado somente quando o rastreamento de conexão for menor que cinco tuplas, ou seja, quando a afinidade de sessão estiver configurada como CLIENT_IP ou CLIENT_IP_PROTO: e o modo de acompanhamento é PER_SESSION).

O valor máximo do tempo limite de inatividade configurável é de 57.600 segundos (16 horas).

Para saber como alterar o valor do tempo limite de inatividade, consulte Configurar uma política de rastreamento de conexão.

Conexões para implantações de um único cliente

Ao testar conexões com o endereço IP de um balanceador de carga de rede de passagem interna que tem apenas um cliente, lembre-se do seguinte:

  • Se a VM cliente não estiver sendo balanceada de carga, ou seja, se não for também uma VM de back-end, novas conexões serão enviadas às VMs de back-end íntegras do balanceador de carga. No entanto, como todas as opções de afinidade de sessão dependem pelo menos do endereço IP do sistema cliente, as conexões do mesmo cliente podem ser distribuídas para a mesma VM de back-end com mais frequência do que o esperado.

    Na prática, isso quer dizer é que não é possível monitorar com precisão a distribuição de tráfego por meio de um balanceador de carga de rede de passagem interno que se conecta de um único cliente. O número necessário de clientes para monitorar a distribuição de tráfego varia de acordo com o tipo do balanceador de carga, o tipo de tráfego e o número de back-ends íntegros.

  • Se a VM cliente também for uma VM de back-end do balanceador de carga, as conexões enviadas para o endereço IP da regra de encaminhamento do balanceador de carga serão sempre respondidas pela mesma VM de back-end (que também é a VM cliente). Isso acontece independente de a VM de back-end estar íntegra. Isso acontece para todo o tráfego enviado ao endereço IP do balanceador de carga, não apenas o tráfego no protocolo e as portas especificadas na regra de encaminhamento interno do balanceador de carga.

    Para mais informações, consulte Como enviar solicitações a partir de VMs submetidas a balanceamento de carga.

Diminuição da conexão

A diminuição da conexão é um processo aplicado a conexões estabelecidas nos seguintes casos:

  • Uma VM ou um endpoint é removido de um back-end (grupo de instâncias ou NEG).
  • Um back-end remove uma VM ou um endpoint (por substituição, abandono, ao fazer upgrades ou reduzir em escala vertical).

Por padrão, a diminuição de conexão está desativada. Quando desativadas, as conexões estabelecidas são encerradas o mais rápido possível. Quando a diminuição da conexão estiver ativada, as conexões estabelecidas poderão persistir por um tempo limite configurável, após o qual a instância da VM de back-end será encerrada.

Para mais detalhes sobre como a diminuição da conexão é acionada e como ativá-la, consulte Como ativar a diminuição da conexão.

Fragmentação UDP

Os balanceadores de carga de rede de passagem interna podem processar pacotes UDP fragmentados e não fragmentados. Se o aplicativo usar pacotes UDP fragmentados, lembre-se do seguinte:
  • Os pacotes UDP podem se tornar fragmentados antes de chegar a uma rede VPC do Google Cloud.
  • Google Cloud As redes VPC encaminham fragmentos UDP à medida que chegam, sem esperar que todos os fragmentos cheguem.
  • As redes que não são doGoogle Cloud e os equipamentos de rede locais podem encaminhar fragmentos UDP assim que chegarem, atrasar pacotes UDP fragmentados até que todos os fragmentos tenham chegado ou descartar pacotes UDP fragmentados. Para ver mais detalhes, consulte a documentação da operadora ou equipamento de rede.

Se você espera pacotes UDP fragmentados e precisa encaminhá-los para os mesmos back-ends, use as seguintes regras de encaminhamento e parâmetros de configuração do serviço de back-end:

  • Configuração da regra de encaminhamento: use apenas uma UDP por regra de encaminhamento por endereço IP com balanceamento de carga e configure a regra de encaminhamento para aceitar tráfego em todas as portas. Isso garante que todos os fragmentos cheguem à mesma regra de encaminhamento. Mesmo que os pacotes fragmentados (exceto o primeiro fragmento) não tenham uma porta de destino, a configuração da regra de encaminhamento para processar o tráfego para todas as portas também a configura para receber fragmentos UDP que não têm informações de porta. Para configurar todas as portas, use a Google Cloud CLI para definir --ports=ALL ou use a API para definir allPorts como True

  • Configuração do serviço de back-end: defina a afinidade da sessão do serviço de back-end como CLIENT_IP (hash de duas tuplas) ou CLIENT_IP_PROTO (três tuplas) hash) para que o mesmo back-end seja selecionado para pacotes UDP que incluem informações de porta e fragmentos UDP (que não sejam o primeiro fragmento) sem informações de porta. Defina o modo de rastreamento de conexão do serviço de back-end como PER_SESSION para que as entradas da tabela de rastreamento de conexão sejam criadas usando os mesmos hashes de duas ou três tuplas.

Failover

Um balanceador de carga de rede de passagem interna permite designar alguns back-ends como back-ends de failover. Esses back-ends só são usados quando o número de VMs íntegras nos grupos de instâncias de back-end primários está abaixo de um limite configurável. Por padrão, se todas as VMs primárias e de failover não estiverem íntegras, como um último recurso, Google Cloud distribui novas conexões somente entre todas as VMs principais.

Ao adicionar um back-end a um serviço de back-end do balanceador de carga de rede de passagem interno, por padrão, ele é um back-end primário. Para designar um back-end como sendo de failover, faça isso quando adicioná-lo ao serviço de back-end do balanceador de carga ou edite esse serviço posteriormente.

Para uma visão geral conceitual detalhada do failover em balanceadores de carga de rede de passagem interna, consulte Failover para balanceadores de carga de rede de passagem interna.

A seguir