O balanceador de carga de rede de proxy interno Trusted Cloud by S3NS é 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.
O balanceador de carga de rede de proxy interno é um balanceador de carga de camada 4 que permite executar e escalonar o tráfego de serviço TCP atrás de um endereço IP interno regional que seja acessível apenas para clientes na mesma rede VPC ou clientes conectados à rede VPC. O balanceador de carga encerra primeiro a conexão TCP entre o cliente e o balanceador de carga em um proxy Envoy. O proxy abre uma segunda conexão TCP com back-ends hospedados em Trusted Cloud by S3NS, no local ou em outros ambientes de nuvem. Para mais casos de uso, consulte Visão geral do balanceador de carga de rede proxy.
Modos de operação
Esse balanceador de carga está disponível no modo regional e será daqui por diante chamado de balanceador de carga de rede de proxy interno regional. O balanceador de carga é implementado como um serviço gerenciado baseado no proxy Envoy de código aberto. No modo regional, todos os clientes e back-ends estão em uma região especificada. Use este balanceador de carga se quiser veicular conteúdo de apenas uma geolocalização (por exemplo, para atender a regulamentações de conformidade).
Arquitetura
O diagrama a seguir mostra os recursos do Trusted Cloud necessários para balanceadores de carga de rede de proxy internos.
Regional
Este diagrama mostra os componentes de uma implantação do balanceador de carga de rede de proxy interno regional no nível Premium.
Sub-rede somente proxy
No diagrama anterior, a sub-rede somente proxy fornece um conjunto de endereços IP que o Google usa para executar proxies Envoy em seu nome. Crie uma sub-rede somente proxy em cada região de uma rede VPC em que você usa um balanceador de carga de rede de proxy interno baseado no Envoy.
A tabela a seguir descreve os requisitos de sub-redes somente proxy para balanceadores de carga de rede de proxy internos:
| Modo balanceador de carga | Valor da flag de sub-rede somente proxy --purpose |
|---|---|
| Balanceador de carga de rede de proxy interno regional |
Balanceadores de carga regionais e entre regiões não podem compartilhar as mesmas sub-redes Todos os balanceadores de carga regionais baseados no Envoy em uma região e rede VPC compartilham a mesma sub-rede somente proxy |
Além disso:
- As sub-redes somente proxy são usadas apenas para proxies Envoy, não para seus back-ends.
- As instâncias de máquina virtual (VM) de back-end ou os endpoints de todos os balanceadores de carga de rede de proxy internos em uma região e rede VPC recebem conexões da sub-rede somente proxy.
- O endereço IP de um balanceador de carga de rede de proxy interno não está localizado na sub-rede somente proxy. O endereço IP do balanceador de carga é definido pela regra de encaminhamento interno gerenciado dele.
Regras de encaminhamento e endereços IP
As regras de encaminhamento roteiam o tráfego por endereço IP, porta e protocolo para uma configuração de balanceamento de carga que consiste em proxy de destino e serviço de back-end.
Especificação de endereço IP. Cada regra de encaminhamento referencia um endereço IP regional único que pode ser usado nos registros DNS do aplicativo. É possível reservar um endereço IP estático que possa ser usado ou permitir que o Cloud Load Balancing atribua um para você. Recomendamos reservar um endereço IP estático. Caso contrário, será necessário atualizar o registro DNS com o endereço IP temporário recém-atribuído sempre que uma regra de encaminhamento for excluída e uma nova for criada.
Os clientes usam o endereço IP e a porta para se conectar aos proxies do Envoy relativos ao balanceador de carga. O endereço IP da regra de encaminhamento é o endereço IP do balanceador de carga, que é chamado frequentemente de endereço IP virtual ou VIP. Os clientes que se conectam a um balanceador de carga precisam usar o TCP. Para ver a lista completa de protocolos suportados, consulte Comparação de recursos do balanceador 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 back-ends.
Especificação da porta. Cada regra de encaminhamento usada em um balanceador de carga de rede de proxy interno pode ter referência a uma única porta de 1 a 65535. Para permitir várias portas, configure várias regras de encaminhamento.
A tabela a seguir mostra os requisitos de regras de encaminhamento para balanceadores de carga de rede de proxy internos:
| Modo balanceador de carga | Regra de encaminhamento, endereço IP e sub-rede somente proxy --purpose |
Roteamento do cliente para o front-end do balanceador de carga |
|---|---|---|
| Balanceador de carga de rede de proxy interno regional |
Esquema de balanceamento de carga:
Sub-rede somente proxy
Endereço IP
|
Os back-ends também precisam estar na mesma região que o balanceador de carga. |
Regras de encaminhamento e redes VPC
Esta seção descreve como as regras de encaminhamento usadas por balanceadores de carga de aplicativo externos são associadas às redes VPC.
| Modo balanceador de carga | Associação de rede 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 sempre existem dentro das redes VPC. Ao criar a regra de encaminhamento, é necessário especificar a sub-rede de onde o endereço IP interno é retirado. Essa sub-rede precisa estar na mesma região e rede VPC que uma sub-rede somente proxy. que criamos. Assim, há uma associação de rede implícita. |
Proxies de destino
O balanceador de carga de rede de proxy interno encerra as conexões TCP do cliente e cria novas conexões com os back-ends. Por padrão, o endereço IP do cliente original e as informações da porta não são preservados. É possível preservar essas informações usando o protocolo PROXY. O proxy de destino encaminha solicitações recebidas diretamente para o serviço de back-end do balanceador de carga.
A tabela a seguir mostra as APIs de proxy de destino exigidas pelos balanceadores de carga de rede de proxy internos:
| Modo balanceador de carga | Proxy de destino |
|---|---|
| Balanceador de carga de rede de proxy interno regional | regionTargetTcpProxies regional |
Serviço de back-end
Um serviço de back-end direciona o tráfego de entrada para um ou mais back-ends anexados. Um back-end é um grupo de instâncias ou um grupo de endpoints da rede. O back-end contém informações do modo de balanceamento para definir totalidade com base nas conexões (ou, para back-ends de grupos de instâncias, na utilização).
Cada balanceador de carga de rede de proxy interno tem um único recurso de serviço de back-end.
A tabela a seguir especifica os requisitos de serviço de back-end para balanceadores de carga de rede de proxy internos:
| Modo balanceador de carga | Tipo de serviço de back-end |
|---|---|
| Balanceador de carga de rede de proxy interno regional | regionBackendServices regional |
Back-ends compatíveis
O serviço de back-end é compatível com os seguintes tipos de back-ends:
| Modo balanceador de carga | Back-ends compatíveis em um serviço de back-end | ||||||
|---|---|---|---|---|---|---|---|
| Grupos de instâncias | NEGs por zona | NEGs na Internet | NEGs sem servidor | NEGs híbridos | GKE | ||
| Balanceador de carga de rede de proxy interno regional | Endpoints do tipo GCE_VM_IP_PORT |
Somente NEGs regionais | |||||
Todos os back-ends precisam ser do mesmo tipo (grupos de instâncias ou NEGs). É possível usar simultaneamente diferentes tipos de back-ends de grupos de instâncias ou simultaneamente para diferentes tipos de back-ends de NEGs, mas não é possível usar grupos de instâncias e back-ends de NEG juntos no mesmo serviço de back-end.
É possível misturar NEGs zonais e híbridos no mesmo serviço de back-end.
Para minimizar as interrupções do serviço aos usuários, ative a diminuição da conexão nos serviços de back-end. Essas interrupções podem acontecer quando um back-end é encerrado, removido manualmente ou removido por um escalonador automático. Para saber mais sobre como usar a diminuição da conexão para minimizar as interrupções do serviço, consulte Ativar a diminuição da conexão.
Back-ends e redes VPC
Para grupos de instâncias, NEGs zonais e NEGs de conectividade híbrida, todos os back-ends precisam estar localizados no mesmo projeto e região do serviço de back-end. No entanto, um balanceador de carga pode referenciar um back-end que usa outra rede VPC no mesmo projeto que o serviço de back-end. A conectividade entre a rede VPC do balanceador de carga e a rede VPC de back-end pode ser configurada usando o peering de rede VPC, túneis da Cloud VPN ou anexos da VLAN do Cloud Interconnect.
Definição de rede de back-end
- Para NEGs zonais e híbridos, especifique explicitamente a rede VPC ao criar o NEG.
- Para grupos gerenciados de instâncias, a rede VPC é definida no modelo de instância.
- Para grupos não gerenciados de instâncias, a rede VPC do grupo de instâncias é definida para corresponder à rede VPC da interface
nic0da primeira VM adicionada ao grupo de instâncias.
Requisitos de rede de back-end
A rede do seu back-end precisa atender a um dos requisitos de rede a seguir:
A rede VPC do back-end precisa corresponder exatamente à rede VPC da regra de encaminhamento.
A rede VPC do back-end precisa estar conectada à rede VPC da regra de encaminhamento usando o peering de rede VPC. É necessário configurar as trocas de rotas de sub-rede para permitir a comunicação entre a sub-rede somente proxy na rede VPC da regra de encaminhamento e as sub-redes usadas pelas instâncias ou endpoints de back-end.
Para os outros tipos de back-end, todos os back-ends precisam estar localizados na mesma rede e região VPC.
Back-ends e interfaces de rede
Se você usar back-ends de grupos de instâncias, os pacotes serão sempre entregues a nic0. Se
você quiser enviar pacotes para interfaces não nic0 (vNICs ou
interfaces de rede dinâmicas), use
back-ends NEG.
Se você usar back-ends de NEG zonal, os pacotes serão enviados para qualquer interface de rede representada pelo endpoint no NEG. Os endpoints do NEG precisam estar na mesma rede VPC que a rede VPC definida explicitamente do NEG.
Protocolo para comunicação com os back-ends
Ao configurar um serviço de back-end para um balanceador de carga da rede de proxy interno, defina o protocolo que o serviço usará para se comunicar com os back-ends. O balanceador de carga usa apenas o protocolo que você especifica e não tenta negociar uma conexão com o outro protocolo. Os balanceadores de carga de rede de proxy internos aceitam apenas TCP para comunicação com os back-ends.
Verificação de integridade
Cada serviço de back-end especifica uma verificação de integridade que monitora periodicamente a prontidão dos back-ends para receber uma conexão do balanceador de carga. Isso reduz o risco de as solicitações serem enviadas para back-ends que não possam atender à solicitação. As verificações de integridade não conferem se o aplicativo está funcionando.
Protocolo de verificação de integridade
Embora não seja obrigatório e nem sempre possível, é recomendável usar uma verificação de integridade que tenha um protocolo que corresponda ao protocolo do serviço de back-end. Por exemplo, uma verificação de integridade TCP testa com mais precisão a conectividade TCP com back-ends. Para ver a lista de protocolos de verificação de integridade compatíveis, consulte a seção Verificações de integridade na página de comparação de recursos do balanceador de carga.
A tabela a seguir especifica o escopo das verificações de integridade compatíveis com os balanceadores de carga de rede de proxy interno em cada modo:
| Modo balanceador de carga | Tipo de verificação de integridade |
|---|---|
| Balanceador de carga de rede de proxy interno regional | regionHealthChecks regional |
Para saber mais sobre verificações de integridade, consulte:
Regras de firewall
Os balanceadores de carga de rede de proxy interno exigem as seguintes regras de firewall:
- Uma regra de permissão de entrada que permite o tráfego das sondagens de verificação de integridade do Google. Para mais informações sobre os intervalos de endereços IP de sondagem de verificação de integridade específicos e por que é necessário permitir o tráfego deles, consulte Intervalos de IP de sondagem e regras de firewall.
- Uma regra de permissão de entrada que permita o tráfego da sub-rede somente proxy.
As portas dessas regras de firewall precisam ser configuradas da seguinte maneira:
Permite o tráfego para a porta de destino da verificação de integridade de cada serviço de back-end.
Para back-ends de grupos de instâncias: determine as portas a serem configuradas pelo mapeamento entre a porta nomeada do serviço de back-end e os números de porta associados a essa porta nomeada em cada grupo de instâncias. Os números podem variar entre os grupos de instâncias atribuídos ao mesmo serviço de back-end.
Para back-ends NEG de
GCE_VM_IP_PORT, permita o tráfego para os números de porta dos endpoints.
Há algumas exceções aos requisitos de regras de firewall para esses balanceadores de carga:
- Não é necessário permitir o tráfego dos intervalos de sondagem de verificação de integridade do Google para NEGs híbridos. No entanto, se você estiver usando uma combinação de NEGs híbridos e zonais em um único serviço de back-end, será necessário permitir o tráfego dos intervalos de sondagem de verificação de integridade do Google para os NEGs zonais.
- Para NEGs regionais da Internet, as verificações de integridade são opcionais. O tráfego de balanceadores de carga que usam NEGs regionais da Internet é proveniente da sub-rede somente proxy e, em seguida, é convertido por NAT (usando o Cloud NAT) para endereços IP NAT alocados automaticamente ou manualmente. Esse tráfego inclui sondagens de verificação de integridade e solicitações de usuários do balanceador de carga aos back-ends. Para detalhes, consulte NEGs regionais: usar um gateway do Cloud NAT.
Acesso de cliente
Os clientes podem estar na mesma rede ou em uma rede VPC conectada usando o peering de rede VPC.
Para balanceadores de carga de rede de proxy regionais internos, os clientes precisam estar, por padrão, 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 locais podem acessar o balanceador de carga por meio de túneis Cloud VPN ou anexos da VLAN. Esses túneis ou anexos precisam estar na mesma região do balanceador de carga.
Arquitetura da VPC compartilhada
O balanceador de carga de rede de proxy interno é compatível com redes que usam a VPC compartilhada. A VPC compartilhada permite manter uma separação clara de responsabilidades entre administradores de rede e desenvolvedores de serviços. Suas equipes de desenvolvimento podem se concentrar na criação de serviços em projetos de serviço, enquanto as equipes de infraestrutura de rede podem provisionar e administrar o balanceamento de carga. Se você ainda não estiver familiarizado com a VPC compartilhada, leia a documentação de visão geral da VPC compartilhada.
| Endereço IP | Regra de encaminhamento | Proxy de destino | Componentes de back-end |
|---|---|---|---|
Um endereço IP interno precisa ser definido no mesmo projeto que os back-ends. Para que o balanceador de carga esteja disponível em uma rede VPC compartilhada, o 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 do projeto host. O endereço vem do intervalo de IP principal da sub-rede referenciada. |
Uma regra de encaminhamento interna precisa ser definida no mesmo projeto que os back-ends. 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 mesma sub-rede (na rede VPC compartilhada) que o endereço IP interno associado. |
O proxy de destino precisa ser definido no mesmo projeto que os back-ends. | Em um cenário de VPC compartilhada, as VMs de back-end costumam ficar 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
Um balanceador de carga de rede de proxy interno distribui o tráfego para os back-ends da seguinte maneira:
- As conexões originadas de um único cliente são enviadas para a mesma zona, desde que os back-ends íntegros (grupos de instâncias ou NEGs) nessa zona estejam disponíveis e tenham capacidade, conforme determinado pelo modo de balanceamento.
Para balanceadores de carga de rede de proxy internos regionais, o modo de balanceamento pode ser
CONNECTION(back-ends de grupo de instâncias ou NEG) ouUTILIZATION(somente back-ends de grupo de instâncias). - As conexões de um cliente serão enviadas para o mesmo back-end se você tiver configurado a afinidade da sessão.
- Depois que um back-end é selecionado, o tráfego é distribuído entre instâncias
(em um grupo de instâncias) ou endpoints (em um NEG) de acordo com uma
política de balanceamento de carga. Para saber mais sobre os algoritmos de política de balanceamento de carga suportados, consulte a configuração
localityLbPolicyna documentação da API do serviço de back-end regional.
afinidade da sessão
Com a afinidade da sessão, é possível configurar o serviço de back-end do balanceador de carga para enviar todas as solicitações do mesmo cliente ao mesmo back-end, desde que ele esteja íntegro e tenha capacidade.
Os balanceadores de carga de rede de proxy interno oferecem os seguintes tipos de afinidade da sessão:Nenhum
Uma configuração de afinidade da sessão de
NONEnão significa que não há afinidade da sessão. Isso significa que nenhuma opção afinidade da sessão foi configurada explicitamente.O hash é sempre realizado para selecionar um back-end. Uma configuração de afinidade da sessão de
NONEsignifica que o balanceador de carga usa um hash de cinco tuplas para selecionar um back-end. O hash de 5 tuplas 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 da sessão de
NONEé o valor padrão.Afinidade de IP do cliente
A afinidade da sessão IP do cliente (
CLIENT_IP) é um hash de duas tuplas criado com os endereços IP de origem e destino do pacote. A afinidade de IP do cliente encaminha todas as solicitações do mesmo endereço IP do cliente para o mesmo back-end, desde que esse back-end tenha capacidade e se mantenha íntegro.Ao usar a afinidade de IP do cliente, lembre-se do 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 ao 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 ou sistema de proxy intermediário antes de ser entregue a um balanceador de carga Trusted Cloud . Em situações em que muitos clientes compartilham o mesmo endereço IP de origem efetivo, algumas VMs de back-end podem receber mais conexões ou solicitações do que outras.
Lembre-se do seguinte ao configurar a afinidade da sessão:
Não confie na afinidade da sessão para fins de autenticação ou segurança. A afinidade da sessão pode ser interrompida sempre que o número de back-ends de exibição e íntegros muda. Para mais detalhes, consulte Perda de afinidade da sessão.
Os valores padrão das sinalizações
--session-affinitye--subsetting-policysãoNONE, e apenas um por vez pode ser definido como um valor diferente.
Perda da afinidade da sessão
Todas as opções afinidade da sessão exigem o seguinte:
- A instância ou o endpoint de back-end selecionado precisa permanecer configurado como um
back-end. A afinidade da sessão pode ser interrompida quando um dos seguintes eventos ocorre:
- Remova a instância selecionada do grupo de instâncias.
- O escalonamento automático ou a recuperação automática do grupo de instâncias gerenciadas remove a instância selecionada do grupo.
- Você remove o endpoint selecionado do NEG.
- Remova do serviço de back-end o grupo de instâncias ou o NEG que contém a instância ou o endpoint selecionado.
- A instância ou o endpoint de back-end selecionado precisa permanecer íntegro. A afinidade de sessão pode ser interrompida quando a instância ou o endpoint selecionado falha nas verificações de integridade.
O grupo de instâncias ou NEG que contém a instância ou o endpoint selecionado não pode estar cheio, conforme definido pela capacidade desejada. Para grupos gerenciados de instâncias regionais, o componente zonal do grupo de instâncias que contém a instância selecionada não pode estar cheio. A afinidade da 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. Como o nível de ocupação pode mudar de maneiras imprevisíveis ao usar o modo de balanceamento
UTILIZATION, use o modoRATEouCONNECTIONpara minimizar situações em que a afinidade da sessão pode ser interrompida.O número total de instâncias ou endpoints de back-end configurados precisa permanecer constante. Quando pelo menos um dos seguintes eventos ocorre, o número de instâncias ou endpoints de back-end configurados muda, e a afinidade da sessão pode ser interrompida:
Adicionar novas instâncias ou endpoints:
- Você adiciona instâncias a um grupo de instâncias atual no serviço de back-end.
- O escalonamento automático de grupos gerenciados de instâncias adiciona instâncias a um grupo gerenciado de instâncias no serviço de back-end.
- Você adiciona endpoints a um NEG atual no serviço de back-end.
- Adicione grupos de instâncias ou NEGs não vazios ao serviço de back-end.
Remover qualquer instância ou endpoint, não apenas a instância ou o endpoint selecionado:
- Você remove qualquer instância de um back-end de grupo de instâncias.
- O escalonamento automático ou a recuperação automática de um grupo de instâncias gerenciadas remove qualquer instância de um back-end grupo gerenciado de instâncias.
- Você remove qualquer endpoint de um back-end de 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 endpoints de back-end íntegros precisa permanecer constante. Quando pelo menos um dos seguintes eventos ocorre, o número de instâncias ou endpoints de back-end íntegros muda, e a afinidade da sessão pode ser interrompida:
- Qualquer instância ou endpoint passa na verificação de integridade, fazendo a transição de não íntegro para íntegro.
- Qualquer instância ou endpoint falha na verificação de integridade, passando de íntegro para não íntegro ou tempo limite.
Failover
Se um back-end não estiver íntegro, o tráfego será redirecionado automaticamente para back-ends íntegros.
A tabela a seguir descreve o comportamento de failover para balanceadores de carga de rede de proxy internos:
| Modo balanceador de carga | Comportamento de failover | Comportamento quando nenhum back-end estiver íntegro |
|---|---|---|
| Balanceador de carga de rede de proxy interno regional | O balanceador de carga implementa um algoritmo suave de failover por zona. Em vez de aguardar a integridade de todos os back-ends de uma zona, o balanceador de carga começa a redirecionar o tráfego para uma zona diferente quando a proporção de back-ends íntegros ou não íntegros em qualquer zona estiver abaixo de um determinado limite de porcentagem (70%. Esse limite não pode ser configurado). Se todos os back-ends em todas as zonas não estiverem íntegros, o balanceador de carga encerrará imediatamente a conexão do cliente. O proxy do Envoy envia o tráfego para back-ends íntegros em uma região com base na distribuição de tráfego configurada. |
Encerrar a conexão |
Balanceamento de carga para aplicativos do GKE
Se você estiver criando aplicativos no Google Kubernetes Engine (GKE), poderá usar NEGs zonais independentes para balancear a carga do tráfego diretamente para contêineres. Com NEGs independentes, você é responsável por criar o objeto Serviço que cria o NEG zonal e, em seguida, associar o NEG ao serviço de back-end para que o balanceador de carga possa se conectar aos pods.
Documentação relacionada do GKE:
Cotas e limites
Para informações sobre cotas e limites, consulte Cotas e limites.
Limitações
- O balanceador de carga de rede de proxy interno não é compatível com o tráfego IPv6.
- O balanceador de carga de rede de proxy interno não é compatível com implantações de VPC compartilhada, em que o front-end do balanceador de carga está em um projeto host ou de serviço e o serviço de back-end e os back-ends estão em outro projeto de serviço (também conhecido como referência de serviço entre projetos).
A seguir
Configure um balanceador de carga de rede de proxy interno regional com um back-end de NEG zonal
Configure um balanceador de carga de rede de proxy interno regional com um back-end de NEG híbrido