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 Network Load Balancer
Você pode registrar os destinos com um ou mais grupos de destino. O balanceador de carga inicia as solicitações de roteamento para um destino recém-registrado assim que o processo de registro é concluído e o destino é aprovado nas verificações de integridade iniciais. 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 obter 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. Não há suporte a verificações de integridade passivas para tráfego UDP e grupos de destino com a persistência ativada. Para obter mais informações, consulte Sessões persistentes.
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 Network Load Balancers também falharão quando você tiver um grupo de destino 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, talvez você veja as conexões TCP para este teste enviadas do seu balanceador de carga para os destinos registrados com o receptor TLS. É possível identificar essas conexões TCP porque elas têm o endereço IP de origem do seu Network Load Balancer e 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 as falhas UnhealthyThresholdCountconsecutivas, o balanceador de carga colocará o alvo fora de serviço. Quando as verificações de integridade excedem os sucessos HealthyThresholdCountconsecutivos, o balanceador de carga coloca o alvo de volta em serviço.
| Configuração | Descrição | Padrão |
|---|---|---|
|
HealthCheckProtocol |
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 |
|
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. |
Porta em que cada destino recebe o tráfego do balanceador de carga. |
|
HealthCheckPath |
[Verificações de integridade de HTTP/HTTPS] O caminho da verificação de integridade que é o destino para verificações de integridade. 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 |
|
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. |
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. |
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.
| Valor | 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, falhou em uma verificação de integridade ou está 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 destino não respondeu a verificações de integridade ou falhou em verificações de integridade e entrou em um período de carência. O destino oferece suporte a 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 destino não está registrado com um grupo de destino, o grupo de destino não é usado em uma regra de receptor ou o destino está em uma Zona de disponibilidade que não está habilitada. 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 |
