Visão geral das verificações de integridade

O Google Cloud oferece mecanismos de verificação de integridade que determinam se back-ends, como grupos de instâncias e grupos de endpoints da rede (NEGs, na sigla em inglês) por zona, estão respondendo de maneira adequada ao tráfego. Neste documento, discutimos conceitos de verificação de integridade específicos dos balanceadores de carga do Google Cloud e do Traffic Director.

O Google Cloud oferece sistemas de verificação de integridade global e regional que se conectam a back-ends de maneira configurável e periódica. Cada tentativa de conexão é chamada de sondagem, e cada sistema de verificação de integridade é chamado de sonda. O Google Cloud registra o sucesso ou o fracasso de cada sondagem.

As verificações de integridade funcionam com balanceadores de carga e Traffic Director. Com base em um número configurável de sondagens sequenciais com sucesso ou com falha, o Google Cloud calcula um estado de integridade geral para cada back-end no balanceador de carga ou no Traffic Director. 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 Google Cloud usa o estado geral de integridade de cada back-end para determinar se eles estão qualificados para receber novas solicitações ou conexõ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. Isso é abordado em detalhes na seção Como as verificações de integridade funcionam.

O Google Cloud usa rotas especiais não definidas na sua rede de nuvem privada virtual (VPC) para verificações de integridade. Para informações completas, consulte Caminhos de retorno do balanceador de carga.

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

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

As duas categorias são 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 Google Cloud entram em contato com os 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.

O Traffic Director e a maioria dos balanceadores de carga do Google Cloud exigem verificações de integridade não legadas, mas o balanceamento de carga de rede exige verificações de integridade legadas que usam o protocolo HTTP. Encontre orientações específicas sobre como selecionar a categoria, o protocolo e as portas na próxima seção, Como selecionar uma verificação de integridade.

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

Como selecionar uma verificação de integridade

As verificações de integridade precisam ser compatíveis com o Traffic Director ou com o tipo de balanceador de carga e os tipos de back-ends (grupos de instâncias ou NEGs zonais) usados pelo produto. Os três fatores que precisam ser especificados 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 Google Cloud usarão para sondar periodicamente os 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.

Para informações sobre os tipos de verificações de integridade compatíveis com vários balanceadores de carga, consulte Verificações de integridade.

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 usem o protocolo HTTP. Todos os outros tipos de balanceador de carga usam verificações de integridade normais.

É preciso selecionar um protocolo na lista de protocolos compatíveis com a categoria da verificação de integridade. Usar o mesmo protocolo do balanceador de carga é uma prática recomendada, mas 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. No caso dos balanceadores de carga de rede, é preciso executar um servidor HTTP nas instâncias de máquina virtual (VM) para responder às sondagens de verificação de integridade.

Na tabela a seguir estão listadas 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 • gRPC
• HTTP
• HTTPS
• HTTP/2 (com TLS)
• SSL
• TCP
Verificação de integridade legada • HTTP
• HTTPS

As verificações de integridade legadas com HTTPS 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 que o balanceador de carga usa determinam qual método de especificação de portas pode ser usado.

Categoria de verificação de integridade Métodos e significados da especificação de portas
Verificação de integridade --port: especifique um número de porta TCP
--use-serving-port:
• para grupos de instâncias, use a porta nomeada em que o serviço de back-end se inscreve para
• para NEGs zonais, use a porta definida em cada endpoint
Verificação de integridade legada --port: especificar um número de porta TCP

Guia do balanceador de carga

Nesta tabela são listadas as especificações de categoria, escopo e porta compatíveis com cada balanceador de carga e tipo de back-end do Google Cloud.

Balanceador de carga Tipo de back-end Categoria e escopo da verificação de integridade Especificação da porta
Balanceamento de carga TCP/UDP interno 1 Grupos de instâncias Verificação de integridade (global ou regional)
  • Número de porta personalizado (--port)
