O Google Cloud oferece verificações de integridade configuráveis para back-ends do balanceador de carga do Google Cloud, back-ends do Traffic Director e recuperação automática baseada em aplicativo para grupos de instâncias gerenciadas. 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 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:
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 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. 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.
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, 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 de aplicativo externo global Balanceador de carga de aplicativo clássico 1 Balanceador de carga de rede de proxy externo global Balanceador de carga de rede de proxy clássico |
NEGs compatíveis | Verificação de integridade (global) |
|
| Grupos de instâncias | Verificação de integridade (global) |
|
|
| Balanceador de carga de aplicativo externo regional | NEGs compatíveis | Verificação de integridade (regional) |
|
| Grupos de instâncias | Verificação de integridade (regional) |
|
|
|
Balanceador de carga de aplicativo interno entre regiões Balanceador de carga de rede de proxy interno entre regiões |
NEGs compatíveis | Verificação de integridade (global) |
|
| Grupos de instâncias | Verificação de integridade (global) |
|
|
|
Balanceador de carga de aplicativo interno regional Balanceador de carga de rede de proxy interno regional Balanceador de carga de rede de proxy externo regional |
NEGs compatíveis | Verificação de integridade (regional) |
|
| Grupos de instâncias | Verificação de integridade (regional) |
|
|
| Balanceador de carga de rede de passagem externa 2 | Grupos de instâncias | Verificação de integridade (regional) |
|
| 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). |
|
| Balanceador de carga de rede de passagem interna 2 | NEGs compatíveis | Verificação de integridade (global ou regional) |
|
| Grupos de instâncias | Verificação de integridade (global ou regional) |
|
| 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 |
--use-serving-port porque os serviços de back-end usados com balanceadores de carga de rede de passagem interna e balanceadores de carga de rede de passagem externa não fazem inscrição em nenhuma porta nomeada. Além disso, os balanceadores de carga de rede de passagem interna são compatíveis apenas com NEGs zonais com endpoints GCE_VM_IP, que não têm informações de porta.
Outras observações de uso
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 Traffic Director
Lembre-se das diferenças de comportamento a seguir ao usar verificações de integridade com o Traffic Director.
Com o Traffic Director, o comportamento da verificação de integridade para endpoints de rede do tipo
INTERNET_FQDN_PORTeNON_GCP_PRIVATE_IP_PORTé diferente do comportamento da verificação de integridade para outros tipos de endpoints de rede. Em vez de usar as tarefas de software dedicadas, o Traffic Director programa proxies Envoy para realizar verificações de integridade para NEGs da Internet (endpointsINTERNET_FQDN_PORT) e NEGs híbridos (endpointsNON_GCP_PRIVATE_IP_PORT).O Envoy é compatível com os seguintes protocolos para verificação de integridade:
- HTTP
- HTTPS
- HTTP/2
- TCP
Quando o Traffic Director está integrado ao Diretório de serviços e você vincula um serviço do Diretório de serviços a um serviço de back-end do Traffic Director, 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 | Motivo | 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.
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 |
|---|---|---|
|
|
Regras de firewall para todos os produtos, exceto balanceadores de carga de rede de passagem externa |
| Balanceador de carga de rede de passagem externa |
Para tráfego IPv4 para os back-ends:
Para tráfego IPv6 para os back-ends:
|
Regras de firewall para balanceadores de carga de rede de passagem externa |
| Balanceador de carga de rede de passagem interna |
Para tráfego IPv4 para os back-ends:
Para tráfego IPv6 para os back-ends:
|
Regras de firewall para balanceadores de carga de rede de passagem interna |
| Traffic Director com back-ends de NEG da Internet e back-ends de NEG híbrido | Endereços IP das VMs que executam o software Envoy | Exemplo de regra de firewall |
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
Quando uma verificação de integridade usa o protocolo HTTP, HTTPS ou HTTP/2, cada sondagem exige que um código de status 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çãorequest-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, /.
|
Respostaresponse |
A flag de resposta opcional permite configurar uma verificação de integridade baseada 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 um código de 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:
- 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 | Motivo | 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 externo regional Balanceador de carga de aplicativo interno |
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. |
| Balanceadores de carga de rede de passagem interna e 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.
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
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.
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.