Visão geral das verificações de integridade

O Google Cloud oferece verificações de integridade para determinar se os back-ends respondem ao tráfego. Neste documento, discutimos conceitos de verificação de integridade dos balanceadores de carga do Google Cloud e do Traffic Director.

As verificações de integridade se conectam a back-ends de maneira configurável e periódica. Cada tentativa de conexão é chamada de sondagem. O Google Cloud registra o êxito ou a falha de cada sondagem.

Com base em um número configurável de sondagens sequenciais com êxito ou falha, um estado geral de integridade é calculado para cada back-end. 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 configurável separadamente não são íntegros.

O estado de integridade geral de cada back-end determina a qualificação para receber novas solicitações ou conexões. É possível configurar os critérios que definem uma sondagem com êxito. Abordamos isso em detalhes na seção Como as verificações de integridade funcionam.

As verificações de integridade usam rotas especiais que não estão definidas na sua rede de nuvem privada virtual (VPC). Para informações completas, consulte Caminhos de retorno do balanceador de carga.

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

As verificações de integridade têm uma categoria e um protocolo. As duas categorias são verificações de integridade e verificações de integridade legadas, e os protocolos compatíveis são estes:

O protocolo e a porta determinam como as sondagens de verificação de integridade são feitas. Por exemplo, uma verificação de integridade pode usar o protocolo HTTP na porta TCP 80 ou usar o protocolo TCP para uma porta nomeada em um grupo de instâncias.

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

Como selecionar uma verificação de integridade

As verificações de integridade precisam ser compatíveis com o tipo de balanceador de carga (ou Traffic Director) e os tipos de back-end. Os fatores que você precisa considerar ao selecionar uma verificação de integridade são estes:

  • Categoria: verificação de integridade ou verificação de integridade legada.
  • Protocolo: usado pelo Google Cloud para analisar os back-ends.
  • Especificação de porta: portas que o Google Cloud usa com o protocolo.

O guia do balanceador de carga descreve as seleções válidas de verificação de integridade para cada tipo de balanceador de carga e back-end. Para um resumo de nível superior, consulte a tabela de recursos de verificações de integridade.

Categoria e protocolo

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 baseados em pool de destino exigem verificações de integridade legadas e que elas usem o protocolo HTTP, mesmo que os balanceadores de carga de rede baseados em pool de destino sejam compatíveis com TCP ou UDP. Para balanceadores de carga de rede baseados em pool de destino, execute um servidor HTTP nas instâncias de máquina virtual (VM) para que eles possam responder a sondagens de verificação de integridade.

Para quase todos os outros tipos de balanceador de carga, você precisa usar verificações de integridade regulares e não legadas em que o protocolo corresponde ao protocolo de serviço de back-end do balanceador de carga.

Categoria e especificação de porta

É necessário especificar uma porta para a verificação de integridade. As verificações de integridade têm dois métodos de especificação de porta (--port e --use-serving-port), enquanto as legadas têm apenas um (--port).

Guia do balanceador de carga

Esta tabela mostra a categoria, o escopo e a especificação de porta compatíveis com cada balanceador de carga e tipo de back-end.

Balanceador de carga Tipo de back-end Categoria e escopo da verificação de integridade Especificação da porta
Balanceador de carga HTTP(S) externo global

Balanceador de carga HTTP(S) externo global (clássico) 1

Balanceamento de carga de proxy TCP

Proxy SSL Balanceamento de carga
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)
Balanceador de carga HTTP(S) externo regional 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)
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)
Balanceamento de carga de rede 2 Grupos de instâncias Verificação de integridade (regional)
  • Número de porta personalizado (--port)
Instâncias nos
pools de destino
Verificação de integridade legada
(global com o protocolo HTTP)
As verificações de integridade legadas só são compatíveis com a especificação do número da porta (--port).
Balanceamento de carga TCP/UDP interno 2 NEGs por zona Verificação de integridade (global ou regional)
  • Número de porta personalizado (--port)
Grupos de instâncias Verificação de integridade (global ou regional)
  • Número de porta personalizado (--port)

1 Para balanceadores de carga HTTP(S) externos, as verificações de integridade legadas não são recomendadas, mas podem ser compatíveis, dependendo do modo do balanceador de carga.

Modo balanceador de carga Compatível com verificações de integridade legadas
Balanceador de carga HTTP(S) externo global Não
Balanceador de carga HTTP(S) externo regional Não
Balanceador de carga HTTP(S) externo Sim, se todas as condições a seguir forem verdadeiras:
  • Os back-ends são grupos de instâncias.
  • As VMs de back-end exibem tráfego que usa o protocolo HTTP ou HTTPS.

