Visão geral do balanceamento de carga TCP/UDP interno

O balanceamento de carga TCP/UDP interno do Google Cloud é um balanceador de carga regional em que é possível executar e dimensionar serviços com um endereço IP de balanceamento de carga interno acessível somente às instâncias de máquina virtual (VM) interna.

Ele distribui o tráfego entre instâncias de VM na mesma região em uma rede de nuvem privada virtual (VPC) usando um endereço IP interno.

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 geral de balanceador de carga TCP/UDP interno (clique para ampliar)
Exemplo geral de balanceador de carga TCP/UDP interno (clique para ampliar)

Para informações sobre as diferenças entre os balanceadores de carga do Google Cloud, consulte os documentos a seguir:

Protocolos, esquema e escopo

Cada balanceador de carga TCP/UDP interno é compatível com:

  • Um serviço de back-end com esquema de balanceamento de carga INTERNAL e o protocolo TCP ou UDP (mas não ambos)
  • Grupos de instâncias gerenciadas e não gerenciadas de back-end localizados em uma região e uma rede VPC
  • Uma ou mais regras de encaminhamento, cada uma usando o protocolo TCP ou UDP, que corresponde ao protocolo do serviço de back-end
  • Cada regra de encaminhamento com o próprio endereço IP exclusivo ou várias regras de encaminhamento que compartilham um endereço IP comum
  • Cada regra de encaminhamento com até cinco portas ou todas as portas
  • Se o acesso global estiver ativado, os clientes em qualquer região
  • Se o acesso global estiver desativado, os clientes na mesma região do balanceador de carga

Os balanceadores de carga TCP/UDP internos não são compatíveis com:

Acesso de cliente

Ative o acesso global para que as instâncias de VMs clientes de qualquer região acessem o balanceador de carga TCP/UDP interno. A VM cliente precisa estar na mesma rede ou em uma rede VPC conectada usando peering da rede VPC.

Na tabela a seguir, é possível ver um resumo do acesso do cliente.

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 do Cloud VPN ou anexos de interconexão (VLANs). 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 do Cloud VPN ou anexos de interconexão (VLANs). Esses túneis ou anexos podem estar em qualquer região.

Casos de uso

Os balanceadores de carga TCP/UDP internos lidam com muitos casos de uso. Nesta seção, veremos alguns exemplos gerais.

Exemplos de acesso

Acesse um balanceador de carga TCP/UDP interno na rede VPC por uma rede conectada usando o seguinte:

  • 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

Use o balanceamento de carga TCP/UDP interno com outros balanceadores de carga. Por exemplo, se você incorporar balanceadores de carga HTTP externos, o balanceador de carga externo será a camada da Web e dependerá dos serviços por trás do balanceador de carga interno.

No diagrama a seguir, você verá o exemplo de uma configuração de três camadas que usa balanceadores de carga HTTP(S) externos e balanceadores de carga TCP/UDP internos:

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 HTTP(S) e balanceamento de carga TCP/UDP interno (clique para ampliar)

Serviço da Web de três camadas com exemplo de acesso global

Se você ativar o acesso global, suas VMs da Web podem estar em outra região, como mostrado no diagrama a seguir.

Este exemplo de aplicativo multicamada mostra:

  • Uma camada da Web voltada para a Internet disponível globalmente que equilibra a carga do tráfego com balanceamento de carga HTTP(S)
  • Uma camada interna de banco de dados de balanceamento de carga de back-end na região us-east1 acessada pela camada global da Web.
  • Uma VM cliente que faz parte da camada da Web na região europe-west1 com acesso à camada do banco de dados de balanceamento de carga interno localizada em us-east1.
Aplicativo da Web de três camadas com balanceamento de carga HTTP(S), acesso global e balanceamento de carga TCP/UDP interno (clique para ampliar)
Aplicativo da Web de três camadas com balanceamento de carga HTTP(S), acesso global e balanceamento de carga TCP/UDP interno (clique para ampliar)

