As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Verificações de integridade para grupos de destino do Application Load Balancer
Seu Application Load Balancer envia periodicamente solicitações para seus destinos registrados para testar o status deles. Esses testes se chamam verificações de integridade.
Cada nó do load balancer só roteia solicitações para os destinos íntegros nas Zonas de disponibilidade habilitadas para o load balancer. Cada nó do load balancer verifica a integridade de cada destino usando as configurações de verificação de integridade para os grupos de destino em que o destino é registrado. Após o destino ser registrado, ele deverá ser aprovado em uma verificação de integridade para ser considerado íntegro. Após cada verificação de integridade ser concluída, o nó do load balancer fechará a conexão estabelecida para a verificação de integridade.
Se um grupo de destino contiver somente destinos registrados não íntegros, o balanceador de carga encaminhará as solicitações para todos esses destinos, independentemente do status de integridade. Isso significa que se todos os destinos falharem nas verificações de integridade ao mesmo tempo em todas as zonas de disponibilidade habilitadas, o balanceador de carga apresentará falha ao abrir. O efeito da falha na abertura é permitir o tráfego para todos os destinos em todas as zonas de disponibilidade habilitadas, independentemente do seu estado de integridade, mas com base no algoritmo de balanceamento de carga.
As verificações de integridade não oferecem suporte ao WebSockets.
Configurações de verificação de integridade
Você pode configurar verificações de integridade para os destinos em um grupo de destino conforme descrito na tabela a seguir. Os nomes das configurações usados na tabela são os nomes usados na API. O balanceador de carga envia uma solicitação de verificação de integridade a todos os destinos registrados, a cada segundo de HealthCheckIntervalSeconds, usando a porta, o protocolo e o caminho de verificação de integridade especificados. Cada solicitação de verificação de integridade é independente e o resultado dura por todo o intervalo. O tempo necessário para o destino responder não afeta o intervalo da próxima solicitação de verificação de integridade. Se a verificação de integridade exceder as falhas consecutivas de UnhealthyThresholdCount, o load balancer tirará o destino de serviço. Quando as verificações de integridade excederem os sucessos consecutivos de HealthyThresholdCount, o load balancer colocará o destino de volta em serviço.
| Configuração | Descrição |
|---|---|
HealthCheckProtocol |
O protocolo que o load balancer usa ao executar verificações de integridade nos destinos. Em Application Load Balancers, os possíveis protocolos são HTTP e HTTPS. O padrão é o protocolo HTTP. Esses protocolos usam o método HTTP GET para enviar solicitações de verificação de integridade. |
HealthCheckPort |
A porta que o load balancer usa ao executar verificações de integridade nos destinos. O padrão é usar a porta em que cada destino recebe o tráfego do load balancer. |
HealthCheckPath |
O destino para verificações de integridade nos destinos. Se a versão do protocolo for HTTP/1.1 ou HTTP/2, especifique um URI válido (/path?query). O padrão é /. Se a versão do protocolo for gRPC, especifique o caminho de um método personalizado de verificação de integridade com o formato |
HealthCheckTimeoutSeconds |
O tempo, em segundos, durante o qual ausência de resposta de um destino significa uma falha na verificação de integridade. O intervalo é de 2 a 120 segundos. O padrão é de 5 segundos se o tipo de destino é |
HealthCheckIntervalSeconds |
A quantia aproximada de tempo, em segundos, entre as verificações de integridade de um destino individual. O intervalo é de 5 a 300 segundos. O padrão é de 30 segundos se o tipo de destino é |
HealthyThresholdCount |
O número de verificações de integridade bem-sucedidas consecutivas necessárias antes de considerar íntegro um destino não íntegro. O intervalo é de 2 a 10. O padrão é 5. |
UnhealthyThresholdCount |
O número de verificações de integridade consecutivas exigido antes considerar um destino não íntegro. O intervalo é de 2 a 10. O padrão é 2. |
Matcher |
O códigos a serem usados ao verificar uma resposta bem-sucedida de um destino. Eles são chamados de códigos de sucesso no console. Se a versão do protocolo for HTTP/1.1 ou HTTP/2, os valores possíveis são de 200 a 499. Você pode especificar valores múltiplos (por exemplo, "200,202") ou um intervalo valores (por exemplo, "200-299"). O valor padrão é 200. Se a versão do protocolo for gRPC, os valores possíveis são de 0 a 99. Você pode especificar valores múltiplos (por exemplo, "0,1") ou um intervalo valores (por exemplo, "0-5"). O valor padrão é 12. |
Status de integridade do destino
Antes que o load balancer envie uma solicitação de verificação de integridade para um destino, você deverá registrá-lo com um grupo de destino, especificar o grupo de destino em uma regra do listener e garantir que a Zona de disponibilidade do destino esteja habilitado para o load balancer. Antes de um destino receber solicitações do load balancer, ele deverá ser aprovado nas verificações de integridade iniciais. Após o destino ser aprovado nas verificações de integridade iniciais, o status será Healthy.
A tabela a seguir descreve os valores possíveis para o status de integridade de um destino registrado.
| Value | Descrição |
|---|---|
|
O load balancer está no processo de registro do destino ou executando as verificações de integridade iniciais no destino. Códigos de motivo relacionados: |
|
O destino é íntegro. Códigos de motivo relacionados: nenhum |
|
O destino não respondeu a uma verificação de integridade ou falhou em uma verificação de integridade. Códigos de motivo relacionados: |
|
O destino não está registrado em um grupo de destino, o grupo de destino não é usado em uma regra do listener, o destino está em uma zona de disponibilidade desativada ou o destino está no estado parado ou encerrado. Códigos de motivo relacionados: |
|
O destino está cancelando o registro e está acontecendo drenagem da conexão. Código de motivo relacionado: |
|
As verificações de integridade estão desativadas para o grupo de destino. Código de motivo relacionado: |
Códigos de motivo de verificação de integridade
Se o status de um destino for qualquer valor diferente de Healthy, a API retornará um código de motivo e uma descrição do problema; o console exibirá a mesma descrição. Os códigos de motivo que começarem com Elb são originados no load balancer, e os códigos de motivo que começarem com Target são originados no destino. Para obter mais informações sobre as possíveis causas de falhas na verificação de integridade, consulte Solução de problemas.
| Código do motivo | Descrição |
|---|---|
|
Verificações de integridade iniciais em andamento |
|
As verificações de integridade falharam devido a um erro interno |
|
O registro do destino está em andamento |
|
O cancelamento do registro do destino está em andamento |
|
Verificações de integridade com falha |
|
As verificações de integridade estão desativadas |
|
O destino está no estado interrompido O destino está no estado encerrado O destino está no estado encerrado ou interrompido O destino está em um estado inválido |
|
O endereço IP não pode ser usado como um destino, uma vez que está sendo usado por um load balancer. |
|
O grupo de destino não está configurado para receber tráfego do load balancer O destino está em uma Zona de disponibilidade que não está habilitada para o load balancer |
|
O destino não está registrado no grupo de destino |
|
As verificações de integridade apresentaram falhas com estes códigos: [código] |
|
Solicitação expirada |
