Vista geral do balanceador de carga de rede de proxy interno

O balanceador de carga de rede de proxy interno é um balanceador de carga baseado em proxy com tecnologia do software de proxy Envoy de código aberto e da pilha de virtualização de rede Andromeda. Trusted Cloud by S3NS

O Network Load Balancer de proxy interno é um balanceador de carga da camada 4 que lhe permite executar e dimensionar o tráfego de serviço TCP por detrás de um endereço IP interno regional acessível apenas a clientes na mesma rede VPC ou clientes ligados à sua rede VPC. O balanceador de carga termina primeiro a ligação TCP entre o cliente e o balanceador de carga num proxy Envoy. O proxy abre uma segunda ligação TCP a back-ends alojados em Trusted Cloud by S3NS, nas instalações ou noutros ambientes na nuvem. Para mais exemplos de utilização, consulte a vista geral do balanceador de carga de rede de proxy.

Modos de funcionamento

Este equilibrador de carga está disponível no modo regional e, a partir deste momento, é denominado equilibrador de carga de rede de proxy interno regional. O balanceador de carga é implementado como um serviço gerido com base no proxy Envoy de código aberto. No modo regional, todos os clientes e backends estão numa região especificada. Use este equilibrador de carga se quiser publicar conteúdo a partir de apenas uma geolocalização (por exemplo, para cumprir os regulamentos de conformidade).

Arquitetura

O diagrama seguinte mostra os Trusted Cloud recursos necessários para equilibradores de carga de rede de proxy interno.

Regional

Este diagrama mostra os componentes de uma implementação do Network Load Balancer de proxy interno regional no nível Premium.

Componentes do balanceador de carga de rede de proxy interno regional.
Componentes do balanceador de carga de rede do proxy interno regional (clique para aumentar).

Sub-rede só de proxy

No diagrama anterior, a sub-rede apenas de proxy fornece um conjunto de endereços IP que a Google usa para executar proxies do Envoy em seu nome. Tem de criar uma sub-rede apenas de proxy em cada região de uma rede VPC onde usa um balanceador de carga de rede de proxy interno baseado no Envoy.

A tabela seguinte descreve os requisitos de sub-rede apenas de proxy para equilibradores de carga de rede de proxy interno:

Modo do balanceador de carga Valor da flag --purpose da sub-rede só de proxy
Balanceador de carga de rede de proxy interno regional

REGIONAL_MANAGED_PROXY

Os balanceadores de carga regionais e entre regiões não podem partilhar as mesmas sub-redes

Todos os balanceadores de carga baseados no Envoy numa região e na rede VPC partilham a mesma sub-rede só de proxy.

Além disso:

  • As sub-redes apenas de proxy são usadas apenas para proxies do Envoy e não para os seus back-ends.
  • As instâncias ou os pontos finais de máquinas virtuais (VM) de back-end de todos os balanceadores de carga de rede de proxy interno numa região e numa rede VPC recebem ligações da sub-rede só de proxy.
  • O endereço IP de um Network Load Balancer de proxy interno não está localizado na sub-rede apenas de proxy. O endereço IP do balanceador de carga é definido pela respetiva regra de encaminhamento gerida interna.

Regras de encaminhamento e endereços IP

As regras de encaminhamento encaminham o tráfego por endereço IP, porta e protocolo para uma configuração de balanceamento de carga constituída por um proxy de destino e um serviço de back-end.

Especificação do endereço IP. Cada regra de encaminhamento faz referência a um único endereço IP regional que pode usar nos registos DNS da sua aplicação. Pode reservar um endereço IP estático que pode usar ou permitir que o Cloud Load Balancing atribua um por si. Recomendamos que reserve um endereço IP estático. Caso contrário, tem de atualizar o registo DNS com o endereço IP efémero recém-atribuído sempre que eliminar uma regra de encaminhamento e criar uma nova.

Os clientes usam o endereço IP e a porta para estabelecer ligação aos proxies Envoy do balanceador de carga. O endereço IP da regra de encaminhamento é o endereço IP do balanceador de carga (por vezes, denominado endereço IP virtual ou VIP). Os clientes que se ligam a um balanceador de carga têm de usar TCP. Para ver a lista completa de protocolos suportados, consulte o artigo Comparação de funcionalidades do equilibrador de carga.

