Visão geral do balanceamento de carga de rede TCP/UDP externo baseado em serviço de back-end

O balanceamento de carga de rede TCP/UDP externo do Google Cloud, referido balanceamento de carga de rede, é um balanceador de carga regional sem proxy. Um balanceador de carga de rede distribui o tráfego externo entre instâncias de máquina virtual (VM) na mesma região.

É possível configurar um balanceador de carga de rede para o tráfego TCP, UDP, ESP e ICMP. A compatibilidade com ESP e ICMP está em versão de pré-lançamento.

Um balanceador de carga de rede pode receber tráfego de:

  • Qualquer cliente na Internet
  • VMs do Google Cloud com IPs externos
  • VMs do Google Cloud que têm acesso à Internet por meio do Cloud NAT ou NAT baseada em instância

O balanceamento de carga da rede tem as seguintes características:

  • O balanceamento de carga da rede é um serviço gerenciado.
  • O balanceamento de carga da rede é implementado usando a rede virtual Andromeda e o Google Maglev.
  • Os balanceadores de carga de rede não são proxies.
    • Os pacotes com balanceamento de carga são recebidos por VMs de back-end com os endereços IP de origem e destino do pacote e, se o protocolo for baseado em portas, as portas de origem e de destino inalteradas.
    • As conexões com balanceamento de carga são encerradas pelas VMs de back-end.
    • As respostas das VMs de back-end vão diretamente para os clientes, e não voltam pelo balanceador de carga. O termo do setor para isso é retorno direto do servidor.

Os balanceadores de carga de rede com base em serviço de back-end têm as seguintes características:

  • Back-ends de grupos gerenciados de instâncias. Os balanceadores de carga de rede baseados em serviço de back-end são compatíveis com o uso de grupos gerenciados de instâncias como back-ends. Esses grupos automatizam determinados aspectos do gerenciamento de back-end e oferecem melhor escalonabilidade e confiabilidade em comparação com grupos de instâncias não gerenciadas.
  • Controle de distribuição de tráfego detalhado. Uma configuração de serviço de back-end contém um conjunto de valores, como verificações de integridade, afinidade da sessão e rastreamento de conexão, políticas de drenagem da conexão e failover. A maioria dessas configurações tem valores padrão que permitem começar rapidamente.
  • Verificações de integridade. Os balanceadores de carga de rede baseados em serviço de back-end usam verificações de integridade que correspondem ao tipo de tráfego (TCP, SSL, HTTP, HTTPS ou HTTP/2) que estão distribuindo.

Arquitetura

O diagrama a seguir ilustra os componentes de um balanceador de carga de rede:

Balanceador de carga de rede TCP/UDP externo com serviço de back-end regional
Balanceamento de carga de rede com serviço de back-end regional

O balanceador de carga é composto de vários componentes de configuração. Um único balanceador de carga pode ter o seguinte:

  • Um ou mais endereços IP externos regionais
  • Uma ou mais regras de encaminhamento externo regionais
  • Um serviço de back-end externo regional
  • Um ou mais grupos de instâncias de back-end
  • Verificação de integridade associada ao serviço de back-end

Além disso, você precisa criar regras de firewall que permitam que o tráfego de balanceamento de carga e as sondagens de verificação de integridade alcancem as VMs de back-end.

Endereço IP

Um balanceador de carga de rede requer pelo menos uma regra de encaminhamento. Essa regra faz referência a um único endereço IP externo regional. Os endereços IP externos regionais podem ser acessados em qualquer lugar na Internet, mas são provenientes de um pool exclusivo para cada região do Google Cloud.

Ao criar uma regra de encaminhamento, especifique o nome ou endereço IP de um endereço IP externo regional reservado existente. Se você não especificar um endereço IP, a regra de encaminhamento fará referência a um endereço IP externo regional temporário. Use um endereço IP reservado se você precisar manter o endereço associado ao seu projeto para reutilização depois de excluir uma regra de encaminhamento ou se precisar que várias regras de encaminhamento façam referência ao mesmo endereço IP.

