Conceitos de balanceamento de carga TCP/UDP interno

O balanceamento de carga TCP/UDP interno é um balanceador de carga regional que permite executar e escalonar seus serviços por meio de um endereço IP de balanceamento de carga privado, acessível apenas às suas instâncias internas de máquina virtual.

Visão geral

O balanceamento de carga TCP/UDP interno do Google Cloud Platform (GCP) distribui o tráfego entre instâncias de VM da mesma região em uma rede VPC, usando um endereço IP privado interno (RFC 1918).

Como pode ser visto no diagrama de alto nível a seguir, um serviço de balanceamento de carga TCP/UDP interno tem um front-end (a regra de encaminhamento) e um back-end (o serviço de back-end e os grupos de instâncias).

Exemplo de balanceador de carga TCP/UDP interno de alto nível (clique para ampliar)
Exemplo de balanceador de carga TCP/UDP interno de alto nível (clique para ampliar)

Protocolos, esquema e escopo

Cada balanceador de carga TCP/UDP interno é compatível com tráfego TCP ou UDP (não ambos).

Um balanceador de carga TCP/UDP interno usa um único serviço de back-end com um esquema de balanceamento de carga interno. O significado disso é que ele equilibra o tráfego dentro do GCP nas suas instâncias. Não é possível usá-lo para equilibrar o tráfego originado da Internet.

O escopo de um balanceador de carga TCP/UDP interno é regional e não global. Isto é, significa que um balanceador de carga TCP/UDP interno não pode abranger várias regiões. Em uma única região, o balanceador de carga atende a todas as zonas. Consulte Regiões e Zonas.

Consulte Como escolher um balanceador de carga e Visão geral do balanceamento de carga para ver informações sobre como os balanceadores de carga do Cloud diferem uns dos outros.

Casos de uso

Exemplos de acesso

É possível acessar um balanceador de carga TCP/UDP interno na rede VPC de uma rede conectada usando:

  • Peering de rede VPC
  • Cloud VPN e Cloud Interconnect

Para ver exemplos detalhados, consulte Balanceamento de carga TCP/UDP interno e Redes conectadas.

Exemplo de serviço da Web de três camadas

O balanceamento de carga TCP/UDP interno pode ser usado com outros balanceadores de carga, como balanceadores de carga HTTP. Nesse caso, o balanceador de carga externo é usado pela camada da Web que, posteriormente, usa os serviços do balanceador de carga interno.

O diagrama a seguir descreve um exemplo de uma configuração de três camadas em que são usados balanceadores de carga HTTP(S) externo e TCP/UDP interno:

Aplicativo da Web de três camadas com balanceamento de carga de HTTP(S) e balanceamento de carga TCP/UDP interno (clique para ampliar)
Aplicativo da Web de três camadas com balanceamento de carga de HTTP(S) e balanceamento de carga TCP/UDP interno (clique para ampliar)

Como funciona o balanceamento de carga TCP/UDP interno

O balanceamento de carga TCP/UDP interno tem as seguintes características:

  • O balanceador de carga é um serviço gerenciado.
  • O balanceador de carga não é um proxy.
  • Ele é implementado em redes virtuais.
  • Não há dispositivo intermediário ou ponto único de falha.
  • As respostas das VMs de back-end são enviadas diretamente aos clientes e não voltam pelo balanceador de carga.

O balanceamento de carga TCP/UDP interno não encerra conexões de clientes, diferentemente de um balanceador de carga baseado em dispositivo ou instância. Em vez de o tráfego ser enviado para um balanceador de carga e depois para os back-ends, o tráfego é enviado diretamente para os back-ends. O ambiente de convidado do GCP, Linux ou Windows, configura cada VM de back-end com o endereço IP do balanceador de carga e a rede virtual do GCP gerencia o fornecimento de tráfego e faz o escalonamento da maneira adequada.

Arquitetura

Um balanceador de carga TCP/UDP interno com vários grupos de instâncias de back-end distribui conexões entre VMs de back-end em todos esses grupos de instâncias. Para ver detalhes sobre o método de distribuição e suas opções de configuração, consulte a distribuição de tráfego.

Exceto os "Grupos de endpoints de rede" (NEGs, na sigla em inglês), qualquer outro tipo de grupo de instâncias pode ser usado como back-end do balanceador de carga: grupos de instâncias não gerenciadas, grupos de instâncias gerenciadas por zona ou grupos de instâncias gerenciadas por região.

Em Alta disponibilidade, você encontra instruções sobre como projetar um balanceador de carga interno que não dependa de uma única zona.