O endereço IP interno associado à regra de encaminhamento pode ser proveniente de uma sub-rede na mesma rede e região que os seus back-ends.

Especificação da porta. Cada regra de encaminhamento que usar num Network Load Balancer de proxy interno pode fazer referência a uma única porta de 1 a 65535. Para suportar várias portas, tem de configurar várias regras de encaminhamento.

A tabela seguinte mostra os requisitos das regras de encaminhamento para equilibradores de carga de rede de proxy interno:

Modo do balanceador de carga Regra de encaminhamento, endereço IP e sub-rede só de proxy --purpose Encaminhamento do cliente para a interface do balanceador de carga
Balanceador de carga de rede de proxy interno regional

Regional forwardingRules

Endereço IP regional

Esquema de balanceamento de carga:

INTERNAL_MANAGED

Sub-rede só de proxy --purpose:

REGIONAL_MANAGED_PROXY

Endereço IP --purpose:

SHARED_LOADBALANCER_VIP

Os backends também têm de estar na mesma região que o equilibrador de carga.

Regras de encaminhamento e redes VPC

Esta secção descreve como as regras de encaminhamento usadas por equilibradores de carga de aplicações externos estão associadas a redes VPC.

Modo do balanceador de carga Associação da rede da VPC
Balanceador de carga de rede de proxy interno entre regiões

Balanceador de carga de rede de proxy interno regional

Os endereços IPv4 internos regionais existem sempre em redes VPC. Quando cria a regra de encaminhamento, tem de especificar a sub-rede a partir da qual o endereço IP interno é retirado. Esta sub-rede tem de estar na mesma região e rede VPC que uma sub-rede apenas de proxy. criado. Assim, existe uma associação de rede implícita.

Proxies de destino

O Network Load Balancer do proxy interno termina as ligações TCP do cliente e cria novas ligações aos back-ends. Por predefinição, o endereço IP do cliente original e as informações da porta não são preservados. Pode preservar estas informações através do protocolo PROXY. O proxy de destino encaminha os pedidos recebidos diretamente para o serviço de back-end do equilibrador de carga.

A tabela seguinte mostra as APIs de proxy de destino necessárias para os equilibradores de carga de rede de proxy internos:

Modo do balanceador de carga Proxy de destino
Balanceador de carga de rede de proxy interno regional Regional regionTargetTcpProxies

Serviço de back-end

Um serviço de back-end direciona o tráfego recebido para um ou mais back-ends anexados. Um back-end é um grupo de instâncias ou um grupo de pontos finais de rede. O back-end contém informações do modo de equilíbrio para definir a capacidade total com base nas ligações (ou, por exemplo, apenas back-ends de grupo, na utilização).

Cada balanceador de carga de rede de proxy interno tem um único recurso de serviço de back-end.

A tabela seguinte especifica os requisitos do serviço de back-end para balanceadores de carga de rede de proxy interno:

Modo do balanceador de carga Tipo de serviço de back-end
Balanceador de carga de rede de proxy interno regional Regional regionBackendServices

Back-ends suportados

O serviço de back-end suporta os seguintes tipos de back-ends:

Modo do balanceador de carga Back-ends suportados num serviço de back-end
Grupos de instâncias NEGs zonais NEGs da Internet NEGs sem servidor NEGs híbridos GKE
Balanceador de carga de rede de proxy interno regional Endpoints do tipo
GCE_VM_IP_PORT		 Apenas NEGs regionais

Todos os back-ends têm de ser do mesmo tipo (grupos de instâncias ou NEGs). Pode usar simultaneamente diferentes tipos de back-ends de grupos de instâncias ou pode usar simultaneamente diferentes tipos de back-ends de NEG, mas não pode usar back-ends de grupos de instâncias e de NEG em conjunto no mesmo serviço de back-end.

Pode misturar NEGs zonais e NEGs híbridos no mesmo serviço de back-end.

Para minimizar as interrupções de serviço para os seus utilizadores, ative a drenagem de ligações nos serviços de back-end. Essas interrupções podem ocorrer quando um back-end é terminado, removido manualmente ou removido por um dimensionamento automático. Para saber mais acerca da utilização da drenagem de ligações para minimizar as interrupções do serviço, consulte o artigo Ative a drenagem de ligações.

