Noções básicas sobre serviços de back-end

Um serviço de back-end é um recurso com campos que contêm valores de configuração para estes serviços de balanceamento de carga do Google Cloud:

  • Balanceamento de carga HTTP(S) externo
  • Balanceamento de carga HTTP(S) interno
  • Balanceamento de carga de proxy SSL
  • Balanceamento de carga de proxy TCP
  • Balanceamento de carga TCP/UDP interno

O balanceamento de carga de rede não usa um serviço de back-end.

Os balanceadores de carga usam as informações de configuração no recurso do serviço de back-end para as seguintes funções:

  • Direcionar o tráfego para os back-ends corretos, que são grupos de instâncias ou grupos de endpoints de rede
  • Distribuir o tráfego de acordo com um modo de balanceamento, que é definido no serviço de back-end para cada back-end
  • Monitorar a integridade do back-end usando a verificação de integridade designada no serviço de back-end
  • Manter a afinidade da sessão

Arquitetura

O número de serviços de back-end por balanceador de carga depende do tipo de balanceador de carga:

Tipo de balanceador de carga Número de serviços de back-end
Balanceamento de carga HTTP(S) externo Vários
Balanceamento de carga HTTP(S) interno Vários
Balanceamento de carga de proxy SSL 1
Balanceamento de carga de proxy TCP 1
Balanceamento de carga TCP/UDP interno 1

Cada serviço de back-end contém um ou mais back-ends.

Para um determinado serviço de back-end, todos os back-ends precisam ser grupos de instâncias ou grupos de endpoints de rede. É possível associar diferentes tipos de grupos de instâncias (por exemplo, gerenciadas e não gerenciadas) ao mesmo serviço de back-end, mas não é possível associar grupos de instâncias e grupos de endpoints de rede ao mesmo serviço de back-end.

Configurações do serviço de back-end

Cada serviço de back-end tem as seguintes configurações que podem ser ajustadas:

  • Afinidade da sessão (opcional). Normalmente, os balanceadores de carga usam um algoritmo de hash para distribuir solicitações entre instâncias disponíveis. Em uso normal, o hash é baseado em endereço IP de origem, endereço IP de destino, porta de origem, porta de destino e protocolo (um hash de cinco tuplas). A afinidade da sessão ajusta o que está incluído no hash e tenta enviar todas as solicitações do mesmo cliente para a mesma instância de máquina virtual.
  • O tempo limite do serviço de back-end. Esse valor é interpretado de maneiras diferentes, dependendo do tipo de balanceador de carga e do protocolo usado:
    • Para um balanceador de carga HTTP(S), o tempo limite do serviço de back-end é um tempo limite de solicitação/resposta, exceto para conexões que são atualizadas para usar o protocolo Websocket.
    • Durante o envio de tráfego WebSocket para um balanceador de carga HTTP(S), o tempo limite do serviço de back-end é interpretado como o tempo máximo que um WebSocket, inativo ou ativo, pode permanecer aberto.
    • Para um balanceador de carga de proxy TCP ou proxy SSL, o tempo limite do serviço de back-end é interpretado como um tempo limite de inatividade para todo o tráfego.
    • Para um balanceador de carga TCP/UDP interno, o parâmetro de tempo limite do serviço de back-end é ignorado.
  • Uma verificação de integridade. O verificador de integridade consulta as instâncias conectadas ao serviço de back-end em intervalos configurados. Instâncias aprovadas na verificação de integridade são autorizadas a receber novas solicitações. Instâncias não íntegras não recebem solicitações até que estejam íntegras novamente.

Consulte o recurso da API do serviço de back-end ou o guia de usuário da ferramenta de linha de comando gcloud para ver descrições das propriedades disponíveis ao trabalhar com serviços de back-end.

Back-ends

É possível adicionar vários back-ends a apenas um serviço de back-end. Cada back-end é um recurso que recebe o tráfego distribuído por um balanceador de carga do Google Cloud. Existem três tipos diferentes de recursos que podem ser usados como back-ends:

