Conceitos de verificação de integridade

O Google Cloud Platform (GCP) fornece mecanismos de verificação de integridade que determinam se os back-ends, como grupos de instâncias e grupos de endpoints da rede (NEGs, na sigla em inglês), respondem adequadamente ao tráfego. Neste documento, você verá conceitos de verificação de integridade específicos do GCP e dos balanceadores de carga.

Visão geral

O GCP fornece sistemas de verificação de integridade globais e regionais que se conectam a back-ends de modo configurável e periódico. Cada tentativa de conexão é chamada de uma sondagem, e o GCP registra o sucesso ou a falha de cada uma delas.

As verificações de integridade e os balanceadores de carga trabalham juntos. Com base em um número configurável de sondagens sequenciais com sucesso ou com falha, o GCP calcula um estado de integridade geral para cada back-end no balanceador de carga. Os back-ends que respondem com êxito pelo número de vezes configurado são considerados íntegros. Aqueles que não respondem com êxito por um número de vezes distinto não são íntegros.

O GCP usa o estado geral de integridade de cada back-end para determinar se está qualificado para receber novas solicitações. Além de configurar a frequência da sondagem e os limites do estado de integridade, é possível configurar os critérios que definem uma sondagem bem-sucedida. Neste documento, há uma descrição detalhada de como as verificações de integridade funcionam.

O GCP usa rotas especiais não definidas em sua rede VPC para verificações de integridade. Para mais informações, leia Caminhos de retorno do balanceador de carga.

Categorias, protocolos e portas da verificação de integridade

O GCP organiza as verificações de integridade por categoria e protocolo.

Há duas categorias de verificação de integridade: verificações de integridade e verificações de integridade legadas. Cada categoria é compatível com um conjunto diferente de protocolos e um meio para especificar a porta usada para a verificação de integridade. O protocolo e a porta determinam como os sistemas de verificação de integridade do GCP entram em contato com seus back-ends. Por exemplo, é possível criar uma verificação de integridade que use o protocolo HTTP na porta TCP 80 ou criar uma verificação de integridade que use o protocolo TCP para uma porta nomeada configurada em um grupo de instâncias.

A maioria dos balanceadores de carga do GCP requer verificações de integridade não legadas, mas o balanceamento de carga de rede exige o uso de verificações de integridade legadas que usam o protocolo HTTP. Consulte Como selecionar uma verificação de integridade para orientações específicas sobre como selecionar a categoria e o protocolo e especificar as portas.

Não é possível converter uma verificação de integridade legada em uma verificação de integridade ou vice-versa.

O termo verificação de integridade não se refere a verificações de integridade legadas. Neste documento, elas são explicitamente chamadas de verificações de integridade legadas.

Como selecionar uma verificação de integridade

As verificações de integridade precisam ser compatíveis com o tipo de balanceador de carga e seus respectivos tipos de back-ends, grupos de instâncias ou grupos de endpoint de rede. Os três fatores que você precisa especificar ao criar uma verificação de integridade são os seguintes:

  • Categoria: verificação de integridade ou verificação de integridade legada, que precisa ser compatível com o balanceador de carga.
  • Protocolo: define qual protocolo os sistemas do GCP usam para sondar periodicamente seus back-ends.
  • Especificação de porta: define quais portas são usadas para o protocolo da verificação de integridade.

O guia no final desta seção resume as combinações válidas de categoria, protocolo e especificação de porta de verificação de integridade com base em um determinado tipo de balanceador de carga e tipo de back-end.

Conforme usado nesta seção, o termo grupo de instâncias refere-se a grupos de instâncias não gerenciadas, grupos de instâncias zonais gerenciadas ou grupos de instâncias regionais gerenciadas.

Categoria e protocolo

O tipo de balanceador de carga e os tipos de back-ends que o balanceador de carga usa determinam a categoria da verificação de integridade. O balanceamento de carga de rede requer verificações de integridade legadas que usam o protocolo HTTP. Para todos os outros tipos de balanceador de carga, use verificações de integridade regulares.