VPC compartilhada

A tabela a seguir resume os requisitos do componente para o balanceamento de carga TCP/UDP interno usado com uma rede VPC compartilhada. Para ver um exemplo, consulte Como criar um balanceador de carga TCP/UDP interno na página "Como provisionar a VPC compartilhada".

Endereço IP Regra de encaminhamento Componentes de back-end
Um endereço IP interno precisa ser definido no mesmo projeto que as VMs de back-end.

Para que o balanceador de carga esteja disponível em uma rede VPC compartilhada, o endereço IP interno do Google Cloud precisa ser definido no mesmo projeto de serviço em que as VMs de back-end estão localizadas e precisa fazer referência a uma sub-rede na rede VPC compartilhada desejada no projeto host. O endereço em si vem do intervalo de IP principal da sub-rede referenciada.

Se você criar um endereço IP interno em um projeto de serviço e a sub-rede do endereço IP estiver na rede VPC do projeto de serviço, o balanceador de carga TCP/UDP interno será local para o projeto de serviço. Ele não é local para nenhum projeto host de VPC compartilhada.		 Uma regra de encaminhamento interna precisa ser definida no mesmo projeto das VMs de back-end.

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 a mesma sub-rede (na rede VPC compartilhada) que o endereço IP interno associado referencia.

Se você criar uma regra de encaminhamento interno em um projeto de serviço e a sub-rede da regra de encaminhamento estiver na rede VPC do projeto de serviço, o balanceador de carga TCP/UDP interno será local para o projeto de serviço. Ele não é local para nenhum projeto host de VPC compartilhada.		 Em um cenário de VPC compartilhada, as VMs de back-end 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.

Outros casos de uso

  • Como usar um balanceador de carga TCP/UDP interno como o próximo salto para um gateway NAT: é possível rotear o tráfego para os back-ends de firewall ou appliance virtual de gateway por meio de um balanceador de carga TCP/UDP interno.
  • "Hub and spoke": como trocar rotas de próximo salto usando o peering de rede VPC: é possível configurar uma topologia "hub-and-spoke" com seus appliances virtuais de firewall de próximo salto localizados na rede VPC hub. Rotas que usam o balanceador de carga como próximo salto na rede VPC hub podem ser usadas em cada rede spoke.
  • Balanceamento de carga para várias NICs nas VMs de back-end.

Para mais informações sobre esses casos de uso, consulte Balanceadores de carga TCP/UDP internos como próximos saltos.

Como funciona o balanceamento de carga TCP/UDP interno

Os balanceadores de carga TCP/UDP internos têm as seguintes características:

  • São um serviço gerenciado.
  • Não são um proxy.
  • São implementados em redes virtuais.

Diferente dos balanceadores de carga baseados em dispositivo ou em instâncias de VM, os balanceadores de carga TCP/UDP internos não encerram conexões de clientes. Em vez do tráfego ser enviado para um balanceador de carga e para os back-ends íntegros, os clientes enviam tráfego direto para os back-ends íntegros:

  • Não há dispositivo intermediário ou ponto único de falha.
  • As solicitações do cliente para o endereço IP do balanceador de carga vão diretamente para as VMs de back-end íntegras.
  • As respostas das VMs de back-end vão diretamente para os clientes, e não voltam pelo balanceador de carga. As respostas TCP usam retorno direto do servidor. Para ver mais informações, consulte Pedidos TCP e UDP e pacotes de retorno.

O balanceador de carga monitora a integridade da VM usando sondagens de verificação de integridade. Para mais informações, consulte a seção Verificação de integridade.

O ambiente de convidado do Linux, o do Windows ou um processo equivalente do Google Cloud configura cada VM de back-end com o endereço IP do balanceador de carga. A rede virtual do Google Cloud gerencia o fornecimento de tráfego, escalonando conforme apropriado.

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 informações sobre o método de distribuição e as opções de configuração, consulte Distribuição de tráfego.