As instâncias que participam como VMs de back-end para balanceadores de carga TCP/UDP internos precisam executar o Ambiente de convidado Linux, o ambiente de convidado do Windows ou outros processos que ofereçam funcionalidades equivalentes. É preciso que esse ambiente de convidado possa entrar em contato com o servidor metadata.google.internal, 169.254.169.254 para que ele gere rotas locais e aceitar o tráfego enviado ao endereço IP interno do balanceador de carga.

Neste diagrama, ilustramos a distribuição de tráfego entre VMs localizadas em dois grupos de instâncias separados. O tráfego enviado da instância do cliente para o endereço IP do balanceador de carga (10.10.10.9) é distribuído entre as VMs de back-end em qualquer um dos grupos de instâncias. As respostas enviadas de qualquer uma das VMs de back-end exibidas são entregues diretamente à VM cliente.

O balanceamento de carga TCP/UDP interno pode ser usado com uma rede VPC de modo personalizado ou modo automático. Também é possível criar balanceadores de carga TCP/UDP internos com uma rede legada atual.

Somente VMs cliente na região podem acessar o balanceador de carga TCP/UDP interno. Para enviar pacotes a um balanceador de carga TCP/UDP interno, as VMs cliente estejam na mesma rede VPC precisam estar localizadas na mesma região, mas não necessariamente na mesma sub-rede. Também é possível se comunicar com um balanceador de carga TCP/UDP interno de um sistema cliente em uma rede diferente, desde que a outra rede esteja corretamente conectada à rede VPC em que o balanceador de carga está definido. Consulte Balanceamento de carga TCP/UDP interno e Redes conectadas.

Alta disponibilidade

Por design, o balanceador de carga TCP/UDP interno tem alta disponibilidade. Não há etapas especiais para tornar o balanceador de carga altamente disponível, uma vez que o mecanismo não depende de um único dispositivo ou de uma instância de VM.

Nas seguintes práticas recomendadas, descrevemos como implantar instâncias de VM de back-end para que você não dependa de uma única zona:

Componentes

Um balanceador de carga TCP/UDP interno tem os seguintes componentes do GCP.

Componente Motivo Requisitos
Endereço IP interno Este é o endereço do balanceador de carga. É preciso que o endereço IP interno esteja na mesma sub-rede que a regra de encaminhamento interno. É preciso que a sub-rede esteja na mesma região do serviço de back-end.
Regra de encaminhamento interno Uma regra de encaminhamento interno, combinada ao endereço IP interno, é o front-end do balanceador de carga. Ela define o protocolo e as portas que o balanceador de carga aceita e direciona o tráfego para um serviço de back-end interno regional. As regras de encaminhamento para balanceadores de carga TCP/UDP internos precisam:
• Ter um load-balancing-scheme de INTERNAL
• Usar um ip-protocol de TCP ou UDP, correspondente ao protocol do serviço de back-end
• Referenciar uma subnet na rede VPC na mesma região do serviço de back-end
Serviço de back-end interno regional O serviço de back-end interno regional define o protocolo usado para a comunicação com os back-ends (grupos de instâncias) e especifica uma verificação de integridade. Os back-ends podem ser grupos de instâncias não gerenciadas, grupos de instâncias gerenciadas por zona ou grupos de instâncias gerenciadas por região. O serviço de back-end precisa:
• Ter um load-balancing-scheme de INTERNAL
• Usar um protocol de TCP ou UDP, correspondente ao protocol da regra de encaminhamento
• Ter uma verificação de integridade associada
• Ter back-ends de referência na mesma região. Os grupos de instâncias de back-end podem estar em qualquer sub-rede da região. O serviço de back-end em si não está vinculado a uma sub-rede específica.
Verificação de integridade Cada serviço de back-end precisa ter uma verificação de integridade associada. A verificação de integridade define os parâmetros sob os quais o GCP considera os back-ends que gerencia para se qualificar para receber tráfego. Somente VMs íntegras nos grupos de instâncias de back-end receberão tráfego enviado de VMs cliente para o endereço IP do balanceador de carga. A regra de encaminhamento e o serviço de back-end podem usar TCP ou UDP, mas o GCP não tem uma verificação de integridade para o tráfego UDP. Para saber mais informações, consulte verificações de integridade e tráfego UDP.

Endereço IP interno

O balanceamento de carga TCP/UDP interno usa um endereço IPv4 interno (privado, RFC 1918) do intervalo de IP principal da sub-rede que você selecionou ao criar a regra de encaminhamento interno. O endereço IP não pode ser de um intervalo de IP secundário da sub-rede.