Back-ends e redes VPC

  • Para grupos de instâncias, NEGs zonais e NEGs de conetividade híbrida, todos os back-ends têm de estar localizados no mesmo projeto e região que o serviço de back-end. No entanto, um equilibrador de carga pode fazer referência a um back-end que usa uma rede VPC diferente no mesmo projeto que o serviço de back-end. A conetividade entre a rede VPC do balanceador de carga e a rede VPC de back-end pode ser configurada através do intercâmbio da rede VPC, de túneis do Cloud VPN ou de anexos de VLAN do Cloud Interconnect.

    Definição da rede de back-end

    • Para NEGs zonais e NEGs híbridos, especifica explicitamente a rede VPC quando cria o NEG.
    • Para grupos de instâncias geridas, a rede VPC é definida no modelo de instância.
    • Para grupos de instâncias não geridos, a rede VPC do grupo de instâncias é definida para corresponder à rede VPC da interface nic0 para a primeira VM adicionada ao grupo de instâncias.

    Requisitos de rede de back-end

    A rede do seu back-end tem de cumprir um dos seguintes requisitos de rede:

    • A rede da VPC do back-end tem de corresponder exatamente à rede da VPC da regra de encaminhamento.

    • A rede da VPC do back-end tem de estar ligada à rede da VPC da regra de encaminhamento através do intercâmbio das redes da VPC. Tem de configurar as trocas de trajetos de sub-rede para permitir a comunicação entre a sub-rede apenas de proxy na rede VPC da regra de encaminhamento e as sub-redes usadas pelas instâncias ou os pontos finais de back-end.

  • Para todos os outros tipos de back-end, todos os back-ends têm de estar localizados na mesma rede e região da VPC.

Back-ends e interfaces de rede

Se usar back-ends de grupos de instâncias, os pacotes são sempre entregues a nic0. Se quiser enviar pacotes para interfaces não nic0 (vNICs ou interfaces de rede dinâmicas), use backends de NEG.

Se usar back-ends de NEG zonais, os pacotes são enviados para qualquer interface de rede representada pelo ponto final no NEG. Os pontos finais do NEG têm de estar na mesma rede VPC que a rede VPC definida explicitamente do NEG.

Protocolo para comunicar com os back-ends

Quando configura um serviço de back-end para um balanceador de carga de rede de proxy interno, define o protocolo que o serviço de back-end usa para comunicar com os back-ends. O balanceador de carga usa apenas o protocolo que especificar e não tenta negociar uma ligação com o outro protocolo. Os balanceadores de carga de rede de proxy interno só suportam TCP para comunicar com os back-ends.

Verificação de funcionamento

Cada serviço de back-end especifica uma verificação de estado que monitoriza periodicamente a disponibilidade dos back-ends para receber uma ligação do equilibrador de carga. Isto reduz o risco de os pedidos serem enviados para back-ends que não podem processar o pedido. As verificações de estado não verificam se a própria aplicação está a funcionar.

Protocolo de verificação de funcionamento

Embora não seja obrigatório e nem sempre seja possível, é uma prática recomendada usar uma verificação de estado cujo protocolo corresponda ao protocolo do serviço de back-end. Por exemplo, uma verificação de estado TCP testa com maior precisão a conetividade TCP aos back-ends. Para ver a lista de protocolos de verificação de funcionamento suportados, consulte a secção Verificações de funcionamento da página de comparação de funcionalidades do balanceador de carga.

A tabela seguinte especifica o âmbito das verificações de saúde suportadas pelos equilibradores de carga de rede de proxy interno em cada modo:

Modo do balanceador de carga Tipo de verificação de funcionamento
Balanceador de carga de rede de proxy interno regional Regional regionHealthChecks

Para mais informações sobre as verificações de funcionamento, consulte o seguinte:

Regras de firewall

Os balanceadores de carga de rede de proxy internos requerem as seguintes regras de firewall:

  • Uma regra de permissão de entrada que permite o tráfego das sondas de verificação de funcionamento da Google. Para mais informações sobre os intervalos de endereços IP de sondagem de verificação de estado específicos e o motivo pelo qual é necessário permitir o tráfego proveniente dos mesmos, consulte o artigo Intervalos de IP de sondagem e regras de firewall.
  • Uma regra de permissão de entrada que permite o tráfego da sub-rede só de proxy.