Exceto os "Grupos de endpoints de rede" (NEGs, na sigla em inglês), qualquer 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 do Linux ou do Windows apropriado ou outros processos que proporcionem funcionalidade equivalente. Esse ambiente de convidado precisa contatar o servidor de metadados (metadata.google.internal e 169.254.169.254) para ler os metadados da instância a fim de gerar rotas locais para 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.

Alta disponibilidade

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

Para garantir que as instâncias de VM de back-end sejam implantadas em várias zonas, siga estas recomendações de implantação:

Componentes

Os balanceadores de carga TCP/UDP internos consistem nos seguintes componentes do Google Cloud.

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. A sub-rede precisa estar na mesma região e na mesma rede VPC 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 ip-protocol de TCP ou UDP, correspondendo ao protocol do serviço de back-end;
• fazer referência a subnet na mesma rede VPC e 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 load-balancing-scheme de INTERNAL;
• usar protocol de TCP ou UDP, correspondendo ao ip-protocol da regra de encaminhamento;
• ter uma verificação de integridade vinculada;
• ter uma região vinculada. A região da regra de encaminhamento e todos os grupos de instâncias de back-end precisam ser os mesmos da região do serviço de back-end.
• estar vinculado a uma única rede VPC. Quando não especificada, a rede é inferida com base na que é usada pela interface de rede padrão de cada VM de back-end (nic0).

Mesmo que o serviço de back-end não esteja vinculado a uma sub-rede específica, a sub-rede da regra de encaminhamento precisa estar na mesma rede VPC do serviço de back-end.
Verificação de integridade Cada serviço de back-end precisa ter uma verificação de integridade vinculada. A verificação de integridade define os parâmetros sob os quais o Google Cloud considera os back-ends que gerencia qualificados para receber tráfego. Só VMs íntegras nos grupos de instâncias de back-end recebem o tráfego enviado de VMs cliente para o endereço IP do balanceador de carga. Por mais que a regra de encaminhamento e o serviço de back-end possam usar TCP ou UDP, o Google Cloud 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 do intervalo de IP principal da sub-rede selecionado 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. Escolha receber um endereço IP temporário ou usar um endereço IP reservado.

Regras de firewall

Seu balanceador de carga TCP/UDP interno requer as seguintes regras de firewall:

O exemplo em Como configurar regras de firewall mostra como criar ambos.

Regras de encaminhamento

Uma regra de encaminhamento especifica o protocolo e as portas em que o balanceador de carga aceita tráfego. Como os balanceadores de carga TCP/UDP internos não são proxies, passam o tráfego para back-ends no mesmo protocolo e na mesma porta.

Um balanceador de carga TCP/UDP interno exige, no mínimo, uma regra de encaminhamento interno. Defina várias regras de encaminhamento para o mesmo balanceador de carga.

A regra de encaminhamento precisa fazer referência a uma sub-rede específica na mesma rede VPC e na mesma região dos componentes de back-end do balanceador de carga. Esse requisito tem as seguintes implicações:

  • A sub-rede especificada para a regra de encaminhamento não precisa ser igual a uma das usadas pelas VMs de back-end. No entanto, a sub-rede precisa estar na mesma região da regra de encaminhamento.
  • Quando você cria uma regra de encaminhamento interno, o Google Cloud escolhe um endereço IP interno regional disponível pelo 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 acesso global

As regras de encaminhamento dos balanceadores de carga TCP/UDP internos são regionais, mesmo quando o acesso global está ativado. Depois de ativar o acesso global, a sinalização allowGlobalAccess da regra de encaminhamento interno regional é definida como true.

Regras de encaminhamento e especificações de porta

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

  • Especifique entre uma e cinco portas, por número.
  • Especifique ALL para encaminhar tráfego a todas as portas.