É preciso selecionar um protocolo na lista de protocolos compatíveis com a categoria da verificação de integridade. Recomenda-se usar o mesmo protocolo do balanceador de carga. No entanto, isso não é obrigatório e nem sempre é possível. Por exemplo, os balanceadores de carga de rede exigem verificações de integridade legadas e requerem que elas usem o protocolo HTTP, ainda que o balanceamento de carga de rede ofereça suporte a TCP e UDP em geral. Para balanceadores de carga de rede, você precisa executar um servidor HTTP em suas VMs para que elas possam responder a sondagens de verificação de integridade.

A tabela a seguir lista as categorias da verificação de integridade e os protocolos compatíveis com cada categoria.

Categoria de verificação de integridade Protocolos compatíveis
Verificação de integridade • HTTP
• HTTPS
• HTTP/2
• SSL
• TCP
Verificação de integridade legada • HTTP
• HTTPS. As verificações de integridade de HTTPS legadas não são compatíveis com balanceadores de carga de rede e não podem ser usadas com a maioria dos outros tipos de balanceadores de carga.

Categoria e especificação de porta

Além de um protocolo, é preciso selecionar uma especificação de porta para a verificação de integridade. As verificações de integridade fornecem três métodos de especificação de portas, e as verificações de integridade legadas fornecem um método. Nem todos os métodos de especificação de porta são aplicáveis a cada tipo de balanceador de carga. O tipo de balanceador de carga e os tipos de back-ends usados determinam qual método de especificação de portas é possível usar.

Categoria de verificação de integridade Métodos e significados da especificação de portas
Verificação de integridade --port: especifica um número de porta TCP.
--port-name: especifica qualquer porta nomeada definida em um grupo de instâncias.
--use-serving-port: para grupos de instâncias, use a mesma porta nomeada usada pelo serviço de back-end. Para grupos de endpoint da rede, use a porta definida em cada endpoint.
Verificação de integridade legada --port: especifica um número de porta TCP.

Observação: a sinalização --use-serving-port é implementada com gcloud beta compute health-checks create, mas não com gcloud beta compute health-checks update.

Guia do balanceador de carga

Use esta tabela para escolher a categoria e o protocolo corretos para a verificação de integridade de um determinado balanceador de carga.

Balanceador de carga Tipo de back-end Categoria e escopo da verificação de integridade Especificação da porta
TCP/UDP interno Grupos de instância em um serviço de back-end interno regional Verificação de integridade (global) Número da porta (--port) ou porta nomeada (--port-name).
Não é possível usar a sinalização --use-serving-port porque os serviços de back-end com esquemas de balanceamento de carga INTERNAL não têm uma porta nomeada associada.
HTTP(S) interno Grupos de endpoint da rede
em um serviço de back-end
Verificação de integridade (regional) Número da porta (--port) ou
--use-serving-port
Grupos de instância em um serviço de back-end Verificação de integridade (regional) Número da porta (--port), porta nomeada (--port-name) ou
--use-serving-port
Rede Grupos de instância usando pools de destino Verificação de integridade legada (global)
usando o protocolo HTTP
As verificações de integridade legadas só são compatíveis com a especificação de porta pelo número da porta (--port).
Proxy TCP
Proxy SSL
HTTP(S) 1
Grupos de endpoint da rede
em um serviço de back-end
Verificação de integridade (global) Número da porta (--port) ou
--use-serving-port
Grupos de instância em um serviço de back-end Verificação de integridade (global) Número da porta (--port), porta nomeada (--port-name) ou
--use-serving-port

1É possível, mas não recomendado, usar uma verificação de integridade legada para serviços de back-end associados a balanceadores de carga HTTP(S) nas seguintes circunstâncias:

  • Os back-ends usados pelo serviço de back-end são grupos de instâncias, não grupos de endpoint da rede.
  • As VMs de back-end podem ser sondadas usando HTTP ou HTTPS.

Como as verificações de integridade funcionam

Sondagens

Ao criar uma verificação de integridade ou criar uma verificação de integridade legada, você especifica as seguintes sinalizações ou aceita seus valores padrão. Essas sinalizações controlam a frequência com que cada sistema de verificação de integridade do GCP sonda os back-ends de grupo de instância ou NEG. O GCP implementa sondagens usando vários sistemas.

