Visão geral do balanceador de carga de rede de passagem externa baseada em serviço

Os balanceadores de carga de rede de passagem externa são regionais, da camada 4, que distribuem o tráfego externo entre back-ends (grupos de instâncias ou grupos de endpoints de rede) na mesma região do balanceador de carga. Esses back-ends precisam estar na mesma região e projeto, mas podem estar em redes VPC diferentes. Esses balanceadores de carga são criados no Maglev e na pilha de virtualização de rede Andromeda.

Os balanceadores de carga de rede de passagem externos podem 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 da NAT baseada em instância

Os balanceadores de carga de rede de passagem externos não são proxies. O balanceador de carga em si não encerra conexões de usuário. Os pacotes com carga balanceada são enviados às VMs de back-end com os respectivos endereços IP de origem e destino, protocolo e, se aplicável, portas inalteradas. Em seguida, as VMs de back-end encerram as conexões de usuário. As respostas das VMs de back-end vão diretamente para os clientes, e não voltam pelo balanceador de carga. Esse processo é conhecido como retorno direto do servidor (DSR).

Os balanceadores de carga de rede de passagem externos baseados em serviço de back-end dão suporte aos seguintes recursos:

• Back-ends de grupos gerenciados e não gerenciados de instâncias. Os balanceadores de carga de rede de passagem externos baseados em serviço de back-end dão suporte a grupos gerenciados e não 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 não gerenciados de instâncias.
• Back-ends de NEG zonal. Os balanceadores de carga de rede de passagem externos baseados em serviço de back-end dão suporte ao uso de NEGs zonais com endpoints GCE_VM_IP. Os endpoints GCE_VM_IP do NEG zonal permitem fazer o seguinte:
  • Encaminhe pacotes para qualquer interface de rede, não apenas para nic0.
  • Coloque o mesmo endpoint GCE_VM_IP em dois ou mais NEGs zonais conectados a diferentes serviços de back-end.
• Suporte a vários protocolos. Os balanceadores de carga de rede de passagem externa baseados em serviço de back-end podem balancear a carga de tráfego TCP, UDP, ESP, GRE, ICMP e ICMPv6.
• Compatível com conectividade IPv6. Os balanceadores de carga de rede de passagem externa baseados em serviço de back-end podem lidar com tráfego IPv4 e IPv6.
• Controle de distribuição de tráfego detalhado. Um serviço de back-end permite que o tráfego seja distribuído de acordo com uma afinidade de sessão configurável, o modo de acompanhamento de conexão e balanceamento de carga ponderado. 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. A maioria dessas configurações tem valores padrão que permitem começar rapidamente.
• Suporte a verificações de integridade não legadas. Os balanceadores de carga de rede de passagem externos 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) sendo distribuído.
• Integração com o Google Cloud Armor. O Google Cloud Armor é compatível com proteção avançada contra DDoS de rede para balanceadores de carga de rede de passagem externa. Para mais informações, consulte Configurar proteção avançada contra DDoS de rede.

• Integração com o GKE. Ao criar aplicativos no GKE, é recomendado usar o controlador de serviços do GKE integrado, que implanta balanceadores de carga do Google Cloud em nome dos usuários do GKE. O mesmo ocorre com a arquitetura de balanceamento de carga independente descrita nesta página, exceto pelo fato de o ciclo de vida dela ser totalmente automatizado e controlado pelo GKE.

  Documentação relacionada do GKE:

  • Conceitos do serviço LoadBalancer
  • Como exibir aplicativos que usam serviços

Arquitetura

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

Balanceador de carga de rede de passagem externa com um 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 back-ends: todos os grupos de instâncias ou todos os back-ends de NEG por zona (endpoints GCE_VM_IP)
• 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 de passagem externa requer pelo menos uma regra de encaminhamento. A regra de encaminhamento faz referência a um endereço IP externo regional que pode ser acessado em qualquer lugar da Internet.

• Para o Tráfego IPv4, a regra de encaminhamento faz referência a um único endereço IPv4 externo regional. Os endereços IPv4 externos regionais vêm de um pool exclusivo para cada região do Google Cloud. O endereço IP pode ser um endereço estático reservado ou um endereço temporário.

• Para o tráfego IPv6, a regra de encaminhamento faz referência a um intervalo /96 de uma sub-rede de pilha dupla com um intervalo de sub-rede IPv6 externo na rede VPC. Os endereços IPv6 externos estão disponíveis apenas no nível Premium. O intervalo de endereços IPv6 pode ser um endereço estático reservado ou um endereço temporário.

  Observação: Para mais detalhes sobre a compatibilidade com IPv6, consulte a documentação da VPC sobreIntervalos de sub-rede IPv6 e Endereços IPv6.

Use um endereço IP reservado para regra de encaminhamento 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.

Os balanceadores de carga de rede de passagem externa são compatíveis com os níveis Premium e Standard para endereços IPv4 externos regionais. O endereço IP e a regra de encaminhamento precisam usar o mesmo nível de rede. Os endereços IPv6 externos regionais estão disponíveis apenas no nível Premium.

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 é um endereço associado à regra de encaminhamento do balanceador de carga.

