Visão geral do balanceamento de carga TCP/UDP interno

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O balanceamento de carga TCP/UDP interno do Google Cloud é um balanceador de carga regional criado na pilha de virtualização de rede Andromeda.

O balanceamento de carga TCP/UDP interno distribui o tráfego entre instâncias de máquina virtual (VM) interna na mesma região em uma rede de nuvem privada virtual (VPC). Com ela, é possível executar e escalonar serviços em um endereço IP interno que seja acessível apenas para sistemas na mesma rede VPC ou sistemas conectados à sua rede VPC.

Um serviço de balanceamento de carga TCP/UDP interno tem um front-end (a regra de encaminhamento) e um back-end (o serviço de back-end). Use grupos de instâncias ou NEGs zonais GCE_VM_IP como back-ends no serviço de back-end. Neste exemplo, mostramos os back-ends de grupos de instâncias.

Exemplo geral de balanceador de carga TCP/UDP interno de alto nível.
Exemplo geral de balanceador de carga TCP/UDP interno de alto nível (clique para ampliar)

Conheça as diferenças entre os balanceadores de carga do Google Cloud nos documentos a seguir:

Casos de uso

Use o balanceamento de carga TCP/UDP interno nas seguintes circunstâncias:

  • Você precisa de um balanceador de carga de alto desempenho de camada 4 para tráfego TCP ou UDP.

  • Se você estiver veiculando tráfego por meio de TLS (SSL), é aceitável fazer com que o tráfego SSL encerrado pelos back-ends em vez de no balanceador de carga. O balanceador de carga TCP/UDP interno não pode encerrar o tráfego SSL.

  • Você precisa encaminhar os pacotes originais sem proxy. Por exemplo, se você precisa que o endereço IP de origem do cliente seja preservado.

  • Você tem uma configuração atual que usa um balanceador de carga de passagem e quer migrá-lo sem alterações.

Os balanceadores de carga TCP/UDP internos lidam com muitos casos de uso. Nesta seção, veremos alguns exemplos detalhados.

Exemplos de acesso

Acesse um balanceador de carga TCP/UDP interno na rede VPC por uma rede conectada usando o seguinte:

  • Peering de rede VPC
  • Cloud VPN e Cloud Interconnect

Para exemplos detalhados, consulte Balanceamento de carga TCP/UDP interno e redes conectadas.

Exemplo de serviço da Web de três camadas

Use o balanceamento de carga TCP/UDP interno com outros balanceadores de carga. Por exemplo, se você incorporar balanceadores de carga HTTP externos, o balanceador de carga HTTP(S) externo será a camada da Web e dependerá dos serviços por trás do balanceador de carga TCP/UDP interno.

No diagrama a seguir, você verá o exemplo de uma configuração de três camadas que usa balanceadores de carga HTTP(S) externos e balanceadores de carga TCP/UDP internos:

Aplicativo da Web de três camadas com balanceamento de carga de HTTP(S) e balanceamento de carga TCP/UDP interno
Aplicativo da Web de três camadas com balanceamento de carga de HTTP(S) e balanceamento de carga TCP/UDP interno (clique para ampliar)

Serviço da Web de três camadas com exemplo de acesso global

Se você ativar o acesso global, as VMs da Web podem estar em outra região, como mostrado no diagrama a seguir.

Este exemplo de aplicativo multicamada mostra:

  • Uma camada da Web voltada para a Internet disponível globalmente que equilibra a carga do tráfego com balanceamento de carga HTTP(S)
  • Uma camada interna de banco de dados de balanceamento de carga de back-end na região us-east1 acessada pela camada global da Web.
  • Uma VM cliente que faz parte da camada da Web na região europe-west1 com acesso à camada do banco de dados de balanceamento de carga interno localizada em us-east1.
Aplicativo da Web de três camadas com balanceamento de carga de HTTP(S), acesso global e balanceamento de carga TCP/UDP interno
Aplicativo da Web de três camadas com balanceamento de carga de HTTP(S), acesso global e balanceamento de carga TCP/UDP interno (clique para ampliar)

Como usar balanceadores de carga TCP/UDP internos como próximos saltos

Use um balanceador de carga TCP/UDP interno como o próximo gateway a que os pacotes serão encaminhados no caminho até o destino final. Para fazer isso, defina o balanceador de carga como o próximo salto em uma rota estática personalizada.

Um balanceador de carga TCP/UDP interno implantado como próximo salto em uma rota personalizada processa todo o tráfego, independentemente do protocolo (TCP, UDP ou ICMP).

Veja uma arquitetura de amostra usando um balanceador de carga TCP/UDP interno como o próximo salto para um gateway NAT. É possível rotear o tráfego para os back-ends de firewall ou appliance virtual de gateway por meio de um balanceador de carga TCP/UDP interno.