As configurações de verificação de integridade não podem ser definidas em cada back-end. As verificações de integridade são associadas a um serviço de back-end por completo, e as verificações de integridade legadas estão associadas a um pool de destino ou serviço de back-end para determinados balanceadores de carga HTTP(S). Assim, os parâmetros da sondagem são os mesmos para todos os back-ends referenciados por um determinado serviço de back-end ou pool de destino.

Sinalização de configuração Motivo Valor padrão
Intervalo de verificação
check-interval
O intervalo de verificação é a quantidade de tempo desde o início de uma sondagem emitida por um sistema até o início da próxima sondagem emitida pelo mesmo sistema. As unidades são informadas em segundos. Se omitido, o GCP usa 5s (5 segundos).
Tempo limite
timeout
O tempo limite é o tempo que o GCP aguardará uma resposta a uma sondagem. O valor precisa ser menor ou igual ao intervalo de verificação. As unidades são informadas em segundos. Se omitido, o GCP usa 5s (5 segundos).

Intervalos de IP da sondagem

Os endereços IP de origem dos sistemas de sondagem do GCP dependem do tipo de balanceador de carga. Use a tabela a seguir para criar regras de firewall de permissão de entrada que permitem o tráfego de sistemas de sondagem do GCP para seus back-ends.

Balanceador de carga Intervalos de IP da sondagem Exemplo de regra de firewall
Interno
Proxy TCP
Proxy SSL
HTTP(S)
HTTP(S) interno
35.191.0.0/16
130.211.0.0/22
Regras de firewall para todos os balanceadores de carga, exceto balanceadores de carga de rede
Rede 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Regras de firewall para balanceadores de carga de rede

Várias sondagens e frequências

O GCP envia sondagens de verificação de integridade de vários sistemas redundantes a partir dos intervalos de IP de origem apropriados. Nenhum sistema é responsável por todas as sondagens. Vários sistemas emitem sondagens simultaneamente para que a falha de um deles não faça com que o GCP perca o controle dos estados de integridade do back-end.

As configurações de intervalo e de tempo limite definidas para uma verificação de integridade são aplicadas a cada sistema de sondagem. Para um determinado back-end, os registros de acesso ao software e o tcpdump mostram sondagens de verificação de integridade mais frequentes do que as configurações definidas. Vários sistemas de sondagem que entram em contato com seus back-ends simultaneamente resultam em mais sondagens de verificação de integridade do que a configuração de um único sistema.

Esse é o comportamento esperado e não é possível configurar o número de sistemas de sondagem que o GCP usa para verificações de integridade. No entanto, é possível estimar o efeito de várias sondagens simultâneas considerando os seguintes fatores:

  • Para estimar a frequência de sondagem por serviço de back-end, considere o seguinte:

    • Frequência de base por serviço de back-end: cada verificação de integridade tem uma frequência de verificação associada, inversamente proporcional ao intervalo de verificação configurado:

      1(intervalo de verificação)

      Ao associar uma verificação de integridade a um serviço de back-end, você estabelece uma frequência de base usada por cada sistema de sondagem para back-ends nesse serviço de back-end.

    • Fator de escala da sondagem: a frequência de base do serviço de back-end é multiplicada pelo número de sistemas de sondagens simultâneas que o GCP usa. Esse número pode variar, mas geralmente fica entre 5 e 10.

  • Várias regras de encaminhamento para balanceadores de carga TCP/UDP internos: se você tiver configurado várias regras de encaminhamento internas, cada uma com um endereço IP diferente, apontando para o mesmo serviço de back-end interno regional, o GCP usará vários sistemas de sondagem para verificar cada endereço IP. A frequência de sondagem por serviço de back-end é multiplicada pelo número de regras de encaminhamento configuradas.

  • Várias regras de encaminhamento para balanceadores de carga de rede: se você tiver configurado várias regras de encaminhamento que apontem para o mesmo pool de destino, o GCP usará vários sistemas de sondagem para verificar cada endereço IP. A frequência da sondagem conforme vista por cada back-end no pool de destino é multiplicada pelo número de regras de encaminhamento configuradas.

  • Vários proxies de destino para balanceadores de carga HTTP(S): se você configurou vários proxies de destino para o mesmo mapa de URLs para o balanceamento de carga HTTP(S), o GCP usa vários sistemas de sondagem para verificar o endereço IP associado a cada proxy de destino. A frequência de sondagem por serviço de back-end é multiplicada pelo número de proxies de destino configurados.

  • Vários proxies de destino para balanceadores de carga de proxy TCP e de proxy SSL: se você tiver configurado vários proxies de destino para o mesmo serviço de back-end para proxy SSL ou proxy TCP, o GCP usará vários sistemas de sondagem para verificar o endereço IP associado a cada proxy de destino. A frequência de sondagem por serviço de back-end é multiplicada pelo número de proxies de destino configurados.

  • Soma por serviços de back-end: se um back-end, como um grupo de instâncias, for usado por vários serviços de back-end, as instâncias de back-end serão contatadas com a mesma frequência que a soma das frequências para cada verificação de integridade do serviço de back-end.

    Com os back-ends de grupos de endpoints de rede (NEGs, na sigla em inglês), é mais difícil determinar o número exato de sondagens de verificação de integridade. Por exemplo, o mesmo endpoint pode estar em vários NEGs, em que esses NEGs não têm necessariamente o mesmo conjunto de endpoints, e endpoints diferentes podem apontar para o mesmo back-end.