Para um determinado serviço de back-end, todos os back-ends têm que ser grupos de instâncias ou, se compatíveis, NEGs ou buckets de back-end. Não é possível usar diferentes tipos de back-ends com o mesmo serviço de back-end. Além disso:

  • Back-ends para balanceadores de carga TCP/UDP internos são compatíveis somente com back-ends de grupos de instâncias.
  • Se um balanceador de carga HTTP(S) tem dois (ou mais) serviços de back-end, é possível usar grupos de instâncias como back-ends para um serviço de back-end e NEGs como back-ends para o outro serviço de back-end.

Back-ends e endereços IP externos

As VMs de back-end não precisam de endereços IP externos:

  • Para balanceadores de carga HTTP(S), de Proxy SSL e de Proxy TCP: os clientes se comunicam com um front-end do Google (GFE, na sigla em inglês) usando o endereço IP externo do balanceador de carga. O GFE se comunica com as VMs de back-end usando os endereços IP internos da interface de rede principal. Como o GFE é um proxy, as VMs de back-end em si não exigem endereços IP externos.

  • Para balanceadores de carga de rede: esses balanceadores encaminham pacotes usando conversão de endereços de rede (NAT, na sigla em inglês) bidirecional. Quando as VMs de back-end enviam respostas aos clientes, elas usam o endereço IP externo da regra de encaminhamento do balanceador de carga como endereço IP de origem.

  • Para balanceadores de carga internos: as VMs de back-end de um balanceador de carga interno não precisam de endereços IP externos.

Distribuição de tráfego

Os valores dos campos a seguir no recurso de serviços de back-end determinam alguns aspectos do comportamento do back-end:

  • Um modo de balanceamento, que diz ao sistema de balanceamento de carga como determinar quando o back-end está sendo totalmente utilizado. Se todos os back-ends do serviço de back-end em uma região estiverem em pleno uso, as novas solicitações serão encaminhadas automaticamente para a região mais próxima que ainda tenha capacidade de processá-las. O modo de balanceamento pode ser baseado em conexões, utilização de back-end ou solicitações por segundo (taxa).
  • Uma configuração de capacidade. Capacidade é um controle adicional que interage com a configuração do modo de balanceamento. Por exemplo, se normalmente você quer que as instâncias operem no máximo com 80% de utilização de back-end, defina o modo de balanceamento como utilização de back-end e sua capacidade como 80%. Se você quiser reduzir o uso da instância pela metade, deixe a capacidade em 80% de utilização de back-end e defina o escalonador de capacidade como 0,5. Para diminuir o serviço de back-end, defina o escalonador de capacidade como 0 e deixe a capacidade como está. Para mais informações sobre capacidade e utilização de back-end, leia Como escalonar com base na utilização da CPU ou na capacidade de disponibilização do balanceamento de carga.

Observações:

  • Se a utilização média de todas as instâncias em grupos de instâncias de back-end conectadas ao mesmo serviço de back-end for inferior a 10%, a preferência no GCP poderá ser por zonas específicas. Isso pode acontecer quando você usa grupos de instâncias regionais gerenciadas, grupos de instâncias de zona gerenciadas e grupos de instâncias de zona não gerenciadas. Esse desequilíbrio zonal será resolvido automaticamente à medida que mais tráfego for enviado ao balanceador de carga. Os serviços de back-end em outras regiões não afetam nada disso.

O Traffic Director também usa recursos do serviço de back-end. Especificamente, o Traffic Director usa serviços de back-end com um esquema de balanceamento de carga que é INTERNAL_SELF_MANAGED. Para um serviço interno de back-end autogerenciado, a distribuição de tráfego é realizada usando uma combinação de modo de balanceamento de carga e política de balanceamento de carga. O serviço de back-end direciona o tráfego para um back-end (grupo de instâncias ou NEG) de acordo com o modo de balanceamento do back-end e, depois de selecionar um back-end, o Traffic Director distribui o tráfego de acordo com uma política de balanceamento de carga.

Os serviços de back-end autogerenciados internos são compatíveis com os seguintes modos de balanceamento:

  • UTILIZATION, se todos os back-ends forem grupos de instâncias.
  • RATE, se todos os back-ends forem grupos de instâncias ou NEGs.

Se você escolher o modo de balanceamento RATE, precisará especificar uma taxa máxima por back-end, instância ou endpoint.

