Google Cloud oferece verificações de estado configuráveis para back-ends do Google Cloud balanceador de carga, back-ends da Cloud Service Mesh e autorreparação baseada em aplicações para grupos de instâncias geridas. Este documento aborda os principais conceitos de verificação do estado de funcionamento.
Salvo indicação em contrário, Google Cloud as verificações de estado são implementadas por tarefas de software dedicadas que se ligam a back-ends de acordo com os parâmetros especificados num recurso de verificação de estado. Cada tentativa de ligação é denominada uma sondagem. Google Cloud regista o sucesso ou o fracasso de cada sondagem.
Com base num número configurável de sondagens bem-sucedidas ou falhadas sequenciais, é calculado um estado de funcionamento geral para cada back-end. Os back-ends que respondem com êxito para o número de vezes configurado são considerados em bom estado. Os back-ends que não respondem com êxito um número de vezes configurável separadamente são considerados não saudáveis.
O estado de saúde geral de cada back-end determina a elegibilidade para receber novos pedidos ou ligações. Pode configurar os critérios que definem uma sondagem bem-sucedida. Isto é abordado detalhadamente na secção Como funcionam as verificações de saúde.
As verificações de estado implementadas por tarefas de software dedicadas usam rotas especiais que não estão definidas na sua rede de nuvem virtual privada (VPC). Para mais informações, consulte Caminhos para verificações de estado.
Categorias, protocolos e portas de verificação de estado
As verificações de funcionamento têm uma categoria e um protocolo. As duas categorias são verificações de funcionamento e verificações de funcionamento antigas, e os respetivos protocolos suportados são os seguintes:
Verificações de funcionamento
- Regional (gRPC, TCP, SSL, HTTP, HTTPS ou HTTP/2)
- gRPC regional (com TLS) (pré-visualização)
- Global (gRPC, TCP, SSL, HTTP, HTTPS ou HTTP/2)
- gRPC global (com TLS) (pré-visualização)
Verificações de funcionamento antigas:
O protocolo e a porta determinam como são feitas as sondagens de verificação de funcionamento. Por exemplo, uma verificação de estado pode usar o protocolo HTTP na porta TCP 80 ou pode usar o protocolo TCP para uma porta com nome num grupo de instâncias.
Não pode converter uma verificação de estado antiga numa verificação de estado nem converter uma verificação de estado numa verificação de estado antiga.
Selecione uma verificação de funcionamento
As verificações de estado têm de ser compatíveis com o tipo de balanceador de carga (ou Cloud Service Mesh) e os tipos de back-end. Os fatores a considerar quando seleciona uma verificação de estado são os seguintes:
- Categoria: verificação de funcionamento ou verificação de funcionamento antiga. Apenas os balanceadores de carga de rede de passagem externos baseados em conjunto de destino requerem verificações de funcionamento antigas. Para todos os outros produtos, vai usar verificações de estado normais.
- Protocolo: protocolo que o Google Cloud usa para sondar os back-ends. É melhor usar uma verificação de funcionamento (ou uma verificação de funcionamento antiga) cujo protocolo corresponda ao protocolo usado pelo serviço de back-end ou pelo grupo de destino do balanceador de carga. No entanto, os protocolos de verificação de funcionamento e os protocolos do balanceador de carga não têm de ser os mesmos.
- Especificação da porta: portas que Google Cloud usa com o protocolo.
Tem de especificar uma porta para a verificação de estado. As verificações de funcionamento têm dois métodos de especificação de portas:
--porte--use-serving-port. Para as verificações de estado antigas, existe um método:--port. Para mais informações sobre os requisitos de portas de verificação de funcionamento por balanceador de carga, consulte as flags de especificação de portas.
A secção seguinte descreve as seleções de verificações de funcionamento válidas para cada tipo de balanceador de carga e back-end.
Guia do balanceador de carga
Esta tabela mostra a categoria e o âmbito da verificação de estado suportados para cada tipo de equilibrador de carga.
| Modo do balanceador de carga | Verificações de funcionamento antigas suportadas |
|---|---|
Balanceador de carga de aplicações externo global Balanceador de carga de aplicações clássico |
Sim, se ambas as seguintes afirmações forem verdadeiras:
|
| Balanceador de carga de aplicações externo regional | Não |
Notas de utilização adicionais
Para grupos de instâncias de back-end, NEGs zonais com pontos finais
GCE_VM_IPe NEGs zonais com pontos finaisGCE_VM_IP_PORT, os verificadores apenas tentam estabelecer ligação a instâncias de VM (ou instâncias de VM que contêm pontos finais) se as VMs estiverem em execução. As sondas não tentam estabelecer ligação a instâncias (ou instâncias de VM que contêm pontos finais) se estiverem paradas.Um Network Load Balancer de encaminhamento externo baseado num conjunto de destino tem de usar uma verificação de funcionamento HTTP antiga. Não pode usar uma verificação de funcionamento de HTTPS antiga nem qualquer verificação de funcionamento não antiga. Se usar um balanceador de carga de rede de passagem externo baseado em conjunto de destino para equilibrar o tráfego TCP, tem de executar um serviço HTTP nas VMs que estão a ser equilibradas para que possam responder a sondagens de verificação de funcionamento.
Para quase todos os outros tipos de equilibradores de carga, tem de usar verificações de estado normais e não antigas em que o protocolo corresponde ao protocolo do serviço de back-end do equilibrador de carga.Para serviços de back-end que usam o protocolo gRPC, use apenas verificações de estado do gRPC ou TCP. Não use verificações de estado HTTP(S) ou HTTP/2.
Determinados balanceadores de carga baseados no Envoy que usam back-ends de NEG híbridos não suportam verificações de funcionamento gRPC. Para mais informações, consulte a vista geral das NEGs híbridas.
Verificação do estado de funcionamento com o Cloud Service Mesh
Tenha em atenção as seguintes diferenças no comportamento quando usa verificações de funcionamento com o Cloud Service Mesh.
Com a Cloud Service Mesh, o comportamento de verificação do estado de funcionamento para os pontos finais de rede do tipo
INTERNET_FQDN_PORTeNON_GCP_PRIVATE_IP_PORTdifere do comportamento de verificação do estado de funcionamento para outros tipos de pontos finais de rede. Em vez de usar as tarefas de software dedicadas, o Cloud Service Mesh programa proxies Envoy para realizar verificações de estado para NEGs de Internet (pontos finaisINTERNET_FQDN_PORT) e NEGs híbridos (pontos finaisNON_GCP_PRIVATE_IP_PORT).O Envoy suporta os seguintes protocolos para a verificação do estado de funcionamento:
- HTTP
- HTTPS
- HTTP/2
- TCP
Quando a Cloud Service Mesh está integrada com o Service Directory e associa um serviço do Service Directory a um serviço de back-end da Cloud Service Mesh, não pode definir uma verificação de estado no serviço de back-end.
Como funcionam as verificações de funcionamento
As secções seguintes descrevem o funcionamento das verificações de estado.
Sondas
Quando cria uma verificação de funcionamento ou uma verificação de funcionamento antiga, especifica as seguintes flags ou aceita os respetivos valores predefinidos. Cada verificação de funcionamento ou verificação de funcionamento antiga que criar é implementada por várias sondas. Estas flags controlam a frequência com que cada sondagem avalia instâncias em grupos de instâncias ou pontos finais em NEGs zonais.
Não é possível configurar as definições de uma verificação de funcionamento por back-end. As verificações de estado estão associadas a um serviço de back-end completo. Para um balanceador de carga de rede de encaminhamento externo baseado num conjunto de destino, é associada uma verificação de funcionamento de HTTP antiga a todo o conjunto 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 conjunto de destinos.
| Sinalização de configuração | Finalidade | Valor predefinido |
|---|---|---|
Intervalo de verificaçãocheck-interval |
O intervalo de verificação é o período desde o início de uma sondagem emitida por um verificador até ao início da sondagem seguinte emitida pelo mesmo verificador. As unidades são segundos. | 5s (5 segundos) |
Limite de tempotimeout |
O tempo limite é o tempo que o sistema Google Cloud aguarda uma resposta a uma sondagem. O valor tem de ser inferior ou igual ao intervalo de verificação. As unidades são segundos. | 5s (5 segundos) |
Intervalos de IP de sondagem e regras de firewall
Para que as verificações de estado funcionem, tem de criar regras de firewall de allowentrada para que o tráfego dos Google Cloud probers possa estabelecer ligação aos seus back-ends. Para ver
instruções, consulte o artigo Crie regras de firewall
necessárias.
A tabela seguinte mostra os intervalos de IP de origem a permitir para cada equilibrador de carga:
| Produto | Intervalos de IPs de origem da sonda de verificação de funcionamento |
|---|---|
|
Para o tráfego IPv6 para os back-ends:
|
|
Para o tráfego IPv6 para os back-ends:
|
|
|
| Balanceador de carga de rede de passagem externo 3 |
Para o tráfego IPv4 para os back-ends:
Para o tráfego IPv6 para os back-ends:
|
| Balanceador de carga de rede de encaminhamento interno |
Para o tráfego IPv4 para os back-ends:
Para o 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 ver uma configuração de exemplo, consulte a documentação do Cloud Service Mesh |
1 Não é necessário permitir o tráfego dos intervalos de sondagem de verificação de estado da Google para NEGs híbridos. No entanto, se estiver a usar uma combinação de NEGs híbridos e zonais num único serviço de back-end, tem de permitir o tráfego dos intervalos de sondas de verificação de estado da Google para os NEGs zonais.
2 Para NEGs de Internet regionais, as verificações de funcionamento são opcionais. O tráfego dos balanceadores de carga que usam NEGs de Internet regionais tem origem na sub-rede apenas de proxy e, em seguida, é traduzido pela NAT (através da NAT da nuvem) para endereços IP da NAT alocados manual ou automaticamente. Este tráfego inclui sondagens de verificação de funcionamento e pedidos de utilizadores do equilibrador de carga para os back-ends. Para ver detalhes, consulte o artigo NEGs regionais: use um gateway NAT da nuvem.
3 Os balanceadores de carga de rede de encaminhamento externo baseados em pool de destino suportam apenas tráfego IPv4 e
podem encaminhar verificações de funcionamento através do servidor de metadados. Neste caso,
as origens dos pacotes de verificação de funcionamento correspondem ao endereço IP do servidor de metadados:
169.254.169.254. Não tem de criar regras de firewall para permitir o tráfego do servidor de metadados. Os pacotes do servidor de metadados são sempre permitidos.
Considerações de segurança para intervalos de IPs de sondas
Considere as seguintes informações quando planear verificações de funcionamento e as regras da firewall necessárias:
Os intervalos de IP de sondagem pertencem à Google. Google Cloud usa rotas especiais fora da sua rede VPC, mas dentro da rede de produção da Google, para comunicar entre sondadores de verificações de estado e VMs de back-end.
Os intervalos de IPs de sondagem são usados exclusivamente na rede de produção da Google para verificação do estado e equilíbrio de carga. Google Cloud A rede de produção da Google impede que os intervalos de IPs de sondagem sejam usados para qualquer outro fim, aplicando o seguinte:
Os routers de limite da Google rejeitam pacotes da Internet se os pacotes fizerem spoofing de endereços IP de origem de um intervalo de IPs de sondagem.
Não pode usar os intervalos de IPs de sondagem para sub-redes nas suas redes VPC. Para mais informações, consulte os intervalos de sub-redes IPv4 proibidos e as especificações IPv6.
Importância das regras de firewall
Google Cloud requer que crie as regras de firewall de allow
entrada necessárias para permitir o tráfego de sondas para os seus back-ends:
Os intervalos de IP de sondagem são um conjunto completo de endereços IP possíveis usados por Google Cloud sondas. Se usar o
tcpdumpou uma ferramenta semelhante, é possível que não observe tráfego de todos os endereços IP em todos os intervalos de IPs de sondagem. Como prática recomendada, crie regras de firewall de entrada que permitam todos os intervalos de IPs de sondagem como origens. Google Cloud pode implementar novas sondas automaticamente sem notificação.Como prática recomendada, limite estas regras apenas aos protocolos e às portas que correspondam aos usados pelas suas verificações de funcionamento.
Se não tiver regras de firewall de entrada allow que permitam a verificação de estado,
a regra de entrada implícita deny bloqueia
o tráfego de entrada. Quando os verificadores não conseguem contactar os seus back-ends, o equilibrador de carga considera que os seus back-ends não estão em bom estado.
Várias sondagens e frequência
Google Cloud envia sondagens de verificação de estado de funcionamento a partir de vários sistemas redundantes denominados sondadores. Os verificadores usam intervalos de IPs de origem específicos. Google Cloud não depende apenas de um verificador para implementar uma verificação de estado. Vários verificadores avaliam simultaneamente as instâncias nos back-ends do grupo de instâncias ou os pontos finais nos back-ends do NEG zonal. Se um verificador falhar, Google Cloud continua a monitorizar os estados de integridade do back-end.
As definições de intervalo e tempo limite que configurar para uma verificação
de estado são aplicadas a cada verificador. Para um determinado back-end, os registos de acesso ao software e
tcpdump mostram sondagens mais frequentes do que as definições configuradas.
Este comportamento é esperado e não pode configurar o número de sondadores que o Google Cloud usa para verificações de funcionamento. Google Cloud No entanto, pode estimar o efeito de várias sondagens simultâneas tendo em conta os seguintes fatores.
Para estimar a frequência de sondagem por serviço de back-end, considere o seguinte:
Frequência base por serviço de back-end. Cada verificação de funcionamento tem uma frequência de verificação associada, inversamente proporcional ao intervalo de verificação configurado:
1⁄(intervalo de verificação)
Quando associa uma verificação de estado a um serviço de back-end, estabelece uma frequência base usada por cada verificador para back-ends nesse serviço de back-end.
Fator de escalabilidade da sonda. A frequência base do serviço de back-end é multiplicada pelo número de sondas simultâneas que usa. Google Cloud Este número pode variar, mas, geralmente, está entre 5 e 10.
Várias regras de encaminhamento para balanceadores de carga de rede de passagem interna. Se tiver configurado várias regras de encaminhamento interno (cada uma com um endereço IP diferente) que apontam para o mesmo serviço de back-end interno regional, oGoogle Cloud usa vários verificadores 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 externos. Se tiver configurado várias regras de encaminhamento que apontam para o mesmo serviço de back-end ou conjunto de destinos,o Google Cloud Load Balancing usa vários verificadores para verificar cada endereço IP. Google Cloud A frequência da 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 aplicações externos. Se tiver vários proxies de destino que direcionam o tráfego para o mesmo mapa de URLs, Google Cloud usa vários verificadores 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 configurou vários proxies de destino que direcionam o tráfego para o mesmo serviço de back-end, o Google Cloud Load BalancingGoogle Cloud usa vários verificadores 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 dos 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 são contactadas com a frequência da soma das frequências da verificação de estado de cada serviço de back-end.
Com back-ends de NEG zonais, é mais difícil determinar o número exato de sondagens de verificação de estado. Por exemplo, o mesmo ponto final pode estar em vários NEGs zonais. Esses NEGs zonais não têm necessariamente o mesmo conjunto de pontos finais, e diferentes pontos finais podem apontar para o mesmo back-end.
Destino para pacotes de sondagem
A tabela seguinte mostra a interface de rede e os endereços IP de destino para os quais os verificadores de funcionamento enviam pacotes, consoante o tipo de balanceador de carga.
Para balanceadores de carga de rede de encaminhamento externo e balanceadores de carga de rede de encaminhamento interno, a aplicação tem de ser associada 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 encaminhamento externo | 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 externos baseados em conjunto de destino, o mesmo conjunto de destino), Google Cloud envia sondagens para o endereço IP de cada regra de encaminhamento. Isto pode resultar num aumento do número de sondagens. |
| Balanceador de carga de rede de encaminhamento interno | Para backends de grupos de instâncias e backends de NEG zonais com
pontos finais GCE_VM_IP, a interface de rede usada depende de
como o serviço de backend está configurado. Para ver 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, Google Cloud envia sondagens para o endereço IP de cada regra de encaminhamento. Isto pode resultar num aumento do número de sondagens. |
Critérios de sucesso para HTTP, HTTPS e HTTP/2
As verificações de funcionamento de HTTP, HTTPS e HTTP/2 requerem sempre a receção de um código de resposta HTTP 200 (OK) antes do limite de tempo da verificação de funcionamento. 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 HTTP 200 (OK), pode:
Configure cada verificador de verificação de estado para enviar pedidos HTTP para um caminho de pedido específico, em vez do caminho de pedido predefinido,
/.Configure cada verificador de funcionamento para verificar a presença de uma string de resposta esperada no corpo da resposta HTTP. A string de resposta esperada tem de ser composta apenas por carateres ASCII imprimíveis de byte único, localizados nos primeiros 1024 bytes do corpo da resposta HTTP.
A tabela seguinte apresenta as combinações válidas de caminho do pedido e flags de resposta disponíveis para verificações de estado HTTP, HTTPS e HTTP/2.
| Sinalizações de configuração | Comportamento do verificador | Critérios de sucesso |
|---|---|---|
Nem --request-path nem --response
especificado
|
O verificador usa / como o caminho do pedido. |
Apenas código de resposta HTTP 200 (OK). |
--request-path e --response especificados
|
O verificador usa o caminho do pedido configurado. | O código de resposta HTTP 200 (OK) e até aos primeiros 1024 carateres ASCII do corpo da resposta HTTP têm de corresponder à string de resposta esperada. |
Apenas --response especificados
|
O verificador usa / como o caminho do pedido. |
O código de resposta HTTP 200 (OK) e até aos primeiros 1024 carateres ASCII do corpo da resposta HTTP têm de corresponder à string de resposta esperada. |
Apenas --request-path especificados
|
O verificador usa o caminho do pedido configurado. | Apenas código de resposta HTTP 200 (OK). |
Critérios de sucesso para SSL e TCP
As verificações de funcionamento de TCP e SSL têm os seguintes critérios de sucesso base:
Para as verificações de estado de TCP, um verificador de estado tem de abrir com êxito uma ligação TCP ao back-end antes do limite de tempo da verificação de estado.
Para as verificações de estado de SSL, um verificador de estado tem de abrir com êxito uma ligação TCP ao back-end e concluir o handshake TLS/SSL antes do limite de tempo da verificação de estado.
Para verificações de estado de TCP, a ligação TCP tem de ser fechada de uma das seguintes formas:
- Através da sonda de verificação de estado de funcionamento que envia um pacote FIN ou RST (reposição), ou
- Através do envio de um pacote FIN pelo back-end. Se um back-end enviar um pacote TCP RST, a sondagem pode ser considerada sem êxito se o verificador de estado já tiver enviado um pacote FIN.
A tabela seguinte lista as combinações válidas de flags de pedido e resposta que estão disponíveis para verificações de estado de TCP e SSL. Os flags de pedido e resposta têm de consistir apenas em carateres ASCII imprimíveis de byte único, com cada string a ter um comprimento máximo de 1024 carateres.
| Sinalizações de configuração | Comportamento do verificador | Critérios de sucesso |
|---|---|---|
Nem --request nem --response especificado
|
O verificador não envia nenhuma string de pedido. | Apenas critérios de sucesso básicos. |
--request e --response especificados
|
A sonda envia a string de pedido configurada. | Os critérios de êxito base e a string de resposta recebida pelo verificador têm de corresponder exatamente à string de resposta esperada. |
Apenas --response especificados
|
O verificador não envia nenhuma string de pedido. | Os critérios de êxito base e a string de resposta recebida pelo verificador têm de corresponder exatamente à string de resposta esperada. |
Apenas --request especificados
|
A sonda envia a string de pedido configurada. | Apenas critérios de sucesso base (não é verificada nenhuma string de resposta). |
Critérios de sucesso para gRPC
As verificações de funcionamento do gRPC são usadas apenas com aplicações gRPC, Google Cloud balanceadores de carga e Cloud Service Mesh. Google Cloud Suporta dois tipos de verificações de funcionamento do gRPC:
- As verificações de funcionamento
GRPC_WITH_TLSsão usadas para verificar o funcionamento dos back-ends gRPC com TLS ativado. Suportam a encriptação TLS não autenticada, o que significa que as verificações de funcionamento não validam a identidade do servidor. - As verificações de funcionamento
GRPCsão usadas para verificar o funcionamento de back-ends gRPC não seguros. Não suportam a autenticação nem a encriptação, pelo que não podem ser usados para back-ends gRPC com o protocolo TLS ativado.
Se estiver a usar verificações de estado do gRPC (com ou sem TLS), certifique-se de que o serviço gRPC envia a resposta RPC com o estado OK e o campo de estado definido como SERVING ou NOT_SERVING, respetivamente.
Para mais informações, consulte o seguinte:
Critérios de sucesso para verificações de funcionamento antigas
Se a resposta recebida pela sondagem de verificação do estado antiga for HTTP 200 OK, a sondagem é considerada bem-sucedida. Todos os outros códigos de resposta HTTP, incluindo um redirecionamento (301, 302), são considerados não íntegros.
Estado de funcionamento
Google Cloud usa as seguintes flags de configuração para determinar o estado de funcionamento geral de cada back-end para o qual o tráfego é equilibrado.
| Sinalização de configuração | Finalidade | Valor predefinido |
|---|---|---|
Limite saudávelhealthy-threshold |
O limite saudável especifica o número de resultados de sondagem bem-sucedidos sequenciais para que um back-end anteriormente não saudável seja considerado saudável. | Um limite de 2
sondas. |
Limite de mau estado de funcionamentounhealthy-threshold |
O limite não saudável especifica o número de resultados de sondagem com falhas sequenciais para que um back-end anteriormente saudável seja considerado não saudável. | Um limite de 2
sondas. |
Google Cloud considera que os back-ends estão em bom estado de funcionamento depois de este limite de bom estado de funcionamento ser atingido. Os backends saudáveis são elegíveis para receber novas associações.
Google Cloud Considera que os back-ends estão em mau estado de funcionamento quando o limite de mau estado de funcionamento é atingido. Os back-ends não íntegros não são elegíveis para receber novas ligações. No entanto, as ligações existentes não são terminadas imediatamente. Em alternativa, a ligação permanece aberta até ocorrer um tempo limite ou até o tráfego ser interrompido.
As ligações existentes podem não devolver respostas, consoante a causa da falha da sondagem. Um back-end em mau estado de funcionamento pode voltar a funcionar corretamente se conseguir atingir novamente o limite de funcionamento correto.
O comportamento específico quando todos os back-ends estão em mau estado difere consoante o tipo de equilibrador de carga que está a usar:
| Balanceador de carga | Comportamento quando todos os back-ends estão em mau estado |
|---|---|
| Balanceador de carga de aplicações clássico | Devolve um Código de estado HTTP `502` aos clientes quando todos os back-ends estão em mau estado. |
|
Balanceador de carga de aplicações externo global Balanceador de carga de aplicações interno entre regiões Balanceador de carga de aplicações externo regional Balanceador de carga de aplicações interno regional |
Devolve um Código de estado HTTP `503` aos clientes quando todos os back-ends estão em mau estado. |
| Balanceadores de carga de rede de proxy | Termina novas ligações TCP de clientes quando todos os back-ends estão em mau estado. |
| Balanceador de carga de rede de encaminhamento interno Balanceadores de carga de rede de encaminhamento externos baseados em serviços de back-end |
Distribui novas ligações de acordo com a configuração de comutação por falha, o peso do back-end e o estado de funcionamento do back-end. Para obter mais detalhes, consulte as secções: |
| Balanceadores de carga de rede de passagem externos baseados em grupos de destino | Distribui o tráfego a todas as VMs de back-end como último recurso quando todos os back-ends não estão em bom estado. |
Notas adicionais
As secções seguintes incluem algumas notas adicionais sobre a utilização de verificações de funcionamento no Google Cloud.
Certificados e verificações de funcionamento
Google Cloud Os verificadores de estado de funcionamento não realizam a validação de certificados, mesmo para protocolos que requerem que os seus back-ends usem certificados (SSL, HTTPS e HTTP/2). Por exemplo:
- Pode usar certificados autoassinados ou certificados assinados por qualquer autoridade de certificação (CA).
- Os certificados que expiraram ou que ainda não são válidos são aceitáveis.
- Nem o atributo
CNnem o atributosubjectAlternativeNametêm de corresponder a um cabeçalhoHostou a um registo PTR de DNS.
Cabeçalhos
As verificações de saúde que usam qualquer protocolo, mas não as verificações de saúde antigas, permitem-lhe
definir um cabeçalho de proxy através da flag --proxy-header.
As verificações de estado que usam protocolos HTTP, HTTPS ou HTTP/2 e as verificações de estado antigas permitem especificar um cabeçalho HTTP Host através da flag --host.
Se estiver a usar cabeçalhos de pedidos personalizados, tenha em atenção que o equilibrador de carga adiciona estes cabeçalhos apenas aos pedidos do cliente e não às sondagens de verificação do estado. Se o seu back-end exigir um cabeçalho específico para autorização que esteja em falta no pacote de verificação de funcionamento, a verificação de funcionamento pode falhar.
Exemplo de verificação de funcionamento
Suponhamos que configura uma verificação de funcionamento com as seguintes definições:
- Intervalo: 30 segundos
- Limite de tempo: 5 segundos
- Protocolo: HTTP
- Limite não saudável: 2 (predefinição)
- Limite saudável: 2 (predefinição)
Com estas definições, a verificação de funcionamento comporta-se da seguinte forma:
- Vários sistemas redundantes são configurados simultaneamente com os parâmetros de verificação do estado. As definições de intervalo e limite de tempo são aplicadas a cada sistema. Para mais informações, consulte o artigo Várias sondagens e frequência.
Cada verificador de funcionamento faz o seguinte:
- Inicia uma ligação HTTP a partir de um dos endereços IP de origem para a instância de back-end a cada 30 segundos.
- Aguarda até cinco segundos por um código de estado HTTP
200 (OK)(os critérios de êxito para os protocolos HTTP, HTTPS e HTTP/2).
Um back-end é considerado não saudável quando, pelo menos, um sistema de sondagem de verificação de estado faz o seguinte:
- Não recebe um código de resposta
HTTP 200 (OK)para duas sondagens consecutivas. Por exemplo, a ligação pode ser recusada ou pode haver um limite de tempo de ligação ou de tomada. - Recebe duas respostas consecutivas que não correspondem aos critérios de êxito específicos do protocolo.
- Não recebe um código de resposta
Um back-end é considerado em bom estado quando, pelo menos, um sistema de sondagem de verificação do estado recebe duas respostas consecutivas que correspondem aos critérios de êxito específicos do protocolo.
Neste exemplo, cada sonda inicia uma ligação a cada 30 segundos. Decorrem 30 segundos entre as tentativas de ligação de um verificador, independentemente da duração do limite de tempo (se o limite de tempo da ligação foi atingido ou não). Por outras palavras, o tempo limite tem de ser sempre inferior ou igual ao intervalo e o tempo limite nunca aumenta o intervalo.
Neste exemplo, a sincronização de cada sonda é a seguinte, em segundos:
- t=0: iniciar a sondagem A.
- t=5: Stop probe A.
- t=30: Start probe B.
- t=35: Stop probe B.
- t=60: Start probe C.
- t=65: Stop probe C.
O que se segue?
- Para criar, modificar e usar verificações de funcionamento, consulte o artigo Use verificações de funcionamento.
- Para resolver problemas de verificações de funcionamento, ative o registo de verificações de funcionamento.