Caso de uso de NAT (clique para ampliar)
Caso de uso de NAT (clique para ampliar)

Outros casos de uso incluem:

  • "Hub and spoke": como trocar rotas de próximo salto usando o peering de rede VPC: é possível configurar uma topologia "hub-and-spoke" com seus appliances virtuais de firewall de próximo salto localizados na rede VPC hub. Rotas que usam o balanceador de carga como próximo salto na rede VPC hub podem ser usadas em cada rede spoke.
  • Balanceamento de carga para várias NICs nas VMs de back-end.

Para mais informações sobre esses casos de uso, consulte Balanceadores de carga TCP/UDP internos como próximos saltos.

Balanceamento de carga TCP/UDP interno e GKE

Para detalhes sobre como o GKE cria balanceadores de carga TCP/UDP internos para Serviços, consulte Conceitos de Serviço do LoadBalancer na documentação do GKE.

Como funciona o balanceamento de carga TCP/UDP interno

Os balanceadores de carga TCP/UDP internos têm as seguintes características:

  • São um serviço gerenciado.
  • Não são um proxy.
  • São implementados em redes virtuais.

Ao contrário de um balanceador de carga de proxy, um balanceador de carga TCP/UDP interno não encerra conexões de clientes e depois abre novas conexões com back-ends. Em vez disso, um balanceador de carga TCP/UDP interno roteia as conexões diretamente dos clientes para os back-ends íntegros, sem nenhuma interrupção.

  • Não há dispositivo intermediário ou ponto único de falha.
  • As solicitações do cliente para o endereço IP do balanceador de carga vão diretamente para as VMs de back-end íntegras.
  • As respostas das VMs de back-end vão diretamente para os clientes, e não voltam pelo balanceador de carga. As respostas TCP usam retorno direto do servidor. Para mais informações, consulte Pedidos TCP e UDP e pacotes de retorno.

O balanceador de carga monitora a integridade da VM usando sondagens de verificação de integridade. Para mais informações, consulte a seção Verificação de integridade.

O ambiente de convidado do Linux, o do Windows ou um processo equivalente do Google Cloud configura cada VM de back-end com o endereço IP do balanceador de carga. Para VMs criadas a partir de imagens do Google Cloud, o agente de convidado (antigo ambiente de convidado do Windows ou Linux) instala a rota local do endereço IP do balanceador de carga. As instâncias do Google Kubernetes Engine baseadas no Container-Optimized OS implementam isso usando iptables.

A rede virtual do Google Cloud gerencia o fornecimento de tráfego, escalonando conforme apropriado.

Protocolos, esquema e escopo

Cada balanceador de carga TCP/UDP interno é compatível com:

  • Um serviço de back-end com esquema de balanceamento de carga INTERNAL e o protocolo TCP ou UDP (mas não ambos)
  • VMs de back-end especificadas como uma destas:
  • Suporte ao tráfego IPv4 e IPv6 ao usar back-ends de grupos de instâncias. Os grupos de endpoints de rede zonais (NEGs, na sigla em inglês) com endpoints GCE_VM_IP são compatíveis apenas com o tráfego IPv4.
  • Uma ou mais regras de encaminhamento, cada uma usando o protocolo TCP ou UDP, correspondendo ao protocolo do serviço de back-end.
  • Cada regra de encaminhamento com o próprio endereço IP exclusivo ou várias regras de encaminhamento que compartilham um endereço IP comum.
  • Cada regra de encaminhamento com até cinco portas ou todas as portas.
  • Se o acesso global estiver ativado, os clientes em qualquer região.
  • Se o acesso global estiver desativado, os clientes na mesma região do balanceador de carga.

Os balanceadores de carga TCP/UDP internos não são compatíveis com:

  • VMs de back-end em várias regiões.
  • Equilíbrio de tráfego com origem na Internet, a menos que esteja usando um balanceador de carga externo.
  • Protocolos diferentes de TCP, UDP e ICMP para o tráfego IPv6.
  • Pacotes IPv6 com cabeçalhos fragmentados.

Acesso de cliente

Por padrão, os clientes precisam estar na mesma região do balanceador de carga. Os clientes podem estar na mesma rede ou em uma rede VPC conectada usando o peering de rede VPC. É possível ativar o acesso global para permitir que clientes de qualquer região acessem o balanceador de carga TCP/UDP interno.

Balanceamento de carga TCP/UDP interno com acesso global (clique para ampliar)
Balanceamento de carga TCP/UDP interno com acesso global (clique para ampliar)

Na tabela a seguir, é possível ver um resumo do acesso do cliente.