Protocolo para os back-ends

Ao criar um serviço de back-end, especifique um protocolo usado para comunicação com os respectivos back-ends. Apenas um protocolo pode ser usado por um serviço de back-end. Não é possível especificar um protocolo secundário para usar como substituto.

Os protocolos disponíveis são os seguintes:

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP

O tipo de protocolo válido depende do tipo de balanceador de carga criado, incluindo o esquema de balanceamento de carga dele. Para mais informações sobre quais protocolos podem ser usados para os serviços de back-end, consulte a documentação referente a cada tipo de balanceador de carga.

O HTTP/2, como protocolo para os back-ends, também está disponível para balanceamento de carga com Entrada.

Se o protocolo de um serviço de back-end for alterado, os back-ends não poderão ser acessados por meio de balanceadores de carga por alguns minutos.

Grupos de instâncias

Serviços de back-end e grupos de instâncias gerenciadas com escalonamento automático

Grupos de instâncias gerenciadas com escalonamento automático são úteis quando é necessário ter muitas máquinas configuradas da mesma forma e você quer adicionar ou remover instâncias automaticamente de acordo com a necessidade.

A porcentagem de escalonamento automático funciona com o modo de balanceamento do serviço de back-end. Por exemplo, suponha que você defina o modo de balanceamento como uma utilização de back-end de 80%, deixe o escalonador de capacidade em 100% e defina a opção Uso do balanceamento de carga de destino no escalonador automático como 80%. Sempre que a utilização de back-end do grupo ultrapassar 64% (80% de 80%), o escalonador automático recorrerá a novas instâncias com base no modelo até que o uso caia para cerca de 64%. Se a utilização geral cair abaixo de 64%, o escalonador automático removerá instâncias até que o uso volte a 64%.

Novas instâncias têm que cumprir um período de espera antes de serem consideradas parte do grupo. Portanto, é possível que o tráfego exceda os 80% de utilização de back-end durante esse tempo, fazendo com que o excesso de tráfego seja direcionado para o próximo serviço de back-end disponível. Quando as instâncias estiverem disponíveis, o novo tráfego será encaminhado para elas. Além disso, se o número de instâncias alcançar o máximo permitido pelas configurações do escalonador automático, ele deixará de adicionar instâncias, seja qual for o uso. Nesse caso, o tráfego extra terá a carga balanceada para a próxima região disponível.

Como configurar grupos de instâncias gerenciadas com escalonamento automático

Para configurar grupos de instâncias gerenciadas com escalonamento automático, execute as etapas a seguir:

  1. Crie um modelo de instância para o grupo de instâncias.
  2. Crie um grupo de instâncias gerenciadas e atribua o modelo a ele.
  3. Ative o escalonamento automático com base na capacidade de disponibilização do balanceamento de carga.

Restrições e orientações para grupos de instâncias

Como o Cloud Load Balancing oferece muita flexibilidade na forma como o balanceamento de carga é configurado, é possível criar configurações que não funcionam bem. Tenha em mente as restrições e orientações a seguir ao criar grupos de instâncias para uso com balanceamento de carga.

  • Não coloque uma instância de máquina virtual em mais de um grupo de instâncias.
  • Não exclua um grupo de instâncias se ele estiver sendo usado por um back-end.
  • A configuração será mais simples se você não adicionar o mesmo grupo de instâncias em dois back-ends diferentes. Caso você adicione o mesmo grupo de instâncias a dois back-ends:
    • os dois back-ends têm que usar o mesmo modo de balanceamento, UTILIZATION ou RATE;
    • é possível usar maxRatePerInstance e maxRatePerGroup juntos. É aceitável definir um back-end para usar maxRatePerInstance e o outro para maxRatePerGroup;
    • se o grupo de instâncias atender a duas ou mais portas para vários back-ends respectivamente, será preciso especificar nomes de porta diferentes no grupo de instâncias.
  • Todas as instâncias em um grupo de instâncias gerenciadas ou não gerenciadas precisam estar na mesma rede VPC e, se aplicável, na mesma sub-rede.
  • Se você estiver utilizando um grupo de instâncias gerenciadas com escalonamento automático, não use o modo de balanceamento maxRate no serviço de back-end. As opções possíveis são maxUtilization ou maxRatePerInstance.
  • Não torne um grupo de instâncias gerenciadas com escalonamento automático o destino de dois balanceadores de carga diferentes.
  • Ao redimensionar um grupo de instâncias gerenciadas, o tamanho máximo do grupo tem que ser menor ou igual ao tamanho da sub-rede.

