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 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.
Os Network Load Balancers usam verificações de integridade ativas e passivas para determinar se um destino está disponível para lidar com solicitações. Por padrão, cada nó do load balancer roteia solicitações somente para destinos íntegros na sua zona de disponibilidade. Se você habilitar o balanceamento de carga entre zonas, cada nó do load balancer roteará solicitações para destinos íntegros em todas as zonas de disponibilidade habilitadas. Para ter mais informações, consulte Balanceamento de carga entre zonas.
Com as verificações de integridade passivas, o load balancer observa como os destinos respondem às conexões. As verificações de integridade passivas permitem que o load balancer detecte um destino não íntegro antes que ele seja relatado como não íntegro pelas verificações de integridade ativas. Você não pode desabilitar, configurar nem monitorar as verificações de integridade passivas. As verificações de saúde passivas não são suportadas para tráfego UDP e grupos-alvo com a aderência ativada. Para obter mais informações, consulte Sessões do Sticky.
Se um destino se tornar não íntegro, o balanceador de carga enviará um TCP RST para pacotes recebidos nas conexões de cliente associadas ao destino, a menos que o destino não íntegro acione o balanceador de carga para apresentar falha na abertura.
Se um ou mais grupos de destino não têm um destino íntegro em uma zona de disponibilidade habilitada, removemos o endereço IP da sub-rede correspondente do DNS para que a solicitações não sejam roteadas para destinos nesta zona de disponibilidade. 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. Os balanceadores de carga de rede também falharão quando você tiver um grupo-alvo vazio. 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.
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 forem compatíveis somente com TLS 1.3. Esses destinos devem ser compatíveis com uma versão anterior do TLS, como o TLS 1.2.
Para solicitações de verificação de integridade HTTP ou HTTPS, o cabeçalho de host contém o endereço IP do nó do load balancer e a porta do listener, não o endereço IP do destino e a porta de verificação de integridade.
Se você adicionar um receptor de TLS ao Network Load Balancer, executaremos um teste de conectividade do receptor. Como o encerramento do TLS também encerra uma conexão TCP, uma nova conexão TCP será estabelecida entre o load balancer e seus destinos. Portanto, você pode ver as conexões TCP desse teste enviadas do seu balanceador de carga para os destinos registrados no seu ouvinte TLS. Você pode identificar essas conexões TCP porque elas têm o endereço IP de origem do seu Network Load Balancer e as conexões não contêm pacotes de dados.
Para um serviço de UDP, a disponibilidade do destino pode ser testada usando verificações de integridade não UDP no grupo de destino. Você pode usar qualquer verificação de integridade disponível (TCP, HTTP ou HTTPS) e qualquer porta no destino para verificar a disponibilidade de um serviço de UDP. Se o serviço que recebe a verificação de integridade falhar, o destino será considerado indisponível. Para melhorar a precisão das verificações de integridade de um serviço de UDP, configure o serviço que ouve a porta de verificação de integridade para acompanhar o status do serviço de UDP e parar a verificação de integridade caso o serviço esteja indisponível.
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 a UnhealthyThresholdcontagem de falhas consecutivas, o balanceador de carga desativará o alvo. Quando as verificações de integridade excedem a HealthyThresholdcontagem de sucessos consecutivos, o balanceador de carga coloca o alvo de volta em serviço.
| Configuração | Descrição | Padrão |
|---|---|---|
|
HealthCheckProtocolo |
O protocolo 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 é o protocolo TCP. Se o tipo de destino for |
TCP |
|
HealthCheckPorto |
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. |
Porta em que cada destino recebe o tráfego do balanceador de carga. |
|
HealthCheckCaminho |
[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 segundos. Os valores padrão são seis segundos para verificações de integridade de HTTP e dez segundos para verificações de integridade de TCP e HTTPS. |
Seis segundos para verificações de integridade de HTTP e dez segundos para verificações de integridade de TCP e HTTPS. |
|
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 é 30 segundos. ImportanteAs verificações de integridade de um Network Load Balancer são distribuídas e usam um mecanismo de consenso para determinar a integridade do destino. Portanto, os destinos recebem mais do que o número configurado de verificações de integridade. Para reduzir o impacto em seus destinos se você estiver usando verificações de integridade HTTP, use um destino mais simples, como um arquivo HTML estático, ou alterne para verificações de integridade TCP. |
30 segundos |
|
HealthyThresholdContagem |
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. |
5 |
|
UnhealthyThresholdContagem |
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. |
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. O intervalo é de 200 a 599. O padrão é 200 a 399. |
200-399 |
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.
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 alvo não respondeu a uma verificação de saúde, falhou na verificação de saúde ou está em estado parado. Código de motivo relacionado: |
|
O destino está cancelando o registro e está acontecendo drenagem da conexão. Código de motivo relacionado: |
|
O alvo não respondeu às verificações de saúde ou foi reprovado nas verificações de saúde e entrou em um período de carência. O alvo suporta conexões existentes e não aceitará novas conexões durante esse período de carência. Código de motivo relacionado: |
|
A integridade do destino não está disponível. Código de motivo relacionado: |
|
O alvo não está registrado em um grupo-alvo, o grupo-alvo não é usado em uma regra de ouvinte ou o alvo está em uma zona de disponibilidade que não está ativada. Códigos de motivo relacionados: |
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 em uma dica de ferramenta. Observe que 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.
| 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 |
|
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 |
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
Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/
. -
No painel de navegação, em Balanceamento de carga, selecione Grupos de destino.
-
Escolha o nome do grupo de destino para abrir sua página de detalhes.
-
O painel Detalhes exibe o número total de destinos, mais o número de destinos para cada status de integridade.
-
Na guia Destinos, a coluna Status da integridade indica o status de cada destino.
-
Se o status de um destino for qualquer valor diferente de
Healthy, a coluna Detalhes do status da integridade 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 as configurações de verificação de integridade de um grupo de destino
Você pode modificar as configurações de verificação de integridade do seu grupo de destino a qualquer momento.
Para modificar as configurações de verificação de integridade de um grupo de destino usando o console
Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/
. -
No painel de navegação, em Balanceamento de carga, selecione Grupos de destino.
-
Escolha o nome do grupo de destino para abrir sua página de detalhes.
-
Na guia Verificações de integridade, selecione Editar.
-
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.