Acesso global desativado Acesso global ativado
Os clientes precisam estar na mesma região que o balanceador de carga. Também precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando o peering da rede VPC. Os clientes podem estar em qualquer região. Ainda precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando peering da rede VPC.
Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos precisam estar na mesma região do balanceador de carga. Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos podem estar em qualquer região.

Endereços IP para pacotes de solicitação e retorno

Quando uma VM de back-end recebe um pacote com carga balanceada de um cliente, a origem e o destino do pacote são os seguintes:

  • Origem: é o endereço IPv4 interno, IPv6 ou IPv4 do cliente de um dos intervalos IPv4 de alias do cliente.
  • Destino: o endereço IP da regra de encaminhamento do balanceador de carga. A regra de encaminhamento usa um único endereço IPv4 interno ou um intervalo IPv6 interno.

Como o balanceador de carga é um balanceador de carga de transmissão, e não um proxy, os pacotes chegam carregando o endereço IP de destino da regra de encaminhamento do balanceador de carga. O software em execução nas VMs de back-end precisa ser configurado para fazer o seguinte:

  • Detectar (vincular) o endereço IP da regra de encaminhamento do balanceador de carga ou qualquer endereço IP (0.0.0.0 ou ::).
  • Se o protocolo da regra de encaminhamento do balanceador de carga suportar portas: detectar em (vincular) uma porta incluída na regra de encaminhamento do balanceador de carga

Os pacotes de retorno são enviados diretamente das VMs de back-end do balanceador de carga para o cliente. Os endereços IP de origem e de destino do pacote de retorno dependem do protocolo:

  • O TCP é orientado por conexão. Assim, as VMs de back-end respondem com pacotes cujos endereços IP de origem correspondam ao endereço IP da regra de encaminhamento para que o cliente possa associar os pacotes de resposta à conexão TCP apropriada.
  • O UDP não tem conexão. Portanto, as VMs de back-end podem enviar pacotes de resposta com endereços IP de origem que correspondam ao endereço IP da regra de encaminhamento ou a qualquer endereço IP atribuído à VM. Na prática, a maioria dos clientes espera que a resposta seja do mesmo endereço IP que enviou os pacotes.

Nesta tabela, há um resumo das origens e dos destinos dos pacotes de resposta:

Tipo de tráfego Origem Destino
TCP O endereço IP da regra de encaminhamento do balanceador de carga A origem do pacote solicitante
UDP Na maioria dos casos de uso, o endereço IP da regra de encaminhamento do balanceador de carga † A origem do pacote solicitante

† É possível definir a origem do pacote de resposta para o endereço IPv4 interno principal da NIC da VM ou um intervalo de endereços IP do alias. Se a VM estiver com o encaminhamento de IP ativado, origens de endereço IP arbitrárias também poderão ser usadas. Não usar o endereço IP da regra de encaminhamento como uma origem é um cenário avançado, porque o cliente recebe um pacote de resposta de um endereço IP interno que não corresponde ao endereço IP a que ele enviou um pacote de solicitação.

Arquitetura

Um balanceador de carga TCP/UDP interno com vários back-ends distribui conexões entre todos esses back-ends. Para informações sobre o método de distribuição e as opções de configuração, consulte Distribuição de tráfego.

É possível usar grupos de instâncias ou NEGs zonais, mas não uma combinação de ambos, como back-ends para um balanceador de carga TCP/UDP interno:

  • Se você escolher grupos de instâncias, poderá usar grupos não gerenciados de instâncias, gerenciadas por zona, regionais ou uma combinação de tipos de grupos.
  • Se você escolher NEGs zonais, use NEGs zonais GCE_VM_IP.

Em Alta disponibilidade, você encontra instruções sobre como projetar um balanceador de carga interno que não dependa de uma única zona.

As instâncias que participam como VMs de back-end para balanceadores de carga TCP/UDP internos precisam executar o ambiente de convidado do Linux ou do Windows apropriado ou outros processos que proporcionem funcionalidade equivalente. Esse ambiente de convidado precisa contatar o servidor de metadados (metadata.google.internal e 169.254.169.254) para ler os metadados da instância a fim de gerar rotas locais para aceitar o tráfego enviado ao endereço IP interno do balanceador de carga.

Neste diagrama, ilustramos a distribuição de tráfego entre VMs localizadas em dois grupos de instâncias separados. O tráfego enviado da instância do cliente para o endereço IP do balanceador de carga (10.10.10.9) é distribuído entre as VMs de back-end em qualquer um dos grupos de instâncias. As respostas enviadas de qualquer uma das VMs de back-end exibidas são entregues diretamente à VM cliente.

O balanceamento de carga TCP/UDP interno pode ser usado com uma rede VPC de modo personalizado ou automático. Também é possível criar balanceadores de carga TCP/UDP internos com uma rede legada disponível.

Os balanceadores de carga TCP/UDP internos consistem nos seguintes componentes do Google Cloud.