Com uma regra de encaminhamento interno compatível com todas as portas TCP ou UDP, é possível fazer com que as VMs de back-end executem vários aplicativos, cada um na própria porta. O tráfego enviado para uma determinada porta é entregue ao aplicativo correspondente e todos os aplicativos usam o mesmo endereço IP.

Quando precisar encaminhar o tráfego em mais de cinco portas específicas, combine regras de firewall com as regras de encaminhamento. Ao criar a regra de encaminhamento, especifique todas as portas e crie regras de firewall de entrada allow que tenham apenas tráfego para as portas desejadas. Aplique as regras de firewall às VMs de back-end.

Não modifique regras de encaminhamento depois de criá-las. Se precisar alterar as portas especificadas ou o endereço IP interno de uma regra de encaminhamento interno, será necessário excluí-lo e recriá-lo.

Várias regras de encaminhamento para um único serviço de back-end

É possível configurar várias regras de encaminhamento interno que fazem referência ao mesmo serviço de back-end interno. Um balanceador de carga TCP/UDP interno exige, no mínimo, uma regra de encaminhamento interno.

Configurar várias regras de encaminhamento para o mesmo serviço de back-end permite fazer o seguinte, usando TCP ou UDP (não os dois):

  • Atribua vários endereços IP ao balanceador de carga. É possível criar várias regras de encaminhamento, cada uma usando um endereço IP exclusivo. Cada regra de encaminhamento pode especificar todas as portas ou um conjunto de até cinco portas.

  • Atribua um conjunto específico de portas, usando o mesmo endereço IP, ao balanceador de carga. É possível criar várias regras de encaminhamento que compartilham o mesmo endereço IP, em que cada regra de encaminhamento usa um conjunto específico de até cinco portas. Essa é uma alternativa à configuração de uma única regra de encaminhamento que especifica todas as portas.

Para mais informações sobre cenários que envolvem duas ou mais regras de encaminhamento interno que compartilham um endereço IP interno comum, consulte Várias regras de encaminhamento com o mesmo endereço IP.

Ao usar várias regras de encaminhamento interno, configure o software em execução nas suas VMs de back-end para vincular a todos os endereços IP da regra de encaminhamento ou a qualquer endereço (0.0.0.0/0). O endereço IP de destino de um pacote entregue pelo balanceador de carga é o endereço IP interno associado à regra de encaminhamento interno correspondente. Para ver mais informações, consulte Solicitações TCP e UDP e pacotes de retorno.

Serviço de back-end

Cada balanceador de carga TCP/UDP interno tem um serviço de back-end interno regional que define parâmetros e comportamento de back-end. O nome do serviço de back-end é o nome do balanceador de carga TCP/UDP interno mostrado no Console do Google Cloud.

Todo os serviços de back-end definem os seguintes parâmetros de back-end:

  • Protocolo. Um serviço de back-end aceita tráfego TCP ou UDP, mas não ambos, nas portas especificadas por uma ou mais regras de encaminhamento interno. Com o serviço de back-end, é possível direcionar tráfego às VMs de back-end nas mesmas portas para as quais o tráfego foi enviado. O protocolo do serviço de back-end precisa corresponder ao protocolo da regra de encaminhamento.

  • Distribuição de tráfego. Com um serviço de back-end, é possível fazer com que o tráfego seja distribuído de acordo com uma afinidade de sessão configurável.

  • Verificação de integridade. Os serviços de back-end precisam ter uma verificação de integridade vinculada.

Cada serviço de back-end opera em uma única região e distribui o tráfego para VMs de back-end em uma única rede VPC:

  • Região. Os back-ends são grupos de instâncias na mesma região do serviço de back-end e da regra de encaminhamento. Os back-ends podem ser grupos de instâncias não gerenciadas, gerenciadas por zona ou gerenciadas por região.

  • Rede VPC. Todas as VMs de back-end precisam ter uma interface de rede na rede VPC vinculada ao serviço de back-end. Como opção, especifique explicitamente a rede de um serviço de back-end ou use uma rede implícita. Em ambos os casos, cada sub-rede da regra de encaminhamento interno precisa estar na rede VPC do serviço de back-end.