Destino dos pacotes de verificação de integridade

As sondagens de verificação de integridade do GCP enviam pacotes somente para a interface de rede principal de cada instância de back-end. O endereço IP de destino desses pacotes depende do tipo de balanceador de carga:

  • Para balanceadores de carga TCP/UDP internos e balanceadores de carga de rede, o destino dos pacotes de verificação de integridade é o endereço IP da regra de encaminhamento do balanceador de carga. Se várias regras de encaminhamento apontarem para o mesmo pool de destino ou serviço de back-end, o GCP enviará sondagens para cada endereço IP da regra de encaminhamento. Isso pode resultar em um aumento no número de sondagens, conforme descrito na seção anterior.
  • Para balanceadores de carga HTTP(S), proxy TCP, proxy SSL e HTTP(S) interno que usam grupos de instância como back-end, o destino dos pacotes de verificação de integridade é o endereço IP interno principal associado à interface de rede principal de cada instância de back-end.
  • Para balanceadores de carga HTTP(S), HTTP(S) interno, de proxy TCP e de proxy SSL que usam grupos de endpoints de rede como back-end, o destino dos pacotes de verificação de integridade é o endereço IP do endpoint, que pode ser o endereço de IP do alias primário ou secundário.

Verificações de integridade com base em conteúdo

Como alternativa, as verificações de integridade HTTP(S), HTTP/2, TCP e SSL podem ser baseadas em conteúdo (solicitação/resposta). Em uma verificação baseada em conteúdo, a sondagem envia uma string de solicitação para o back-end. A verificação de integridade está configurada para esperar uma resposta específica para a sondagem.

Critérios de sucesso para HTTP, HTTPS e HTTP/2

As respostas das sondagens para verificações de integridade usando protocolos HTTP, HTTPS ou HTTP / 2 são bem-sucedidas somente se o GCP receber uma resposta HTTP 200 (OK) à solicitação enviada e se a resposta for entregue antes do tempo limite da sondagem.

Os pedidos são enviados para um caminho de solicitação configurável, ou /, se não especificado. Qualquer resposta é aceita, a menos que você use a verificação baseada em conteúdo para fornecer uma string de resposta esperada. As sinalizações disponíveis para controlar critérios de sucesso para verificações de integridade HTTP, HTTPS e HTTP/2 são as seguintes:

Sinalização de configuração Motivo
Solicitar caminho
request-path
Especifique o caminho do URL para o qual o GCP envia solicitações de sondagem de verificação de integridade.
Se omitido, o GCP enviará essas solicitações para o caminho raiz, /. A opção request-path não é compatível com parâmetros de consulta.
Resposta
response
A sinalização de resposta opcional permite que você configure uma verificação de integridade com base em conteúdo. A string de resposta esperada precisa ser menor ou igual a 1.024 caracteres ASCII (byte único). Quando configurada, o GCP espera essa sequência dentro dos primeiros 1.024 bytes da resposta, além de receber o status HTTP 200 (OK).