O balanceamento de carga de rede aceita endereços IP externos regionais de nível Padrão e Premium. O endereço IP e a regra de encaminhamento precisam usar o mesmo nível de rede.

Veja as etapas para reservar um endereço IP em Endereços IP externos.

Regra de encaminhamento

Uma regra de encaminhamento externo regional especifica o protocolo e as portas em que o balanceador de carga aceita tráfego. Como os balanceadores de carga de rede não são proxies, eles transmitem o tráfego para back-ends no mesmo protocolo e na mesma porta se o pacote transportar informações de porta. A regra de encaminhamento em combinação com o endereço IP forma o front-end do balanceador de carga.

O balanceador de carga preserva os endereços IP de origem dos pacotes de entrada. O endereço IP de destino dos pacotes de entrada é o endereço associado à regra de encaminhamento do balanceador de carga.

O tráfego de entrada é associado a uma regra de encaminhamento, que é uma combinação de um determinado endereço IP, protocolo e, se o protocolo for baseado em portas, uma das portas, um intervalo de portas ou todos. A regra de encaminhamento direciona o tráfego para o serviço de back-end do balanceador de carga.

Um balanceador de carga de rede requer pelo menos uma regra de encaminhamento. Defina várias regras de encaminhamento para o mesmo balanceador de carga, conforme descrito em Várias regras de encaminhamento.

Protocolos da regra de encaminhamento

O balanceamento de carga de rede é compatível com as seguintes opções de protocolo para cada regra de encaminhamento: TCP, UDP e L3_DEFAULT (Pré-lançamento).

Use as opções TCP e UDP para configurar o balanceamento de carga TCP ou UDP. A opção de protocolo L3_DEFAULT permite que um balanceador de carga de rede balanceie a carga do tráfego TCP, UDP, ESP e ICMP.

Além da compatibilidade com protocolos diferentes de TCP e UDP, L3_DEFAULT possibilita que uma única regra de encaminhamento exiba vários protocolos. Por exemplo, os serviços IPSec geralmente processam alguma combinação de tráfego IKE e NAT-T baseado em ESP e UDP. A opção L3_DEFAULT permite que uma única regra de encaminhamento seja configurada para processar todos esses protocolos.