Serviços de back-end e interfaces de rede

Cada serviço de back-end opera em uma única rede VPC e na região do Google Cloud. A rede VPC pode ser implícita ou especificada explicitamente com a sinalização --network no comando gcloud compute backend-services create:

  • Quando especificada explicitamente, a sinalização de VPC --network do serviço de back-end identifica a interface de rede em cada VM de back-end para a qual o tráfego tem a carga balanceada. Cada VM de back-end precisa ter uma interface de rede na rede VPC especificada. Nesse caso, os identificadores da interface de rede (de nic0 a nic7) podem ser diferentes entre as VMs de back-end. Exemplo:

    • Diferentes VMs de back-end no mesmo grupo de instâncias não gerenciadas podem usar identificadores de interface diferentes se cada VM tiver uma interface na rede VPC especificada.
    • O identificador de interface não precisa ser o mesmo em todos os grupos de instâncias de back-end. Pode ser nic0 para VMs de back-end em um grupo de instâncias de back-end e nic2 para VMs de back-end em outro grupo.

  • Se não incluir o sinalizador --network ao criar o serviço de back-end, este escolherá uma rede com base na rede da interface da rede inicial (ou única) usada por todas as VMs de back-end. Isso significa que nic0 precisa estar na mesma rede VPC para todas as VMs em todos os grupos de instâncias de back-end.

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 facilitam a comunicação entre os sistemas de verificação de integridade e os back-ends.

Use uma verificação de integridade atual ou defina uma nova. Os balanceadores de carga TCP/UDP internos usam status de verificação de integridade para determinar como rotear novas conexões, conforme descrito em Distribuição de tráfego.

Use qualquer um dos seguintes protocolos de verificação de integridade. O protocolo da verificação de integridade não precisa corresponder ao protocolo do balanceador de carga:

  • HTTP, HTTPS ou HTTP/2. Se as VMs de back-end enviarem tráfego usando HTTP, HTTPS ou HTTP/2, é melhor usar uma verificação de integridade que corresponda a esse protocolo, porque as que têm como base o HTTP oferecem opções adequadas ao protocolo em questão. Se a disponibilização de tráfego de HTTP for feita por meio de um balanceador de carga TCP/UDP, o protocolo do balanceador de carga será TCP.
  • SSL ou TCP. Se as VMs de back-end não enviarem tráfego do tipo HTTP, terá de usar uma verificação de integridade SSL ou TCP.

Independentemente do tipo de verificação de integridade que você criar, o Google Cloud faz sondagens de verificação de integridade no endereço IP do balanceador de carga TCP/UDP interno, simulando como o tráfego com balanceamento de carga é transmitido. O software executado nas VMs de back-end precisam responder ao tráfego com balanceamento de carga e às sondagens de verificação de integridade enviadas ao endereço IP do balanceador de carga. Para ver mais informações, consulte Destino dos pacotes de sondagem.

Verificações de integridade e tráfego UDP

O Google Cloud 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 com carga usando o protocolo UDP, e um serviço TCP é usado para enviar informações a quem faz as sondagens de verificação de integridade do Google Cloud. Por exemplo, é possível usar um servidor HTTP simples em cada VM de back-end que gera uma resposta HTTP 200 para o Google Cloud. Neste exemplo, é preciso usar a própria lógica em execução na VM de back-end para garantir que o servidor HTTP exiba 200 apenas se o serviço UDP estiver configurado e em execução corretamente.

Solicitações TCP e UDP e devolução de pacotes

