O Google Cloud oferece verificações de integridade configuráveis para back-ends de carga do Cloud Load Balancing,do Cloud Service Mesh e, recuperação automática baseada em aplicativos para instâncias gerenciadas grupos. Neste documento, abordamos os principais conceitos de verificação de integridade.
Salvo indicação contrária, as verificações de integridade do Google Cloud são implementadas por tarefas de software dedicadas que se conectam a back-ends de acordo com os parâmetros especificados em um recurso de verificação de integridade. Cada tentativa de conexão é chamada de sondagem. O Google Cloud registra o sucesso ou o fracasso 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 implementadas por tarefas de software dedicadas usam rotas especiais que não são definidas na sua rede de nuvem privada virtual (VPC). Para mais informações, consulte Caminhos para verificações de integridade.
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:
Verificações de integridade
Verificações de integridade legadas:
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.
Selecionar uma verificação de integridade
As verificações de integridade precisam ser compatíveis com o tipo de balanceador de carga (ou Cloud Service Mesh) 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. Apenas balanceadores de carga de rede de passagem externa baseados em pool de destino exigem verificações de integridade legadas. Para todos os outros produtos, você usará as verificações de integridade padrão.
- Protocolo: usado pelo Google Cloud para analisar os back-ends. É melhor usar uma verificação de integridade (legada ou não) que tenha um protocolo correspondente àquele usado pelo pool de destino ou serviço de back-end do balanceador de carga. No entanto, os protocolos de verificação de integridade e os protocolos do balanceador de carga não precisam ser iguais.
- Especificação de porta: portas que o Google Cloud usa com o protocolo.
É 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:
--porte--use-serving-port. Para verificações de integridade legadas, há um único método:--port. Para mais informações sobre os requisitos de porta de verificação de integridade por balanceador de carga, consulte Flags de especificação de porta.
Na próxima seção, descrevemos as seleções de verificação de integridade válidas para cada tipo de balanceador de carga e back-end.
Guia do balanceador de carga
Esta tabela mostra a categoria e o escopo da verificação de integridade compatíveis com cada tipo de balanceador de carga.
| Modo balanceador de carga | Compatível com verificações de integridade legadas |
|---|---|
Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo clássico |
Sim, se todas as condições a seguir forem verdadeiras:
|
| Balanceador de carga de aplicativo externo regional | Não |
Outras observações de uso
Para back-ends de grupos de instâncias de VM, as verificações de integridade são realizadas apenas nas instâncias de VM iniciadas. As instâncias de VM interrompidas não recebem pacotes de verificação de integridade.
Para balanceadores de carga de rede de passagem interna, só é possível usar
TCPouUDPpara o protocolo do serviço de back-end. Se você processa o tráfego HTTP de VMs por trás de um balanceador de carga TCP/UDP interno, convém executar uma verificação de integridade usando o protocolo HTTP.Um balanceador de carga de rede de passagem externa baseado em pool de destino precisa usar uma verificação de integridade HTTP legada. Ele não pode usar uma verificação de integridade HTTPS legada ou qualquer verificação não legada. Se você usar um balanceador de carga de rede baseado no pool de destino para balancear o tráfego TCP, precisará executar um serviço HTTP nas VMs que estão sendo balanceadas para que possam responder a sondagens de verificação de integridade.
Para quase todos os outros tipos de balanceador de cargas, é preciso usar verificações de integridade não legadas padrão em que o protocolo corresponde àquele do serviço de back-end do balanceador de carga.Para serviços de back-end que usam o protocolo gRPC, use apenas as verificações de integridade gRPC ou TCP. Não use verificações de integridade HTTP(S) ou HTTP/2.
Alguns balanceadores de carga baseados no Envoy que usam back-ends de NEG híbridos não são compatíveis com as verificações de integridade do gRPC. Para mais informações, consulte a visão geral de NEGs híbridos.
Verificação de integridade com o Cloud Service Mesh
Observe as seguintes diferenças de comportamento ao usar verificações de integridade com Cloud Service Mesh.
Com o Cloud Service Mesh, o comportamento da verificação de integridade para endpoints de rede da tipo
INTERNET_FQDN_PORTeNON_GCP_PRIVATE_IP_PORTsão diferentes do tipo de integridade de verificação do comportamento de outros tipos de endpoints de rede. Em vez de usar tarefas de software dedicadas, o Cloud Service Mesh programa proxies Envoy para realizar verificações de integridade para NEGs da Internet (endpointsINTERNET_FQDN_PORT) e híbridos NEGs (NON_GCP_PRIVATE_IP_PORTde endpoints).O Envoy é compatível com os seguintes protocolos para verificação de integridade:
- HTTP
- HTTPS
- HTTP/2
- TCP
Quando o Cloud Service Mesh está integrado ao Diretório de serviços e você vincula um serviço do Diretório de serviços a uma malha de serviço do Cloud serviço de back-end, não é possível definir uma verificação de integridade no serviço de back-end.
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 balanceador de carga de rede de passagem externa 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 | Finalidade | Valor padrão |
|---|---|---|
Intervalo de verificaçãocheck-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 limitetimeout |
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. Para
instruções, consulte Criar regras de firewall
necessárias.
A tabela a seguir mostra os intervalos de IP de origem a serem permitidos para cada balanceador de carga:
| Produto | Intervalos de IPs de origem da sondagem de verificação de integridade |
|---|---|
|
Para tráfego IPv6 para os back-ends:
|
|
Para tráfego IPv6 para os back-ends:
|
|
|
| Balanceador de carga de rede de passagem externa 3 |
Para tráfego IPv4 para os back-ends:
Para tráfego IPv6 para os back-ends:
|
| Balanceador de carga de rede de passagem interna |
Para tráfego IPv4 para os back-ends:
Para tráfego IPv6 para os back-ends:
|
| Cloud Service Mesh com back-ends de NEG da Internet e back-ends de NEG híbridos | Endereços IP das VMs que executam o software Envoy Para conferir um exemplo de configuração, consulte a documentação do Cloud Service Mesh. |
1 Não é necessário colocar intervalos de sondagem de verificação de integridade do Google na lista de permissões para NEGs híbridos. No entanto, se você estiver usando uma combinação de NEGs híbridos e zonais em um único serviço de back-end, será necessário usar lista de permissões dos intervalos de sondagem de verificação de integridade do Google para NEGs zonais.
2 Para NEGs regionais da Internet, as verificações de integridade são opcionais. O tráfego de balanceadores de carga que usam NEGs regionais da Internet é proveniente da sub-rede somente proxy e, em seguida, é convertido por NAT (usando o Cloud NAT) para endereços IP NAT alocados automaticamente ou manualmente. Esse tráfego inclui sondagens de verificação de integridade e solicitações de usuários do balanceador de carga aos back-ends. Para detalhes, consulte NEGs regionais: usar o Cloud NAT para saída.
3 Os balanceadores de carga de rede de passagem externa baseados em pool de destino são compatíveis somente com tráfego IPv4 e podem usar proxy para passar verificações de integridade pelo servidor de metadados. Nesse caso, as origens do pacote de verificação de integridade correspondem ao endereço IP do servidor de metadados: 169.254.169.254. Não é preciso criar regras de firewall para permitir tráfego do servidor de metadados. Os pacotes do servidor de metadados são sempre permitidos.
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.
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 de aplicativos externos e balanceadores de carga de rede de proxy externos. 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
tcpdumpou 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 de rede de passagem interna. 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 de passagem externa. 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 de aplicativo 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 rede de proxy externos e balanceadores de carga de rede de proxy internos regionais. 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 de passagem externa e balanceadores de carga de rede de passagem interna, o aplicativo precisa estar vinculado 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 de rede de passagem externa | 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 balanceadores de carga de rede de passagem externa baseados em pool de destino, o mesmo pool de destino), 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. |
| Balanceador de carga de rede de passagem interna | Para back-ends de grupos de instâncias e back-ends NEG zonais com
endpoints GCE_VM_IP, a interface de rede usada depende de
como o serviço de back-end está configurado. Para mais detalhes, 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
As verificações de integridade HTTP, HTTPS e HTTP/2 sempre exigem que um código de resposta HTTP 200 (OK) seja recebido antes do tempo limite da verificação de integridade. Todos os outros códigos de resposta HTTP, incluindo códigos de resposta de redirecionamento como 301 e 302, são considerados não íntegros.
Além de exigir um código de resposta 200 (OK) HTTP, você pode:
Configure cada sonda de verificação de integridade para enviar solicitações HTTP a um caminho de solicitação específico em vez do caminho de solicitação padrão,
/.Configure cada sondagem de verificação de integridade para verificar a presença de uma string de resposta esperada no corpo da resposta HTTP. A string de resposta esperada precisa ser composta apenas de caracteres ASCII imprimíveis de um único byte, localizados nos primeiros 1.024 bytes do corpo da resposta HTTP.
A tabela a seguir lista combinações válidas de sinalizações de caminho de solicitação e resposta disponíveis para verificações de integridade HTTP, HTTPS e HTTP/2.
| Sinalizações de configuração | Comportamento do Prober | Critérios de sucesso |
|---|---|---|
Nem --request-path nem --response
especificados
|
O detector usa / como o caminho da solicitação. |
Somente o código de resposta HTTP 200 (OK). |
--request-path e --response especificados
|
O detector usa o caminho de solicitação configurado. | O código de resposta HTTP 200 (OK) e até os primeiros
1.024 caracteres ASCII do corpo da resposta HTTP precisam corresponder à string de resposta
esperada. |
Somente --response especificado
|
O detector usa / como o caminho da solicitação. |
O código de resposta HTTP 200 (OK) e até os primeiros
1.024 caracteres ASCII do corpo da resposta HTTP precisam corresponder à string de resposta
esperada. |
Somente --request-path especificado
|
O detector usa o caminho de solicitação configurado. | Somente o código de resposta HTTP 200 (OK). |
Critérios de sucesso para SSL e TCP
As verificações de integridade de TCP e SSL têm os seguintes critérios de sucesso básicos:
Para verificações de integridade TCP, uma sondagem de verificação de integridade precisa abrir uma conexão TCP para o back-end antes do tempo limite da verificação de integridade.
Para verificações de integridade SSL, um verificador de integridade precisa abrir uma conexão TCP com o back-end e concluir o handshake TLS/SSL antes do tempo limite da verificação de integridade.
Para verificações de integridade TCP, a conexão TCP precisa ser fechada de uma das seguintes maneiras:
- Quando a sonda de verificação de integridade envia um pacote FIN ou RST (redefinição),
- O back-end envia um pacote FIN. Se um back-end enviar um pacote TCP RST, a sondagem poderá ser considerada malsucedida se a sonda de verificação de integridade já tiver enviado um pacote FIN.
A tabela a seguir lista combinações válidas de sinalizações de solicitação e resposta que estão disponíveis para verificações de integridade de TCP e SSL. As flags de solicitação e de resposta precisam consistir apenas de caracteres ASCII imprimíveis de um byte, e cada string não pode ter mais de 1.024 caracteres.
| Sinalizações de configuração | Comportamento do Prober | Critérios de sucesso |
|---|---|---|
Nem --request nem --response especificados
|
O detector não envia nenhuma string de solicitação. | Somente os critérios de sucesso básicos. |
--request e --response especificados
|
O detector envia a string de solicitação configurada. | Os critérios de sucesso de base e a string de resposta recebida pelo verificador precisam corresponder exatamente à string de resposta esperada. |
Somente --response especificado
|
O detector não envia nenhuma string de solicitação. | Os critérios de sucesso de base e a string de resposta recebida pelo verificador precisam corresponder exatamente à string de resposta esperada. |
Somente --request especificado
|
O detector envia a string de solicitação configurada. | Somente critérios de sucesso básicos (nenhuma string de resposta é 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.
Observe o seguinte:
- As verificações de integridade do gRPC são usadas apenas com aplicativos e Cloud Service Mesh.
- 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:
- Sinalização adicional para verificações de integridade do gRPC
- Documentação do gRPC para verificações de integridade
Critérios de sucesso para verificações de integridade legadas
Se a resposta recebida pela sondagem de verificação de integridade legada for HTTP 200 OK, a sondagem será considerada bem-sucedida. Todos os outros códigos de resposta HTTP, incluindo um redirecionamento (301, 302), são considerados não íntegros.
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 | Finalidade | Valor padrão |
|---|---|---|
Limite íntegrohealthy-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 íntegrounhealthy-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.
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.
O comportamento específico quando nenhum back-end está íntegro varia de acordo com o tipo de balanceador de carga que você está usando:
| Balanceador de carga | Comportamento quando nenhum back-end estiver íntegro |
|---|---|
| Balanceador de carga de aplicativo clássico | Retorna um código de status HTTP "502" para os clientes quando nenhum back-end está íntegro. |
|
Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo interno entre regiões Balanceador de carga de aplicativo externo regional Balanceador de carga de aplicativo interno regional |
Retorna um código de status HTTP "503" para os clientes quando nenhum back-end está íntegro. |
| Balanceadores de carga de rede proxy | Encerram as conexões do cliente quando nenhum back-end está íntegro. |
| Balanceador de carga de rede de passagem interna Balanceadores de carga de rede de passagem externa baseados em serviço de back-end |
Distribuem o tráfego para todas as VMs de back-end como último recurso quando nenhum back-end está íntegro e o failover não está configurado. Para mais informações sobre esse comportamento, consulte Distribuição de tráfego para balanceadores de carga de rede de passagem interna e Distribuição de tráfego para balanceadores de carga de rede de passagem externa baseados em serviço de back-end. |
| Balanceadores de carga de rede de passagem externa baseados em pool de destino | Distribuem o tráfego para todas as VMs de back-end como último recurso quando nenhum back-end está íntegro. |
Outras observações
As seções a seguir incluem mais algumas observações sobre o uso de verificações de integridade no Google Cloud.
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
CNesubjectAlternativeNamenão precisam corresponder a um cabeçalhoHostou 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.
Se você estiver usando cabeçalhos de solicitação personalizados, observe que o balanceador de carga adiciona esses cabeçalhos apenas às solicitações do cliente, não às sondagens de verificação de integridade. Se o back-end exige um cabeçalho específico para autorização que esteja faltando no pacote de verificação de integridade, ele poderá falhar.
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:
- 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.
Cada sondagem de verificação de integridade faz o seguinte:
- Inicia uma conexão HTTP de um dos endereços IP de origem com a instância de back-end a cada 30 segundos.
- Aguarda até cinco segundos por um código de status HTTP
200 (OK)(os critérios de sucesso para os protocolos HTTP, HTTPS e HTTP/2).
Um back-end é considerado não íntegro quando pelo menos um sistema de sondagem de verificação de integridade faz o seguinte:
- 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. - Recebe duas respostas consecutivas que não correspondem aos critérios de sucesso específicos do protocolo.
- Não recebe um código de resposta
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:
- t=0: iniciar a sondagem A.
- t=5: parar a sondagem A.
- t=30: iniciar a sondagem B.
- t=35: parar a sondagem B.
- t=60: iniciar a sondagem C.
- t=65: parar a sondagem C.
A seguir
- Para criar, modificar e usar verificações de integridade, consulte Como usar verificações de integridade.
- Para resolver problemas de verificações de integridade, ative o registro de verificação de integridade.