Visão geral do balanceador de carga de rede de passagem interna (original) (raw)

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, consulteVisã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 (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 qualificados, sem um proxy entre os clientes e os back-ends. As respostas de cada back-end selecionado são entregues usando o retorno direto do servidor. Para mais informações, consulteDistribuição de tráfego para balanceadores de carga de rede de passagem internae Endereços IP para pacotes de solicitação e 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 do Windows ou um processo equivalente configura cada VM de back-end com o endereço IP do balanceador de carga. Para VMs criadas com base em imagens do Google Cloud , o agente de convidado (antigo ambiente de convidado do Windows ou Linux) instala a rota local do endereço IP do balanceador de carga. As instâncias do Google Kubernetes Engine baseadas no Container-Optimized OS implementam isso usando iptables.

Google Cloud A rede virtual 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:
  • Grupos gerenciados e não gerenciados de instâncias que estão localizados em umaregião e rede VPC.
  • Grupos de endpoints de rede (NEGs) de back-end com endpoints de tipo GCE_VM_IPlocalizados na mesma região e rede VPC. Os endpoints no NEG precisam ser endereços IP internos primários na mesma sub-rede e zona usadas pelo NEG.
• 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 o seguinte:

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

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 umpeering 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 (clique para ampliar).

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

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. Configure o software em execução nas VMs de back-end 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:

1 É 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, 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, mostramos 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 interna não é compatível com o seguinte:

• VMs de back-end em várias regiões
• Balanceamento de tráfego com origem na Internet, a menos que um balanceador de carga externo seja usado.
• Pacotes IPv6 com cabeçalhos fragmentados

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 delas, 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 única somente IPv6 com um intervalo de endereços IPv6 interno (ipv6-access-type definido comoINTERNAL). 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 a compatibilidade com 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:

• Permita a entrada deintervalos de origem de verificação de integridade IPv4 ou IPv6.
• Permitir a entrada de intervalos de origem de endereços IPv4 ou IPv6 do cliente.

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, eles 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 umasub-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 a um endereço IPv4 interno regional do intervalo de endereços IPv4 principal da sub-rede selecionada. O endereço IPv4 pode ser atribuído especificando um endereço IPv4 interno reservado, especificando um endereço IPv4 efêmero personalizado ou permitindo que o Google Cloudatribua automaticamente um endereço IPv4 efêmero.
• 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 internos /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 pode ser atribuído especificando um endereço IPv6 interno reservado, um endereço IPv6 temporário personalizado ou permitindo que Google Cloudatribua automaticamente um endereço IPv6 temporário.
  Para especificar um endereço IPv6 temporário personalizado, use a CLI gcloud ou a API. O console do Google Cloud não permite especificar endereços IPv6 temporários personalizados para regras de encaminhamento.

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:

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, combineregras de firewall com as regras de encaminhamento. Ao criar a regra de encaminhamento, especifique todas as portas e crie regras de firewall de entrada allowque 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:

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

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

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

• Um tipo de back-end, uma região. Os back-ends são grupos de instânciasou NEGs por zona com endpointsGCE_VM_IP na mesma região do serviço de back-end e regra de encaminhamento. Os back-ends de grupos de instâncias podem ser grupos não gerenciados de instâncias, grupos gerenciados de instâncias zonais ou grupos gerenciados de zonas regionais. Os back-ends de NEG zonal precisam usar endpoints GCE_VM_IP.
• Uma rede VPC. 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. O próprio recurso de serviço de back-end também tem uma rede VPC associada, que pode ser definida de maneira explícita ou implícita. Para mais informações sobre a rede do serviço de back-end, consulte Especificação de rede de serviços de back-end e Regras de rede de serviços de back-end.

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

Em um determinado grupo de instâncias (gerenciadas ou não), a interface de rede nic0 de cada VM membro está sempre na mesma rede VPC:

• Para grupos gerenciados de instâncias (MIGs), a rede VPC do grupo de instâncias vem da interface nic0 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. Não é possível mudar a rede VPC do grupo de instâncias depois, mesmo que você remova a primeira instância adicionada ao grupo.

As VMs membros podem ter outras interfaces de rede (vNICs ou interfaces de rede dinâmicas). Cada interface que não é nic0 pode estar na rede VPC do grupo de instâncias (a rede usada pela interface nic0) ou em uma rede VPC diferente.

Para distribuir o tráfego balanceado por carga a uma interface de rede que não seja nic0, recomendamos usar NEGs zonais com endpoints GCE_VM_IP. No entanto, é possível definir a rede VPC de um serviço de back-end para corresponder a uma rede VPC que contenha interfaces de rede não nic0 de VMs em um grupo de instâncias. Para mais informações, consulteEspecificação de rede de serviços de back-ende Regras de rede de serviços de back-end.

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. Do ponto de vista de ser um endpoint em um NEG, a interface de rede é identificada usando o endereço IPv4 interno principal. Para mais informações, consulte NEGs com endpoints GCE_VM_IP.

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.

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. Asregras 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 usará um dos seguintes eventos qualificados 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:

• Primeira regra de encaminhamento que faz referência a um serviço de back-end: se o serviço de back-end não tiver grupos de back-end associados, a primeira regra de encaminhamento que faz referência ao serviço de back-end define a rede VPC do serviço de back-end. A rede VPC do serviço de back-end é a rede que contém a sub-rede usada pela regra de encaminhamento.
• Primeiro grupo de instâncias adicionado ao serviço de back-end: se o serviço de back-end não tiver uma regra de encaminhamento que faça referência a ele, o primeiro grupo de instâncias que você adicionar como back-end definirá a rede VPC do serviço de back-end. A rede VPC do serviço de back-end é a rede do grupo de instâncias, ou seja, a rede VPC que contém a interface de rede nic0 de cada VM de back-end membro.
  • Se as VMs de back-end tiverem uma interface de rede adicional que não seja nic0 na rede VPC do grupo de instâncias, o balanceador de carga enviará apenas o tráfego balanceado por carga para a interface de rede nic0.
• Primeiro back-end do NEG zonal (com endpoints GCE_VM_IP) adicionado ao serviço de back-end: se o serviço de back-end não tiver uma regra de encaminhamento que faça referência a ele, o primeiro back-end do NEG zonal (com endpoints GCE_VM_IP) que você adicionar como um back-end vai definir a rede VPC do serviço de back-end. A rede VPC do serviço de back-end é a rede do NEG.
  • Se as VMs de back-end tiverem duas ou mais interfaces de rede (uma interface nic0 e uma não nic0) na rede VPC do NEG, o balanceador de carga enviará tráfego balanceado por carga apenas para a interface de rede nic0.

Depois que a rede VPC do serviço de back-end for definida por um evento qualificado, todas as regras de encaminhamento ou grupos de back-end adicionados precisarão seguir as regras de rede do 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 adicionar uma regra de encaminhamento que faça referência ao serviço de back-end, ela precisa usar uma sub-rede na 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.
• Ao adicionar back-ends de grupos de instâncias, uma das seguintes condições precisa ser verdadeira:
  • A rede VPC do grupo de instâncias (que é a rede usada pela interface nic0 de cada VM membro) precisa corresponder à rede VPC do serviço de back-end. Se as VMs de back-end tiverem uma interface de rede adicional que não seja nic0 na rede VPC do grupo de instâncias, o balanceador de carga enviará apenas tráfego com balanceamento de carga para a interface de rede nic0.
  • Cada VM de back-end precisa ter uma interface não nic0 na rede VPC do serviço de back-end e a interface de rede não nic0 precisa estar em uma rede diferente da usada pela interface nic0 (ou seja, diferente da rede VPC do grupo de instâncias).
• Ao adicionar back-ends de NEG zonal com endpoints GCE_VM_IP, a rede VPC do NEG precisa corresponder à rede VPC do serviço de back-end. Se as VMs de back-end tiverem duas ou mais interfaces de rede (uma interface nic0 e uma não nic0) na rede VPC da NEG, o balanceador de carga enviará apenas o tráfego balanceado por carga para a interface de rede nic0.

Back-ends de pilha dupla (IPv4 e IPv6)

Se você quiser que o balanceador de carga use back-ends de pilha dupla que processem 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 comoIPV4_IPV6. Se o ipv6-access-type da sub-rede de back-end estiver definido como EXTERNAL, defina também o --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 back-ends somente IPv6, observe os requisitos a seguir:

• As instâncias somente IPv6 são compatíveis 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 comoINTERNAL ou EXTERNAL. Se o ipv6-access-type da sub-rede de back-end estiver definido comoEXTERNAL, use uma sub-rede somente IPv6 diferente com ipv6-access-typedefinido como INTERNAL para a regra de encaminhamento interno do balanceador de carga.
• Os back-ends precisam ser configurados como somente IPv6 com a VM stack-type definida comoIPV6_ONLY. Se o ipv6-access-type da sub-rede de back-end estiver definido como EXTERNAL, defina também o --ipv6-network-tier como PREMIUM. Para mais informações, consulte Criar um modelo de instância com endereços IPv6.

As VMs somente IPv6 podem ser criadas em sub-redes de pilha dupla e somente IPv6, mas as 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.

Recomendamos que você ative a subconfiguração apenas 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

As informações de verificação de integridade são usadas para determinar os back-ends qualificados para novas conexões, e você pode controlar se as conexões atuais persistem em back-ends não íntegros. Para mais informações sobre back-ends qualificados, consulte Distribuição de tráfego para balanceadores de carga de rede de passagem interna.

Tipo, protocolo e porta da verificação de integridade

O serviço de back-end do balanceador de carga precisa referenciar uma verificação de integridade global ou regional, usando qualquer protocolo e porta compatíveis. O protocolo e os detalhes da porta da verificação de integridade não precisam corresponder ao protocolo do serviço de back-end do balanceador de carga e às informações de porta IP da regra de encaminhamento.

Como todos os protocolos de verificação de integridade compatíveis dependem do TCP, quando você usa um balanceador de carga de rede de passagem interna para balancear conexões e tráfego de outros protocolos, as VMs de back-end precisam executar um servidor baseado em TCP para responder às sondagens de verificação de integridade. Por exemplo, é possível usar uma verificação de integridade HTTP combinada com a execução de um servidor HTTP em cada VM de back-end. Neste exemplo, seus scripts ou software são responsáveis por configurar o servidor HTTP para que ele retorne o status 200 somente quando o software que escuta conexões balanceadas por carga estiver operacional.

Para mais informações sobre protocolos e portas de verificação de integridade compatíveis, consulte Categorias, protocolos e portas de verificação de integridade e Como as verificações de integridade funcionam.

Pacotes de verificação de integridade

Os verificadores de integridade enviam pacotes para a interface de rede da VM de back-end na rede VPC que corresponde à especificação de rede do serviço de back-end. Os pacotes de verificação de integridade têm as seguintes características:

• Endereço IP de origem do intervalo de IP da sondagem da verificação de integridade relevante.
• Endereço IP de destino que corresponde a cada endereço IP de uma regra de encaminhamento que faz referência ao serviço de back-end do balanceador de carga de rede de passagem interno.
• Porta de destino que corresponde ao número da porta especificado na verificação de integridade.

O software em execução nas VMs de back-end precisa se vincular e detectar as combinações relevantes de endereço IP e porta. A maneira mais simples de fazer isso é configurar o software para vincular e detectar as portas relevantes de qualquer um dos endereços IP da VM (0.0.0.0). Para mais informações, consulte Destino dos pacotes de sondagem.

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 implantar as instâncias de VM de back-end 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.

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

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 da distribuição de tráfego, incluindo afinidade da sessão, rastreamento de conexão e failover. Para mais detalhes sobre como os balanceadores de carga de rede de passagem interna distribuem o tráfego e como essas opções interagem 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, consulteCotas para recursos de balanceamento de carga.

Limitações

• Não é possível usar o console Google Cloud para criar um balanceador de carga de rede de passagem interno com back-ends de NEG zonais.
• Para NICs dinâmicas, adicione manualmente rotas locais para endereços IP de regra de encaminhamento, conforme descrito no seguinte problema conhecido:Pacotes descartados ao usar NICs dinâmicas com intervalos de IP de alias, encaminhamento de protocolo ou balanceadores de carga de rede de passagem.

A seguir

• Para configurar e testar um balanceador de carga de rede de passagem interna, consulte Configurar um balanceador de carga de rede de passagem interna.
• Para configurar o Cloud Monitoring para balanceadores de carga de rede de passagem interna, consulte Geração de registros e monitoramento do balanceador de carga de rede interno.
• Para resolver problemas com o balanceador de carga de rede de passagem interna, consulte esta página.
• Para usar modelos pré-criados do Terraform e simplificar a configuração e o gerenciamento da infraestrutura de rede do Google Cloud, acesse o repositório do GitHub de soluções simplificadas de configuração de rede do Cloud.