Quando um sistema cliente envia um pacote TCP ou UDP para um balanceador de carga TCP/UDP interno, a origem e o destino do pacote são os seguintes:

  • Origem: o endereço IP interno principal do cliente ou o endereço IP de um dos intervalos de IP do alias do cliente.
  • Destino: o endereço IP da regra de encaminhamento do balanceador de carga.

Quando o balanceador de carga envia um pacote de resposta, a origem e o destino desse pacote dependem do protocolo:

  • O TCP é orientado por conexão, e os balanceadores de carga TCP/UDP internos usam retorno direto do servidor. Assim, os pacotes de resposta são enviados do endereço IP da regra de encaminhamento do balanceador de carga.
  • Por outro lado, o UDP não tem conexão. Por padrão, os pacotes de retorno são enviados do endereço IP interno principal da interface de rede da instância de back-end. De qualquer maneira, esse comportamento pode ser alterado. Por exemplo, configurar um servidor UDP para se vincular ao endereço IP da regra de encaminhamento faz com que os pacotes de resposta sejam enviados do endereço IP da regra de encaminhamento.

Nesta tabela, há um resumo das origens e dos destinos dos pacotes de resposta:

Tipo de tráfego Origem Destino
TCP O endereço IP da regra de encaminhamento do balanceador de carga A origem do pacote solicitante
UDP Depende do software servidor UDP A origem do pacote solicitante

Distribuição de tráfego

A maneira como um balanceador de carga TCP/UDP interno distribui novas conexões depende de você ter 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 VMs de back-end íntegras se pelo menos uma VM de back-end estiver nesse estado. 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 tiver configurado o failover, um balanceador de carga TCP/UDP interno distribuirá novas conexões entre VMs no pool ativo, de acordo com uma política de failover que pode ser configurada. Quando todas as VMs de back-end não forem íntegras, poderá optar por descartar o tráfego.

Por padrão, o método de distribuição de novas conexões usa um hash calculado a partir de cinco informações: o endereço IP do cliente, a porta de origem, o endereço IP da regra de encaminhamento interno do balanceador de carga, a porta de destino e o 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 interferir na 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. Você define a afinidade de sessão quando as VMs de back-end precisam 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 de back-end interno, não por grupo de instâncias de back-end:

  • Nenhuma. esta é a configuração padrão, que é exatamente igual ao IP do cliente, protocolo e porta.
  • 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 do cliente e protocolo. 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, o endereço IP de destino e protocolo do balanceador de carga (TCP ou UDP).

  • IP de cliente, protocolo e porta. Direciona as solicitações de determinado cliente para a mesma VM de back-end com base em um hash criado a partir destas 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
    • 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 menos que os pacotes sejam transmitidos 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, veja a seção seguinte, 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 de sessão escolhida, o Google Cloud usa 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.

No entanto, ao usar um balanceador de carga TCP/UDP interno como próximo salto para uma rota estática personalizada, é provável que o destino do pacote não seja 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.

Para usar um balanceador de carga TCP/UDP interno como o próximo salto de uma rota estática personalizada, consulte Conceitos do próximo salto para balanceamento de carga TCP/UDP interno.

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 íntegra, 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 a VM não íntegra, será direcionado para a VM de back-end íntegra, perdendo a afinidade de sessão.

Como testar conexões de cliente único

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 enviadas às VMs de back-end íntegras do balanceador de carga. No entanto, como todas as opções de afinidade de sessão dependem de, no mínimo, 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 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 VM de cliente/back-end. Isso acontece independentemente de a VM de back-end estar íntegra. Isso acontece para todo o tráfego enviado ao endereço IP do balanceador de carga, não apenas o tráfego no protocolo e as portas especificadas na regra de encaminhamento interno do balanceador de carga.

    Para ver mais informações, consulte Como enviar solicitações a partir de VMs submetidas a balanceamento de carga.

Limites

Para ver informações sobre cotas e limites, consulte Cotas para recursos de balanceamento de carga.

A seguir