Balanceamento de carga HTTP(S) interno NEGs por zona Verificação de integridade (regional)
  • Número de porta personalizado (--port)
  • Número de porta do endpoint (--use-serving-port)
Grupos de instâncias Verificação de integridade (regional)
  • Número de porta personalizado (--port)
  • Porta nomeada do serviço de back-end (--use-serving-port)
Network Load Balancing Instâncias nos
pools de destino
Verificação de integridade legada (global) que usa o protocolo HTTP As verificações de integridade legadas só são compatíveis com a especificação de número da porta (--port).
Balanceamento de carga HTTP(S) externo 2

Balanceamento de carga de proxy TCP

Balanceamento de carga de proxy SSL
NEGs por zona Verificação de integridade (global)
  • Número de porta personalizado (--port)
  • Número de porta do endpoint (--use-serving-port)
Grupos de instâncias Verificação de integridade (global)
  • Número de porta personalizado (--port)
  • Porta nomeada do serviço de back-end (--use-serving-port)

1 Não é possível usar a sinalização --use-serving-port porque os serviços internos de back-end não têm uma porta nomeada associada.
2 É 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) externos nas seguintes circunstâncias:

  • Os back-ends são grupos de instâncias, e não NEGs por zona.
  • As VMs de back-end exibem tráfego que usa protocolos HTTP ou HTTPS.

Como as verificações de integridade funcionam

Veja nas seções a seguir 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 sinalizações a seguir ou aceita os valores padrão. Cada verificação de integridade ou verificação de integridade legada criada é implementada por várias sondagens. Essas sinalizações controlam com que frequência cada sondagem de verificação de integridade do Google Cloud avalia as instâncias em back-ends de grupos de instâncias ou em endpoints nos back-ends de NEG por zona.

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 todo o serviço de back-end, e as verificações de integridade legadas são associadas a todo o pool de destino (para balanceamento de carga de rede) ou serviço de back-end (para determinadas configurações de balanceamento de carga HTTP(S) externo). 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 é o tempo desde o início de uma sondagem emitida por uma sonda até o início da próxima sondagem emitida pela mesma sonda. As unidades são informadas em segundos. Se omitido, o Google Cloud usa 5s (5 segundos).
Tempo limite
timeout
O tempo limite é o tempo que o Google Cloud aguarda a resposta de uma sondagem. O valor precisa ser menor ou igual ao intervalo de verificação. As unidades são informadas em segundos. Se omitido, o Google Cloud usa 5s (5 segundos).

Intervalos de IP e regras de firewall da sondagem

Para que as verificações de integridade funcionem, é preciso criar regras de firewall de entrada allow para que o tráfego das sondas do Google Cloud se conecte aos back-ends.

A tabela a seguir mostra os intervalos de IP de origem a serem permitidos:

Produto Intervalos de IPs de origem da sondagem Exemplo de regra de firewall
Balanceamento de carga TCP/UDP interno
Balanceamento de carga HTTP(S) interno
Balanceamento de carga HTTP(S) externo
Balanceamento de carga de proxy SSL
Balanceamento de carga de proxy TCP
Traffic Director
35.191.0.0/16
130.211.0.0/22
Regras de firewall para todos os produtos, exceto balanceadores de carga de rede
Network Load Balancing 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Regras de firewall para balanceadores de carga de rede

Importância das regras de firewall

No Google Cloud, é preciso criar as regras de firewall de entrada allow necessárias para permitir o tráfego das sondas para os back-ends. Como prática recomendada, limite essas regras apenas aos protocolos e portas que correspondem aos usados pelas verificações de integridade. Para os intervalos de IPs de origem, use os intervalos de IPs da sondagem listados na seção anterior.

