Conceitos do balanceamento de carga HTTP(S) interno

O balanceamento de carga HTTP(S) interno é um balanceador de carga regional da camada 7 baseado em proxy que permite executar e escalonar seus serviços atrás de um endereço IP de balanceamento de carga particular que seja acessível apenas na região do balanceador de carga na rede VPC.

Visão geral

O balanceamento de carga HTTP(S) interno do Google Cloud Platform (GCP) é um balanceador de carga HTTP e HTTPS particular e com base em proxy. Ele distribui o tráfego para as instâncias de back-end da VM ou para endpoints em grupos de endpoints da rede (NEGs, na sigla em inglês) em uma única região da sua rede VPC usando um mapa de URL. O balanceador de carga só pode ser acessado na região escolhida de sua rede VPC em um endereço IP particular interno (RFC 1918).

Para informações sobre como um balanceador de carga HTTP(S) interno se compara a outros do GCP, consulte Como escolher um balanceador de carga.

Tipos de tráfego, esquema e escopo

Um balanceador de carga HTTP(S) interno é definido por um único mapa de URL, que faz referência a um ou mais serviços de back-end com um esquema de balanceamento de carga gerenciado interno. Cada serviço de back-end é compatível com um dos seguintes protocolos: HTTP, HTTPS ou HTTP/2, além VMs de backend ou endpoints em um grupo de endpoints da rede (NEG, na sigla em inglês).

Como o escopo de um balanceador de carga HTTP(S) interno é regional, e não global, os clientes e as VMs de back-end ou os endpoints precisam estar na mesma região. Os clientes em redes conectadas podem usar um túnel do Cloud VPN ou um anexo do Cloud Interconnect na mesma região do balanceador de carga.

Diagrama de alto nível

Cada balanceador de carga HTTP(S) interno tem um endereço IP particular que atua como o front-end para seus endpoints ou VMs de back-end. As solicitações internas de clientes permanecem internas na sua rede e região.

Serviços internos com balanceamento de carga baseado na camada 7 (clique para ampliar)
Serviços internos com balanceamento de carga baseado na camada 7 (clique para ampliar)

Casos de uso

Serviços

Um caso de uso comum é o tráfego de balanceamento de carga entre os serviços. Neste exemplo, o usuário recebe conteúdo de vídeo e imagem usando o mesmo URL de base, mygcpservice.internal, com os caminhos /video e /images.

O mapa de URL do balanceador de carga HTTP interno direciona o tráfego para um serviço de back-end de video e outro serviço de back-end de images, com base no correspondente de caminho do mapa de URL.

O diagrama a seguir mostra três serviços: vídeo, imagens e pagamentos.

Serviços internos (micro) com balanceamento de carga baseado na camada 7 (clique para ampliar)
Serviços internos (micro) com balanceamento de carga baseado na camada 7 (clique para ampliar)

Serviços da web de três camadas

Use o balanceamento de carga HTTP(S) interno para dar suporte a serviços da web de três camadas tradicionais.

No diagrama a seguir, cada camada é escalonada por um tipo de balanceador de carga diferente:

O diagrama mostra três tipos de balanceadores de carga do GCP.

  1. Um balanceador de carga HTTP(S) externo e global distribui o tráfego da Internet para um conjunto de grupos de instâncias de front-end da Web em várias regiões.
  2. Esses front-ends enviam o tráfego HTTP(S) para um conjunto de balanceadores de carga HTTP(S), regionais e internos (o assunto desta visão geral).
  3. Os balanceadores de carga HTTP(S) distribuem o tráfego para grupos de instâncias de middleware.
  4. Essas instâncias de middleware enviam o tráfego para balanceadores de carga TCP/UDP internos, que equilibram a carga do tráfego para clusters de armazenamento de dados.
Roteamento baseado na camada 7 para camadas internas em aplicativos de várias camadas (clique para ampliar)
Roteamento baseado na camada 7 para camadas internas em aplicativos de várias camadas (clique para ampliar)

Arquitetura e recursos