Grupos de endpoints da rede

Um endpoint de rede é uma combinação de endereço IP e porta, especificados de uma destas duas maneiras:

  • Especificando um par IP address:port, como 10.0.1.1:80.
  • Especificando apenas um endereço IP de endpoint de rede. A porta padrão do NEG é usada automaticamente como a porta do par IP address:port.

Os endpoints de rede representam serviços pelos respectivos endereço IP e porta, em vez de se referir a uma determinada VM. Um grupo de endpoints de rede (NEG) é um agrupamento lógico de endpoints de rede.

Um serviço de back-end que usa grupos de endpoints de rede como back-ends distribui o tráfego entre aplicativos ou contêineres executados dentro de instâncias de VM. Para mais informações, consulte Conceitos de grupos de endpoints de rede no balanceamento de carga.

Afinidade da sessão

Sem afinidade da sessão, os balanceadores de carga distribuem as novas solicitações de acordo com o modo de balanceamento do NEG ou do grupo de instâncias de back-end. Alguns aplicativos, como servidores com estado usados por veiculação de anúncios, jogos ou serviços com uso intenso do cache interno, precisam de várias solicitações de um determinado usuário para serem direcionados à mesma instância.

A afinidade da sessão torna isso possível ao identificar o tráfego TCP proveniente do mesmo cliente com base em parâmetros como o endereço IP do cliente ou o valor de um cookie. Isso direciona as solicitações para a mesma instância caso o back-end esteja íntegro e tenha capacidade, de acordo com o respectivo modo de balanceamento.

A afinidade da sessão tem um efeito pouco significativo no tráfego UDP porque uma sessão de UDP consiste em uma solicitação e uma resposta.

Como a afinidade da sessão poderá ser interrompida caso a instância perca a integridade ou fique sobrecarregada, é recomendável não pressupor uma afinidade perfeita.

No balanceamento de carga HTTP(S), a afinidade da sessão funciona melhor com o modo de balanceamento RATE.

Diferentes balanceadores de carga são compatíveis com diferentes opções de afinidade da sessão, conforme resumido nesta tabela:

Balanceador de carga Opções de afinidade da sessão
Interno • Nenhum
• IP do cliente
• IP do cliente e protocolo
• IP do cliente, protocolo e porta
Proxy TCP
Proxy SSL
• Nenhum
• IP do cliente
HTTP(S) • Nenhum
• IP do cliente
• Cookie gerado
Rede O balanceamento de carga de rede não usa serviços de back-end. Em vez disso, você define a afinidade da sessão para balanceadores de carga de rede por meio de pools de destino. Consulte o parâmetro sessionAffinity em Pools de destino.

As seções a seguir abordam dois tipos comuns de afinidade da sessão.

Como usar a afinidade de IP do cliente

A afinidade de IP do cliente direciona as solicitações provenientes do mesmo endereço IP do cliente para a mesma instância de back-end com base em um hash do endereço IP do cliente. A afinidade de IP do cliente é uma opção para todos os balanceadores de carga do Google Cloud que usam serviços de back-end.

Ao usar a afinidade de IP do cliente, tenha isto em mente:

  • O endereço IP do cliente visualizado pelo balanceador de carga talvez não seja o cliente de origem se estiver funcionando com NAT ou fizer solicitações por meio de um proxy. As solicitações feitas por meio de NAT ou proxy usam o endereço IP do roteador NAT ou do proxy como endereço IP do cliente. Isso pode fazer com que o tráfego se acumule desnecessariamente nas mesmas instâncias de back-end.

  • Se um cliente mudar de uma rede para outra, o endereço IP dele será alterado, resultando em afinidade corrompida.

Console