Se não forem estabelecidas regras de firewall allow que permitam o protocolo, a porta e o intervalo de IPs de origem usados pela verificação de integridade, a regra de firewall de entrada deny implícita bloqueará o tráfego de entrada de todas as fontes. Quando não é possível estabelecer o contato entre as sondas e os back-ends, o balanceador de carga do Google Cloud categoriza todos os seus back-ends como não íntegros. O comportamento quando nenhum back-end é íntegro depende do tipo de balanceador de carga:

  • Balanceadores de carga HTTP(S) externos retornam respostas HTTP 502 para os clientes quando nenhum back-end é íntegro.

  • Balanceadores de carga HTTP(S) internos retornam respostas HTTP 503 para os clientes quando nenhum back-end é íntegro.

  • Balanceadores de carga de proxy SSL e TCP esgotam o tempo limite quando nenhum back-end está íntegro.

  • Balanceadores de carga de rede tentam distribuir o tráfego para todas as VMs de back-end quando nenhum back-end é íntegro, como último recurso.

  • Balanceadores de carga TCP/UDP internos sem configuração de failover distribuem o tráfego para todas as VMs de back-end quando nenhum back-end é íntegro, como último recurso. É possível desativar esse comportamento ativando o failover.

Considerações de segurança para intervalos de IP da sondagem

Considere as seguintes informações ao planejar as verificações de integridade e as regras de firewall necessárias:

  • Os intervalos de IP da sondagem pertencem ao Google. O Google Cloud usa rotas especiais fora da rede VPC, mas dentro da rede de produção do Google, para facilitar a comunicação das sondas.

  • O Google usa os intervalos de IPs da sondagem exclusivamente para executar sondagens de verificação de integridade e enviar o tráfego dos Googles Front End (GFEs) para os balanceadores de carga HTTP(S) externos, de proxy SSL e de proxy TCP. Se um pacote for recebido da Internet (incluindo o endereço IP externo de uma instância do Compute Engine ou um nó do Google Kubernetes Engine), e o endereço IP de origem do pacote estiver dentro de um intervalo de IPs de sondagem, o Google descartará o pacote.

  • Os intervalos de IPs de sondagem são um conjunto completo de possíveis endereços IP usados pelas sondas do Google Cloud. Se você usar tcpdump ou uma ferramenta semelhante, talvez não observe o tráfego de todos os endereços IP em todos os intervalos de IPs da sondagem. Como prática recomendada, crie a regra de firewall de entrada allow para o balanceador de carga usando todos os intervalos de IPs de sondagem como origens. Isso possibilita que o Google Cloud implemente novas sondas automaticamente sem notificação.

Várias sondagens e frequências

O Google Cloud envia sondagens de verificação de integridade de vários sistemas redundantes chamados sondas. As sondas usam intervalos de IP de origem específicos. O Google Cloud não depende de apenas uma sonda para implementar uma verificação de integridade. Várias sondas avaliam simultaneamente as instâncias em back-ends de grupos de instâncias ou os endpoints em back-ends de NEGs por zona. Se uma sonda falhar, o Google Cloud continuará rastreando os estados de integridade do back-end.

As configurações do intervalo e do tempo limite definidas para uma verificação de integridade são aplicadas a cada sonda. Para um determinado back-end, os registros de acesso ao software e o tcpdump mostram as sondagens mais frequentes do que as configurações definidas.

