O balanceador de carga de rede de proxy interno do Google Cloud é um balanceador de carga baseado no software de código aberto do proxy Envoy e na 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 à sua 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 no Google Cloud, 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
É possível configurar um balanceador de carga de rede de proxy interno nos seguintes modos:
Balanceador de carga de rede de proxy interno regional Esse é um balanceador de carga regional que é implementado como um serviço gerenciado no proxy Envoy de código aberto. O modo regional garante que todos os clientes e back-ends sejam de uma região específica, o que ajuda quando você precisa de conformidade regional.
Balanceador de carga de rede de proxy interno entre regiões Trata-se de um balanceador de carga multirregional que é implementado como um serviço gerenciado, baseado no proxy Envoy de código aberto. O modo entre regiões permite balancear a carga do tráfego para serviços de back-end distribuídos globalmente, incluindo o gerenciamento de tráfego, que garante que o tráfego seja direcionado para o back-end mais próximo. Esse balanceador de carga também possibilita a alta disponibilidade. Colocar back-ends em várias regiões ajuda a evitar falhas em uma única região. Se os back-ends de uma região estiverem inativos, o tráfego poderá fazer failover para outra região.
A seguinte tabela descreve diferenças importantes entre os modos regional e entre regiões:
Recurso Balanceador de carga de rede de proxy interno regional Balanceador de carga de rede de proxy interno entre regiões Endereço IP virtual (VIP) do balanceador de carga. Alocação por meio de uma sub-rede em uma região específica do Google Cloud. Alocação por meio de uma sub-rede em uma região específica do Google Cloud. Endereços VIP de várias regiões podem compartilhar o mesmo serviço de back-end global.
Acesso de cliente Por padrão, não é acessível globalmente.
Como opção, é possível ativar o acesso global.Sempre acessível globalmente. Clientes de qualquer região do Google Cloud podem enviar tráfego ao balanceador de carga. Back-ends com carga balanceada Back-ends regionais.
O balanceador de carga só pode enviar tráfego para back-ends que estejam na mesma região que o proxy associado a ele.Back-ends globais.
O balanceador de carga pode enviar tráfego para back-ends em qualquer região.Alta disponibilidade e failover Failover automático em back-ends íntegros na mesma região. Failover automático em back-ends íntegros na mesma região ou em regiões diferentes.
Identificar o modo
console do Cloud
No Console do Google Cloud, acesse a página Balanceamento de carga.
Na guia Balanceadores de carga, você verá o tipo do balanceador de carga, o protocolo e a região. Se a região estiver em branco, o balanceador de carga estará no modo entre regiões. Veja na tabela a seguir como identificar o modo do balanceador de carga.
Modo balanceador de carga Tipo do balanceador de carga Tipo de acesso Região Balanceador de carga de rede de proxy interno regional Rede (proxy) Interno Especifica uma região Balanceador de carga de rede de proxy interno entre regiões Rede (proxy) Interno
gcloud
Para determinar o modo de um balanceador de carga, execute o seguinte comando:
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
Na saída do comando, verifique o esquema de balanceamento de carga, a região e o nível da rede. Veja na tabela a seguir como identificar o modo do balanceador de carga.
Modo balanceador de carga Esquema de balanceamento de carga Regra de encaminhamento Balanceador de carga de rede de proxy interno regional INTERNAL_MANAGED Regional Balanceador de carga de rede de proxy interno entre regiões INTERNAL_MANAGED Global
Arquitetura
O diagrama a seguir mostra os recursos do Google 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.
Entre regiões
Este diagrama mostra os componentes de uma implantação de balanceador de carga de rede proxy interno entre regiões no nível Premium na mesma rede VPC. Cada regra de encaminhamento global conta com um endereço IP regional que os clientes usam para se conectar.
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 |
Balanceador de carga de rede de proxy interno entre regiões |
Balanceadores de carga regionais e entre regiões não podem compartilhar as mesmas sub-redes O balanceador de carga entre regiões baseado no Envoy precisa ter uma sub-rede somente proxy em cada região em que está configurado. Os proxies do balanceador de carga entre regiões na mesma região e rede 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
|
É possível ativar o acesso global para permitir que clientes de qualquer região acessem o balanceador de carga. Os back-ends também precisam estar na mesma região que o balanceador de carga. |
Balanceador de carga de rede de proxy interno entre regiões |
Esquema de balanceamento de carga:
Sub-rede somente proxy
Endereço IP
|
O acesso global é ativado por padrão para permitir que clientes de qualquer região acessem o balanceador de carga. Os back-ends podem estar em várias regiões. |
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 em que uma sub-rede somente proxy foi criada. 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 |
Balanceador de carga de rede de proxy interno entre regiões | targetTcpProxies global |
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 |
Balanceador de carga de rede de proxy interno entre regiões | backendServices global |
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 | NEGs do Private Service Connect | GKE | |
Balanceador de carga de rede de proxy interno regional | Endpoints do tipo GCE_VM_IP_PORT |
Somente NEGs regionais | Adicionar um NEG do Private Service Connect | ||||
Balanceador de carga de rede de proxy interno entre regiões | Endpoints do tipo GCE_VM_IP_PORT |
Adicionar um NEG do Private Service Connect |
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 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.
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. Esse recurso está em Pré-lançamento. 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, anexos da VLAN do Cloud Interconnect ou um framework do Network Connectivity Center.
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
nic0
da 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.
- A rede VPC do back-end e a rede VPC da regra de encaminhamento precisam ser spokes VPC no mesmo hub do Network Connectivity Center. Os filtros de importação e exportação precisam permitir a comunicação entre a sub-rede somente proxy na rede VPC da regra de encaminhamento e as sub-redes usadas por 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 várias placas de rede (NIC), 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 o 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 Recursos de balanceamento 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 |
Balanceador de carga de rede de proxy interno entre regiões | healthChecks global |
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.
35.191.0.0/16
130.211.0.0/22
2600:2d00:1:b029::/64
- 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
: permite tráfego para os números de portas dos endpoints.
Há algumas exceções aos requisitos de regras de firewall para esses balanceadores de carga:
- Não é necessário adicionar intervalos de sondagem de verificação de integridade do Google à lista de permissões 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 usar lista de permissões dos intervalos de sondagem de verificação de integridade do Google para 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 o Cloud NAT para saída.
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 internos regionais, os clientes precisam estar, por padrão, na mesma região que o balanceador de carga. É possível ativar o acesso global para permitir que os clientes de qualquer região acessem o balanceador de carga.
Para balanceadores de carga de rede de proxy internos entre regiões, o acesso global é ativado por padrão. Clientes de qualquer região podem acessar o balanceador de carga.
A tabela a seguir resume o acesso do cliente aos balanceadores de carga de rede de proxy interno regionais:
Acesso global desativado | Acesso global ativado |
---|---|
Os clientes precisam estar na mesma região que o balanceador de carga. Também precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando o peering da rede VPC. | Os clientes podem estar em qualquer região. Ainda precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando peering da rede VPC. |
Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos precisam estar na mesma região do balanceador de carga. | Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos podem estar em qualquer região. |
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
localityLbPolicy
na documentação da API do serviço de back-end regional.
Afinidade da sessão
Afinidade da sessão permite 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 o back-end esteja íntegro e tenha capacidade.
O balanceador de carga de rede de proxy interno oferece afinidade de IP do cliente, que 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.
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 o fim da 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. Limite não é configurável de 70%. 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 |
Balanceador de carga de rede de proxy interno entre regiões | Failover automático para back-ends íntegros na mesma região ou em outras regiões. O tráfego é distribuído entre back-ends íntegros que abrangem várias regiões 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, poderá usar NEGs zonais 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 zonal e, em seguida, associar o NEG ao serviço de back-end para que o balanceador de carga possa conectar aos pods.
Documentação relacionada do GKE:
Cotas e limites
Para informações sobre cotas e limites, consulte Cotas para recursos de balanceamento de carga.
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