Para definir a afinidade de IP do cliente:

  1. No Console do Google Cloud, acesse a parte Configuração do back-end da página do balanceador de carga.
    Acessar a página "Balanceamento de carga"
  2. Selecione o lápis Editar do balanceador de carga.
  3. Selecione Configuração de back-end.
  4. Selecione o lápis Editar de um Serviço de back-end.
  5. Na caixa de diálogo Editar serviço de back-end, selecione Client IP no menu suspenso Afinidade da sessão.
    Essa ação ativa a afinidade da sessão de IP do cliente. O campo TTL de cookie de afinidade fica esmaecido porque não tem utilidade para a afinidade de IP do cliente.
  6. Clique no botão Atualizar do Serviço de back-end.
  7. Clique no botão Atualizar do balanceador de carga.

gcloud


Use o comando create para definir a afinidade da sessão para um novo serviço de back-end ou o comando update para configurá-la para um serviço de back-end atual. Neste exemplo, mostramos como usá-lo com o comando update.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity client_ip
    

API


Consulte a referência da API para serviços de back-end.

Quando você define a afinidade de cookie gerado, o balanceador de carga emite um cookie na primeira solicitação. Em cada solicitação subsequente com o mesmo cookie, o balanceador de carga direciona a solicitação para a mesma VM ou o mesmo endpoint de back-end.

  • Em balanceadores de carga HTTP(S) externos, o cookie é chamado de GCLB.
  • Em balanceadores de carga HTTP(S) internos e no Traffic Director, o cookie é denominado GCILB.

A afinidade baseada em cookie pode identificar com mais precisão um cliente para um balanceador de carga, em comparação com a afinidade baseada em IP do cliente. Por exemplo:

  1. Com a afinidade baseada em cookie, o balanceador de carga pode identificar de forma exclusiva dois ou mais sistemas clientes que compartilham o mesmo endereço IP de origem. Usando a afinidade baseada em IP do cliente, o balanceador de carga trata todas as conexões do mesmo endereço IP de origem como se fossem do mesmo sistema cliente.

  2. Se um cliente alterar o próprio endereço IP (por exemplo, um dispositivo móvel migrando de rede para rede), a afinidade baseada em cookie permitirá que o balanceador de carga reconheça conexões subsequentes desse cliente em vez de tratar a conexão como nova.

Quando um balanceador de carga cria um cookie para a afinidade gerada baseada em cookie, ele define o atributo path do cookie como /. Se o mapa de URLs do balanceador de carga tiver uma correspondência de caminhos que especifique mais de um serviço de back-end para um determinado nome de host, todos os serviços de back-end que usam a afinidade da sessão baseada em cookie compartilharão o mesmo cookie de sessão.

A duração do cookie HTTP gerado pelo balanceador de carga é configurável. Defina-a como 0 (padrão), o que significa que o cookie é apenas um cookie de sessão, ou defina a vida útil dele como um valor de 1 a 86400 segundos (24 horas), incluindo esses valores.

Console


Para definir a afinidade de cookie gerado:

  1. No Console do Google Cloud, é possível modificar a afinidade de cookie gerado na parte Configuração de back-end da página do balanceador de carga HTTP(S).
    Acessar a página "Balanceamento de carga"
  2. Selecione o lápis Editar do balanceador de carga.
  3. Selecione Configuração de back-end.
  4. Selecione o lápis Editar de um Serviço de back-end.
  5. Selecione Generated cookie no menu suspenso Afinidade da sessão para selecionar a afinidade de cookie gerado.
  6. No campo TTL do cookie de afinidade, defina a duração do cookie em segundos.
  7. Clique no botão Atualizar do Serviço de back-end.
  8. Clique no botão Atualizar do balanceador de carga.

gcloud


Ative a afinidade de cookie gerado definindo --session-affinity como generated_cookie e --affinity-cookie-ttl como a vida útil do cookie em segundos. Use o comando create para configurá-la para um novo serviço de back-end ou o comando update para configurá-la para um serviço de back-end atual. Neste exemplo, mostramos como usá-lo com o comando update.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity generated_cookie \
        --affinity-cookie-ttl 86400
    

API


Consulte a referência da API para serviços de back-end.

Como desativar a afinidade da sessão