Um front-end interno do balanceador de carga HTTP(S) consiste em um endereço IP interno, uma regra de encaminhamento interna e um proxy HTTP ou HTTPS de destino. Um único mapa de URL direciona o tráfego para um ou mais serviços de back-end com um esquema de balanceamento de carga de INTERNAL_MANAGED. Cada serviço de back-end distribui o tráfego entre os grupos de instância ou os NEGs de back-end de acordo com um modo de balanceamento configurável. Em cada grupo de instância ou NEG, o tráfego é distribuído ainda mais de acordo com uma política configurável. Consulte a distribuição de tráfego para detalhes sobre como isso funciona.

Cada serviço de back-end é regional. Todos os back-ends de um determinado serviço precisam ser grupos de instâncias ou NEGs. Grupos de instâncias não gerenciadas, grupos de instâncias zonais gerenciadas e grupos de instâncias regionais gerenciadas são compatíveis.

O diagrama a seguir mostra os recursos do GCP exigidos para um balanceador de carga HTTP(S) interno.

Componentes do balanceamento de carga HTTP(S) interno (clique para ampliar)
Componentes do balanceamento de carga HTTP(S) interno (clique para ampliar)

Os recursos a seguir definem um balanceador de carga HTTP(S) interno:

  • Uma regra de encaminhamento interno regional, que especifica o endereço IP interno e a porta do balanceador de carga (o endereço usado quando clientes se conectam a ele), além do proxy de destino, para onde cada solicitação recebida é encaminhada.

  • Um proxy HTTP(S) de destino regional recebe uma solicitação do usuário e a encaminha ao mapa de URL. Um proxy HTTPS de destino é compatível com até um número documentado de certificados SSL que permitem que o proxy prove sua identidade para os clientes.

  • Um mapa de URLs regional analisa o URL de uma solicitação e encaminha solicitações para serviços de back-end específicos com base no host e no caminho do URL de solicitação.

  • Um serviço de back-end regional distribui solicitações para back-ends íntegros (grupos de instâncias ou NEGs).

  • Uma verificação de integridade regional informa a disponibilidade dos back-ends.

  • Um ou mais back-ends precisam estar conectados ao serviço de back-end. Os back-ends podem ser dos seguintes tipos:

    • Grupos de instâncias gerenciadas (zonais ou regionais)
    • Grupos de instâncias não gerenciadas (zonais)
    • Grupos de endpoints de rede (zonais)

    Não é possível usar grupos de instâncias e NEGs no mesmo serviço de back-end.

  • Uma sub-rede somente proxy com endereços IP que dão origem ao tráfego do balanceador de carga para os back-ends. É preciso criar uma sub-rede somente proxy em cada região de uma rede VPC. Nela, é possível usar balanceadores de carga HTTP(S) internos. Essa sub-rede é compartilhada por todos os balanceadores de carga HTTP(S) internos na região.

  • Um firewall para que seus back-ends aceitem conexões da sub-rede somente proxy. Consulte o exemplo em Como configurar regras de firewall.

Limitações

  • O balanceamento de carga HTTP(S) interno opera em um nível regional. Não há garantia de que uma solicitação de um cliente em uma zona da região seja enviada para um back-end que esteja na mesma zona que o cliente. A afinidade da sessão não reduz a comunicação entre as zonas.

  • O balanceamento de carga de HTTP(S) interno não é compatível com os seguintes recursos:

  • O balanceamento de carga de HTTP(S) interno não é compatível com peering de rede VPC. Se você precisar de um balanceador de carga interno que seja compatível com o peering de rede VPC, use o balanceamento de carga TCP/UDP interno.

  • O protocolo WebSocket não é compatível.

  • O GCP não avisará você se sua sub-rede somente proxy estiver sem endereços IP.

A seguir

  • Para informações sobre como configurar o balanceamento de carga HTTP(S) interno, consulte esta página.
  • Para informações sobre como gerenciar o recurso de sub-rede somente proxy exigido pelo balanceamento de carga HTTP(S) interno, consulte esta página.
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…