O uso de uma verificação de integridade com base em conteúdo é opcional. Quer você tenha especificado ou não uma string de resposta esperada, o GCP espera que o back-end verificado responda com HTTP 200 (OK). Quando você fornece uma resposta esperada, cada sondagem de verificação de integridade do GCP pesquisa a resposta fornecida por seus back-ends, procurando a string de resposta esperada nos primeiros 1.024 bytes retornados. Uma verificação de integridade de HTTP baseada em conteúdo será considerada bem-sucedida se HTTP 200 (OK) for recebido e a resposta esperada for encontrada nos primeiros 1.024 bytes da resposta retornada.

Critérios de sucesso para SSL e TCP

Por padrão, as respostas de sondagens para verificações de integridade usando protocolos SSL e TCP são bem-sucedidas somente se o GCP conseguir concluir um handshake SSL ou TCP para estabelecer uma sessão antes do tempo limite da sondagem.

Além de concluir um handshake, outra opção possível é fornecer uma string de solicitação e uma string de resposta esperada, cada uma com até 1.024 caracteres ASCII (byte único) de comprimento. Quando uma string de resposta esperada é configurada, o GCP considera uma sondagem bem-sucedida somente se o handshake TCP ou SSL for concluído e a string de resposta corresponder exatamente à string de resposta esperada. As seguintes combinações de sinalizações de solicitação e resposta estão disponíveis para verificações de integridade usando os protocolos SSL e TCP:

Sinalizações de configuração Comportamento
Nenhuma solicitação ou resposta especificada
Nenhuma sinalização especificada: --request, --response
O GCP considerará que a sondagem será bem-sucedida se a sessão TCP ou SSL for estabelecida antes do tempo limite da sondagem.
Solicitação e resposta especificadas
Ambas as sinalizações especificadas: --request, --response
O GCP envia a string de solicitação configurada e aguarda a string de resposta esperada. A sondagem será bem-sucedida se a sessão TCP ou SSL for estabelecida e a string de resposta retornada corresponder exatamente à string de resposta esperada antes do tempo limite da sondagem.
Somente a resposta especificada
Sinalizações especificadas: somente --response
O GCP aguarda a string de resposta esperada. A sondagem será bem-sucedida se a sessão TCP ou SSL for estabelecida e a string de resposta retornada corresponder exatamente à string de resposta esperada antes do tempo limite da sondagem.
Use --response por si só apenas se seus back-ends que estão recebendo balanceamento de carga automático enviarem uma string de resposta como parte do handshake.
Somente a solicitação especificada
Sinalizações especificadas: somente --request
O GCP envia sua string de solicitação configurada. A sondagem será bem-sucedida se uma sessão TCP ou SSL for estabelecida antes do tempo limite da sondagem. A resposta, se houver, não é verificada.

Estado de integridade

O GCP usa as seguintes sinalizações de configuração e verifica se as sondagens foram bem-sucedidas para determinar o estado de integridade geral de cada back-end que está recebendo balanceamento de carga:

Sinalização de configuração Motivo Valor padrão
Limite íntegro
healthy-threshold
O limite íntegro especifica o número de resultados sequenciais de sondagem bem-sucedidos para que um back-end seja considerado íntegro. Se omitido, o GCP usará um limite de 2 sondagens.
Limite não íntegro
unhealthy-threshold
O limite não íntegro especifica o número de resultados de sondagem sequencial com falha para que um back-end seja considerado não íntegro. Se omitido, o GCP usará um limite de 2 sondagens.

O GCP considera que os back-ends são íntegros se o limite de integridade for cumprido. Os back-ends íntegros estão qualificados para receber novas conexões.

O GCP considera que os back-ends não são íntegros se o limite de falta de integridade for cumprido. Os back-ends não íntegros não estão qualificados para receber novas conexões. No entanto, as conexões atuais não são encerradas imediatamente. Em vez disso, a conexão permanece aberta até que o tempo limite seja atingido ou até que o tráfego seja interrompido. O comportamento específico varia de acordo com o tipo de balanceador de carga que você está usando.

Conexões atuais podem não retornar respostas, dependendo da causa da falha da sondagem. Um back-end não íntegro pode se tornar íntegro se for capaz de atingir o limite de integridade novamente.

A seguir

Para informações sobre como configurar verificações de integridade, consulte Como criar verificações de integridade.