Verificações de integridade para os grupos de destino - Elastic Load Balancing

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 os grupos de destino

Você pode registrar os destinos com um ou mais grupos de destino. O Gateway Load Balancer inicia o roteamento de solicitações para um destino recém-registrado assim que o processo de registro é concluído. Pode levar alguns minutos para que o processo de registro seja concluído e as verificações de integridade sejam iniciadas.

O Gateway Load Balancer envia periodicamente uma solicitação para cada destino registrado para verificar seu status. Após cada verificação de integridade ser concluída, o Gateway Load Balancer fechará a conexão estabelecida para a verificação de integridade.

Configurações de verificação de integridade

Você pode configurar as verificações de integridade ativas para os destinos em um grupo de destino usando as configurações a seguir. Se as verificações de integridade excederem o número especificado de falhas UnhealthyThresholdCountconsecutivas, o Gateway Load Balancer desativará o alvo. Quando as verificações de integridade excedem o número especificado de sucessos HealthyThresholdCountconsecutivos, o Gateway Load Balancer coloca o alvo novamente em serviço.

Configuração Descrição

HealthCheckProtocol

O protocole que o load balancer usa ao executar verificações de integridade nos destinos. Os protocolos possíveis são HTTP, HTTPS e TCP. O padrão é TCP.

HealthCheckPort

A porta que o Gateway Load Balancer usa ao executar verificações de integridade nos destinos. O intervalo é de 1 a 65535. O padrão é 80.

HealthCheckPath

[Verificações de integridade HTTP/HTTPS] O caminho da verificação de saúde que é o destino nos alvos das verificações de saúde. O padrão é /.

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. O padrão é 5.

HealthCheckIntervalSeconds

A quantia aproximada de tempo, em segundos, entre as verificações de integridade de um destino individual. O intervalo é de 5 a 300. O padrão é 10 segundos. Esse valor deve ser maior ou igual HealthCheckTimeoutSecondsa.

Importante

As verificações de integridade para Gateway Load Balancers são distribuídas e usam um mecanismo de consenso para determinar a integridade do destino. Portanto, você deve esperar que os dispositivos de destino recebam várias verificações de integridade dentro do intervalo de tempo configurado.

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

[Verificações de integridade de HTTP/HTTPS] Os códigos HTTP a serem usados ao verificar uma resposta bem-sucedida de um destino. Esse valor deve ser entre 200–399.

Status de integridade do destino

Antes que o Gateway 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 receptor e garantir que a zona de disponibilidade do destino esteja habilitada para o Gateway Load Balancer.

A tabela a seguir descreve os valores possíveis para o status de integridade de um destino registrado.

Value Descrição

initial

O Gateway Load Balancer está no processo de registro do destino ou executando as verificações de integridade iniciais no destino.

Códigos de motivo relacionados: Elb.RegistrationInProgress | Elb.InitialHealthChecking

healthy

O destino é íntegro.

Códigos de motivo relacionados: nenhum

unhealthy

O destino não respondeu a uma verificação de integridade ou falhou em uma verificação de integridade.

Código de motivo relacionado: Target.FailedHealthChecks

unused

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: Target.NotRegistered | Target.NotInUse | Target.InvalidState | Target.IpUnusable

draining

O destino está cancelando o registro e está acontecendo drenagem da conexão.

Código de motivo relacionado: Target.DeregistrationInProgress

unavailable

A integridade do destino não está disponível.

Código de motivo relacionado: Elb.InternalError

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 Gateway Load Balancer, e os códigos de motivo que começarem com Target são originados no destino.

Código do motivo Descrição

Elb.InitialHealthChecking

Verificações de integridade iniciais em andamento

Elb.InternalError

As verificações de integridade falharam devido a um erro interno

Elb.RegistrationInProgress

O registro do destino está em andamento

Target.DeregistrationInProgress

O cancelamento do registro do destino está em andamento

Target.FailedHealthChecks

Verificações de integridade com falha

Target.InvalidState

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

Target.IpUnusable

O endereço IP não pode ser usado como um destino, uma vez que está sendo usado por um load balancer.