Componente Motivo Requisitos
Endereço IP interno Este é o endereço do balanceador de carga. É preciso que o endereço IP interno esteja na mesma sub-rede que a regra de encaminhamento interno. A sub-rede precisa estar na mesma região e na mesma rede VPC do serviço de back-end.
Regra de encaminhamento interno Uma regra de encaminhamento interno, combinada ao endereço IP interno, é o front-end do balanceador de carga. Ela define o protocolo e as portas que o balanceador de carga aceita e direciona o tráfego para um serviço de back-end interno regional. As regras de encaminhamento para balanceadores de carga TCP/UDP internos precisam:
• ter um load-balancing-scheme de INTERNAL;
• usar ip-protocol de TCP ou UDP, correspondendo ao protocol do serviço de back-end;
• referenciar subnet na mesma rede VPC e na mesma região do serviço de back-end.
Serviço de back-end interno regional O serviço de back-end interno regional define o protocolo usado para a comunicação com os back-ends e especifica uma verificação de integridade. Os back-ends podem ser grupos não gerenciados de instâncias, grupos gerenciados de instâncias zonais, grupos gerenciados de instâncias regionais ou NEGs zonais com endpoints GCE_VM_IP. O serviço de back-end precisa:
• ter load-balancing-scheme de INTERNAL;
• usar protocol de TCP ou UDP, correspondendo ao ip-protocol da regra de encaminhamento;
• ter uma verificação de integridade vinculada;
• ter uma região vinculada. A regra de encaminhamento e todos os back-ends precisam estar na mesma região que o serviço de back-end
• Estar associados a uma única rede VPC. Quando não especificada, a rede é inferida com base na que é usada pela interface de rede padrão de cada VM de back-end (nic0).

Mesmo que o serviço de back-end não esteja vinculado a uma sub-rede específica, a sub-rede da regra de encaminhamento precisa estar na mesma rede VPC do serviço de back-end.
Verificação de integridade Cada serviço de back-end precisa ter uma verificação de integridade vinculada. A verificação de integridade define os parâmetros sob os quais o Google Cloud considera os back-ends que gerencia qualificados para receber tráfego. Somente VMs de back-end íntegras recebem o tráfego enviado de VMs do cliente para o endereço IP do balanceador de carga.
 Por mais que a regra de encaminhamento e o serviço de back-end possam usar TCP ou UDP, o Google Cloud não tem uma verificação de integridade para o tráfego UDP. Para mais informações, consulte verificações de integridade e tráfego UDP.

Endereço IP interno

O balanceamento de carga TCP/UDP interno é compatível apenas com sub-redes IPv4 (pilha única) e sub-redes IPv4 e IPv6 (pilha dupla). Para mais informações, consulte Tipos de sub-rede.

O balanceamento de carga TCP/UDP interno exige pelo menos uma regra de encaminhamento. A regra de encaminhamento faz referência ao endereço IP interno:

  • Para o tráfego IPv4, a regra de encaminhamento faz referência a um endereço IPv4 do intervalo de sub-rede IPv4 principal.
  • Para Tráfego IPv6, a regra de encaminhamento faz referência a um intervalo /96 de endereços IPv6 internos do intervalo da sub-rede /64 de endereços IPv6 interno. A sub-rede precisa ser uma pilha dupla de sub-rede com um intervalo de endereços IPv6 interno (ipv6-access-type definido como INTERNAL).

Configuração do firewall

Os balanceadores de carga TCP/UDP internos exigem a seguinte configuração para políticas de firewall hierárquicos e regras de firewall da VPC:

Para mais informações, consulte Como configurar regras de firewall.

Regras de encaminhamento

Uma regra de encaminhamento especifica o protocolo e as portas em que o balanceador de carga aceita tráfego. Como os balanceadores de carga TCP/UDP internos não são proxies, passam o tráfego para back-ends no mesmo protocolo e na mesma porta.

Um balanceador de carga TCP/UDP interno exige, no mínimo, uma regra de encaminhamento interno. Defina várias regras de encaminhamento para o mesmo balanceador de carga.

Se você quiser que o balanceador de carga processe tráfego IPv4 e IPv6, crie duas regras de encaminhamento: uma regra para tráfego IPv4 que aponte para back-ends de IPv4 (ou pilha dupla) e uma regra para tráfego IPv6 que aponte somente para back-ends de pilha dupla. É possível ter uma regra de encaminhamento IPv4 e uma de IPv6 para fazer referência ao mesmo serviço de back-end, mas ele precisa fazer referência aos back-ends de pilha dupla.

