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
  • Google Cloud VMs com IPs externos
  • Google Cloud VMs que têm acesso à Internet pelo Cloud NAT ou pela 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. Com um serviço de back-end, é possível distribuir o tráfego de acordo com a afinidade de sessão configurada, a política de rastreamento de conexão e as configurações de balanceamento de carga ponderado. O serviço de back-end também pode ser configurado 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. Para mais informações, consulte Distribuição de tráfego para balanceadores de carga de rede de passagem externa.
  • 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. Se você estiver criando aplicativos no GKE, recomendamos usar o controlador de serviço do GKE integrado, que implanta Google Cloud balanceadores de carga 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:

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

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 Google Cloud intervalo de sub-rede.

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

OGoogle 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

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ão idênticas. OGoogle Cloud não rejeita 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 mãe.

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. Com um serviço de back-end, é possível distribuir o tráfego de acordo com a afinidade de sessão configurada, a política de rastreamento de conexão e as configurações de balanceamento de carga ponderado. O serviço de back-end também pode ser configurado 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. Para mais informações, consulte Distribuição de tráfego para balanceadores de carga de rede de passagem externa.

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

  • 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 de instâncias gerenciadas regional
    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
    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, Google Cloud exigirá que a VM tenha uma interface de rede na sub-rede associada ao NEG. O endereço IP que Google Cloud escolhe 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 uma interface que não seja nic0, use back-ends de NEG zonais (com endpoints GCE_VM_IP).

Back-ends de pilha dupla (IPv4 e IPv6)

Se você quiser que o balanceador de carga use back-ends de pilha dupla que processem o tráfego IPv4 e IPv6, observe os seguintes requisitos:

  • Os back-ends precisam ser configurados em sub-redes de pilha dupla que estejam na mesma região da 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. Se o ipv6-access-type da sub-rede de back-end estiver definido como INTERNAL, será necessário usar uma sub-rede somente IPv6 diferente com ipv6-access-type definido como EXTERNAL para a regra de encaminhamento externo do balanceador de carga.
  • Os back-ends precisam ser configurados para serem de pilha dupla com o stack-type definido como IPv4_IPv6. Se a ipv6-access-type da sub-rede de back-end estiver definida como EXTERNAL, defina também a --ipv6-network-tier como PREMIUM. Para instruções, consulte Criar um modelo de instância com endereços IPv6.

Back-ends somente IPv6

Se você quiser que o balanceador de carga use apenas back-ends IPv6, observe os requisitos a seguir:

  • As instâncias somente IPv6 têm suporte apenas em grupos de instâncias não gerenciadas. Nenhum outro tipo de back-end é compatível.
  • Os back-ends precisam ser configurados em pilha dupla ou sub-redes somente IPv6 que estejam na mesma região da 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 INTERNAL ou EXTERNAL. Se o ipv6-access-type da sub-rede de back-end estiver definido como INTERNAL, use uma sub-rede diferente somente para IPv6 com ipv6-access-type definido como EXTERNAL para a regra de encaminhamento externo do balanceador de carga.
  • Os back-ends precisam ser configurados para serem somente IPv6 com o stack-type da VM definido como IPv6_ONLY. Se a ipv6-access-type da sub-rede de back-end estiver definida como EXTERNAL, defina também a --ipv6-network-tier como PREMIUM. Para instruções, consulte Criar um modelo de instância com endereços IPv6.

VMs somente IPv6 podem ser criadas em sub-redes de pilha dupla e somente IPv6, mas VMs de pilha dupla não podem ser criadas em sub-redes somente 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 Google Cloud verificações de integridade funcionam, consulte Como as verificações de integridade funcionam.

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

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

OGoogle 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 serão balanceadas usando o protocolo UDP, e será necessário executar um serviço TCP para fornecer informações às sondagens de verificação de integridade. 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 de passagem externa são balanceadores de carga de passagem, você controla o acesso aos back-ends do balanceador de carga usando regras de firewall 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 Google Cloud padrão inclui um conjunto limitado de regras de firewall de permissão de entrada pré-preenchidas.

  • 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 Google Cloud verificações de integridade. 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 Google Cloud VM 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 NIC da VM. Google Cloud O Cloud NAT muda o endereço IP de origem do pacote de resposta para o endereço IPv4 externo da NIC ou um 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.

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 balanceador de carga de rede de passagem externa é 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.

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

Os balanceadores de carga de rede de passagem externa são compatíveis com várias opções de personalização de distribuição de tráfego, incluindo afinidade de sessão, rastreamento de conexão, balanceamento de carga ponderado e failover. Para detalhes sobre como os balanceadores de carga de rede de passagem externa distribuem tráfego e como essas opções interagem entre si, consulte Distribuição de tráfego para balanceadores de carga de rede de passagem externa.

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