Target.NotInUse

O grupo de destino não está configurado para receber tráfego do Gateway Load Balancer

O destino está em uma zona de disponibilidade que não está habilitada para o Gateway Load Balancer

Target.NotRegistered

O destino não está registrado no grupo de destino

Cenários de falha do destino do Gateway Load Balancer

Fluxos existentes: por padrão, os fluxos existentes vão para o mesmo destino, a menos que o fluxo expire ou seja redefinido, independentemente da integridade e do status de registro do destino. Essa abordagem facilita a drenagem da conexão e acomoda firewalls de terceiros que às vezes não conseguem responder às verificações de integridade devido ao alto uso da CPU. Para obter mais informações, consulte Target failover.

Novos fluxos: novos fluxos são enviados para um destino íntegro. Quando uma decisão de balanceamento de carga para um fluxo for tomada, o Gateway Load Balancer enviará o fluxo para o mesmo destino, mesmo que esse destino não seja mais íntegro ou que outros destinos fiquem íntegros.

Quando todos os destinos não estão íntegros, o Gateway Load Balancer escolhe um destino aleatoriamente e encaminha o tráfego para ele durante toda a vida útil do fluxo, até que ele seja reiniciado ou tenha atingido o tempo limite. Como o tráfego está sendo encaminhado para um destino não íntegro, o tráfego é descartado até que o destino volte a ser íntegro.

TLS 1.3: se um grupo de destino estiver configurado com verificações de integridade de HTTPS, seus destinos registrados falharão nas verificações de integridade se oferecerem suporte somente a TLS 1.3. Esses destinos devem oferecer suporte a uma versão anterior do TLS, como o TLS 1.2.

Balanceamento de carga entre zonas: por padrão, o balanceamento de carga entre zonas de disponibilidade está desativado. Se o balanceamento de carga entre zonas estiver ativado, cada Gateway Load Balancer poderá ver todos os destinos em todas as zonas de disponibilidade, e todos serão tratados da mesma forma, independentemente da zona.

As decisões de balanceamento de carga e verificação de integridade são sempre independentes entre as zonas. Mesmo quando o balanceamento de carga entre zonas está ativado, o comportamento dos fluxos existentes e dos novos fluxos é o mesmo descrito acima. Para mais informações, consulte Balanceamento de carga entre zonas no Manual do usuário do Elastic Load Balancing.

Verificar a integridade de seus destinos

Você pode verificar a integridade dos destinos registrados com seus grupos de destino.

Para verificar a integridade dos seus destinos usando o console
  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, em Balanceamento de carga, selecione Grupos de destino.

  3. Escolha o nome do grupo de destino para abrir sua página de detalhes.

  4. Na guia Destinos, a coluna Status indica o status de cada destino.

  5. Se o status de destino for qualquer valor diferente de Healthy, a coluna Detalhes do status conterá mais informações.

Para verificar a saúde de seus alvos usando o AWS CLI

Use o comando describe-target-health. O resultado desse comando contém o estado de integridade do destino. Ele incluirá um código de motivo se o status for qualquer valor diferente de Healthy.

Como receber notificações por e-mail sobre destinos não íntegros

Use CloudWatch alarmes para acionar uma função Lambda para enviar detalhes sobre alvos não íntegros. Para step-by-step obter instruções, consulte a seguinte postagem no blog: Identificação de alvos não íntegros do seu balanceador de carga.

Modificar configurações de verificação de integridade

Você pode modificar algumas das configurações de verificação de integridade de seu grupo de destino.

Para modificar as configurações de verificação de integridade de um grupo de destino usando o console
  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, em Balanceamento de carga, selecione Grupos de destino.

  3. Escolha o nome do grupo de destino para abrir sua página de detalhes.

  4. Na guia Detalhes do grupo, na seção Configurações da verificação de integridade, escolha Editar.

  5. Na página Editar configurações da verificação de integridade, modifique as configurações conforme necessário e escolha Salvar alterações.

Para modificar as configurações de verificação de saúde de um grupo-alvo usando o AWS CLI

Use o comando modify-target-group.