As portas destas regras de firewall têm de ser configuradas da seguinte forma:

  • Permita o tráfego para a porta de destino da verificação do estado de funcionamento de cada serviço de back-end.

  • Para back-ends de grupos de instâncias: determine as portas a configurar através do mapeamento entre a porta denominada do serviço de back-end e os números das portas associados a essa porta denominada em cada grupo de instâncias. Os números das portas podem variar entre os grupos de instâncias atribuídos ao mesmo serviço de back-end.

  • Para back-ends de GCE_VM_IP_PORT NEG, permita o tráfego para os números de porta dos pontos finais.

Existem determinadas exceções aos requisitos das regras de firewall para estes equilibradores de carga:

  • Não é necessário permitir tráfego dos intervalos de sondas de verificação de estado da Google para NEGs híbridos. No entanto, se estiver a usar uma combinação de NEGs híbridos e zonais num único serviço de back-end, tem de permitir o tráfego dos intervalos de sondas de verificação de estado da Google para os NEGs zonais.
  • Para NEGs de Internet regionais, as verificações de estado são opcionais. O tráfego dos balanceadores de carga que usam NEGs de Internet regionais tem origem na sub-rede apenas de proxy e, em seguida, é traduzido pela NAT (através da NAT da nuvem) para endereços IP da NAT alocados manual ou automaticamente. Este tráfego inclui sondagens de verificação de funcionamento e pedidos de utilizadores do equilibrador de carga para os back-ends. Para ver detalhes, consulte o artigo NEGs regionais: use um gateway NAT da nuvem.

Acesso de cliente

Os clientes podem estar na mesma rede ou numa rede VPC ligada através do intercâmbio da rede da VPC.

Para balanceadores de carga de rede de proxy interno regionais, os clientes têm de estar na mesma região que o balanceador de carga por predefinição. Também têm de estar na mesma rede VPC que o balanceador de carga ou numa rede VPC que esteja ligada à rede VPC do balanceador de carga através da interligação de redes VPC.

Os clientes no local podem aceder ao balanceador de carga através de túneis de VPN na nuvem ou anexos de VLAN. Estes túneis ou anexos têm de estar na mesma região que o equilibrador de carga.

Arquitetura de VPC partilhada

O balanceador de carga de rede de proxy interno suporta redes que usam a VPC partilhada. A VPC partilhada permite-lhe manter uma separação clara de responsabilidades entre os administradores de rede e os programadores de serviços. As suas equipas de desenvolvimento podem concentrar-se na criação de serviços em projetos de serviços, e as equipas de infraestrutura de rede podem aprovisionar e administrar o equilíbrio de carga. Se ainda não conhece a VPC partilhada, leia a documentação de vista geral da VPC partilhada.

Endereço IP Regra de encaminhamento Proxy de destino Componentes de back-end

Tem de definir um endereço IP interno no mesmo projeto que os back-ends.

Para que o balanceador de carga esteja disponível numa rede de VPC partilhada, o endereço IP interno tem de ser definido no mesmo projeto de serviço onde se encontram as VMs de back-end e tem de fazer referência a uma sub-rede na rede de VPC partilhada pretendida no projeto anfitrião. A própria morada é proveniente do intervalo de IP principal da sub-rede referenciada.

Tem de definir uma regra de encaminhamento interno no mesmo projeto que os back-ends.

Para que o balanceador de carga esteja disponível numa rede de VPC partilhada, a regra de encaminhamento interno tem de ser definida no mesmo projeto de serviço onde as VMs de back-end estão localizadas e tem de fazer referência à mesma sub-rede (na rede de VPC partilhada) à qual o endereço IP interno associado faz referência.

 O proxy de destino tem de ser definido no mesmo projeto que os back-ends. Num cenário de VPC partilhada, as VMs de back-end estão normalmente localizadas num projeto de serviço. Um serviço de back-end interno regional e uma verificação de estado têm de ser definidos nesse projeto de serviço.

Distribuição de tráfego