As regras de encaminhamento que usam os protocolos TCP ou UDP podem fazer referência a um serviço de back-end usando o mesmo protocolo que a regra de encaminhamento ou um serviço de back-end cujo protocolo seja UNSPECIFIED(Pré-lançamento. As regras de encaminhamento L3_DEFAULT só podem referenciar um serviço de back-end com protocolo UNSPECIFIED.

A tabela a seguir resume como usar essas configurações para protocolos diferentes.

Tráfego para balanceamento de carga Protocolo da regra de encaminhamento Protocolo do serviço de back-end
TCP TCP TCP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP ou UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP L3_DEFAULT UNSPECIFIED
ICMP (somente solicitação de eco) L3_DEFAULT UNSPECIFIED

Várias regras de encaminhamento

É possível configurar várias regras de encaminhamento externo regionais para o mesmo balanceador de carga de rede. Opcionalmente, cada regra de encaminhamento pode ter um endereço IP externo regional diferente ou várias regras de encaminhamento podem ter o mesmo endereço IP externo regional.

A configuração de várias regras de encaminhamento externo regionais pode ser útil nestes casos de uso:

  • Você precisa configurar mais de um endereço IP externo para o mesmo serviço de back-end.
  • Você precisa configurar protocolos diferentes e portas ou intervalos de portas não sobrepostos para o mesmo endereço IP externo.

Para um determinado endereço IP, uma regra de encaminhamento L3_DEFAULT pode coexistir com regras de encaminhamento com outros protocolos (TCP ou UDP), mas não com outra regra de encaminhamento L3_DEFAULT.

Um pacote que chega ao endereço IP do balanceador de carga corresponde a uma regra de encaminhamento L3_DEFAULT somente se uma regra de encaminhamento mais específica não estiver disponível (por exemplo, para tráfego TCP ou UDP). Mais especificamente, um pacote que chega em um endereço IP, um protocolo e uma porta corresponde a uma regra de encaminhamento L3_DEFAULT se e somente se não houver outras regras de encaminhamento para esse endereço IP que correspondam ao protocolo e porta de destino.

Ao usar várias regras de encaminhamento, configure o software em execução nas suas VMs de back-end para que ele seja vinculado a todos os endereços IP externos das regras de encaminhamento do balanceador de carga.

Serviço de back-end regional

Cada balanceador de carga de rede tem um serviço de back-end regional que define o comportamento do balanceador de carga e como o tráfego é distribuído para os back-ends. O nome do serviço de back-end é o nome do balanceador de carga da rede mostrado no Console do Google Cloud.

Todo os serviços de back-end definem os seguintes parâmetros de back-end:

  • Protocolo. Um serviço de back-end aceita tráfego no endereço IP e nas portas (se configurado) especificadas por uma ou mais regras de encaminhamento externo regionais. O serviço de back-end transmite pacotes para as VMs de back-end enquanto preserva os endereços IP de origem e destino do pacote, o protocolo e, se o protocolo for baseado em porta, as portas de origem e de destino.

    Os serviços de back-end usados com balanceadores de carga de rede são compatíveis com as seguintes opções de protocolo: TCP, UDP ou UNSPECIFIED (Pré-lançamento).

    Os serviços de back-end com o protocolo UNSPECIFIED podem ser usados com qualquer regra de encaminhamento, não importa qual seja o protocolo da regra. Os serviços de back-end com um protocolo específico (TCP ou UDP) só podem ser referenciados por regras de encaminhamento com o mesmo protocolo (TCP ou UDP). As regras de encaminhamento com o protocolo L3_DEFAULT só podem referenciar serviços de back-end com o protocolo UNSPECIFIED.

    Consulte Especificação de protocolo de regra de encaminhamento para ver uma tabela com possíveis combinações de regra de encaminhamento e protocolo de serviço de back-end.

  • Distribuição de tráfego. Com um serviço de back-end, é possível distribuir o tráfego de acordo com as políticas configuráveis de afinidade da sessão e rastreamento de conexão. Também é possível configurar o serviço de back-end para ativar a diminuição da conexão e designar back-ends de failover para o balanceador de carga.

  • Verificação de integridade. Os serviços de back-end precisam ter uma verificação de integridade vinculada.

Cada serviço de back-end opera em uma única região e distribui o tráfego para a primeira interface de rede (nic0) das VMs de back-end. Os back-ends precisam ser grupos de instâncias na mesma região do serviço de back-end e da regra de encaminhamento. Os back-ends podem ser grupos de instâncias não gerenciadas, gerenciadas por zona ou gerenciadas por região.

Os balanceadores de carga de rede baseados em serviço de back-end aceitam grupos de instâncias com instâncias de membro que usam qualquer rede VPC na mesma região, desde que a rede VPC esteja no mesmo projeto que o serviço de back-end. Todas as VMs em um determinado grupo de instâncias precisam usar a mesma rede VPC.

Grupos de instâncias de back-end

Um balanceador de carga de rede distribui conexões entre as VMs de back-end contidas em grupos de instâncias gerenciados ou não gerenciados. Os grupos de instâncias podem ser regionais ou zonais no escopo.

  • Grupos gerenciados de instâncias regionais Use grupos de instâncias regionais gerenciados se puder implantar o software usando modelos de instância. Os grupos de instâncias gerenciadas por região distribuem automaticamente o tráfego entre várias zonas, fornecendo a melhor opção para evitar possíveis problemas em qualquer zona.

    Veja abaixo um exemplo de implantação usando um grupo de instâncias gerenciadas por região. O grupo de instâncias tem um modelo de instância que define como as instâncias devem ser provisionadas e cada grupo implanta instâncias dentro de três zonas da região us-central1.

    Balanceador de carga de rede com grupo de instâncias gerenciadas por região
    Balanceamento de carga de rede com um grupo de instâncias gerenciadas por região
  • Grupos de instâncias gerenciadas ou não gerenciadas por zona. Use grupos de instâncias zonais em diferentes zonas (na mesma região) para se proteger contra possíveis problemas em qualquer zona.

    Veja aqui um exemplo de implantação usando grupos de instâncias zonais. Esse balanceador de carga fornece disponibilidade em duas zonas.

    Balanceador de carga de rede com grupos de instâncias zonais
    Balanceamento de carga de rede com grupos de instâncias zonais

Verificações de integridade

O balanceamento de carga de rede usa verificações de integridade regionais para determinar quais instâncias podem receber novas conexões. Cada serviço de back-end do balanceador de carga de rede precisa estar associado a uma verificação de integridade regional. Os balanceadores de carga usam o status da verificação de integridade para determinar como rotear novas conexões para instâncias de back-end.

Para mais detalhes sobre como as verificações de integridade do Google Cloud funcionam, consulte Como funcionam as verificações de integridade.

O balanceamento de carga de rede é compatível com os seguintes tipos de verificações de integridade:

Verificações de integridade para outros tráfegos de protocolo

O Google Cloud não oferece verificações de integridade específicas de protocolo além das que são listadas aqui. Ao usar o balanceamento de carga de rede para balancear a carga de um protocolo que não seja TCP, ainda é necessário executar um serviço baseado em TCP nas VMs de back-end para fornecer as informações necessárias de verificação de integridade.

Por exemplo, se você estiver balanceando a carga do tráfego UDP, as solicitações de clientes passarão pelo balanceamento de carga usando o protocolo UDP e será necessário executar um serviço TCP para fornecer informações às sondagens de verificação de integridade do Google Cloud. Para isso, execute um servidor HTTP simples em cada VM de back-end que retorna uma resposta HTTP 200 para as sondagens de verificação de integridade. É preciso usar a própria lógica em execução na VM de back-end para garantir que o servidor HTTP exiba 200 apenas se o serviço UDP estiver configurado e em execução corretamente.

Regras de firewall

Como o balanceamento de carga de rede é um balanceador de carga de passagem, você controla o acesso aos back-ends do balanceador de carga usando as regras de firewall do Google Cloud. Crie regras de firewall de permissão de entrada ou política de firewall hierárquica de permissão de entrada para permitir verificações de integridade e o tráfego com balanceamento de carga.

As regras de encaminhamento e de entrada permitem que as regras de firewall ou as políticas hierárquicas de firewall funcionem juntas da seguinte maneira: uma regra de encaminhamento especifica o protocolo e, se definido, os requisitos de porta que um pacote precisa atender para ser encaminhado para uma VM de back-end. As regras de firewall de permissão de entrada controlam se os pacotes encaminhados são entregues à VM ou descartados. Todas as redes VPC têm uma regra de firewall de entrada de negação implícita que bloqueia pacotes de entrada de qualquer origem. A rede VPC padrão do Google Cloud inclui um conjunto limitado de regras de firewall de permissão de entrada pré-preenchida.

  • Para aceitar o tráfego de qualquer endereço IP na Internet, crie uma regra de firewall de permissão de entrada com o intervalo de origem 0.0.0.0/0. Para permitir apenas o tráfego de determinados intervalos de endereços IP, use intervalos de origem mais restritivos.

  • Como prática recomendada de segurança, a entrada permitida pelas regras de firewall só permite os protocolos e portas IP necessários. Restringir a configuração do protocolo (e, se possível, porta) é especialmente importante ao usar regras de encaminhamento cujo protocolo está definido como L3_DEFAULT. As regras de encaminhamento L3_DEFAULT encaminham pacotes para todos os protocolos IP compatíveis (em todas as portas se o protocolo e o pacote tiverem informações de porta).

  • O balanceamento de carga de rede usa verificações de integridade do Google Cloud. Portanto, sempre permita o tráfego dos intervalos de endereços IP da verificação de integridade. Essas regras de firewall de permissão de entrada podem ser específicas para o protocolo e as portas da verificação de integridade do balanceador de carga.

Caminho de retorno

O balanceamento de carga da rede usa rotas especiais fora da rede VPC para direcionar solicitações de entrada e sondagens de verificação de integridade a cada VM de back-end.

O balanceador de carga preserva os endereços IP de origem dos pacotes. As respostas das VMs de back-end vão diretamente para os clientes, e não voltam pelo balanceador de carga. O termo do setor para isso é retorno direto do servidor.

Arquitetura da VPC compartilhada

Todos os componentes de um balanceador de carga de rede precisam existir no mesmo projeto, exceto o endereço IP. A tabela a seguir resume os componentes da VPC compartilhada para o balanceamento de carga de rede:

Endereço IP Regra de encaminhamento Componentes de back-end
Um endereço IP externo regional precisa ser definido no mesmo projeto que o balanceador de carga ou no projeto host da VPC compartilhada. Uma regra de encaminhamento externo regional precisa ser definida no mesmo projeto que as instâncias no serviço de back-end.

O serviço de back-end regional precisa ser definido no mesmo projeto e na mesma região em que estão as instâncias no grupo de instâncias de back-end.

As verificações de integridade associadas ao serviço de back-end precisam ser definidas no mesmo projeto e na mesma região do serviço de back-end.

Distribuição de tráfego

A maneira como um balanceador de carga de rede 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 distribuirá novas conexões para as VMs de back-end íntegras se pelo menos uma VM de back-end estiver íntegra. 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 um último recurso. Nessa situação, o balanceador de carga roteia cada nova conexão para uma VM de back-end não íntegra.
  • Se você tiver configurado o failover, um balanceador de carga de rede distribuirá novas conexões entre VMs de back-end íntegras, de acordo com uma política de failover que você configurar. Quando todas as VMs de back-end não estiverem íntegras, será possível 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 descarta o tráfego.

Para detalhes sobre como as conexões são distribuídas, consulte a próxima seção Seleção de back-end e rastreamento de conexão.

Para detalhes sobre o funcionamento do failover, consulte a seção Failover.

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

O balanceamento de carga de rede usa 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.

O balanceamento de carga de rede usa 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 entre aqueles que são atualmente íntegros (a menos que todos os back-ends não estejam íntegros, caso em que todos os back-ends são considerados desde que política de failover não tenha sido configurada para descartar o tráfego nessa situação. A afinidade da sessão padrão, NONE, usa os seguintes algoritmos de hash:

      • Para pacotes UDP não fragmentados e TCP, um hash de cinco tuplas do endereço IP de origem do pacote, porta de origem, endereço IP de destino, porta de destino e protocolo
      • Para pacotes UDP fragmentados e todos os outros protocolos, um hash de três tuplas do endereço IP de origem do pacote, do endereço IP de destino e do protocolo

      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:

      • Pacotes TCP. 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 é de cinco tuplas, os pacotes TCP SYN são tratados de maneira diferente. Ao contrário dos pacotes não SYN, eles descartam qualquer entrada de rastreamento de conexão correspondente e sempre selecionam um novo back-end.

        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.
      • Pacotes UDP e ESP. O rastreamento de conexão é ativado somente se a afinidade da sessão estiver definida como algo diferente de NONE.

      • Pacotes ICMP. Não é possível usar o rastreamento de conexão.

      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:

      • Uma entrada na tabela de rastreamento de conexão expira 60 segundos após o balanceador de carga processar o último pacote que corresponde à entrada. Esse valor de tempo limite de inatividade de 60 segundos não é configurável.
      • 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. A afinidade da sessão é especificada para todo o serviço de back-end externo regional, não por grupo de instâncias de back-end.

O balanceamento de carga de rede é compatível com as seguintes opções de afinidade de sessão:

  • 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, IP de destino (CLIENT_IP). Hash de duas tuplas de endereço IP de origem e endereço 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

Para saber como essas opções de afinidade de sessão afetam os métodos de rastreamento de conexão e seleção de back-end, consulte esta tabela.

Modo de rastreamento de conexão

A ativação do rastreamento de conexão depende apenas do protocolo do tráfego com carga balanceada e das configurações de afinidade da sessão. O modo de rastreamento especifica o algoritmo de rastreamento de conexão a ser usado quando o rastreamento de conexão está ativado. Há dois modos de acompanhamento: PER_CONNECTION (padrão) e PER_SESSION.

  • PER_CONNECTION (padrão). Esse é o modo de acompanhamento padrão. Com esse modo de rastreamento de conexão, o tráfego TCP é sempre rastreado por cinco tuplas, independentemente da configuração de afinidade da sessão. Para o tráfego UDP e ESP, o rastreamento de conexão é ativado quando a afinidade da sessão selecionada não é NONE. Os pacotes UDP e ESP são rastreados usando os métodos de rastreamento descritos nesta tabela.

  • PER_SESSION. Se a afinidade da sessão for CLIENT_IP ou CLIENT_IP_PROTO, a configuração desse modo resultará em rastreamento de conexão de duas e três tuplas, respectivamente, para todos os protocolos, exceto ICMP que não é rastreável por conexão. Para outras configurações de afinidade da sessão, o modo PER_SESSION se comporta de maneira idêntica ao modo PER_CONNECTION.

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)

TCP e UDP não fragmentado: hash de cinco tuplas

UDP fragmentado e todos os outros protocolos: hash de três tuplas

  • TCP: rastreamento de conexão de cinco tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
  • TCP: rastreamento de conexão de cinco tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
IP do cliente, IP de destino

(CLIENT_IP)

Todos os protocolos: hash de duas tuplas
  • TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas
  • UDP e ESP fragmentados: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
  • TCP, UDP, ESP: rastreamento de conexão de duas tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
IP do cliente, IP de destino, protocolo

(CLIENT_IP_PROTO)

Todos os protocolos: hash de três tuplas
  • TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas
  • UDP e ESP fragmentados: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
  • TCP, UDP, ESP: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
IP do cliente, porta do cliente, IP de destino, porta de destino, protocolo

(CLIENT_IP_PORT_PROTO)

TCP e UDP não fragmentado: hash de cinco tuplas

UDP fragmentado e todos os outros protocolos: hash de três tuplas

  • TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas
  • UDP e ESP fragmentados: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado
  • TCP e UDP não fragmentado: rastreamento de conexão de cinco tuplas
  • UDP e ESP fragmentados: rastreamento de conexão de três tuplas
  • Todos os outros protocolos: rastreamento de conexão desativado

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

As configurações de persistência de conexão controlam se uma conexão existente persiste em um back-end selecionado depois que esse back-end se tornar não íntegro (contanto que o back-end permaneça no grupo de instâncias de back-end configurado 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)

Todos os outros protocolos: as conexões nunca permanecem 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

Todos os outros protocolos: as conexões nunca persistem em back-ends não íntegros.

NEVER_PERSIST Todos os protocolos: as conexões nunca permanecem 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)