É possível desativar a afinidade da sessão atualizando o serviço de back-end e definindo-a como none. Outra alternativa é editar o serviço de back-end e definir a afinidade da sessão como none em um editor de texto. Também é possível usar um desses dois comandos para modificar a duração do cookie.

Console


Para desativar a afinidade da sessão:

  1. No Console do Google Cloud, é possível desativar a afinidade da sessão na parte Configuração de back-end da página do balanceador de carga.
    Acessar a página "Balanceamento de carga"
  2. Selecione o lápis Editar do balanceador de carga.
  3. Selecione Configuração de back-end.
  4. Selecione o lápis Editar de um Serviço de back-end.
  5. Selecione None no menu suspenso Afinidade da sessão para desativar a afinidade da sessão.
  6. Clique no botão Atualizar do Serviço de back-end.
  7. Clique no botão Atualizar do balanceador de carga.

gcloud


Para desativar a afinidade da sessão, execute o comando a seguir:

      gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
      --session-affinity none
    


OU

gcloud compute backend-services edit [BACKEND_SERVICE_NAME]

API


Consulte a referência da API para serviços de back-end.

Perda da afinidade da sessão

Seja qual for o tipo de afinidade escolhido, um cliente pode perder afinidade com a instância nos cenários descritos a seguir.

  • O grupo de instâncias fica sem capacidade e o tráfego precisa ser encaminhado para uma zona diferente. Neste caso, o tráfego das sessões atuais pode ser enviado para a nova zona, interrompendo a afinidade. Isso pode ser minimizado garantindo que os grupos de instâncias tenham capacidade suficiente para lidar com todos os usuários locais.
  • O escalonamento automático adiciona ou remove instâncias do grupo de instâncias. Nos dois casos, o serviço de back-end realoca a carga e o destino pode ser transferido. Isso pode ser minimizado garantindo que o número mínimo de instâncias provisionadas pelo escalonamento automático seja suficiente para lidar com a carga esperada e usando o escalonamento automático apenas para aumentos inesperados de carga.
  • A instância de destino falha nas verificações de integridade. A afinidade é perdida quando a sessão é transferida para uma instância íntegra.
  • O modo de balanceamento é definido como utilização de back-end, o que pode alterar as capacidades calculadas entre as zonas, enviando algum tráfego para outra zona dentro da região. É mais provável que isso ocorra com baixo tráfego, quando a capacidade calculada é menos estável.
  • A afinidade da sessão pode ser perdida quando os back-ends estão em várias regiões da nuvem e o roteamento do cliente é projetado para que a primeira solicitação e as subsequentes em uma conexão sejam provenientes de locais geográficos diferentes. Isso ocorre porque as solicitações adicionais podem ser roteadas para uma região da nuvem diferente, que é determinada pelo novo local de saída.

Como configurar o tempo limite

Para ter conexões de longa duração com o serviço de back-end a partir do balanceador de carga, configure um tempo limite padrão superior a 30 segundos.

Console


Para configurar o tempo limite:

  1. No Console do Google Cloud, é possível modificar a configuração de tempo limite na parte Configuração de back-end da página do balanceador de carga HTTP(S).
    Acessar a página "Balanceamento de carga"
  2. Selecione o lápis Editar do balanceador de carga.
  3. Selecione Configuração de back-end.
  4. Selecione o lápis Editar do Serviço de back-end.
  5. Na linha das configurações de protocolo, porta e tempo limite, selecione o lápis Editar.
  6. Digite uma nova Configuração de tempo limite em segundos.
  7. Clique no botão Atualizar do Serviço de back-end.
  8. Clique no botão Atualizar do balanceador de carga.

gcloud


Para alterar a configuração de tempo limite com a ferramenta de linha de comando gcloud, use o comando "gcloud compute backend-services update". Anexe --help ao comando para receber informações detalhadas.

gcloud compute backend-services update [BACKEND_SERVICE] [--timeout=TIMEOUT]
    

API


Consulte a referência da API REST para serviços de back-end.

Portas nomeadas