O tráfego de entrada é combinado com uma regra de encaminhamento, que é uma combinação de um determinado endereço IP (seja um endereço IPv4 ou um intervalo de endereços IPv6), protocolo e, se o protocolo for baseado em portas, uma das portas, um intervalo de portas ou todas as portas. A regra de encaminhamento direciona o tráfego para o serviço de back-end do balanceador de carga.

• Se a regra de encaminhamento fizer referência a um endereço IPv4, ela não estará associada a nenhuma sub-rede. Ou seja, o endereço IP dela vem de fora de qualquer intervalo de sub-rede do Google Cloud.

• Se a regra de encaminhamento fizer referência a um intervalo de endereços IPv6 /96, essa regra precisa estar associada a uma sub-rede, e essa sub-rede precisa ser (a) de pilha dupla e (b) ter um intervalo de sub-rede IPv6 externo (--ipv6-access-type definido como EXTERNAL). A sub-rede à qual as referências de regra de encaminhamento podem ser as mesmas usadas pelas instâncias de back-end. No entanto, as instâncias de back-end podem usar uma sub-rede separada, se quiserem. Quando as instâncias de back-end usam uma sub-rede separada, os seguintes itens precisam ser verdadeiros:

Um balanceador de carga de rede de passagem externa requer pelo menos uma regra de encaminhamento. As regras de encaminhamento podem ser configuradas para direcionar o tráfego proveniente de um intervalo específico de endereços IP de origem para um serviço de back-end específico (ou instância de destino). Para ver mais detalhes, consulte Direcionamento de tráfego. Defina várias regras de encaminhamento para o mesmo balanceador de carga, conforme descrito em Várias regras de encaminhamento.

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.

Protocolos da regra de encaminhamento

Os balanceadores de carga de rede de passagem externa são compatíveis com as seguintes opções de protocolo para cada regra de encaminhamento: TCP, UDP e L3_DEFAULT.

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 de passagem externa faça o balanceamento de carga de tráfego TCP, UDP, ESP, GRE, ICMP e ICMPv6.

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 que usa o mesmo protocolo que a regra de encaminhamento ou um serviço de back-end cujo protocolo seja UNSPECIFIED. As regras de encaminhamento L3_DEFAULT só podem referenciar um serviço de back-end com protocolo UNSPECIFIED.