Especifique o endereço IP de um balanceador de carga TCP/UDP interno ao criar a regra de encaminhamento. Opte por receber um endereço IP temporário ou usar um endereço IP reservado.

Regras de encaminhamento

O balanceamento de carga TCP/UDP interno requer pelo menos uma regra de encaminhamento interno em uma sub-rede, na mesma região do serviço de back-end e dos grupos de instâncias. Uma regra de encaminhamento interno precisa estar na mesma região e usar o mesmo protocolo do serviço de back-end do balanceador de carga.

É na regra de encaminhamento que você define as portas em que o balanceador de carga aceita tráfego. Os balanceadores de carga TCP/UDP internos não são proxies. Eles passam tráfego para back-ends na mesma porta em que o tráfego é recebido. É preciso especificar pelo menos um número de porta por regra de encaminhamento.

Além das portas, você precisa fazer referência a uma sub-rede específica na sua rede VPC ao criar uma regra de encaminhamento interno. A sub-rede especificada para a regra de encaminhamento não precisa ser nenhuma das sub-redes usadas pelas VMs de back-end, mas a regra de encaminhamento, a sub-rede e o serviço de back-end precisam estar na mesma região. Quando você cria uma regra de encaminhamento interno, o GCP escolhe um endereço IP interno do intervalo de endereços IP principal da sub-rede selecionada. Como alternativa, especifique um endereço IP interno no intervalo do IP principal da sub-rede.

Regras de encaminhamento e especificações de porta

Ao criar uma regra de encaminhamento interno, escolha uma das seguintes especificações de porta:

  • Especifique pelo menos uma e até cinco portas, por número.
  • Especifique ALL para encaminhar tráfego em todas as portas.

Crie uma regra de encaminhamento interno que dê suporte a todas as portas para encaminhar todo o tráfego de um determinado protocolo (como TCP) a um único balanceador de carga interno. Isso permite que VMs de back-end executem vários aplicativos, um por porta. O tráfego enviado para uma determinada porta é entregue ao aplicativo correspondente e todos os aplicativos usam o mesmo endereço IP.

Se você estiver preocupado com a abertura de aplicativos de back-end para todas as portas, implante regras de firewall nas VMs de back-end para definir o escopo do tráfego recebido para as portas esperadas.

Não é possível modificar as regras de encaminhamento depois de criá-las. Se for necessário alterar as portas especificadas ou o endereço IP interno de uma regra de encaminhamento interno, você precisará excluir e substituir a regra de encaminhamento.

Várias regras de encaminhamento

É possível configurar várias regras de encaminhamento interno para o mesmo balanceador de carga interno. Cada regra de encaminhamento precisa ter seu próprio endereço IP exclusivo e só pode fazer referência a um único serviço de back-end. Várias regras de encaminhamento interno podem fazer referência ao mesmo serviço de back-end.

Configurar várias regras de encaminhamento interno pode ser útil se você precisar de mais de um endereço IP para o mesmo balanceador de carga TCP/UDP interno ou se precisar associar determinadas portas a endereços IP diferentes. Ao usar várias regras de encaminhamento interno, configure o software em execução nas suas VMs de back-end para que se vincule a todos os endereços IP necessários, porque o endereço IP de destino dos pacotes entregues pelo balanceador de carga é o endereço IP interno associado à respectiva regra de encaminhamento interno.

Na página Como configurar o balanceamento de carga TCP/UDP interno, consulte o procedimento para criar uma regra de encaminhamento secundário. No exemplo, duas regras de encaminhamento, uma usando 10.1.2.99 e outra usando 10.5.6.99, são configuradas para o mesmo balanceador de carga. É preciso configurar as VMs de back-end para receber pacotes em um desses endereços IP. Uma maneira de fazer isso é configurar a vinculação dos back-ends a qualquer endereço IP (0.0.0.0/0).

Serviço de back-end

Cada balanceador de carga TCP/UDP interno usa um serviço de back-end interno regional. O nome do serviço de back-end é o nome do balanceador de carga TCP/UDP interno mostrado no Console do GCP.

O serviço de back-end aceita o tráfego direcionado a ele por uma ou mais regras de encaminhamento interno. Um serviço de back-end interno regional aceita tráfego TCP ou UDP, mas não ambos, e fornece tráfego para VMs de back-end nas mesmas portas para que o tráfego foi enviado, com base na regra de encaminhamento.