Esse é o comportamento esperado, e não é possível configurar o número de sondas que o Google Cloud usa para as verificações de integridade. No entanto, é possível estimar o efeito de várias sondagens simultâneas considerando os fatores a seguir.

  • 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 sonda para os back-ends nesse serviço.

    • Fator de escala de sondagem. A frequência de base do serviço de back-end é multiplicada pelo número de sondagens simultâneas usadas pelo Google Cloud. Esse número pode variar, mas costuma ser 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 interno de back-end regional, o Google Cloud usará várias sondas 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 apontam para o mesmo pool de destino, o Google Cloud usará várias sondas para verificar cada endereço IP. A frequência da sondagem conforme vista por cada instância no pool de destino é multiplicada pelo número de regras de encaminhamento configuradas.

  • Vários proxies de destino para balanceadores de carga HTTP(S) externos. Se você tiver configurado vários proxies de destino que direcionam o tráfego para o mesmo mapa de URL do balanceamento de carga HTTP(S) externo, o Google Cloud usará várias sondas 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 SSL e TCP. Se você tiver configurado vários proxies de destino que direcionam o tráfego para o mesmo serviço de back-end do balanceamento de carga de proxy SSL ou TCP, o Google Cloud usará várias sondas 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 referente a cada verificação de integridade do serviço de back-end.

    Com os back-ends de NEG por zona, é mais difícil determinar o número exato de sondagens de verificação de integridade. Por exemplo, um mesmo endpoint pode estar em vários NEGs por zonas, sendo que os NEGs por zona não necessariamente têm o mesmo conjunto de endpoints, e endpoints diferentes podem apontar para o mesmo back-end.

Destino dos pacotes de sondagem

A tabela a seguir mostra a interface de rede e os endereços IP de destino para onde as sondas de verificação de integridade enviam pacotes, dependendo do tipo de balanceador de carga.

Para balanceadores de carga de rede e balanceadores de carga TCP/UDP internos, o aplicativo precisa se vincular ao endereço IP do balanceador de carga (ou a qualquer endereço IP 0.0.0.0).

Balanceador de carga Interface de rede de destino Endereço IP de destino
Balanceamento de carga TCP/UDP interno A interface de rede da instância localizada na rede especificada para o serviço de back-end interno. Se não for especificada, a interface de rede principal (nic0) será usada.

Para mais informações, consulte Serviços de back-end e interfaces de rede.
O endereço IP da regra de encaminhamento interna.

Se várias regras de encaminhamento apontarem para o mesmo serviço de back-end, o Google Cloud enviará sondagens para cada endereço IP da regra de encaminhamento. Isso pode resultar em um aumento no número de sondagens.
Network Load Balancing Interface de rede principal (nic0) O endereço IP da regra de encaminhamento externo.

Se várias regras de encaminhamento apontarem para o mesmo pool de destino, o Google Cloud enviará as sondagens para cada endereço IP da regra de encaminhamento. Isso pode resultar em um aumento no número de sondagens.
Balanceamento de carga HTTP(S) externo

Balanceamento de carga HTTP(S) interno

Balanceamento de carga de proxy SSL

Balanceamento de carga de proxy TCP

Interface de rede principal (nic0)
  • Para back-ends de grupos de instâncias, o endereço IP interno principal associado à interface de rede principal (nic0) de cada instância.
  • Para back-ends de NEG por zona, o endereço IP do endpoint, que é um endereço IP interno principal ou um intervalo de IPs de alias (da interface de rede principal, nic0, na instância que hospeda o endpoint).

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

Quando uma verificação de integridade usa o protocolo HTTP, HTTPS ou HTTP/2, cada sondagem exige que um código de resposta HTTP 200 (OK) seja enviado antes do tempo limite da sondagem. Além disso, há outras possibilidades:

  • É possível configurar as sondas do Google Cloud para enviar solicitações HTTP para um caminho de solicitação específico. Se nenhum caminho de solicitação for especificado, será usado /.

  • Se for configurada uma verificação de integridade com base em conteúdo com uma string de resposta esperada especificada, o Google Cloud precisará encontrar a string esperada nos primeiros 1.024 bytes da resposta HTTP.

  • Se for configurada uma string de resposta esperada, cada sondagem de verificação de integridade do Google Cloud precisará encontrar a string de resposta esperada nos primeiros 1.024 bytes da resposta real dos back-ends.

As combinações de caminho de solicitação e sinalizações de string de resposta a seguir estão disponíveis para verificações de integridade que usam os protocolos HTTP, HTTPS e HTTP/2.