Se você estiver usando o protocolo L3_DEFAULT, vai precisar configurar a regra de encaminhamento para aceitar o tráfego em todas as portas. Para configurar todas as portas, defina --ports=ALL usando a CLI do Google Cloud ou defina allPorts como True usando a API.

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, GRE, ICMP/ICMPv6 (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 de passagem externa. 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.
• Você precisa direcionar o tráfego de determinados endereços IP de origem para back-ends específicos do balanceador de carga.

O Google Cloud exige que os pacotes de entrada não correspondam a mais de uma regra de encaminhamento. Exceto pelas regras de encaminhamento de disco, que serão discutidas na próxima seção, duas ou mais regras de encaminhamento que usam o mesmo endereço IP externo regional precisam ter combinações exclusivas de protocolo e porta de acordo com estas restrições:

• Uma regra de encaminhamento configurada para todas as portas de um protocolo impede a criação de outras regras de encaminhamento usando o mesmo protocolo e endereço IP. As regras de encaminhamento usando protocolos TCP ou UDP podem ser configuradas para usar todas as portas ou podem ser configuradas para portas específicas. Por exemplo, se você criar uma regra de encaminhamento usando endereços IP198.51.100.1 , oTCP e todas as portas, não é possível criar outra regra de encaminhamento usando endereços IP. 198.51.100.1 eTCP protocolo. É possível criar duas regras de encaminhamento, usando o endereço IP 198.51.100.1 e o protocolo TCP, se cada uma tiver portas únicas ou intervalos de portas não sobrepostos. Por exemplo, é possível criar duas regras de encaminhamento usando o endereço IP 198.51.100.1 e o protocolo TCP, em que uma porta da regra de encaminhamento é 80,443 e a outra usa o intervalo de portas 81-442.
• Apenas uma regra de encaminhamento L3_DEFAULT pode ser criada por endereço IP. Isso ocorre porque o protocolo L3_DEFAULT usa todas as portas por definição. Nesse contexto, o termo "todas as portas" inclui protocolos sem informações de porta.

• Uma única regra de encaminhamento L3_DEFAULT pode coexistir com outras regras que usam protocolos específicos (TCP ou UDP). A regra de encaminhamento L3_DEFAULT pode ser usada como último recurso ao encaminhar regras usando o mesmo endereço IP, mas existirem protocolos mais específicos. Uma regra de encaminhamento L3_DEFAULT processará pacotes enviados para o endereço IP de destino se e somente se o endereço IP, o protocolo e a porta de destino do pacote não corresponderem a uma regra de encaminhamento específica do protocolo.
  

  Para ilustrar isso, considere estes dois cenários. Nas duas situações, as regras de encaminhamento usam o mesmo endereço IP 198.51.100.1.

  • Cenário 1. A primeira regra de encaminhamento usa o protocolo L3_DEFAULT. A segunda regra de encaminhamento usa o protocolo TCP e todas as portas. Os pacotes TCP enviados para qualquer porta de destino de 198.51.100.1 são processados pela segunda regra de encaminhamento. Os pacotes que usam protocolos diferentes são processados pela primeira regra de encaminhamento.
  • Cenário 2. A primeira regra de encaminhamento usa o protocolo L3_DEFAULT. A segunda regra de encaminhamento usa o protocolo TCP e a porta 8080. Os pacotes TCP enviados para 198.51.100.1:8080 são processados pela segunda regra de encaminhamento. Todos os outros pacotes, incluindo pacotes TCP enviados para diferentes portas de destino, são processados pela primeira regra de encaminhamento.

Seleção de regra de encaminhamento

O Google Cloud seleciona uma ou nenhuma regra de encaminhamento para processar um pacote recebido usando esse processo de eliminação, começando pelo conjunto de candidatos de regra de encaminhamento que correspondem ao endereço IP de destino do pacote:

• Elimine as regras de encaminhamento que não correspondem ao protocolo do pacote, exceto as regras de encaminhamento L3_DEFAULT. As regras de encaminhamento que usam o protocolo L3_DEFAULT nunca são eliminadas por esta etapa porque L3_DEFAULT corresponde a todos os protocolos. Por exemplo, se o protocolo do pacote for TCP, apenas as regras de encaminhamento que usam o protocolo UDP serão eliminadas.

• Elimine as regras de encaminhamento cuja porta não corresponde à do pacote. As regras de encaminhamento configuradas para todas as portas nunca são eliminadas nesta etapa, porque uma regra corresponde a qualquer porta.

• Se as outras regras de encaminhamento incluírem L3_DEFAULT e regras de encaminhamento específicas do protocolo, elimine as regras de encaminhamento L3_DEFAULT. Se todos os candidatos restantes forem L3_DEFAULT, nenhum será eliminado nesta etapa.

• Neste momento, os candidatos restantes da regra de encaminhamento se enquadram em uma das seguintes categorias:

  • Uma única regra de encaminhamento permanece, que corresponde ao endereço IP, ao protocolo e à porta do pacote do pacote, e é usada para rotear o pacote.
  • Dois ou mais candidatos de regra de encaminhamento permanecem correspondentes ao endereço IP, ao protocolo e à porta do pacote. Isso significa que os candidatos restantes da regra de encaminhamento incluem guiar as regras de encaminhamento (discutidas na próxima seção). Selecione a regra de encaminhamento de direcionamento cujo intervalo origem inclui o CIDR mais específico (correspondência de prefixo mais longa) que contém o endereço IP de origem do pacote. Se nenhuma regra de encaminhamento de direcionamento tiver um intervalo de origem, incluindo o endereço IP de origem do pacote, selecione a regra de encaminhamento principal.
  • Os candidatos da regra de encaminhamento zero permanecem e o pacote é descartado.

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.

Direcionamento de tráfego.

As regras de encaminhamento para balanceadores de carga de rede podem ser configuradas para direcionar o tráfego proveniente de um intervalo específico de endereços IP de origem para um serviço de back-end específico (ou instância de destino).

O direcionamento de tráfego é útil para solucionar problemas e configurações avançadas. Com o direcionamento de tráfego, é possível direcionar determinados clientes para um conjunto diferente de back-ends, uma configuração diferente para os serviços de back-end ou ambos. Exemplo:

• O direcionamento de tráfego permite criar duas regras de encaminhamento que direcionam o tráfego para o mesmo back-end (grupo de instâncias ou NEG) por meio de dois serviços de back-end. Os dois serviços de back-end podem ser configurados com diferentes verificações de integridade, afinidades de sessão ou políticas de controle de distribuição de tráfego distintas (rastreamento de conexão, diminuição de conexão e failover).
• O direcionamento de tráfego permite criar uma regra de encaminhamento para redirecionar o tráfego de um serviço de back-end de baixa largura de banda para um serviço de back-end de alta largura de banda. Ambos os serviços de back-end contêm o mesmo conjunto de endpoints ou VMs de back-end, mas com balanceamento de carga com pesos diferentes usando o balanceamento de carga ponderado.
• O direcionamento de tráfego permite criar duas regras de encaminhamento que direcionam o tráfego para diferentes serviços de back-end, com back-ends distintos (grupos de instâncias ou NEGs). Por exemplo, um grupo de back-ends pode ser configurado usando diferentes tipos de máquina para processar melhor o tráfego de um determinado conjunto de endereços IP de origem.

O direcionamento de tráfego é configurado com um parâmetro de API de regra de encaminhamento chamado sourceIPRanges. As regras de encaminhamento que têm pelo menos um intervalo de IP de origem configurado são chamadas de regras de encaminhamento de direcionamento.

Uma regra de encaminhamento de direção pode ter uma lista de até 64 intervalos de IP de origem. É possível atualizar a lista de intervalos de IP de origem configurados para uma regra de encaminhamento de direcionamento a qualquer momento.

Cada regra de encaminhamento de direcionamento exige que você primeiro crie uma regra de encaminhamento mãe. As regras de encaminhamento pai e direcionamento compartilham o mesmo endereço IP externo regional, protocolo IP e informações da porta. No entanto, a regra de encaminhamento pai não tem informações de endereço IP de origem. Exemplo:

• Regra de encaminhamento pai: endereço IP: 198.51.100.1, protocolo IP: TCP, portas: 80
• Regra de encaminhamento de direcionamento: endereço IP: 198.51.100.1, protocolo IP: TCP, portas: 80, sourceIPRanges: 203.0.113.0/24

Uma regra de encaminhamento pai que aponta para um serviço de back-end pode ser associada a uma regra de encaminhamento de direcionamento que aponta para um serviço de back-end ou uma instância de destino.

Para uma determinada regra de encaminhamento pai, duas ou mais regras de encaminhamento podem ter intervalos de IP de origem sobrepostos, mas não idênticos. Por exemplo, uma regra de encaminhamento pode ter o intervalo de IP de origem 203.0.113.0/24 e outra regra de encaminhamento pode ter o intervalo de IP de origem 203.0.113.0.

Exclua todas as regras de encaminhamento de direcionamento antes de excluir a regra de encaminhamento principal de que elas dependem.

Para saber como os pacotes de entrada são processados ao controlar as regras de encaminhamento, consulte Seleção da regra de encaminhamento.

Comportamento de afinidade da sessão nas mudanças de direção

Nesta seção, descrevemos as condições em que a afinidade da sessão pode ser interrompida quando os intervalos de IP de origem das regras de encaminhamento de direção são atualizados:

• Se uma conexão atual continuar a corresponder à mesma regra de encaminhamento depois que você alterar os intervalos de IP de origem de uma regra de encaminhamento de direcionamento, a afinidade de sessão não será interrompida. Se a mudança resultar em uma conexão existente correspondente a uma regra de encaminhamento diferente, faça o seguinte:
• A afinidade da sessão sempre é interrompida nestas circunstâncias:
  • A regra de encaminhamento recém-correspondida direciona uma conexão estabelecida para um serviço de back-end (ou instância de destino) que não faz referência à VM de back-end selecionada anteriormente.
  • A regra de encaminhamento recém-correspondida direciona uma conexão estabelecida para um serviço de back-end que faz referência à VM de back-end selecionada anteriormente, mas o serviço de back-end não está configurado para manter conexões quando os back-ends não forem íntegros e a VM de back-end falha na verificação de integridade do serviço de back-end.
• A afinidade de sessão pode ser interrompida quando a regra de encaminhamento recém-correspondida direciona uma conexão estabelecida para um serviço de back-end e esse serviço faz referência à VM selecionada anteriormente, mas a combinação do serviço de back-end de afinidade de sessão e modo de rastreamento de conexão resulta em um hash diferente do acompanhamento de conexões.

Como manter a afinidade da sessão em todas as mudanças de direção

Veja nesta seção como evitar a interrupção da afinidade de sessão quando os intervalos de IP de origem das regras de encaminhamento de direção forem atualizados:

• Direcionamento de regras de encaminhamento que apontam para serviços de back-end. Se a regra mãe e a de encaminhamento de apontarem para serviços de back-end, você precisará verificar manualmente se as configurações de afinidade da sessão e política de rastreamento de conexão sãoidênticos. O Google Cloud não rejeitará automaticamente as configurações se elas não forem idênticas.
• Direcionamento de regras de encaminhamento que apontam para instâncias de destino. Uma regra de encaminhamento pai que aponta para um serviço de back-end pode ser associada a uma regra de encaminhamento de direcionamento que aponta para uma instância de destino. Nesse caso, a regra de encaminhamento principal herda as configurações de afinidade da sessão e de política de rastreamento de conexão da regra de encaminhamento pai.

Para ver instruções sobre como configurar o direcionamento de tráfego, consulte Configurar o direcionamento de tráfego.

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 de passagem externa são compatíveis com as seguintes opções de protocolo: TCP, UDP ou UNSPECIFIED.

  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. Um serviço de back-end permite que o tráfego seja distribuído de acordo com uma afinidade de sessão configurável, o modo de acompanhamento de conexão e balanceamento de carga ponderado. 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.

• Back-ends: cada serviço de back-end opera em uma única região e distribui o tráfego para grupos de instâncias ou NEGs zonais na mesma região. É 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 de rede de passagem externo:

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

  Cada grupo de instâncias ou back-end de NEG tem uma rede VPC associada, mesmo que esse grupo de instâncias ou NEG ainda não tenha sido conectado a um serviço de back-end. Para mais informações sobre como uma rede é associada a cada tipo de back-end, consulteBack-ends de grupo de instâncias e interfaces de rede e Back-ends de NEG zonais e interfaces de rede.

Grupos de instâncias

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

Um balanceador de carga de rede de passagem externa distribui apenas o tráfego para a primeira interface de rede (nic0) de VMs de back-end. O balanceador de carga oferece suporte a grupos de instâncias em que as instâncias de membro 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.

Cada grupo de instâncias tem uma rede VPC associada, mesmo que ele ainda não tenha sido conectado a um serviço de back-end. Para mais informações sobre como uma rede é associada a grupos de instâncias, consulte Back-ends de grupos de instâncias e interfaces de rede.

O balanceador de carga de rede de passagem externa tem alta disponibilidade por design. 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. Você só precisa garantir que as instâncias de VM de back-end sejam implantadas em várias zonas para que o balanceador de carga possa solucionar possíveis problemas em qualquer zona.

Observação: as regiões do México, de Montreal e de Osaka têm três zonas em um ou dois data centers físicos. Essas regiões estão em processo de expansão para pelo menos três data centers físicos. Para mais informações, consulte Locais do Cloud e SLAs do Google Cloud Platform. Para melhorar a confiabilidade das cargas de trabalho, considere uma implantação multirregional.

• 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 de passagem externa com um grupo regional de instâncias gerenciadas

• 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 de passagem externa com grupos de instâncias zonais

NEGs por zona

Um balanceador de carga de rede de passagem externa distribui conexões entre endpoints GCE_VM_IP contidos em grupos de endpoints de rede zonais. Esses endpoints precisam estar localizados na mesma região que o balanceador de carga. Para alguns casos de uso recomendados de NEG zonal recomendados, consulte Visão geral dos grupos de endpoints de rede zonais.

Os endpoints no NEG precisam ser endereços IPv4 internos principais das interfaces de rede da VM que estão na mesma sub-rede e zona do NEG zonal. O endereço IPv4 interno principal de qualquer interface de rede de uma instância de VM com várias NICs pode ser adicionado a um NEG, desde que ele esteja na sub-rede dele.

Os NEGs zonais são compatíveis com VMs IPv4 e de pilha dupla (IPv4 e IPv6). Para VMs IPv4 e de pilha dupla, basta especificar apenas a instância de VM ao anexar um endpoint a um NEG. Não é necessário especificar o endereço IP do endpoint. A instância de VM precisa estar sempre na mesma zona que o NEG.

Cada NEG zonal tem uma rede VPC associada e uma sub-rede, mesmo que ele ainda não tenha sido conectado a um serviço de back-end. Para mais informações sobre como uma rede é associada a NEGs zonais, consulte Back-ends de NEG e interfaces de rede por zona.

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 (MIGs), 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. Como opção, cada VM membro pode ter interfaces de rede adicionais (de nic1 a nic7), mas cada interface de rede precisa ser anexada a uma rede VPC diferente. Essas redes também precisam ser diferentes da rede VPC associada ao grupo de instâncias.

Os serviços de back-end não podem distribuir tráfego para VMs de membros do grupo de instâncias em interfaces que não sejam nic0. Se você quiser receber tráfego em uma interface de rede não padrão (de nic1 a nic7), use NEGs zonais com endpoints GCE_VM_IP.

Back-ends de NEG zonais e interfaces de rede

Ao criar um novo NEG zonal com endpoints GCE_VM_IP, é preciso associá-lo explicitamente a uma sub-rede de uma rede VPC antes de adicionar endpoints ao NEG. Nem a sub-rede nem a rede VPC podem ser alteradas após a criação do NEG.

Em um determinado NEG, cada endpoint GCE_VM_IP representa uma interface de rede. A interface de rede precisa estar na sub-rede 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 de rede é identificada usando o endereço IPv4 principal.

Há duas maneiras de adicionar um endpoint GCE_VM_IP a um 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 sub-rede associada ao NEG. O endereço IP escolhido pelo Google Cloud para o endpoint é o endereço IPv4 interno principal da interface de rede da VM na sub-rede associada ao 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 estar na sub-rede associada ao NEG. A especificação de um endereço IP é redundante porque só pode haver uma única interface de rede na sub-rede associada ao NEG.

Serviços de back-end e redes VPC

O serviço de back-end não está associado a nenhuma rede VPC. No entanto, cada grupo de instâncias de back-end ou NEG por zona está associado a uma rede VPC, conforme observado anteriormente. Contanto que todos os back-ends estejam localizados na mesma região e projeto e que todos sejam do mesmo tipo (grupos de instâncias ou NEGs zonais), adicione back-ends que usam o tipo na mesma rede VPC ou em redes diferentes.

Para distribuir pacotes para nic1 até nic7, use back-ends de NEG por zona (com endpoints GCE_VM_IP) porque a rede VPC associada a um grupo de instâncias sempre corresponde à rede VPC usada pela interface nic0 de todas as instâncias-membro.

Back-ends de pilha dupla (IPv4 e IPv6)

Se você quiser que o balanceador de carga seja compatível com o tráfego IPv6, os back-ends precisarão atender a estes requisitos:

• Os back-ends precisam ser configurados em sub-redes de pilha dupla que estejam na mesma região da que a regra de encaminhamento IPv6 do balanceador de carga. Para os back-ends, é possível usar uma sub-rede com o ipv6-access-type definido como EXTERNAL ou INTERNAL. Para usar uma sub-rede com ipv6-access-type definido como INTERNAL, é preciso usar uma sub-rede de pilha dupla separada com ipv6-access-type definido como EXTERNAL para a regra de encaminhamento externo do balanceador de carga. Para ver instruções, consulte Adicionar uma sub-rede de pilha dupla.
• Os back-ends precisam ser configurados para serem de pilha dupla com o --ipv6-network-tier definido como PREMIUM. Para instruções, consulte Criar um modelo de instância com endereços IPv6.

Verificações de integridade

Os balanceadores de carga de rede de passagem externa usam 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 de passagem externa 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.

Os balanceadores de carga de rede de passagem externa são compatíveis com os seguintes tipos de verificações de integridade:

• HTTP, HTTPS ou HTTP/2. Se as VMs de back-end veicularem tráfego usando HTTP, HTTPS ou HTTP/2, é melhor usar uma verificação de integridade correspondente a esse protocolo. Para detalhes, consulte Critérios de sucesso para verificações de integridade HTTP, HTTPS e HTTP/2.
• SSL ou TCP. Se as VMs de back-end não veicularem tráfego do tipo HTTP, use uma verificação de integridade SSL ou TCP. Para mais detalhes, consulte Critérios de sucesso para verificações de integridade de SSL e TCP.

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

O Google Cloud não oferece nenhuma verificação de integridade específica do protocolo além das listadas na seção Verificações de integridade, que já abordamos nesta página. Quando você usa um balanceador de carga de rede de passagem externa para balancear a carga de um protocolo diferente do TCP, ainda é necessário executar um serviço baseado em TCP nas VMs de back-end para fornecer as informações de verificação de integridade necessárias.

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 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 os balanceadores de carga de rede são balanceadores de carga de passagem, você controla o acesso aos back-ends do balanceador de carga usando 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).