A regra de encaminhamento precisa referenciar uma sub-rede específica na mesma rede VPC e na mesma região dos componentes de back-end do balanceador de carga. Esse requisito tem as seguintes implicações:

  • A sub-rede especificada para a regra de encaminhamento não precisa ser igual a uma das usadas pelas VMs de back-end. No entanto, a sub-rede precisa estar na mesma região da regra de encaminhamento.
  • Para o tráfego IPv4, a regra de encaminhamento interno faz referência ao endereço IPv4 interno regional do intervalo de endereços IPv4 principal da sub-rede selecionada. É possível selecionar esse endereço IPv4 automaticamente ou usar um endereço IPv4 estático (reservado).
  • Para Tráfego IPv6, a regra de encaminhamento faz referência a um intervalo /96 de endereços IPv6 do intervalo da sub-rede de endereços IPv6 interno. A sub-rede precisa ser uma sub-rede de pilha dupla com o ipv6-access-type definido como INTERNAL. O intervalo de endereços IPv6 /96 é atribuído automaticamente. Por ser um intervalo, não é possível criar um endereço IPv6 reservado estático.

Regras de encaminhamento e acesso global

As regras de encaminhamento dos balanceadores de carga TCP/UDP internos são regionais, mesmo quando o acesso global está ativado. Depois de ativar o acesso global, a sinalização allowGlobalAccess da regra de encaminhamento interno regional é definida como true.

Regras de encaminhamento e especificações de porta

Ao criar uma regra de encaminhamento interno, escolha uma das seguintes especificações de porta:

  • Especifique entre uma e cinco portas, por número.
  • Especifique ALL para encaminhar tráfego a todas as portas.

Com uma regra de encaminhamento interno compatível com todas as portas TCP ou UDP, é possível fazer com que as VMs de back-end executem vários aplicativos, cada um na própria porta. O tráfego enviado para uma determinada porta é entregue ao aplicativo correspondente, e todos os aplicativos usam o mesmo endereço IP.

Quando precisar encaminhar o tráfego em mais de cinco portas específicas, combine regras de firewall com as regras de encaminhamento. Ao criar a regra de encaminhamento, especifique todas as portas e crie regras de firewall de entrada allow que tenham apenas tráfego para as portas correspondentes. Aplique as regras de firewall às VMs de back-end.

Não modifique regras de encaminhamento depois de criá-las. Se precisar alterar as portas especificadas ou o endereço IP interno de uma regra de encaminhamento interno, será necessário excluí-lo e recriá-lo.

Várias regras de encaminhamento para um único serviço de back-end

É possível configurar várias regras de encaminhamento interno que fazem referência ao mesmo serviço de back-end interno. Um balanceador de carga TCP/UDP interno exige, no mínimo, uma regra de encaminhamento interno.

Configurar várias regras de encaminhamento para o mesmo serviço de back-end permite fazer o seguinte, usando TCP ou UDP (não os dois):

  • Atribua vários endereços IP ao balanceador de carga. É possível criar várias regras de encaminhamento, cada uma usando um endereço IP exclusivo. Cada regra de encaminhamento pode especificar todas as portas ou um conjunto de até cinco portas.

  • Atribua um conjunto específico de portas, usando o mesmo endereço IP, ao balanceador de carga. É possível criar várias regras de encaminhamento que compartilham o mesmo endereço IP, em que cada regra de encaminhamento usa um conjunto específico de até cinco portas. Essa é uma alternativa à configuração de uma única regra de encaminhamento que especifica todas as portas.

Para mais informações sobre cenários que envolvem duas ou mais regras de encaminhamento interno que compartilham um endereço IP interno comum, consulte Várias regras de encaminhamento com o mesmo endereço IP.

Ao usar várias regras de encaminhamento interno, configure o software em execução nas VMs de back-end para que seja vinculado a todos os endereços IP da regra de encaminhamento ou a qualquer endereço (0.0.0.0/0 para IPv4 ou ::/0 para IPv6). O endereço IP de destino de um pacote entregue pelo balanceador de carga é o endereço IP interno vinculado à respectiva regra de encaminhamento interno. Para mais informações, consulte Pedidos TCP e UDP e pacotes de retorno.

Serviço de back-end

Cada balanceador de carga TCP/UDP interno tem um serviço de back-end interno regional que define parâmetros e comportamento de back-end. O nome do serviço de back-end é o nome do balanceador de carga TCP/UDP interno 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 TCP ou UDP, mas não ambos, nas portas especificadas por uma ou mais regras de encaminhamento interno. Com o serviço de back-end, é possível direcionar tráfego às VMs de back-end nas mesmas portas para que o tráfego foi enviado. O protocolo do serviço de back-end precisa corresponder ao protocolo da regra de encaminhamento.

  • Distribuição de tráfego. Com um serviço de back-end, é possível fazer com que o tráfego seja distribuído de acordo com uma afinidade de sessão configurável.

  • 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 VMs de back-end em uma única rede VPC:

Back-ends de grupo de instâncias e interfaces de rede

A rede VPC associada a um grupo de instâncias é a rede VPC usada pela interface de rede nic0 de cada VM membro.

  • Para grupos de instâncias gerenciadas, a rede VPC do grupo de instâncias é definida no modelo de instância.
  • Para grupos de instâncias não gerenciadas, a rede VPC do grupo de instâncias é definida como a rede VPC usada pela interface de rede nic0 da primeira instância de VM adicionada ao grupo de instâncias não gerenciadas.

Em um determinado grupo de instâncias (gerenciadas ou não), todas as instâncias de VM precisam ter as interfaces de rede nic0 na mesma rede VPC. Cada VM membro pode ter uma interface de rede extra (de nic1 a nic7) em uma rede VPC diferente da rede VPC. associada ao grupo de instâncias.

Back-ends de NEG zonais e interfaces de rede

A rede VPC associada a um NEG zonal com endpoints GCE_VM_IP é especificada quando você cria o NEG zonal, antes de adicionar endpoints a ele.

Em um determinado NEG, cada endpoint GCE_VM_IP representa uma interface de rede. A interface de rede precisa estar na rede VPC associada ao NEG. Do ponto de vista de uma instância do Compute Engine, a interface de rede pode usar qualquer identificador (de nic0 a nic7). Da perspectiva de ser um endpoint em um NEG, a interface é identificada usando o endereço IPv4 principal.

Há duas maneiras de adicionar um endpoint GCE_VM_IP a um NEG:

  • Se você especificar um nome de VM e um endereço IP ao adicionar um endpoint, o endereço IP fornecido precisará ser um endereço IPv4 interno principal para uma das interfaces de rede da VM. Essa interface de rede precisa usar a rede VPC associada ao NEG.
  • Se você especificar apenas um nome de VM (sem qualquer endereço IP) ao adicionar um endpoint, o Google Cloud exigirá que a VM tenha uma interface de rede na rede VPC associada ao NEG. O endereço IP que o Google Cloud escolhe para o endpoint é o endereço IPv4 interno principal da interface de rede na rede VPC associada ao NEG.

Especificação da rede de serviço de back-end

É possível associar explicitamente uma rede VPC a um serviço de back-end usando a sinalização --network ao criar o serviço de back-end. As regras da rede de serviço de back-end entram em vigor imediatamente.

Se você omitir a sinalização --network ao criar um serviço de back-end, o Google Cloud usará um dos seguintes eventos qualificados para definir implicitamente a rede VPC associada do serviço de back-end. Após a definição, a rede VPC associada do serviço de back-end não pode ser alterada:

  • Se o serviço de back-end ainda não tiver back-ends associados e você configurar a primeira regra de encaminhamento para referenciar o serviço de back-end, o Google Cloud definirá a rede VPC associada ao serviço de back-end como a rede VPC que contém a sub-rede usada por essa regra de encaminhamento.

  • Se o serviço de back-end ainda não tiver uma regra de encaminhamento que faça referência a ele e você adicionar o primeiro back-end do grupo de instâncias ao serviço de back-end, o Google Cloud vai definir a rede VPC do serviço de back-end como a rede VPC associada ao primeiro back-end do grupo de instâncias. Isso significa que a rede VPC associada do serviço de back-end é a rede usada pela interface de rede nic0 de cada VM no primeiro back-end do grupo de instâncias.

  • Se o serviço de back-end ainda não tiver uma regra de encaminhamento que faça referência a ele e você adicionar o primeiro back-end do NEG zonal (com endpoints GCE_VM_IP) ao serviço de back-end, o Google Cloud definirá a rede VPC para a rede VPC associada ao primeiro back-end do NEG.

Depois que a rede VPC do serviço de back-end for definida por um evento qualificado, todas as regras de encaminhamento adicionais, grupos de instâncias de back-end ou NEGs zonais de back-end adicionados precisarão seguir as regras de rede de serviço de back-end.

Regras da rede de serviço de back-end

As regras a seguir se aplicam depois que um serviço de back-end é associado a uma rede VPC específica.

  • Ao configurar uma regra de encaminhamento para se referir ao serviço de back-end, ela precisa usar uma sub-rede da rede VPC do serviço de back-end. A regra de encaminhamento e o serviço de back-end não podem usar redes VPC diferentes, mesmo que elas estejam conectadas usando o peering de rede VPC.

  • Ao adicionar back-ends de grupos de instâncias, uma das seguintes condições precisa ser verdadeira:

    • A rede VPC associada ao grupo de instâncias, usada pela interface de rede nic0 de cada VM no grupo de instâncias, precisa corresponder à rede VPC associada do serviço de back-end.
    • Cada VM de back-end precisa ter uma interface não nic0 (de nic1 a nic7) na rede VPC associada ao serviço de back-end.

  • Ao adicionar back-ends de NEG zonal com endpoints GCE_VM_IP, a rede VPC associada ao NEG precisa corresponder à rede VPC associada ao serviço de back-end.

