Neste documento, apresentamos os conceitos que você precisa entender para configurar um balanceador de carga de rede de proxy externo. Trusted Cloud
O balanceador de carga de rede proxy externo é um balanceador de carga de proxy reverso que distribui o tráfego TCP vindo da Internet para instâncias de máquina virtual (VM) na sua rede de nuvem privada virtual (VPC) doTrusted Cloud . Ao usar um balanceador de carga de rede de proxy externo, o tráfego de entrada TCP é encerrado no balanceador de carga. Uma nova conexão encaminha o tráfego para o back-end mais próximo.
Os balanceadores de carga de rede de proxy externo permitem que você use um único endereço IP para todos os usuários em todo o mundo. O balanceador de carga roteia automaticamente o tráfego para os back-ends mais próximos do usuário.
Esse balanceador de carga está disponível no modo regional e é chamado de balanceador de carga de rede de proxy regional externo. O balanceador de carga é implementado como um serviço gerenciado baseado no proxy Envoy de código aberto. O modo regional garante que todos os clientes e back-ends estejam 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
Os diagramas a seguir mostram os componentes dos balanceadores de carga de rede de proxy externo.
Regional
Este diagrama mostra os componentes de uma implantação do balanceador de carga de rede de proxy externo regional.
Veja a seguir os componentes dos balanceadores de carga de rede proxy externos.
Sub-rede somente proxy
A sub-rede somente proxy fornece um conjunto de endereços IP
que o Google usa para executar proxies Envoy em seu nome. É preciso criar uma sub-rede somente proxy em cada região de uma rede VPC em que você usa balanceadores de carga. A sinalização --purpose dessa sub-rede somente proxy está definida como
REGIONAL_MANAGED_PROXY. Todos os balanceadores de carga regionais baseados em
Envoy na mesma
região e rede VPC compartilham um pool de proxies do Envoy da
mesma sub-rede somente proxy.
As VMs de back-end ou os endpoints de todos os balanceadores de carga em uma região e rede VPC recebem conexões da sub-rede somente proxy.
Pontos a serem lembrados:
- As sub-redes somente proxy são usadas apenas para proxies Envoy, não para seus back-ends.
- O endereço IP do balanceador de carga não está localizado na sub-rede somente proxy. O endereço IP do balanceador de carga é definido pela regra de encaminhamento externo 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 que pode ser usado nos registros DNS para seu 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 que você reserve um endereço IP estático. Caso contrário, você precisará atualizar seu registro DNS com o endereço IP temporário recém-atribuído sempre que excluir uma regra de encaminhamento e criar uma nova.
Especificação da porta. As regras de encaminhamento externas usadas na definição desse balanceador de carga podem referenciar exatamente uma porta de 1 a 65535. Se você quiser aceitar várias portas consecutivas, precisará configurar várias regras de encaminhamento. É possível configurar várias regras de encaminhamento com o mesmo endereço IP virtual e portas diferentes. Portanto, é possível fazer proxy de vários aplicativos com portas personalizadas separadas para o mesmo endereço IP virtual do proxy TCP. Para mais detalhes, consulte Especificações de porta para regras de encaminhamento.
Para dar suporte a várias portas consecutivas, você precisa configurar várias regras de encaminhamento. É possível configurar várias regras de encaminhamento com o mesmo endereço IP virtual e portas diferentes. Portanto, é possível representar vários aplicativos com portas personalizadas separadas para o mesmo endereço IP virtual do proxy TCP.
A tabela a seguir mostra os requisitos da regra de encaminhamento para balanceadores de carga de rede de proxy externos.
| Modo balanceador de carga | Nível de serviço de rede | Regra de encaminhamento, endereço IP e esquema de balanceamento de carga | Como rotear da Internet para o front-end do balanceador de carga |
|---|---|---|---|
| Balanceador de carga de rede de proxy externo regional | Nível Premium | Regra de encaminhamento externo regional Esquema de balanceamento de carga: |
Solicitações encaminhadas para os proxies do Envoy 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 externo regional | A rede VPC da regra de encaminhamento é a rede em que a sub-rede somente proxy foi criada. Você especifica a rede ao criar a regra de encaminhamento. |
Proxies de destino
Os balanceadores de carga de rede de proxy externo encerram as conexões do cliente e criam novas conexões com os back-ends. O proxy de destino roteia essas novas conexões para o serviço de back-end.
Por padrão, o proxy de destino não preserva o endereço IP original do cliente e as informações da porta. É possível preservar essas informações ativando o protocolo PROXY no proxy de destino.
A tabela a seguir mostra os requisitos de proxy de destino para balanceadores de carga de rede de proxy externos.
| Modo balanceador de carga | Nível de serviço de rede | Proxy de destino |
|---|---|---|
| Balanceador de carga de rede de proxy externo regional | Nível Premium e Standard | regionTargetTcpProxies |
Serviços de back-end
Os serviços de back-end direcionam o tráfego de entrada para um ou mais back-ends anexados. Cada back-end é composto de um grupo de instâncias ou grupo de endpoint da rede e informações sobre a capacidade de serviço do back-end. A capacidade de exibição do back-end pode ser baseada em CPU ou solicitações por segundo (RPS, na sigla em inglês).
Cada balanceador de carga tem um único recurso de serviço de back-end que especifica a verificação de integridade a ser realizada para os back-ends disponíveis.
As alterações no serviço de back-end não são instantâneas. Pode levar vários minutos para que as alterações sejam propagadas para os GFEs. Para garantir o mínimo possível de interrupções aos usuários, ative a diminuição das conexões 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.
Para mais informações sobre o recurso de serviço de back-end, consulte Visão geral dos serviços de back-end.
A tabela a seguir especifica os diferentes back-ends aceitos no serviço de back-end dos balanceadores de carga de rede de proxy externos.
| 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 externo regional | Endpoints do tipo GCE_VM_IP_PORT |
Somente NEGs regionais | |||||
Back-ends e redes VPC
Para back-ends de balanceadores de carga de rede de proxy externo regional, o seguinte se aplica:
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 do proxy de rede externo, 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 externos só aceitam TCP para se comunicar com os back-ends.
Regras de firewall
As seguintes regras de firewall são obrigatórias:
Para balanceadores de carga de rede de proxy externo regional, uma regra de firewall de entrada para permitir que o tráfego da sub-rede somente proxy alcance seus back-ends.
Uma regra de firewall de entrada
allowpara permitir que o tráfego dos intervalos de sondagem de verificação de integridade alcance seus back-ends. Saiba mais sobre sondagens de verificação de integridade e por que é necessário permitir tráfego delas em Intervalos de IP de sondagem e regras de firewall.
As regras de firewall são implementadas no nível da instância da VM, não no nível dos proxies do GFE. Não é possível usar regras de firewall para impedir que o tráfego chegue ao balanceador de carga.
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 de porta podem variar entre grupos de instâncias atribuídos ao mesmo serviço de back-end.
- Para back-ends NEG de
GCE_VM_IP_PORT NEG: permite tráfego para os números de portas dos endpoints.
Endereços IP de origem
O endereço IP de origem dos pacotes, como visto pelos back-ends, não é o endereço IP externo do balanceador de carga.Trusted Cloud Em outras palavras, há duas conexões TCP:
Para os balanceadores de carga de rede de proxy externo regionais:Conexão 1, do cliente original para o balanceador de carga (sub-rede somente proxy):
- Endereço IP de origem: o cliente original (ou endereço IP externo se o cliente estiver atrás de um gateway NAT ou um proxy de encaminhamento).
- Endereço IP de destino: o endereço IP do seu balanceador de carga.
Conexão 2, do balanceador de carga (sub-rede somente proxy) para o endpoint ou a VM de back-end:
Endereço IP de origem: um endereço IP na sub-rede somente proxy compartilhado entre todos os balanceadores de carga baseados em Envoy implantados na mesma região e rede que o balanceador de carga.
Endereço IP de destino: o endereço IP interno da VM ou contêiner de back-end na rede VPC.
Portas abertas
Balanceadores de carga de rede de proxy externo são balanceadores de carga de proxy reverso. O balanceador de carga encerra as conexões de entrada e depois abre novas conexões do balanceador de carga para os back-ends. Esses balanceadores de carga são implementados usando proxies do Google Front End (GFE) em todo o mundo.
Os GFEs têm várias portas abertas para oferecer suporte a outros serviços do Google, executados na mesma arquitetura. Ao executar uma verificação de portas, é possível ver outras portas abertas para outros serviços do Google em execução nos GFEs.
Executar uma verificação de porta no endereço IP de um balanceador de carga baseado no GFE não é útil do ponto de vista de auditoria pelos seguintes motivos:
Uma verificação de porta (por exemplo, com
nmap) geralmente não espera nenhum pacote de resposta ou um pacote TCP RST ao realizar a sondagem de TCP SYN. Os GFEs enviam pacotes SYN-ACK em resposta a sondagens SYN apenas para portas em que você configurou uma regra de encaminhamento. Os GFEs só enviam pacotes para os back-ends em resposta aos enviados para o endereço IP do balanceador de carga e para a porta de destino configurada na regra de encaminhamento. Os pacotes enviados para um endereço IP ou uma porta diferente não são enviados para os back-ends.Os GFEs implementam recursos de segurança, como o Google Cloud Armor. Com o Cloud Armor Standard, os GFEs oferecem proteção sempre ativada contra ataques DDoS volumétricos e baseados em protocolo e inundações de SYN. Essa proteção está disponível mesmo que você não tenha configurado explicitamente o Cloud Armor. Você só vai receber cobranças se configurar políticas de segurança ou se inscrever no Managed Protection Plus.
Os pacotes enviados para o endereço IP do balanceador de carga podem ser respondidos por qualquer GFE na frota do Google. No entanto, a verificação de uma combinação de endereço IP e porta de destino do balanceador de carga interroga apenas um único GFE por conexão TCP. O endereço IP do seu balanceador de carga não é atribuído a um único dispositivo ou sistema. Portanto, a verificação do endereço IP de um balanceador de carga baseado em GFE não verifica todos os GFEs na frota do Google.
Com isso em mente, veja a seguir algumas maneiras mais eficazes de auditar a segurança das instâncias de back-end:
Um auditor de segurança precisa inspecionar a configuração das regras de encaminhamento para a configuração do balanceador de carga. As regras de encaminhamento definem a porta de destino para a qual o balanceador de carga aceita pacotes e os encaminha para os back-ends. Para balanceadores de carga baseados em GFE, cada regra de encaminhamento externo só pode referir-se a uma única porta TCP de destino.
Um auditor de segurança deve inspecionar a configuração da regra de firewall aplicável às VMs de back-end. As regras de firewall definidas bloqueiam o tráfego dos GFEs para as VMs de back-end, mas não bloqueiam o tráfego de entrada para os GFEs. Para ver as práticas recomendadas, consulte a seção de regras de firewall.
Arquitetura da VPC compartilhada
Os balanceadores de carga de rede de proxy externos regionais aceitam implantações que usam redes VPC compartilhadas. 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 externo precisa ser definido no mesmo projeto que o balanceador de carga. | A regra de encaminhamento externo precisa ser definida no mesmo projeto que as instâncias de back-end (o projeto de serviço). | O proxy TCP de destino precisa ser definido no mesmo projeto que as instâncias de back-end. |
Para balanceadores de carga de rede de proxy externo regional, as VMs de back-end geralmente 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
Ao adicionar um grupo de instâncias de back-end ou NEG a um serviço de back-end, você especifica um modo de balanceamento, que define um método para medir a carga de back-end e a capacidade de destino.
Para balanceadores de carga de rede de proxy externo, o modo de balanceamento pode ser CONNECTION ou UTILIZATION:
- Se o modo de balanceamento de carga for
CONNECTION, a carga será distribuída com base no número total de conexões que o back-end pode processar. - Se o modo de balanceamento de carga for
UTILIZATION, a carga será distribuída com base na utilização das instâncias em um grupo. Esse modo de balanceamento se aplica apenas a back-ends de grupos de instâncias de VMs.
A distribuição do tráfego entre back-ends é determinada pelo modo de balanceamento do balanceador de carga.
Balanceador de carga de rede de proxy externo regional
Para balanceadores de carga de rede externos regionais, a distribuição de tráfego é baseada no modo de balanceamento de carga e na política de localidade do balanceamento de carga.
O modo de balanceamento determina o peso/fração de tráfego que precisa ser enviada para cada back-end
(grupo de instâncias ou NEG). A política de localidade do balanceamento de carga
(LocalityLbPolicy) determina como os back-ends do grupo são balanceados por carga.
Quando um serviço de back-end recebe tráfego, ele direciona primeiro o tráfego para um back-end (grupo de instâncias ou NEG) de acordo com o modo de balanceamento. Depois que um back-end é selecionado, o tráfego é distribuído entre as instâncias ou os endpoints do grupo, de acordo com a política de localidade do balanceamento de carga.
Para ver mais informações, consulte os seguintes tópicos:
- Modos de balanceamento
- Política de localidade do balanceamento de carga (documentação da API de 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 externo 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.
- Para balanceadores de carga de rede de proxy externos globais e clássicos, a afinidade da sessão pode ser interrompida se um Google Front End (GFE) de primeira camada diferente for usado para solicitações ou conexões subsequentes após a mudança no caminho de roteamento. Um GFE de primeira camada diferente pode ser selecionado se o caminho de roteamento de um cliente na Internet para o Google mudar entre solicitações ou conexões.
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
O failover para balanceadores de carga de rede de proxy externos funciona da seguinte maneira:
- Se um back-end se tornar não íntegro, o tráfego será redirecionado automaticamente para back-ends íntegros na mesma região.
- Se nenhum back-end estiver íntegro, o balanceador de carga descartará o tráfego.
Balanceamento de carga para aplicativos do GKE
Se você estiver criando aplicativos no Google Kubernetes Engine, poderá usar NEGs independentes para balancear a carga do tráfego diretamente para contêineres. Com os NEGs independentes, você é responsável por criar o objeto Serviço que cria o NEG e, em seguida, associar o NEG ao serviço de back-end para que o balanceador de carga possa conectar aos pods.
Para documentação relacionada, consulte Balanceamento de carga nativo de contêiner por meio de NEGs zonais independentes.
Limitações
Não é possível criar um balanceador de carga de rede de proxy externo regional no nível Premium usando o Trusted Cloud console. Use a CLI gcloud ou a API.
Trusted Cloud não oferece garantias sobre o tempo de vida das conexões TCP quando você usa balanceadores de carga de rede de proxy externo. Os clientes precisam ser resilientes a quedas de conexão, tanto devido a problemas mais amplos da Internet quanto a reinicializações programadas regularmente dos proxies que gerenciam as conexões.
A seguir
- Configure um balanceador de carga de rede de proxy externo regional (proxy TCP).
- Geração de registros e monitoramento do balanceador de carga de rede.