• Os balanceadores de carga de rede de passagem externa usam 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.

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 IP externo associado a uma VM do Google Cloud ou um endereço IP roteável pela Internet de um sistema que se conecta ao balanceador de carga.
• Destino: o endereço IP da regra de encaminhamento do balanceador de carga.

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.
• UDP, ESP, GRE e ICMP não têm conexão. 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 externo 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, ESP, GRE, ICMP	Na maioria dos casos de uso, o endereço IP da regra de encaminhamento do balanceador de carga ^†	A origem do pacote solicitante

^† Quando uma VM tem um endereço IP externo ou quando você está usando o Cloud NAT, também é possível definir o endereço IP de origem do pacote de resposta como o endereço IPv4 interno principal da VM de dados. O Google Cloud ou o Cloud NAT altera o endereço IP de origem do pacote de resposta para o endereço IPv4 externo da placa de rede (NIC, na sigla em inglês) ou o endereço IPv4 externo do Cloud NAT a fim de enviar o pacote de resposta para o endereço IP externo do cliente. 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 externo que não corresponde ao endereço IP a que ele enviou um pacote de solicitação.

Caminho de retorno

Os balanceadores de carga da rede usam 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 de passagem externa precisam existir no mesmo projeto, exceto o endereço IP. A tabela a seguir resume os componentes da VPC compartilhada para balanceadores de carga de rede de passagem externa:

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 os back-ends (grupo de instâncias ou NEG por zona). 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 os balanceadores de carga de rede de passagem externa distribuem 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 externa 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

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 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 entre aqueles que são íntegros (a menos que todos os back-ends não estejam íntegros, caso em que todos os back-ends são considerados desde que a 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.

      Além disso, observe o seguinte:

      Se você ativar o balanceamento de carga ponderado, a seleção de back-end baseada em hash será ponderada com base nos pesos informados por instâncias de back-end. Exemplo:

      • Considere um serviço de back-end configurado com a afinidade de sessão definida como NONE e uma regra de encaminhamento com protocolo UDP. Se houver duas instâncias de back-end íntegras com pesos 1 e 4, os back-ends receberão 20% e 80% dos pacotes UDP, respectivamente.
      • Considere um serviço de back-end que esteja configurado com afinidade de sessão de três tuplas e rastreamento de conexão. A afinidade da sessão é CLIENT_IP_PROTO, e o modo de acompanhamento de conexão é PER_SESSION. Se houver três instâncias íntegras de back-end com pesos 0, 2 e 6, os back-ends receberão tráfego para 0%, 25% e 75% dos novos endereços IP de origem (os endereços IP de origem para os quais não houver entradas de tabela de rastreamento de conexão) respectivamente. O tráfego para conexões atuais vai para os back-ends atribuídos anteriormente.
        Cuidado: se os pesos mudarem com frequência, o balanceamento de carga pesado poderá ser prejudicial à afinidade da sessão. Há vários balanceadores de carga, e o rastreamento de conexão não é replicado neles. Para afinidade da sessão sustentada, não use balanceamento de carga ponderado ou use com pouca frequência.
        .

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

      • Pacotes ICMP e ICMPv6. 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. Consulte Tempo limite de inatividade para mais detalhes.
      • 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 para cada back-end.

Os balanceadores de carga de rede de passagem externa são compatíveis 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, ESP e GRE, o acompanhamento de conexão é ativado quando a afinidade de sessão selecionada não é NONE. Os pacotes UDP, ESP e GRE 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 modoPER_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 Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP, UDP, ESP, GRE: 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 Fragmentação de UDP, ESP e GRE: rastreamento de conexão de três tuplas Todos os outros protocolos: rastreamento de conexão desativado	TCP, UDP, ESP, GRE: 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 Fragmentação de UDP, ESP e GRE: 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 Fragmentação de UDP, ESP e GRE: 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 permanece em um endpoint ou VM de back-end selecionado depois que o back-end se torna não íntegro, desde que o back-end permaneça no grupo de back-end configurado do balanceador de carga (em um grupo de instâncias ou um NEG).

O comportamento descrito nesta seção não se aplica aos casos em que você remove uma instância de back-end de um grupo de instâncias, remove um endpoint de back-end do NEG ou remove o grupo de instâncias ou o NEG 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, GRE, UDP: as conexões permanecem em back-ends não íntegros se a afinidade da sessão não for NONE ICMP, ICMPv6:não aplicável porque não é possível acompanhar a conexão. Essa opção só deve ser usada para casos de uso avançados.	Não é possível configurar

Observação: quando o balanceador de carga move uma conexão de um back-end não íntegro, o balanceador de carga cria uma nova entrada na tabela de rastreamento. A nova entrada mapeia a conexão para um back-end diferente com base na afinidade da sessão configurada. A nova entrada permanece válida como qualquer outra entrada. Se o back-end não íntegro retornar como íntegro, isso sozinho não fará com que a entrada da tabela de rastreamento de conexão seja removida, a menos que acione um failback e diminuição da conexão em failover e failback tenha sido desativada).

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.