2 Não é possível usar a sinalização --use-serving-port porque os serviços de back-end usados com balanceamento de carga TCP/UDP interno e balanceamento de carga de rede não se inscrevem em nenhuma porta nomeada.

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 uma verificação de integridade legada, você especifica as seguintes sinalizações ou aceita seus valores padrão. Cada verificação de integridade ou verificação de integridade legada criada é implementada por várias sondagens. Essas sinalizações controlam a frequência em que cada sondagem avalia as instâncias em grupos de instâncias ou endpoints em NEGs 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 um serviço de back-end inteiro. Para um balanceamento de carga de rede baseado em pool de destino, uma verificação de integridade de HTTP legada é associada a todo o pool de destino. 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. 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. 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
  • Balanceador de carga HTTP(S) externo global
  • Balanceador de carga HTTP(S) externo global (clássico)
  • Balanceador de carga HTTP(S) externo regional
  • Balanceamento de carga HTTP(S) interno
  • Balanceamento de carga TCP/UDP interno
  • 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
Balanceamento de carga de rede Para todos os tipos de back-end:
35.191.0.0/16
209.85.152.0/22
209.85.204.0/22

Além disso, apenas para pools com base no pool de destino:
169.254.169.254
(servidores de metadados)

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 IP de origem, use os intervalos de IP da sondagem listados na seção anterior.

Se você não tiver regras de firewall de entrada allow que permitam a verificação de integridade, a regra deny implícita bloqueia o tráfego de entrada. Quando não é possível estabelecer o contato com os back-ends, o balanceador de carga considera os back-ends não íntegros. O comportamento quando nenhum back-end está íntegro depende do tipo de balanceador de carga:

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 na rede de produção do Google para facilitar a comunicação das sondas.

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

  • Os intervalos de IP 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 veja o tráfego de todos os endereços IP em todos os intervalos de IP de sondagem. Como prática recomendada, crie regras de firewall de entrada que permitam todos os intervalos de IP de sondagem como origens. O Google Cloud pode implementar 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 NEG 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 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 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 back-ends nesse serviço de back-end.

    • 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 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 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 serviço de back-end ou pool de destino, o Google Cloud usará várias sondas para verificar cada endereço IP. A frequência de sondagem por VM de back-end é multiplicada pelo número de regras de encaminhamento configuradas.

  • Vários proxies de destino para balanceadores de carga HTTP(S) externos. Se você tiver vários proxies de destino que direcionam o tráfego para o mesmo mapa de URL, 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, 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 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 NEG por zona, é 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 por zona. Esses NEGs por zona não têm necessariamente 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
  • Balanceador de carga HTTP(S) externo global
  • Balanceador de carga HTTP(S) externo global (clássico)
  • Balanceador de carga HTTP(S) externo regional
  • Balanceamento de carga HTTP(S) interno
  • Balanceamento de carga de proxy SSL
  • Balanceamento de carga de proxy TCP
  • Traffic Director
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. Ele pode ser um endereço IP interno principal ou um intervalo de IP de alias da interface de rede principal, nic0, na instância que hospeda o endpoint.
Balanceamento de carga de rede Interface de rede principal (nic0) O endereço IP da regra de encaminhamento externo.

Se várias regras de encaminhamento apontarem para o mesmo serviço de back-end (para balanceamento de carga de rede baseado em pool de destino, o mesmo pool de destino), o Google Cloud enviará sondagens para cada regra de encaminhamento do endereço IP. Isso pode resultar em um aumento no número de sondagens.
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 interno.

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.

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 entregue 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 específica, o Google Cloud precisa encontrar a string esperada nos primeiros 1.024 bytes do corpo da resposta HTTP.

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
Especificar 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, /.
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 forem verdadeiras:

  • Cada sonda do Google Cloud pode concluir um handshake de SSL ou TCP antes do tempo limite configurado para a sondagem.
  • Para verificações de integridade TCP, a sessão TCP é encerrada de maneira suave por meio de:
    • Back-end ou
    • A sonda do Google Cloud que envia um pacote TCP RST (redefinição) enquanto a sessão TCP da sonda ainda está estabelecida

Se o back-end enviar um pacote TCP RST (redefinição) para encerrar uma sessão TCP de uma verificação de integridade TCP, a sondagem poderá ser considerada malsucedida. Isso acontece quando a sonda do Google Cloud já iniciou um encerramento suave do TCP.

É 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 de 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 sinalizadores 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 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 base 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 de base são atendidas e a string de resposta retornada corresponde exatamente à esperada.

--response só pode ser usada por 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.

Observações:

  • As verificações de integridade do gRPC são usadas apenas com aplicativos gRPC e o Traffic Director.
  • As verificações de integridade do gRPC não são compatíveis com TLS.

Para ver mais informações, consulte os seguintes tópicos:

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. 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. Um limite de 2 sondagens.

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

O Google Cloud considera 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

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 verificações de integridade com base em conteúdo para instruir as sondagens de verificação de integridade do Google Cloud a validar mais completamente a resposta do back-end.

  • 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 baseada 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 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 sondas 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