Os serviços de back-end precisam ter pelo menos um grupo de instâncias de back-end e uma verificação de integridade associada. Os back-ends podem ser grupos de instâncias não gerenciadas, grupos de instâncias gerenciadas por zonas ou grupos de instâncias gerenciadas por região na mesma região do serviço de back-end e regra de encaminhamento. O serviço de back-end distribui o tráfego para as VMs de back-end e gerencia a afinidade da sessão, quando tiver sido configurado para tal.

Verificação de integridade

O serviço de back-end do balanceador de carga precisa estar associado a uma verificação de integridade. Rotas especiais fora da rede VPC são usadas para facilitar a comunicação entre os sistemas de verificação de integridade e os back-ends.

É possível usar uma verificação de integridade atual ou definir uma nova. Os balanceadores de carga TCP/UDP internos só enviam tráfego para VMs de back-end que passam nas verificações de integridade. No entanto, se todas as VMs de back-end falharem nas verificações de integridade, o GCP distribuirá o tráfego entre todas elas.

É possível usar qualquer um dos seguintes protocolos de verificação de integridade. O protocolo da verificação de integridade não precisa corresponder ao protocolo do próprio balanceador de carga.

  • HTTP, HTTPS ou HTTP/2: se as VMs de back-end veicularem tráfego usando HTTP, HTTPS ou HTTP/2, é melhor usar uma verificação de integridade correspondente a esse protocolo, porque as verificações de integridade baseadas em HTTP oferecem opções apropriadas para esse protocolo. Observe que a veiculação de tráfego de tipo HTTP por meio de um balanceador de carga TCP/UDP interno significa que o protocolo do balanceador de carga é TCP.
  • SSL ou TCP: se suas VMs de back-end não veicularem tráfego do tipo HTTP, você deverá usar uma verificação de integridade de SSL ou TCP.

Independentemente do tipo de verificação de integridade que você criar, o GCP enviará sondagens de verificação de integridade para o endereço IP do balanceador de carga TCP/UDP interno, simulando como o tráfego com carga balanceada seria entregue. É preciso que os softwares executados nas suas VMs de back-end respondam ao tráfego com carga balanceada e às sondagens de verificações de integridade enviadas ao endereço IP do próprio balanceador de carga. Para saber mais informações, consulte Destino para pacotes de verificação de integridade.

Verificações de integridade e tráfego UDP

O GCP não oferece uma verificação de integridade que use o protocolo UDP. Ao usar o balanceamento de carga TCP/UDP interno com tráfego UDP, você precisa executar um serviço baseado em TCP nas suas VMs de back-end para fornecer informações de verificação de integridade.

Nessa configuração, as solicitações de clientes são balanceadas por carga usando o protocolo UDP. Um serviço TCP é usado para fornecer informações às sondagens de verificação de integridade do GCP. Por exemplo, é possível executar um servidor HTTP simples em cada VM de back-end que retorna uma resposta HTTP 200 para o GCP. Neste exemplo, você deve usar sua própria lógica em execução na VM de back-end para garantir que o servidor HTTP retorne apenas 200, se o serviço UDP estiver configurado e em execução corretamente.

Distribuição de tráfego

A maneira como um balanceador de carga TCP/UDP interno distribui novas conexões depende de você ter ou não configurado o failover:

  • Se você não tiver configurado o failover, um balanceador de carga TCP/UDP interno distribuirá novas conexões entre todas as suas VMs de back-end íntegras se pelo menos uma VM de back-end estiver íntegra. Quando todas as VMs de back-end não estiverem íntegras, o balanceador de carga distribuirá novas conexões entre todos os back-ends como um último recurso.

  • Se você tiver configurado o failover, um balanceador de carga TCP/UDP interno distribuirá nova conexão entre VMs no pool ativo, de acordo com uma política de failover que você configurar. Quando todas as VMs de back-end não são íntegras, é possível optar por eliminar o tráfego ou não.

Por padrão, o método de distribuição de novas conexões usa um hash calculado a partir de cinco informações: endereço IP do cliente, porta de origem, endereço IP da regra de encaminhamento interno do balanceador de carga, porta de destino e protocolo. É possível modificar o método de distribuição de tráfego para o tráfego TCP especificando uma opção de afinidade de sessão.

O estado da verificação de integridade controla a distribuição de novas conexões. Uma sessão TCP estabelecida persiste em uma VM de back-end não íntegra se a VM de back-end não íntegra ainda estiver manipulando a conexão.

Opções de afinidade de sessão