Tempo limite de inatividade

As entradas nas tabelas de rastreamento de conexão expiram 60 segundos após o balanceador de carga processar o último pacote que corresponde à entrada. Esse valor de tempo limite de inatividade não pode ser modificado.

Balanceamento de carga ponderado

Cuidado: se os pesos mudarem com frequência, o balanceamento de carga ponderado poderá ser prejudicial à afinidade da sessão. Há vários balanceadores de carga, e o rastreamento de conexão não é replicado neles. Para afinidade da sessão sustentada, recomendamos que você não use o balanceamento de carga ponderado ou use com pouca frequência.

É possível configurar um balanceador de carga de rede para distribuir o tráfego entre as instâncias de back-end do balanceador com base nos pesos informados por uma verificação de integridade HTTP usando o balanceamento de carga ponderado.

O balanceamento de carga ponderado requer que você configure estes dois itens:

• Defina a política do balanceador de carga de localidade (localityLbPolicy) do serviço de back-end como WEIGHTED_MAGLEV.
• Configure o serviço de back-end com uma verificação de integridade HTTP. As respostas da verificação de integridade HTTP precisam conter um campo de cabeçalho de resposta HTTP personalizado X-Load-Balancing-Endpoint-Weight para especificar os pesos com valores de 0 a 1000 para cada instância de back-end.

