Visão geral do balanceador de carga de rede de passagem interna

Um balanceador de carga de rede de passagem interno é um balanceador de carga regional, criado na pilha de virtualização de rede Andromeda.

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

Use um balanceador de carga de rede de passagem interno nas seguintes circunstâncias:

  • Você precisa de um balanceador de carga de passagem de camada 4 de alto desempenho para os protocolos TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.
  • Se você estiver veiculando tráfego por meio de TLS (SSL), é aceitável fazer com que o tráfego SSL encerrado pelos back-ends em vez de no balanceador de carga. O balanceador de carga de rede de passagem interna não pode encerrar o tráfego SSL.
  • Você precisa encaminhar os pacotes originais sem proxy. Por exemplo, se você precisa que o endereço IP de origem do cliente seja preservado.
  • Você tem uma configuração atual que usa um balanceador de carga de passagem e quer migrá-lo sem alterações.

Os balanceadores de carga de rede de passagem internos são adequados para muitos casos de uso. Para conferir alguns exemplos gerais, consulte Visão geral do balanceador de carga de rede de passagem.

Como funcionam os balanceadores de carga de rede de passagem internos

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

Exemplo geral de balanceador de carga de rede de passagem interno.
Exemplo geral de balanceador de carga de rede de passagem interno (clique para ampliar).

Ao contrário de um balanceador de carga de proxy, um balanceador de carga de rede de passagem interno não encerra conexões de clientes e depois estabelece novas conexões com back-ends. Em vez disso, um balanceador de carga de rede de passagem interno encaminha diretamente as conexões dos clientes para back-ends íntegros, sem qualquer interrupção. As respostas das VMs de back-ends íntegros são enviadas diretamente aos clientes, e não voltam pelo balanceador de carga. As respostas TCP usam o retorno direto do servidor. Para mais informações, consulte Solicitações TCP e UDP e pacotes de retorno.

O balanceador de carga monitora a integridade do back-end usando sondagens de verificação de integridade. Para mais informações, consulte a seção Verificação de integridade.

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

A rede virtualGoogle Cloud gerencia o fornecimento de tráfego e o escalonamento conforme apropriado.

Protocolos, esquema e escopo

Cada balanceador de carga de rede de passagem interna é compatível com o seguinte:

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

Um balanceador de carga de rede de passagem interna não é compatível com:

Acesso de cliente

Por padrão, o balanceador de carga só dá suporte a clientes que estão na mesma região que ele. Os clientes podem estar na mesma rede que o balanceador de carga ou em uma rede VPC conectada por um peering de rede VPC. É possível ativar o acesso global para permitir que clientes de qualquer região acessem o balanceador de carga de rede de passagem interno.

Balanceador de carga de rede de passagem interno com acesso global.
Balanceador de carga de rede de passagem interno com acesso global (clique para ampliar).

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

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

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

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

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

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

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

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

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

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

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

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

Arquitetura

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

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

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

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

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

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

É possível usar um balanceador de carga de rede de passagem interna com uma rede VPC de modo personalizado ou automático. Também é possível criar balanceadores de carga de rede de passagem interna com uma rede legada existente.

Um balanceador de carga de rede de passagem interno não dá suporte ao seguinte:

Endereço IP interno

Os balanceadores de carga de rede de passagem interna são compatíveis com sub-redes somente IPv4, de pilha dupla e somente IPv6. Para mais informações sobre cada uma, consulte Tipos de sub-redes.

Um balanceador de carga de rede de passagem interna requer pelo menos uma regra de encaminhamento. A regra de encaminhamento faz referência ao endereço IP interno:

  • Para o tráfego IPv4, a regra de encaminhamento faz referência a um endereço IPv4 do intervalo de sub-rede IPv4 principal.
  • Para Tráfego IPv6, a regra de encaminhamento faz referência a um intervalo /96 de endereços IPv6 internos do intervalo da sub-rede /64 de endereços IPv6 interno. A sub-rede precisa ser de pilha dupla ou de pilha única somente IPv6 (Pré-lançamento) com um intervalo de endereços IPv6 interno (ipv6-access-type definido como INTERNAL). O intervalo de endereços IPv6 pode ser um endereço estático reservado ou um endereço temporário.

    Para mais informações sobre o suporte a IPv6, consulte a documentação da VPC sobre Intervalos de sub-rede IPv6 e Endereços IPv6.

Configuração do firewall

Os balanceadores de carga de rede de passagem interna exigem a seguinte configuração para políticas de firewall hierárquicas e regras de firewall da VPC:

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

Regras de encaminhamento

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

Um balanceador de carga de rede de passagem interna requer pelo menos uma regra de encaminhamento interno. Defina várias regras de encaminhamento para o mesmo balanceador de carga.

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

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

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

Protocolos da regra de encaminhamento

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

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

A opção L3_DEFAULT (Visualizar) permite que você faça o balanceamento de carga dos protocolos TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.

Além de aceitar protocolos diferentes de TCP e UDP, a opção L3_DEFAULT possibilita que uma única regra de encaminhamento encaminhe simultaneamente o tráfego de vários protocolos. Por exemplo, além de fazer solicitações HTTP, também é possível dar um ping no endereço IP do balanceador de carga.

As regras de encaminhamento que usam os protocolos TCP ou UDP podem fazer referência a um serviço de back-end usando o mesmo protocolo que a regra de encaminhamento ou um serviço de back-end usando o 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 (IPv4 ou IPv6) TCP TCP or UNSPECIFIED
UDP (IPv4 ou IPv6) UDP UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE L3_DEFAULT UNSPECIFIED

Regras de encaminhamento e acesso global