Sinalização de configuração Critérios de sucesso
Caminho da solicitação
request-path
Especifique o caminho do URL para o qual o Google Cloud envia solicitações de sondagem de verificação de integridade.
Se for omitido, o Google Cloud enviará solicitações de sondagem 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 configurado, o Google Cloud espera essa string nos primeiros 1.024 bytes da resposta além de receber o status HTTP 200 (OK).

Critérios de sucesso para SSL e TCP

A menos que você especifique uma string de resposta esperada, as sondagens das verificações de integridade que usam os protocolos SSL e TCP são bem-sucedidas quando as duas condições de base a seguir são verdadeiras:

  • Cada sonda do Google Cloud consegue concluir um handshake de SSL ou TCP antes do tempo limite configurado para a sondagem.
  • Nos casos de verificações de integridade de TCP, a sessão TCP é encerrada normalmente pelo back-end ou pela sonda do Google Cloud, ou o back-end envia um pacote TCP RST (reset) enquanto a sessão TCP da sonda ainda está estabelecida.

Tenha em mente que se o back-end enviar um pacote TCP RST (reset) para encerrar uma sessão TCP de uma verificação de integridade TCP depois que a sonda do Google Cloud iniciar um encerramento normal de TCP, a sondagem poderá ser considerada malsucedida.

É possível criar uma verificação de integridade baseada em conteúdo fornecendo uma string de solicitação e uma string de resposta esperada, cada uma com até 1.024 caracteres ASCII (byte único). Quando uma string de resposta esperada é configurada, o Google Cloud só considera uma sondagem bem-sucedida se as condições de base forem atendidas e a string de resposta retornada corresponder exatamente à esperada.

As combinações de sinalizações de solicitação e resposta a seguir estão disponíveis para verificações de integridade que usam os protocolos SSL e TCP.

Sinalizações de configuração Critérios de sucesso
Nem solicitação nem resposta especificadas

Nenhuma sinalização especificada: --request, --response
O Google Cloud considera a sondagem bem-sucedida quando as condições de base são atendidas.
Solicitação e resposta especificadas

Ambas as sinalizações especificadas: --request, --response
O Google Cloud envia a string de solicitação configurada e aguarda a string de resposta esperada. O Google Cloud considera a sondagem bem-sucedida quando as condições básicas são atendidas e a string de resposta retornada corresponde exatamente à esperada.
Somente resposta especificada

Sinalizações especificadas: somente --response
O Google Cloud aguarda a string de resposta esperada e considera a sondagem bem-sucedida quando as condições básicas são atendidas e a string de resposta retornada corresponde exatamente à esperada.

--response só deverá ser usada sozinha se os back-ends enviarem automaticamente uma string de resposta como parte do handshake de TCP ou SSL.
Somente solicitação especificada

Sinalizações especificadas: somente --request
O Google Cloud envia a string de solicitação configurada e considera a sondagem bem-sucedida quando as condições básicas são atendidas. A resposta, se houver, não é verificada.

Critérios de sucesso para gRPC

Se você estiver usando verificações de integridade do gRPC, certifique-se de que o serviço gRPC envie a resposta RPC com o status OK e o campo de status definido como SERVING ou NOT_SERVING, conforme necessário. Para mais informações, consulte a documentação do gRPC para verificações de integridade.

Estado de integridade

O Google Cloud usa as sinalizações de configuração a seguir para determinar o estado geral de integridade de cada back-end para quem o tráfego é submetido ao 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 Google Cloud 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 Google Cloud usará um limite de 2 sondagens.

O Google Cloud considera os back-ends íntegros depois que esse limite de integridade é atingido. Os back-ends íntegros estão qualificados para receber novas conexões.

O Google Cloud considera os back-ends não íntegros quando o limite não íntegro é atingido. 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.

Outras observações

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