Se você usa o mesmo back-end (grupo de instâncias ou NEG) para vários balanceadores de carga de rede de passagem externa baseados em serviço de back-end que usam balanceamento de carga ponderado, recomendamos usar um request-path exclusivo para cada verificação de integridade do serviço de back-end. Isso permite que a instância de endpoint atribua diferentes pesos a diferentes serviços de back-end. Para mais informações, consulte Critérios de sucesso para verificações de integridade HTTP, HTTPS e HTTP/2.

Para selecionar um back-end para uma nova conexão, os back-ends recebem uma ordem de prioridade estrita com base no peso e no status de integridade, conforme mostrado na tabela a seguir:

Peso	Íntegro	Prioridade de seleção de back-end
Peso maior que zero	Sim	4
Peso maior que zero	Não	3
Peso igual a zero	Sim	2
Peso igual a zero	Não	1

Apenas os back-ends de maior prioridade estão qualificados para seleção de back-end. Se todos os back-ends qualificados tiverem peso zero, o balanceador de carga distribuirá novas conexões entre todos os back-ends qualificados, tratando-os com o mesmo peso. Para ver exemplos de balanceamento de carga ponderado, consulte Seleção de back-end e rastreamento de conexão.

O balanceamento de carga ponderado pode ser usado nos seguintes cenários:

• Se algumas conexões processarem mais dados do que outras ou se algumas conexões ficarem mais tempo do que outras, a distribuição da carga do back-end pode ficar desigual. Ao sinalizar um peso por instância mais baixo, uma instância com alta carga pode reduzir a participação de novas conexões, enquanto continua atendendo as conexões atuais.

• Se um back-end estiver sobrecarregado e a atribuição de mais conexões puder interromper as conexões existentes, eles não atribuirão peso zero a si mesmo. Ao sinalizar o peso zero, uma instância de back-end deixa de fornecer novas conexões, mas continua a atender as atuais.

• Se um back-end estiver drenando conexões existentes antes da manutenção, ele atribuirá zero peso a si mesmo. Ao sinalizar o peso zero, a instância de back-end deixa de atender novas conexões, mas continua a atender as atuais.

Para mais informações, consulte Configurar o balanceamento de carga ponderado.

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).
• Um back-end é 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

Observação: as recomendações a seguir sobre como lidar com pacotes UDP fragmentados com balanceadores de carga de rede de passagem externa baseados em serviço de back-end são diferentes das recomendações para balanceadores de carga de rede externos de rede com passagem legados.

Os balanceadores de carga de rede de passagem externa baseados em serviço de back-end 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 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 regra de encaminhamento UDP ou L3_DEFAULT por endereço IP com balanceamento de carga 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 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.

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 ou L3_DEFAULT por endereço IP 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