Subconfiguração de back-ends

A subconfiguração do back-end é um recurso opcional que melhora o desempenho ao limitar o número de back-ends a que o tráfego é distribuído.

Ative a subconfiguração se precisar aceitar mais de 250 VMs de back-end em um único balanceador de carga. Para mais informações, consulte Subconfiguração de back-end para balanceador de carga TCP/UDP interno.

Verificação de integridade

O serviço de back-end do balanceador de carga precisa estar associado a uma verificação de integridade global ou regional. Rotas especiais fora da rede VPC facilitam a comunicação entre os sistemas de verificação de integridade e os back-ends.

Use uma verificação de integridade atual ou defina uma nova. Os balanceadores de carga TCP/UDP internos usam status de verificação de integridade para determinar como rotear novas conexões, conforme descrito em Distribuição de tráfego.

Use qualquer um dos seguintes protocolos de verificação de integridade. O protocolo da verificação de integridade não precisa corresponder ao protocolo do balanceador de carga:

  • HTTP, HTTPS ou HTTP/2. Se as VMs de back-end enviarem tráfego usando HTTP, HTTPS ou HTTP/2, é melhor usar uma verificação de integridade que corresponda a esse protocolo, porque as que têm como base o HTTP oferecem opções adequadas ao protocolo em questão. Se a disponibilização de tráfego de HTTP for feita por meio de um balanceador de carga TCP/UDP, o protocolo do balanceador de carga será TCP.
  • SSL ou TCP. Se as VMs de back-end não enviarem tráfego do tipo HTTP, será necessário usar uma verificação de integridade SSL ou TCP.

Independentemente do tipo de verificação de integridade que você criar, o Google Cloud enviará sondagens de verificação de integridade para o endereço IP da regra de encaminhamento do balanceador de carga TCP/UDP interno, para a interface de rede na rede VPC selecionada pelo serviço de back-end do balanceador de carga. Isso simula como o tráfego com carga balanceado é entregue. O software em execução nas VMs de back-end precisa responder às sondagens de tráfego com carga balanceada e às verificações de integridade enviadas ao endereço IP de cada regra de encaminhamento (o software precisa detectar em 0.0.0.0:<port> e não em um endereço IP específico atribuído a uma interface de rede). Para mais informações, consulte Destino dos pacotes de sondagem.

Verificações de integridade e tráfego UDP

O Google Cloud não oferece uma verificação de integridade que use o protocolo UDP. Ao usar o balanceamento de carga TCP/UDP interno com tráfego UDP, você precisa executar um serviço baseado em TCP nas suas VMs de back-end para fornecer informações de verificação de integridade.

Nessa configuração, as solicitações de clientes são balanceadas com carga usando o protocolo UDP e um serviço TCP é usado para enviar informações a quem faz as sondagens de verificação de integridade do Google Cloud. Por exemplo, é possível usar um servidor HTTP simples em cada VM de back-end que gera uma resposta HTTP 200 para o Google Cloud. Neste exemplo, é 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.

Arquitetura de alta disponibilidade

Por design, o balanceador de carga TCP/UDP interno tem alta disponibilidade. Não há etapas especiais para deixar o balanceador de carga altamente disponível porque o mecanismo não depende de um único dispositivo ou instância de VM.

Para garantir que as instâncias de VM de back-end sejam implantadas em várias zonas, siga estas recomendações de implantação:

  • 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.

  • Se você usar grupos de instâncias gerenciadas por zona ou não gerenciadas, use vários grupos em zonas diferentes (na mesma região) para o mesmo serviço de back-end. O uso de várias zonas é uma proteção contra possíveis problemas que possam ocorrer em qualquer zona.

Arquitetura da VPC compartilhada

A tabela a seguir resume os requisitos do componente para o balanceamento de carga TCP/UDP interno usado com uma rede VPC compartilhada. Para um exemplo, consulte como criar um balanceador de carga TCP/UDP interno na página "Como provisionar a VPC compartilhada".

Endereço IP Regra de encaminhamento Componentes de back-end
Um endereço IP interno precisa ser definido no mesmo projeto que as VMs de back-end.

Para que o balanceador de carga esteja disponível em uma rede VPC compartilhada, o endereço IP interno do Google Cloud precisa ser definido no mesmo projeto de serviço em que as VMs de back-end estão localizadas e precisa referenciar uma sub-rede na rede VPC compartilhada do projeto host. O endereço vem do intervalo de IP principal da sub-rede referenciada.