As regras de encaminhamento de um balanceador de carga de rede de passagem interna são regionais, mesmo quando o acesso global está ativado. Depois de ativar o acesso global, a sinalização allowGlobalAccess da regra de encaminhamento interno regional é definida como true.

Regras de encaminhamento e especificações de porta

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

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

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

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

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

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

É possível configurar várias regras de encaminhamento interno que fazem referência ao mesmo serviço de back-end interno. Um balanceador de carga de rede de passagem interna requer pelo menos uma regra de encaminhamento interno.

Configurar várias regras de encaminhamento para o mesmo serviço de back-end permite fazer o seguinte:

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

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

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

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

Serviço de back-end

Cada balanceador de carga de rede de passagem interna tem um serviço de back-end interno regional que define parâmetros e comportamento de back-end. O nome do serviço de back-end é o nome do balanceador de carga de rede de passagem interno mostrado no Console do Google Cloud.

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

  • Protocolo. Um serviço de back-end é compatível com tráfego IPv4 e IPv6. Se o protocolo tiver um conceito de porta (como TCP ou UDP), o serviço de back-end entrega pacotes para VMs de back-end na mesma porta de destino para a qual o tráfego foi enviado.

    Os serviços de back-end são compatíveis com as seguintes opções de protocolo IPv4: TCP, UDP, ou UNSPECIFIED.

    Os serviços de back-end são compatíveis com as seguintes opções de protocolo IPv6: TCP ou UDP. O protocolo do serviço de back-end precisa corresponder ao protocolo da regra de encaminhamento.

    Para ver uma tabela com possíveis combinações protocolos de regras de encaminhamento e serviços de back-end, consulte Especificação do protocolo de regras de encaminhamento.

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

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

Cada serviço de back-end opera em uma única região e distribui o tráfego para VMs de back-end em uma única rede VPC:

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

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

  • Para grupos de instâncias gerenciadas (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.

Back-ends de NEGs 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.

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

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

Se você omitir a flag --network ao criar um serviço de back-end, oGoogle Cloud vai usar um dos eventos de qualificação a seguir para definir implicitamente a rede VPC associada do serviço de back-end. Depois de definida, a rede VPC associada do serviço de back-end não pode ser alterada:

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

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

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

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

Regras da rede de serviço de back-end

As seguintes regras se aplicam depois de associar um serviço de back-end a uma rede VPC específica:

  • Ao configurar uma regra de encaminhamento que faça referência ao serviço de back-end, ela precisa usar uma sub-rede da rede VPC do serviço de back-end. A regra de encaminhamento e o serviço de back-end não podem usar redes VPC diferentes, mesmo que elas estejam conectadas (por exemplo, usando o peering de rede VPC).

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

    • A rede VPC associada ao grupo de instâncias, ou seja, a rede VPC usada pela interface de rede nic0 de cada VM no grupo de instâncias, precisa corresponder à rede VPC associada ao serviço de back-end.
    • Cada VM de back-end precisa ter uma interface não nic0 (de nic1 a nic7) na rede VPC associada ao serviço de back-end.
  • Ao adicionar back-ends de NEG zonal com endpoints GCE_VM_IP, a rede VPC associada ao NEG precisa corresponder à rede VPC associada ao serviço de back-end.

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 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 INTERNAL ou EXTERNAL. Se o ipv6-access-type da sub-rede de back-end estiver definido como EXTERNAL, use uma sub-rede de pilha dupla ou somente IPv6 diferente com ipv6-access-type definido como INTERNAL para a regra de encaminhamento interno do balanceador de carga. Para mais informações, consulte Adicionar uma sub-rede de pilha dupla.
  • 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 mais informaçõ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 EXTERNAL, use uma sub-rede somente IPv6 diferente com ipv6-access-type definido como INTERNAL para a regra de encaminhamento interno 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 mais informaçõ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.

Subconfiguração de back-ends

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

Ative a subconfiguração se precisar aceitar mais de 250 VMs de back-end em um único balanceador de carga. Para mais informações, consulte Subcriação de back-end para o balanceador de carga de rede de passagem interna.

Verificação de integridade

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

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

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

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

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

Verificações de integridade e tráfego UDP

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

Nessa configuração, as solicitações de clientes são balanceadas por carga usando o protocolo UDP, e um serviço TCP é usado para enviar informações às sondagens de verificação de integridade Google Cloud . Por exemplo, é possível executar um servidor HTTP simples em cada VM de back-end que retorna uma resposta HTTP 200 para Google Cloud. Neste exemplo, é preciso usar a própria lógica em execução na VM de back-end para garantir que o servidor HTTP exiba 200 apenas se o serviço UDP estiver configurado e em execução corretamente.

Arquitetura de alta disponibilidade

O balanceador de carga de rede de passagem interna está altamente disponível por padrão. Não há etapas especiais para deixar o balanceador de carga altamente disponível porque o mecanismo não depende de um único dispositivo ou instância de VM.

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

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

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

Arquitetura da VPC compartilhada

A tabela a seguir resume os requisitos do componente para balanceadores de carga de rede de passagem interna usados com redes VPC compartilhadas. Por exemplo, consulte Como criar um balanceador de carga de rede de passagem interna na página "Como provisionar a VPC compartilhada".

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

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

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

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

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

Distribuição de tráfego

Os balanceadores de carga de rede de passagem interna 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 e failover. Para detalhes sobre como os balanceadores de carga de rede de passagem interna distribuem o tráfego e como essas opções interajam entre si, consulte Distribuição de tráfego para balanceadores de carga de rede de passagem interna.

Cotas e limites

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

Limitações

  • Não é possível usar o console do Google Cloud para criar um balanceador de carga de rede de passagem interno com back-ends de NEG zonais.

A seguir