A afinidade de sessão controla a distribuição de novas conexões de clientes para as VMs de back-end do balanceador de carga. Defina a afinidade de sessão quando as VMs de back-end precisarem acompanhar as informações de estado dos clientes ao enviar o tráfego TCP. Esse é um requisito comum para aplicativos da Web.

A afinidade de sessão funciona com base no melhor esforço para o tráfego TCP. Como o protocolo UDP não é compatível com sessões, a afinidade de sessão não afeta o tráfego UDP.

Os balanceadores de carga TCP/UDP internos são compatíveis com as seguintes opções de afinidade de sessão, que você especifica para todo o serviço interno de back-end e não por grupo de instâncias de back-end:

  • Nenhuma: esta é a configuração padrão, que é efetivamente igual ao protocolo IP e à porta do cliente.
  • IP do cliente: direciona as solicitações de um determinado cliente para a mesma VM de back-end com base em um hash criado a partir do endereço IP do cliente e do endereço IP de destino.
  • IP e protocolo do cliente: direciona as solicitações de um cliente específico para a mesma VM, com base em um hash criado a partir de três informações: endereço IP do cliente, endereço IP de destino e protocolo do balanceador de carga (TCP ou UDP).
  • IP, protocolo e porta do cliente: direciona as solicitações de um determinado cliente para a mesma VM de back-end com base em um hash criado a partir dessas cinco informações:

    • Endereço IP de origem do cliente que envia a solicitação
    • Porta de origem do cliente que envia a solicitação
    • O endereço IP de destino
    • Porta de destino
    • Protocolo (TCP ou UDP)

    O endereço IP de destino é o endereço IP da regra de encaminhamento do balanceador de carga, a não ser que os pacotes sejam entregues ao balanceador de carga devido a uma rota estática personalizada. Se um balanceador de carga TCP/UDP interno for o próximo salto de uma rota, consulte Afinidade de sessão e balanceador de carga TCP/UDP interno do próximo salto.

Afinidade de sessão e balanceador de carga TCP/UDP interno do próximo salto

Independentemente da opção de afinidade da sessão que você escolher, o GCP usará o destino do pacote. Ao enviar um pacote diretamente para o balanceador de carga, o destino do pacote corresponde ao endereço IP da regra de encaminhamento do balanceador de carga.

Ao usar um balanceador de carga TCP/UDP interno como próximo salto para uma rota estática personalizada, o destino do pacote provavelmente não será o endereço IP da regra de encaminhamento do balanceador de carga. Para pacotes com um destino no intervalo de destino da rota, a rota direciona para o balanceador de carga.

Afinidade de sessão e estado de verificação de integridade

A alteração dos estados de integridade das VMs de back-end pode causar perda de afinidade de sessão. Por exemplo, se uma VM de back-end não estiver íntegra e houver pelo menos outra VM de back-end compatível, um balanceador de carga TCP/UDP interno não distribuirá novas conexões à VM não íntegra. Se um cliente tiver afinidade de sessão com essa VM não íntegra, ele será direcionado para a outra VM de back-end saudável, perdendo sua afinidade de sessão.

Como testar conexões de um único cliente

Ao testar conexões com o endereço IP de um balanceador de carga TCP/UDP interno de um único sistema cliente, lembre-se do seguinte:

Se o sistema cliente não for uma VM que está sendo balanceada, isto é, nem uma VM de back-end, novas conexões serão entregues às VMs de back-end compatíveis do balanceador de carga. No entanto, como todas as opções de afinidade de sessão dependem de pelo menos o endereço IP do sistema cliente, as conexões do mesmo cliente podem ser distribuídas para a mesma VM com mais frequência do que o esperado. Na prática, o significado disso é que não é possível monitorar com precisão a distribuição de tráfego por meio de um balanceador de carga TCP/UDP interno de um único cliente. O número necessário de clientes para monitorar a distribuição de tráfego varia de acordo com o tipo do balanceador de carga, o tipo de tráfego e o número de back-ends íntegros.

Se a VM cliente também for uma VM de back-end do balanceador de carga, as conexões enviadas ao endereço IP da regra de encaminhamento do balanceador de carga serão sempre respondidas pela própria VM cliente de back-end. Isso acontece independentemente de a VM de back-end estar íntegra e de todo o tráfego enviado ao endereço IP do balanceador de carga, não apenas do protocolo e da (s) porta (s) especificada na regra de encaminhamento interno do balanceador de carga. Para saber mais informações, consulte o envio de solicitações de VMs com balanceamento de carga.

Limites

Para saber informações sobre cotas e limites, consulte Cotas do recurso de balanceamento de carga.

A seguir