ESP, UDP: as conexões permanecem em back-ends não íntegros se a afinidade da sessão não for NONE

ICMP: não aplicável, já que o ICMP não é rastreável pela conexão

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

Não é possível configurar

Comportamento de persistência de conexão TCP em back-ends não íntegros

Sempre que uma conexão TCP com rastreamento de cinco tuplas persiste em um back-end não íntegro:

  • Se o back-end não íntegro continuar a responder aos pacotes, a conexão continuará até que seja redefinida ou fechada (pelo back-end não íntegro ou pelo cliente).
  • Se o back-end não íntegro enviar um pacote de redefinição de TCP (RST) ou não responder aos pacotes, o cliente poderá tentar novamente com uma nova conexão, permitindo que o balanceador de carga selecione um back-end íntegro e diferente. Os pacotes TCP SYN sempre selecionam um back-end novo e íntegro.

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

Diminuição da conexão

A diminuição da conexão é um processo aplicado a sessões estabelecidas quando:

  • uma VM de back-end é removida de um grupo de instâncias; ou
  • quando um grupo gerenciado de instâncias remove uma VM de back-end (por substituição, abandono, durante upgrades contínuos ou redução vertical); ou
  • quando um grupo de instâncias é removido de um serviço de back-end.

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

O balanceamento de carga de rede processa pacotes UDP fragmentados e não fragmentados. os pacotes não fragmentados são processados normalmente em todas as configurações; 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.
  • As redes VPC do Google Cloud encaminham fragmentos UDP à medida que chegam (sem esperar que todos os fragmentos cheguem).
  • As redes que não são do Google 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. Consulte a documentação do outro provedor de rede ou do equipamento de rede para mais detalhes.