Um balanceador de carga de rede de proxy interno distribui o tráfego para os respetivos back-ends da seguinte forma:

  1. As ligações originadas de um único cliente são enviadas para a mesma zona, desde que existam back-ends (grupos de instâncias ou NEGs) em bom estado de funcionamento nessa zona e tenham capacidade, conforme determinado pelo modo de balanceamento. Para equilibradores de carga de proxy interno regionais, o modo de equilíbrio pode ser CONNECTION (grupos de instâncias ou back-ends de NEG) ou UTILIZATION (apenas back-ends de grupos de instâncias).
  2. As ligações de um cliente são enviadas para o mesmo back-end se tiver configurado a afinidade de sessão.
  3. Depois de selecionar um back-end, o tráfego é distribuído entre instâncias (num grupo de instâncias) ou pontos finais (num NEG) de acordo com uma política de balanceamento de carga. Para ver os algoritmos da política de equilíbrio de carga suportados, consulte a definição localityLbPolicy na documentação da API do serviço de back-end regional.

Afinidade de sessão

A afinidade de sessão permite-lhe configurar o serviço de back-end do balanceador de carga para enviar todos os pedidos do mesmo cliente para o mesmo back-end, desde que o back-end esteja em bom estado e tenha capacidade.

Os balanceadores de carga de rede de proxy internos oferecem os seguintes tipos de afinidade de sessão:

  • Nenhum

    Uma definição de afinidade de sessão de NONE não significa que não existe afinidade de sessão. Significa que não está configurada explicitamente nenhuma opção de afinidade de sessão.

    A aplicação de hash é sempre realizada para selecionar um back-end. Uma definição de afinidade de sessão de NONE significa que o balanceador de carga usa um hash de 5 tuplos para selecionar um back-end. O hash de 5 tuplos consiste no endereço IP de origem, na porta de origem, no protocolo, no endereço IP de destino e na porta de destino.

    Uma afinidade de sessão de NONE é o valor predefinido.

  • Afinidade de IP do cliente

    A afinidade de sessão do IP do cliente (CLIENT_IP) é um hash de 2 tuplos criado a partir dos endereços IP de origem e destino do pacote. A afinidade de IP do cliente encaminha todos os pedidos do mesmo endereço IP do cliente para o mesmo back-end, desde que esse back-end tenha capacidade e permaneça em bom estado.

    Quando usa a afinidade de IP do cliente, tenha em atenção o seguinte:

    • O endereço IP de destino do pacote só é igual ao endereço IP da regra de encaminhamento do balanceador de carga se o pacote for enviado diretamente para o balanceador de carga.
    • O endereço IP de origem do pacote pode não corresponder a um endereço IP associado ao cliente original se o pacote for processado por um NAT intermédio ou um sistema de proxy antes de ser entregue a um equilibrador de carga. Trusted Cloud Em situações em que muitos clientes partilham o mesmo endereço IP de origem efetivo, algumas VMs de back-end podem receber mais ligações ou pedidos do que outras.

Tenha em atenção o seguinte quando configurar a afinidade de sessão:

  • Não confie na afinidade de sessão para fins de autenticação ou segurança. A afinidade de sessão pode ser interrompida sempre que o número de back-ends de publicação e em bom estado de funcionamento muda. Para mais detalhes, consulte o artigo Perder a afinidade da sessão.

  • Os valores predefinidos das flags --session-affinity e --subsetting-policy são ambos NONE, e só é possível definir um deles de cada vez para um valor diferente.

Perder a afinidade de sessão

Todas as opções de afinidade de sessão requerem o seguinte:

  • A instância ou o ponto final do back-end selecionado tem de permanecer configurado como um back-end. A afinidade de sessão pode ser interrompida quando ocorre um dos seguintes eventos:
    • Remove a instância selecionada do respetivo grupo de instâncias.
    • O dimensionamento automático ou a autorreparação do grupo de instâncias geridas remove a instância selecionada do respetivo grupo de instâncias geridas.
    • Remove o ponto final selecionado do respetivo NEG.
    • Remove o grupo de instâncias ou o NEG que contém a instância ou o ponto final selecionado do serviço de back-end.
  • A instância ou o ponto final do back-end selecionado tem de permanecer em bom estado. A afinidade de sessão pode ser interrompida quando a instância ou o ponto final selecionado falha nas verificações de estado.