Se você criar um endereço IP interno em um projeto de serviço e a sub-rede do endereço IP estiver na rede VPC do projeto de serviço, o balanceador de carga TCP/UDP interno será local para o projeto de serviço. Ele não é local para nenhum projeto host de VPC compartilhada.		 Uma regra de encaminhamento interna precisa ser definida no mesmo projeto das VMs de back-end.

Para que o balanceador de carga esteja disponível em uma rede VPC compartilhada, a regra de encaminhamento interno precisa ser definida no mesmo projeto de serviço das VMs de back-end, e precisa referenciar a mesma sub-rede (na rede VPC compartilhada) que o endereço IP interno associado.

Se você criar uma regra de encaminhamento interno em um projeto de serviço e a sub-rede da regra de encaminhamento estiver na rede VPC do projeto de serviço, o balanceador de carga TCP/UDP interno será local para o projeto de serviço. Ele não é local para nenhum projeto host de VPC compartilhada.		 Em um cenário de VPC compartilhada, as VMs de back-end estão localizadas em um projeto de serviço. Um serviço de back-end interno regional e uma verificação de integridade precisam ser definidos nesse projeto de serviço.

Distribuição de tráfego

A maneira como um balanceador de carga TCP/UDP interno distribui novas conexões depende de você ter configurado o failover:

  • Se você não tiver configurado o failover, um balanceador de carga TCP/UDP 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 TCP/UDP 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

O balanceamento de carga TCP/UDP interno usa algoritmos configuráveis de rastreamento de conexão e seleção de back-end para determinar como o tráfego é distribuído para as VMs de back-end. O balanceamento de carga TCP/UDP interno 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:

      • 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 TCP/UDP 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. O balanceamento de carga de rede chama essa opção de afinidade de sessão 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 TCP/UDP interno do próximo salto.

Afinidade de sessão e balanceador de carga TCP/UDP interno do próximo salto

Ao usar um balanceador de carga TCP/UDP interno como próximo salto para uma rota estática personalizada, é provável que o destino do pacote não seja o endereço IP da regra de encaminhamento do balanceador de carga.

Um pacote será entregue ao balanceador de carga se o destino do pacote couber no destino da rota estática personalizada e se a rota estática personalizada for uma rota aplicável.

Todas as opções de afinidade de sessão, exceto IP do cliente, nenhum destino usam o endereço IP de destino do pacote. Ao usar uma rota estática personalizada em que próximo salto seja um balanceador de carga TCP/UDP interno:

  • Se o balanceador de carga tiver apenas um back-end (o pool ativo, se você tiver configurado o failover), todas as opções de afinidade da sessão escolherão esse back-end. A escolha da afinidade da sessão não faz diferença quando há um único back-end (no pool ativo).

  • Se o balanceador de carga tiver mais de um back-end (no pool ativo, se tiver configurado o failover) e você escolher qualquer opção de afinidade da sessão, exceto IP do cliente, nenhum destino, os pacotes enviados do mesmo cliente para qualquer endereço IP no destino da rota não são garantidos de serem processados pelo mesmo back-end. Isso ocorre porque o hash de afinidade da sessão é calculado a partir das informações que também incluem o endereço IP de destino do pacote, que pode ser qualquer endereço no intervalo de destino da rota.

  • Se você precisar garantir que o mesmo back-end processe todos os pacotes enviados do mesmo cliente para qualquer endereço IP no destino da rota, use a opção de afinidade da sessão IP do cliente, sem destino.

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 o balanceamento de carga de rede)

 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.

Como testar conexões de cliente único

Ao testar conexões com o endereço IP de um balanceador de carga TCP/UDP interno de um único sistema cliente, lembre-se do seguinte:

  • Se o sistema cliente não for uma VM que está sendo balanceada, isto é, nem é 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 de, no mínimo, o endereço IP do sistema cliente, as conexões do mesmo cliente podem ser distribuídas para a mesma VM 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 TCP/UDP 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 for uma VM de back-end do balanceador de carga, as conexões enviadas ao endereço IP da regra de encaminhamento do balanceador de carga serão sempre respondidas pela VM de cliente/back-end. Isso acontece independentemente 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.

Fragmentação UDP

Os balanceadores de carga TCP/UDP internos 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.
  • 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. Para ver mais detalhes, consulte a documentação do provedor de rede 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

O balanceamento de carga TCP/UDP interno 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, o Google Cloud distribuirá novas conexões somente entre todas as VMs primárias.

Ao adicionar um back-end a um serviço de back-end do balanceador de carga TCP/UDP 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 no balanceamento de carga interno TCP/UDP, consulte visão geral de failover para balanceamento de carga interno TCP/UDP.

Cotas e limites

Para informações sobre cotas e limites, consulte Cotas para recursos de balanceamento de carga.

A seguir