Se você espera pacotes UDP fragmentados, faça o seguinte:

  • Use apenas uma regra de encaminhamento UDP por endereço IP com carga balanceada e configure a regra de encaminhamento para aceitar o tráfego em todas as portas. Isso garante que todos os fragmentos cheguem à mesma regra de encaminhamento, mesmo que não tenham a mesma porta de destino. Para configurar todas as portas, defina --ports=ALL usando a ferramenta de linha de comando gcloud ou defina allPorts como True usando a API.

  • Use uma das seguintes abordagens para configurar o serviço de back-end:

    • Desative a afinidade da sessão e o rastreamento de conexão. Defina a afinidade de sessão como NONE. O balanceador de carga usa um hash de cinco tuplas para selecionar um back-end para pacotes não fragmentados (que têm informações de porta) e um hash de três tuplas para pacotes fragmentados (que não têm informações de porta). Nesta configuração, pacotes UDP fragmentados e não fragmentados do mesmo cliente podem ser encaminhados para back-ends diferentes.
    • Ative a afinidade da sessão com duas ou três tuplas e o rastreamento de conexão. Defina a afinidade de sessão como CLIENT_IP ou CLIENT_IP_PROTO e o modo de rastreamento de conexão como PER_SESSION. Nessa configuração, os pacotes UDP fragmentados e não fragmentados do mesmo cliente são encaminhados para o mesmo back-end (sem usar informações de porta).