As verificações de integridade com base em conteúdo têm critérios de sucesso que dependem da avaliação de uma string de resposta esperada. Use uma verificação de integridade com base em conteúdo para instruir as sondagens de verificação de integridade do Google Cloud a validar a resposta do back-end mais completamente.

  • As verificações de integridade HTTP, HTTPS ou HTTP/2 baseadas em conteúdo são configuradas pela especificação de uma string de resposta esperada ou, opcionalmente, pela definição de um caminho de solicitação. Para mais detalhes, consulte Critérios de sucesso para HTTP, HTTPS e HTTP/2.

  • As verificações de integridade SSL ou TCP baseadas em conteúdo são configuradas pela especificação de uma string de resposta esperada ou, opcionalmente, pela definição de uma string de solicitação. Para mais detalhes, consulte Critérios de sucesso para SSL e TCP.

Certificados e verificações de integridade

As sondas de verificação de integridade do Google Cloud não realizam validação de certificado, mesmo para protocolos que exigem que os back-ends usem certificados (SSL, HTTPS e HTTP/2). Por exemplo:

  • É possível usar certificados autoassinados ou certificados assinados por qualquer autoridade de certificação (CA, na sigla em inglês).
  • Certificados que expiraram ou que ainda não são válidos são aceitos.
  • Os atributos CN e subjectAlternativeName não precisam corresponder a um cabeçalho Host ou a um registro PTR de DNS.

Cabeçalhos

As verificações de integridade que usam qualquer protocolo, mas não as verificações de integridade legadas, permitem definir um cabeçalho proxy usando a sinalização --proxy-header.

As verificações de integridade que usam protocolos HTTP, HTTPS ou HTTP/2 e verificações de integridade legadas permitem especificar um cabeçalho HTTP Host usando a sinalização --host.

Exemplo de verificação de integridade

Suponha que você tenha configurado uma verificação de integridade com as seguintes configurações:

  • Intervalo: 30 segundos
  • Tempo limite: 5 segundos
  • Protocolo: HTTP
  • Limite não íntegro: 2 (padrão)
  • Limite íntegro: 2 (padrão)

Com essas configurações, a verificação de integridade se comporta desta maneira:

  1. Vários sistemas redundantes são configurados simultaneamente com os parâmetros da verificação de integridade. As configurações de intervalo e tempo limite são aplicadas a cada sistema. Para mais informações, consulte Várias sondagens e frequências.
  2. Cada sondagem de verificação de integridade faz o seguinte:

    1. Inicia uma conexão HTTP de um dos endereços IP de origem com a instância de back-end a cada 30 segundos.
    2. Aguarda até cinco segundos por um código de resposta HTTP 200 (OK) (os critérios de sucesso para os protocolos HTTP, HTTPS e HTTP/2).
  3. Um back-end é considerado não íntegro quando pelo menos um sistema de sondagem de verificação de integridade faz o seguinte:

    1. Não recebe um código de resposta HTTP 200 (OK) para duas sondagens consecutivas. Por exemplo, a conexão pode ser recusada ou pode haver um tempo limite de conexão ou soquete.
    2. Recebe duas respostas consecutivas que não correspondem aos critérios de sucesso específicos do protocolo.
  4. Um back-end é considerado íntegro quando pelo menos um sistema de sondagem de verificação de integridade recebe duas respostas consecutivas que correspondem aos critérios de sucesso específicos do protocolo.

Neste exemplo, cada sonda inicia uma conexão a cada 30 segundos. Trinta segundos se passam entre as tentativas de conexão da sonda, independentemente da duração do tempo limite (se a conexão expirou ou não). Em outras palavras, o tempo limite precisa ser sempre menor ou igual ao intervalo, e ele nunca aumenta o intervalo.

Neste exemplo, o tempo de cada sonda é o seguinte, em segundos:

  1. t=0: iniciar a sondagem A.
  2. t=5: parar a sondagem A.
  3. t=30: iniciar a sondagem B.
  4. t=35: parar a sondagem B.
  5. t=60: iniciar a sondagem C.
  6. t=65: parar a sondagem C.

A seguir