É possível configurar um balanceador de carga de rede de passagem externa para distribuir conexões entre instâncias de VM ou endpoints em back-ends primários (grupos de instâncias ou NEGs) e, em seguida, alternar, se necessário, para usar back-ends de failover. Com o failover, você garante um método para aumentar a disponibilidade e ter maior controle sobre como gerenciar a carga de trabalho quando os back-end principais não estiverem íntegras.

Por padrão, quando você adiciona um back-end a um serviço de back-end do balanceador de carga de rede externo, esse back-end é 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 o failover funciona, consulte Visão geral do failover para balanceadores de carga de rede de passagem externa.

Conectividade de Internet de saída a partir de back-ends

As instâncias de VM configuradas como endpoints de back-end do balanceador de carga de rede de passagem externa podem iniciar conexões com a Internet usando o endereço IP da regra de encaminhamento do balanceador de carga como o endereço IP de origem da conexão de saída.

Geralmente, uma instância de VM usa o próprio endereço IP externo ou o Cloud NAT para iniciar conexões. Você usa o endereço IP da regra de encaminhamento para iniciar conexões de endpoints de back-end apenas em cenários especiais, como quando você precisa que instâncias de VM originem e recebam conexões no mesmo endereço IP externo e também precisa da redundância de back-end fornecida pelo balanceador de carga de rede de passagem externa para conexões de entrada.

Os pacotes de saída enviados de VMs de back-end diretamente para a Internet não têm restrições em relação a protocolos e portas de tráfego. Mesmo que um pacote de saída esteja usando o endereço IP da regra de encaminhamento como origem, o protocolo e a porta de origem do pacote não precisam corresponder ao protocolo e à especificação da porta da regra de encaminhamento. No entanto, os pacotes de resposta de entrada precisam corresponder ao endereço IP, ao protocolo e à porta de destino da regra de encaminhamento. Para mais informações, consulte Caminhos para balanceadores de carga de rede de passagem externa e encaminhamento de protocolo externo.

Além disso, todas as respostas às conexões de saída da VM estão sujeitas ao balanceamento de carga, assim como todos os outros pacotes de entrada destinados ao balanceador de carga. Isso significa que as respostas podem não chegar na mesma VM de back-end que iniciou a conexão com a Internet. Se as conexões de saída e as conexões de entrada balanceadas de carga tiverem protocolos e portas em comum, tente uma das sugestões a seguir:

• Sincronize o estado da conexão de saída nas VMs de back-end para que as conexões possam ser atendidas mesmo que as respostas cheguem a uma VM de back-end diferente da que iniciou a conexão.

• Use uma configuração de failover, com uma única VM principal e uma VM de backup. Em seguida, a VM de back-end ativa que inicia as conexões de saída sempre recebe os pacotes de resposta.

Esse caminho para a conectividade de Internet de um back-end de balanceador de carga de rede de passagem externo é o comportamento padrão pretendido de acordo com as regras implícitas de firewall do Google Cloud. No entanto, se você tiver preocupações de segurança sobre deixar esse caminho aberto, use regras de firewall de saída direcionadas para bloquear o tráfego de saída não solicitado para a Internet.

Limitações

• Não é possível usar o Console do Google Cloud para:

  • Crie ou modifique um balanceador de carga de rede de passagem externa cuja regra de encaminhamento usa o protocolo L3_DEFAULT.
  • Crie ou modifique um balanceador de carga de rede de passagem externa cujo protocolo de serviço de back-end esteja definido como UNSPECIFIED.
  • Crie ou modifique um balanceador de carga de rede de passagem externa que configure uma política de rastreamento de conexão.
  • Criar ou modificar o direcionamento de tráfego baseado em IP de origem para uma regra de encaminhamento.

  Use a CLI do Google Cloud ou a API REST.

• Os balanceadores de carga de rede de passagem externos não dão suporte ao peering de rede VPC.

Preços

Para informações sobre preços, consulte Preços.

A seguir

• Para configurar um balanceador de carga de rede de passagem externa com um serviço de back-end somente para tráfego TCP ou UDP (compatível com tráfego IPv4 e IPv6), consulte Configurar um balanceador de carga de rede de passagem externa com um serviço de back-end.
• Para configurar um balanceador de carga de rede de passagem externa para vários protocolos IP (compatível com tráfego IPv4 e IPv6), consulte Configurar um balanceador de carga de rede de passagem externa para vários protocolos IP.
• Para configurar um balanceador de carga de rede de passagem externa com um back-end de NEG zonal, consulte Configurar um balanceador de carga de rede de passagem externa com NEGs zonais.
• Para configurar um balanceador de carga de rede de passagem externa com um pool de destino, consulte Configurar um balanceador de carga de rede de passagem externa com um pool de destino.
• Para saber como fazer a transição de um balanceador de carga de rede de passagem externa de um back-end de pool de destino para um serviço de back-end regional, consulteComo fazer a transição de um balanceador de carga de rede de passagem externa de um pool de destino para um serviço de back-end.