Como usar instâncias de destino como back-ends

Se você estiver usando instâncias de destino como back-ends para o balanceador de carga de rede e espera pacotes UDP fragmentados, use apenas uma regra de encaminhamento UDP por endereço IP com carga balanceada. e configure a regra de encaminhamento para aceitar o tráfego em todas as portas. Isso garante que todos os fragmentos cheguem à mesma regra de encaminhamento, mesmo que não tenham a mesma porta de destino. Para configurar todas as portas, defina --ports=ALL usando gcloud ou defina allPorts como True usando a API.

Failover

Configure um balanceador de carga de rede para distribuir conexões entre instâncias de máquina virtual (VM) nos grupos de instâncias do back-end primário e depois troque para os grupos de instância de back-end de failover, se necessário. Com o failover, você garante um método para aumentar a disponibilidade e ter maior controle sobre como gerenciar a carga de trabalho quando as VMs de back-end principais não estiverem íntegras.

Por padrão, quando você adiciona um back-end ao serviço de back-end de um balanceador de carga de rede, ele é primário. Para designá-lo como back-end 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 mais detalhes sobre como funciona o failover, consulte a Visão geral do failover para o balanceamento de carga de rede.

Limitações

  • Os NEGs não são compatíveis como back-ends para balanceadores de carga de rede.
  • Os balanceadores de carga de rede baseados em serviço de back-end não são compatíveis com o Google Kubernetes Engine.
  • Não é possível usar o Console do Google Cloud para fazer o seguinte:

    • Criar ou modificar um balanceador de carga de rede em que a regra de encaminhamento use o protocolo L3_DEFAULT.
    • Criar ou modificar um balanceador de carga de rede em que o protocolo do serviço de back-end esteja definido como UNSPECIFIED.
    • Configure uma política de rastreamento de conexão para um serviço de back-end.

    Usar a ferramenta de linha de comando gcloud ou a API REST.

A seguir