Todas as opções de afinidade de sessão têm os seguintes requisitos adicionais:

  • O grupo de instâncias ou o NEG que contém a instância ou o ponto final selecionado não pode estar cheio, conforme definido pela respetiva capacidade alvo. (Para grupos de instâncias geridas regionais, o componente zonal do grupo de instâncias que contém a instância selecionada não pode estar cheio.) A afinidade de sessão pode ser interrompida quando o grupo de instâncias ou o NEG está cheio e outros grupos de instâncias ou NEGs não estão. Uma vez que a capacidade pode mudar de formas imprevisíveis quando usa o modo de balanceamento UTILIZATION, deve usar o modo de balanceamento RATE ou CONNECTION para minimizar as situações em que a afinidade de sessão pode ser interrompida.

  • O número total de instâncias ou pontos finais de back-end configurados tem de permanecer constante. Quando ocorre, pelo menos, um dos seguintes eventos, o número de instâncias ou pontos finais de back-end configurados é alterado e a afinidade de sessão pode ser interrompida:

    • Adicionar novas instâncias ou pontos finais:

      • Adiciona instâncias a um grupo de instâncias existente no serviço de back-end.
      • O dimensionamento automático do grupo de instâncias geridas adiciona instâncias a um grupo de instâncias geridas no serviço de back-end.
      • Adiciona pontos finais a um NEG existente no serviço de back-end.
      • Adiciona grupos de instâncias ou NEGs não vazios ao serviço de back-end.

    • Remover qualquer instância ou ponto final, não apenas a instância ou o ponto final selecionado:

      • Remover qualquer instância de um back-end de grupo de instâncias.
      • O dimensionamento automático ou a autorreparação do grupo de instâncias geridas remove qualquer instância de um back-end do grupo de instâncias geridas.
      • Remover qualquer ponto final de um back-end do NEG.
      • Remova qualquer grupo de instâncias de back-end ou NEG existente e não vazio do serviço de back-end.

  • O número total de instâncias ou pontos finais de back-end saudáveis tem de permanecer constante. Quando ocorre, pelo menos, um dos seguintes eventos, o número de instâncias ou pontos finais de back-end íntegros muda e a afinidade de sessão pode ser interrompida:

    • Qualquer instância ou ponto final passa na respetiva verificação de estado, passando de não saudável para saudável.
    • Qualquer instância ou ponto final falha na respetiva verificação de estado, passando de em bom estado para em mau estado ou tempo limite.

Failover

Se um back-end ficar em mau estado, o tráfego é automaticamente redirecionado para back-ends em bom estado.

A tabela seguinte descreve o comportamento de comutação por falha para equilibradores de carga de rede de proxy internos:

Modo do balanceador de carga Comportamento de comutação por falha Comportamento quando todos os back-ends estão em mau estado
Balanceador de carga de rede de proxy interno regional

O balanceador de carga implementa um algoritmo de comutação por falha gradual por zona. Em vez de aguardar que todos os back-ends numa zona fiquem em mau estado, o balanceador de carga começa a redirecionar o tráfego para uma zona diferente quando a proporção de back-ends em bom estado para back-ends em mau estado em qualquer zona for inferior a uma determinada percentagem (70%; não é possível configurar este limite). Se todos os back-ends em todas as zonas estiverem em mau estado, o equilibrador de carga termina imediatamente a ligação do cliente.

O proxy Envoy envia tráfego para back-ends em bom estado numa região com base na distribuição de tráfego configurada.

 Termina a ligação

Balanceamento de carga para aplicações do GKE

Se estiver a criar aplicações no Google Kubernetes Engine (GKE), pode usar NEGs zonais autónomos para equilibrar a carga do tráfego diretamente para contentores. Com os NEGs autónomos, é responsável por criar o objeto Service que cria o NEG zonal e, em seguida, associar o NEG ao serviço de back-end para que o equilibrador de carga possa estabelecer ligação aos pods.

Documentação do GKE relacionada:

Quotas e limites

Para ver informações sobre quotas e limites, consulte o artigo Quotas e limites.

Limitações

  • O Network Load Balancer de proxy interno não suporta tráfego IPv6.
  • O Network Load Balancer de proxy interno não suporta implementações de VPC partilhada em que o front-end do Load Balancer está num projeto anfitrião ou de serviço e o serviço de back-end e os back-ends estão noutro projeto de serviço (também conhecido como referência de serviço entre projetos).

O que se segue?