Para balanceadores de carga HTTP(S) internos, HTTP(S) externos, de Proxy SSL e de Proxy TCP, é necessário que os serviços de back-end tenham uma porta nomeada associada para o caso de os back-ends deles serem grupos de instâncias. A porta nomeada informa ao balanceador de carga que ele tem que usá-la configurada no grupo de instâncias de back-end, o que a transforma em um número de porta. Essa é a porta que o balanceador de carga usa para conectar as VMs de back-end, que pode ser diferente da porta que os clientes usam para fazer contato com o próprio balanceador de carga.

As portas nomeadas são pares de chave-valor que representam um nome de serviço e um número de porta em que um serviço está em execução. O par de chave-valor é definido em um grupo de instâncias. Quando um serviço de back-end usa esse grupo de instâncias como back-end, ele pode "se inscrever" na porta nomeada:

  • Cada grupo de instâncias pode ter até cinco portas nomeadas (pares de chave-valor) definidas.
  • Cada serviço de back-end para um balanceador de carga HTTP(S), de Proxy SSL ou de Proxy TCP que usa back-ends de grupos de instâncias só pode "se inscrever" em uma porta nomeada.
  • Ao especificar uma porta nomeada para um serviço de back-end, todos os grupos de instâncias de back-end precisam ter pelo menos uma porta nomeada definida que use esse mesmo nome.

Portas nomeadas não podem ser usadas nestas circunstâncias:

  • Para back-ends de NEG: os NEGs definem as portas por endpoint, e não há nenhum par de chave-valor de porta nomeada associado a um NEG.
  • Para balanceadores de carga TCP/UDP internos: como eles são balanceadores de carga de passagem (e não proxies), os serviços de back-end deles não são compatíveis com a configuração de uma porta nomeada.

Verificações de integridade

É necessário que cada serviço de back-end tenha uma verificação de integridade associada a ele. A verificação de integridade tem que ser anterior à criação do serviço de back-end.

A verificação de integridade é executada continuamente e os resultados dela ajudam a determinar quais instâncias são capazes de receber novas solicitações.

Instâncias não íntegras não recebem novas solicitações e continuam a ser consultadas. Se uma instância não íntegra for aprovada em uma verificação de integridade, ela será considerada íntegra e começará a receber novas conexões.

Para mais informações, leia os seguintes documentos:

Como ver os resultados de uma verificação de integridade dos serviços de back-end

Após a criação das verificações de integridade e do serviço de back-end, os resultados da verificação de integridade poderão ser visualizados.

Console


Para ver o resultado de uma verificação de integridade em um serviço de back-end:

  1. Acesse a página de resumo do balanceamento de carga.
    Acessar a página "Balanceamento de carga"
  2. Clique no nome de um balanceador de carga.
  3. Em Back-end, veja a coluna Íntegros na tabela Grupo de instâncias de um Serviço de back-end.

gcloud


Para ver os resultados da verificação de integridade mais recente com a ferramenta de linha de comando gcloud, use o comando backend-services get-health.

gcloud compute backend-services get-health [BACKEND_SERVICE]
    

O comando retorna um valor healthState para todas as instâncias no serviço de back-end especificado, com um valor HEALTHY ou UNHEALTHY:

      healthStatus:
        - healthState: UNHEALTHY
          instance: us-central1-b/instances/www-video1
        - healthState: HEALTHY
          instance: us-central1-b/instances/www-video2
      kind: compute#backendServiceGroupHealth
      

API


Para comandos da API, consulte a página Verificações de integridade.

Recursos adicionais ativados no recurso do serviço de back-end

Não serão discutidos neste documento os seguintes recursos opcionais do Google Cloud, que são ativados com o recurso de serviço de back-end:

Outras observações

As alterações nos serviços de back-end não são instantâneas. Pode levar vários minutos para que as alterações sejam propagadas pela rede.

Estes recursos do Traffic Director não são compatíveis com os balanceadores de carga do Google Cloud:

  • Disjuntores
  • Detecção de outliers
  • Políticas de balanceamento de carga
  • Afinidade da sessão baseada em cookie HTTP
  • Afinidade da sessão baseada em cabeçalho HTTP

A seguir

Para documentação relacionada e informações sobre como os serviços de back-end são usados no balanceamento de carga, analise o seguinte: