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 saúde para grupos-alvo do Network Load Balancer
Você pode registrar os destinos com um ou mais grupos de destino. O balanceador de carga começa a rotear solicitações para um destino recém-registrado assim que o processo de registro é concluído e os destinos passam pelas 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. As verificações de saúde passivas não são suportadas para UDP tráfego e grupos-alvo com a aderência ativada. Para obter mais informações, consulte Sessões do Sticky.
Se um destino não estiver íntegro, o balanceador de carga enviará um TCP RST para pacotes recebidos nas conexões do cliente associadas ao destino, a menos que o destino não íntegro faça com que o balanceador de carga falhe na abertura.
Se os grupos-alvo não tiverem um destino saudável em uma zona de disponibilidade ativada, removemos o endereço IP da sub-rede correspondente para que as solicitações não DNS possam ser roteadas para destinos nessa 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-alvo estiver configurado com verificações de HTTPS saúde, seus alvos registrados falharão nas verificações de saúde se oferecerem suporte somente à TLS versão 1.3. Esses alvos devem oferecer suporte a uma versão anterior doTLS, como TLS 1.2.
Para HTTP nossas solicitações de verificação de HTTPS integridade, o cabeçalho do host contém o endereço IP do nó do balanceador de carga e da porta do ouvinte, não o endereço IP do destino e da porta de verificação de integridade.
Se você adicionar um TLS ouvinte ao seu Network Load Balancer, realizaremos um teste de conectividade do ouvinte. Como o TLS encerramento também encerra uma TCP conexão, uma nova TCP conexão é estabelecida entre seu balanceador de carga e seus destinos. Portanto, você pode ver as TCP conexões desse teste enviadas do seu balanceador de carga para os destinos registrados com seu TLS ouvinte. Você pode identificar essas TCP conexões 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 UDP serviço, a disponibilidade alvo pode ser testada usando verificações não relacionadas UDP à integridade do seu grupo-alvo. Você pode usar qualquer verificação de saúde disponível (TCPHTTP,, ouHTTPS) e qualquer porta em seu destino para verificar a disponibilidade de um UDP serviço. 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 saúde de um UDP serviço, configure o serviço que escuta a porta de verificação de integridade para rastrear o status do seu UDP serviço e falhar na verificação de saúde se o serviço não estiver disponí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 HTTPHTTPS, TCP e. O padrão é o TCP protocolo. 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 |
[HTTP/verificações de HTTPS saúde] 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 6 segundos para HTTP e 10 segundos para TCP verificações de HTTPS saúde. |
6 segundos para verificações de HTTP saúde e 10 segundos para TCP verificações de HTTPS saúde. |
|
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 alvos se você estiver usando verificações de HTTP saúde, use um destino mais simples nos alvos, como um HTML arquivo estático, ou alterne para verificações de TCP saúde. |
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 |
[HTTP/verificações de HTTPS saúde] Os HTTP códigos a serem usados ao verificar uma resposta bem-sucedida de um alvo. 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 alvo for qualquer valor diferente deHealthy, ele API retornará um código de motivo e uma descrição do problema, e 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 |
