Grupos de destino para seus Application Load Balancers - Elastic Load Balancing
Configuração de roteamentoTarget typeTipo de endereço IPVersão do protocoloDestinos registradosAtributos do grupo de destinoAlgoritmos de roteamentoPesos-alvo automáticos (ATW)Atraso do cancelamento do registroModo de iniciação lenta

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á.

Grupos de destino para seus Application Load Balancers

Os grupos de destino roteiam solicitações para destinos registrados individuais, como instâncias do EC2, usando o protocolo e o número de porta que você especifica. Você pode registrar um destino com vários grupos de destino. Você pode configurar verificações de integridade em cada grupo de destino. As verificações de integridade são executadas em todos os destinos registrados a um grupo de destino especificado em uma regra de listeners para seu load balancer.

Cada grupo de destino é usado para rotear solicitações para um ou mais destinos registrados. Ao criar cada regra do listener, especifique um grupo de destino e condições. Quando uma condição da regra é atendida, o tráfego é encaminhado para o grupo de destino correspondente. Você pode criar grupos de destino diferentes para tipos de solicitações diferentes. Por exemplo, você pode criar um grupo de destino para solicitações gerais e outros grupos de destino para solicitações para os microsserviços do aplicativo. Você só pode usar cada grupo de destino com um balanceador de carga. Para ter mais informações, consulte Componentes do Application Load Balancer.

Você define as configurações de verificação de integridade para seu load balancer por grupo de destino. Cada grupo de destino usa as configurações de verificação de integridade padrão, a menos que você as substitua ao criar o grupo de destino ou as modifique posteriormente. Após especificar um grupo de destino em uma regra para um listener, o load balancer monitora continuamente a integridade de todos os destinos registrados com o grupo de destino que estiverem em uma Zona de disponibilidade habilitada para o load balancer. O load balancer roteia solicitações para os destinos registrados que são íntegros.

Conteúdo

Configuração de roteamento

Por padrão, um load balancer roteia solicitações para seus destinos usando o protocolo e o número da porta que você especificou ao criar o grupo de destino. Como alternativa, você pode substituir a porta usada para rotear o tráfego para um destino quando registrá-lo no grupo de destino.

Os grupos de destino são compatíveis com os seguintes protocolos e portas:

  • Protocolos: HTTP, HTTPS

  • Ports (Portas): 1-65535

Se um grupo de destino estiver configurado com o protocolo HTTPS ou usar as verificações de integridade de HTTPS, as conexões TLS com os destinos usarão as configurações de segurança da política ELBSecurityPolicy-2016-08. O balanceador de carga estabelecerá conexões TLS com os destinos usando certificados instalados nos destinos. O load balancer não valida esses certificados. Portanto, é possível usar certificados autoassinados ou certificados que tenham expirado. Como o balanceador de carga e seus destinos estão em uma nuvem privada virtual (VPC), o tráfego entre o balanceador de carga e os destinos é autenticado no nível do pacote, portanto, não corre o risco man-in-the-middle de ataques ou falsificação, mesmo que os certificados nos destinos não sejam válidos. O tráfego que sai não AWS terá essas mesmas proteções, e etapas adicionais podem ser necessárias para proteger ainda mais o tráfego.

Target type

Durante a criação de um grupo de destino, você especifica seu tipo de destino, que determina o tipo de destino especificado ao registrar destinos com esse grupo de destino. Depois de criar um grupo de destino, você não pode mudar o seu tipo de destino.

Os possíveis tipos de destino são os seguintes:

instance

Os destinos são especificados por ID de instância.

ip

Os destinos são endereços IP.

lambda

O destino é uma função Lambda.

Quando o tipo de destino é ip, você pode especificar os endereços IP de um dos seguintes blocos CIDR:

  • As sub-redes da VPC para o grupo de destino

  • 10.0.0.0/8 (RFC 1918)

  • 100.64.0.0/10 (RFC 6598)

  • 172.16.0.0/12 (RFC 1918)

  • 192.168.0.0/16 (RFC 1918)

Importante

Você não pode especificar publicamente endereços IP roteáveis.

Todos os blocos CIDR compatíveis permitem que você registre os seguintes destinos em um grupo de destino:

  • Instâncias em uma VPC emparelhada com a VPC do balanceador de carga (mesma região ou região diferente).

  • AWS recursos que são endereçáveis por endereço IP e porta (por exemplo, bancos de dados).

  • Recursos locais vinculados AWS por meio AWS Direct Connect de uma conexão VPN Site-to-Site.

nota

Para Application Load Balancers implantados em uma zona local, os destinos ip devem estar na mesma zona local para receber tráfego.

Para obter mais informações, consulte O que são Zonas AWS Locais?

Se você especificar destinos usando um ID de instância, o tráfego é roteado para instâncias usando o endereço IP privado especificado na interface de rede principal para a instância. Se você especificar destinos usando endereços IP, você pode rotear o tráfego para uma instância com qualquer endereço IP privado de uma ou mais interfaces de rede. Isso permite que vários aplicativos em uma instância usem a mesma porta. Cada interface de rede pode ter seu próprio security group.

Se o tipo de destino do seu grupo de destino for lambda, você poderá registrar uma única função Lambda. Quando o load balancer recebe uma solicitação para a função Lambda, ele invoca a função Lambda. Para ter mais informações, consulte Funções do Lambda como destino.

Você pode configurar o Amazon Elastic Container Service (Amazon ECS) como destino do seu Application Load Balancer. Para obter mais informações, consulte Creating an Application Load Balancer no Guia do usuário do Amazon Elastic Container Service para. AWS Fargate

Tipo de endereço IP

Ao criar um novo grupo de destino, você pode selecionar o tipo de endereço IP dele. Isso controla a versão do IP usada para comunicação com os destinos e para a verificação do status de integridade deles.

Application Load Balancers são compatíveis com grupos de destino IPv4 e IPv6. A seleção padrão é IPv4.

Considerações

  • Todos os endereços IP de um grupo de destino devem ter o mesmo tipo de endereço IP. Por exemplo, você não pode registrar um destino IPv4 com um grupo de destino IPv6.

  • Os grupos de destino IPv6 só podem ser usados com balanceadores de carga dualstack.

  • Os grupos de destino IPv6 são compatíveis com destinos do tipo IP e instância.

Versão do protocolo

Por padrão, os Application Load Balancers enviam solicitações aos destinos usando HTTP/1.1. Você pode usar a versão do protocolo para enviar solicitações aos destinos usando HTTP/2 ou gRPC.

A tabela a seguir resume o resultado das combinações de protocolo de solicitação e versão de protocolo do grupo de destino.

Protocolo de solicitação Versão do protocolo Resultado
HTTP/1.1 HTTP/1.1 Bem-sucedida
HTTP/2 HTTP/1.1 Bem-sucedida
gRPC HTTP/1.1 Erro
HTTP/1.1 HTTP/2 Erro
HTTP/2 HTTP/2 Bem-sucedida
gRPC HTTP/2 Sucesso se os destinos forem compatíveis com gRPC
HTTP/1.1 gRPC Erro
HTTP/2 gRPC Sucesso se for uma solicitação POST
gRPC gRPC Bem-sucedida
Considerações sobre a versão do protocolo gRPC

  • O único protocolo de receptor compatível é HTTPS.

  • O único tipo de ação compatível com as regras do receptor é forward.

  • Só há compatibilidade com os tipos de destino instance e ip.

  • O balanceador de carga analisa as solicitações do gRPC e encaminha as chamadas do gRPC para os grupos de destino adequados com base no pacote, serviço e método.

  • O balanceador de carga é compatível com streaming unário no lado do cliente, streaming no lado do servidor e streaming bidirecional.

  • Você deve fornecer um método de verificação de integridade personalizado com o formato /package.service/method.

  • É necessário especificar os códigos de status a serem usados ao verificar uma resposta bem-sucedida de um destino.

  • Não é possível usar funções do Lambda como destino.

Considerações sobre a versão do protocolo HTTP/2

  • O único protocolo de receptor compatível é HTTPS.

  • O único tipo de ação compatível com as regras do receptor é forward.

  • Só há compatibilidade com os tipos de destino instance e ip.

  • O balanceador de carga é compatível com streaming proveniente dos clientes. O balanceador de carga não é compatível com streaming para os destinos.

Destinos registrados

O seu load balancer serve como um ponto único de contato para clientes e distribui o tráfego de entrada nos destinos íntegros registrados. Você pode registrar cada destino com um ou mais grupos de destino.

Se a demanda da seu aplicativo aumentar, você pode registrar destinos adicionais com um ou mais grupos de destino, a fim de dar conta da demanda. O balanceador de carga começa a rotear o tráfego para um destino recém-registrado assim que o processo de registro é concluído e o destino passa pela primeira verificação de integridade inicial, independentemente do limite configurado.

Se a demanda na seu aplicativo diminuir, ou se você precisar fazer manutenção nos seus destinos, você pode cancelar o registro dos destinos dos seus grupos de destino. Cancelar o registro de um destino o remove do seu grupo de destino, mas não afeta o destino de outra forma. O load balancer interrompe as solicitações de roteamento ao destino assim que o registro dele for cancelado. O destino entra no estado draining até que as solicitações em andamento tenham sido concluídas. Você pode registrar o destino com o grupo de destino novamente quando estiver pronto para retomar o recebimento de solicitações.

Se você estiver registrando destinos por ID de instância, poderá usar o balanceador de carga com um grupo do Auto Scaling. Depois que você anexar um grupo de destino a um grupo do Auto Scaling, o Auto Scaling registrará os destinos no grupo de destino para você quando ele os iniciar. Para obter mais informações, consulte Anexar um balanceador de carga ao seu grupo do Auto Scaling no Guia do usuário do Amazon EC2 Auto Scaling.

Limites

  • Não é possível registrar os endereços IP de outro Application Load Balancer na mesma VPC. Se o outro Application Load Balancer estiver em uma VPC emparelhada à VPC do balanceador de carga, você poderá registrar seus endereços IP.

  • Não será possível registrar instâncias por ID de instância se elas estiverem em uma VPC emparelhada com a VPC do balanceador de carga (mesma região ou região diferente). Você poderá registrar essas instâncias pelo endereço IP.

Atributos do grupo de destino

Os seguintes atributos do grupo de destino são compatíveis se o tipo de grupo de destino for instance ou ip:

deregistration_delay.timeout_seconds

A quantidade de tempo que o Elastic Load Balancing deve aguardar antes de cancelar o registro de um destino. O intervalo é de 0 a 3.600 segundos. O valor de padrão é de 300 segundos.

load_balancing.algorithm.type

O algoritmo de balanceamento de carga determina como o load balancer seleciona os destinos ao rotear as solicitações. O valor éround_robin,least_outstanding_requests, ouweighted_random. O padrão é round_robin.

load_balancing.algorithm.anomaly_mitigation

Disponível somente quando load_balancing.algorithm.type estáweighted_random. Indica se a mitigação de anomalias está ativada. O valor é on ou off. O padrão é off.

load_balancing.cross_zone.enabled

Indica se o balanceamento de carga entre zonas está habilitado. O valor é true, false ou use_load_balancer_configuration. O padrão é use_load_balancer_configuration.

slow_start.duration_seconds

O período, em segundos, durante o qual o load balancer envia a um destino recém-registrado uma parcela de tráfego com aumento linear ao grupo de destino. O intervalo é de 30 a 900 segundos (15 minutos). O padrão é 0 segundos (desativado).

stickiness.enabled

Indica se sticky sessions estão habilitadas. O valor é true ou false. O padrão é false.

stickiness.app_cookie.cookie_name

O nome do cookie da aplicação. O nome do cookie da aplicação não pode ter os seguintes prefixos:AWSALB, AWSALBAPP ou AWSALBTG. Esses prefixos são reservados para uso pelo balanceador de carga.

stickiness.app_cookie.duration_seconds

O período de expiração de cookie baseado em aplicação, em segundos. Após esse período, o cookie será considerado antigo. O valor mínimo é 1 segundo e o valor máximo é 7 dias (604.800 segundos). O valor padrão é de 1 dia (86.400 segundos).

stickiness.lb_cookie.duration_seconds

O período de expiração do cookie baseado em duração, em segundos. Após esse período, o cookie será considerado antigo. O valor mínimo é 1 segundo e o valor máximo é 7 dias (604.800 segundos). O valor padrão é de 1 dia (86.400 segundos).

stickiness.type

O tipo de perdurabilidade. Os valores possíveis são lb_cookie e app_cookie.

target_group_health.dns_failover.minimum_healthy_targets.count

O número mínimo de destinos que devem estar íntegros. Se o número de destinos íntegros for menor do que esse valor, marque a zona como não íntegra no DNS, para que o tráfego seja roteado somente para zonas íntegras. Os valores possíveis são off ou um número inteiro de 1 até o número máximo de destinos. Quando off, a falha de DNS inativo estará desabilitada, o que significa que cada grupo de destino contribuirá de modo independente para o failover de DNS. O padrão é um.

target_group_health.dns_failover.minimum_healthy_targets.percentage

O percentual mínimo de destinos que devem estar íntegros. Se o percentual de destinos íntegros for inferior a esse valor, marque a zona como não íntegra no DNS, para que o tráfego seja roteado somente para zonas íntegras. Os valores possíveis são off ou um número inteiro de 1 até o número máximo de destinos. Quando off, a falha de DNS inativo estará desabilitada, o que significa que cada grupo de destino contribui de modo independente para o failover de DNS. O padrão é um.

target_group_health.unhealthy_state_routing.minimum_healthy_targets.count

O número mínimo de destinos que devem estar íntegros. Se o número de destinos íntegros for menor do que desse valor, envie tráfego para todos os alvos, incluindo alvos não íntegros. O intervalo é de 1 ao número máximo de destinos. O padrão é um.

target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage

O percentual mínimo de destinos que devem estar íntegros. Se a porcentagem de destinos íntegros for menor do que valor, envie tráfego para todos os destinos, incluindo destinos não íntegros. Os valores possíveis são off ou um número inteiro de 1 a 100. O padrão é off.

O seguinte atributo do grupo de destino é compatível se o tipo de grupo de destino for lambda:

lambda.multi_value_headers.enabled

Indica se os cabeçalhos da solicitação e resposta trocados entre o load balancer e a função Lambda incluem matrizes de valores ou strings. Os valores possíveis são true ou false. O valor padrão é false. Para ter mais informações, consulte Cabeçalhos de vários valores.

Algoritmos de roteamento

Um algoritmo de roteamento é o método usado pelo balanceador de carga para determinar quais destinos receberão solicitações. O algoritmo de roteamento round robin é usado por padrão para rotear solicitações no nível do grupo-alvo. As solicitações menos pendentes e os algoritmos de roteamento aleatório ponderado também estão disponíveis com base nas necessidades do seu aplicativo. Um grupo-alvo só pode ter um algoritmo de roteamento ativo por vez, no entanto, o algoritmo de roteamento pode ser atualizado sempre que necessário.

Se você ativar sessões fixas, o algoritmo de roteamento selecionado será usado para a seleção inicial do destino. Solicitações futuras do mesmo cliente serão encaminhadas para o mesmo destino, ignorando o algoritmo de roteamento selecionado.

Round robin

  • O algoritmo de roteamento round robin direciona as solicitações uniformemente entre alvos saudáveis no grupo-alvo, em uma ordem sequencial.

  • Esse algoritmo é comumente usado quando as solicitações recebidas têm complexidade semelhante, os destinos registrados são semelhantes em capacidade de processamento ou se você precisa distribuir as solicitações igualmente entre os destinos.

Solicitações menos pendentes

  • O algoritmo de roteamento de solicitações menos pendentes encaminha as solicitações para os destinos com o menor número de solicitações em andamento.

  • Esse algoritmo é comumente usado quando as solicitações recebidas variam em complexidade, os alvos registrados variam em capacidade de processamento.

  • Quando um balanceador de carga compatível com HTTP/2 usa destinos compatíveis somente com HTTP/1.1, ele converte a solicitação em várias solicitações HTTP/1.1. Nessa configuração, o algoritmo de solicitações menos pendentes tratará cada solicitação HTTP/2 como várias solicitações.

  • Ao usar WebSockets, o destino é selecionado usando o algoritmo de solicitações menos pendentes. Depois de selecionado, o balanceador de carga cria uma conexão com o destino e envia todas as mensagens por essa conexão.

  • O algoritmo de roteamento de solicitações menos pendentes não pode ser usado com o modo de início lento.

Aleatório ponderado

  • O algoritmo de roteamento aleatório ponderado direciona as solicitações uniformemente entre alvos saudáveis no grupo-alvo, em uma ordem aleatória.

  • Esse algoritmo suporta a mitigação automática de anomalias de pesos alvo (ATW).

  • O algoritmo de roteamento aleatório ponderado não pode ser usado com o modo de início lento.

Modificar o algoritmo de roteamento de um grupo-alvo

Você pode modificar o algoritmo de roteamento do seu grupo-alvo a qualquer momento.

Para modificar o algoritmo de roteamento usando o novo console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, em Load Balancing (Balanceamento de carga), escolha Grupos de destino.

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

  4. Na página de detalhes dos grupos-alvo, na guia Atributos, escolha Editar.

  5. Na página Editar atributos do grupo-alvo, na seção Configuração de tráfego, em Algoritmo de balanceamento de carga, escolha Round robin, Menos solicitações pendentes ou Weighted random.

  6. Escolha Salvar alterações.

Para modificar o algoritmo de roteamento usando o AWS CLI

Use o comando modify-target-group-attributes com o atributo load_balancing.algorithm.type.

Pesos-alvo automáticos (ATW)

O Automatic Target Weights (ATW) monitora constantemente os alvos que executam seus aplicativos, detectando desvios significativos de desempenho, conhecidos como anomalias. O ATW fornece a capacidade de ajustar dinamicamente a quantidade de tráfego roteado para os alvos, por meio da detecção de anomalias de dados em tempo real.

O Automatic Target Weights (ATW) realiza automaticamente a detecção de anomalias em cada Application Load Balancer em sua conta. Quando alvos anômalos são identificados, o ATW pode tentar estabilizá-los automaticamente reduzindo a quantidade de tráfego para os quais são roteados, o que é conhecido como mitigação de anomalias. O ATW otimiza continuamente a distribuição de tráfego para maximizar as taxas de sucesso por alvo e, ao mesmo tempo, minimizar as taxas de falha do grupo-alvo.

Considerações:

  • Atualmente, a detecção de anomalias monitora os códigos de resposta HTTP 5xx provenientes de seus alvos e as falhas de conexão com eles. A detecção de anomalias está sempre ativada e não pode ser desativada.

  • O ATW não é suportado ao usar o Lambda como alvo.

Detecção de anomalias

O ATW monitora a detecção de anomalias de qualquer alvo que esteja exibindo um desvio significativo no comportamento de outros alvos em seu grupo-alvo. Esses desvios, chamados de anomalias, são determinados pela comparação dos erros percentuais de um alvo com os erros percentuais de outros alvos no grupo-alvo. Esses erros podem ser tanto erros de conexão quanto códigos de erro HTTP. Alvos que reportam significativamente mais do que seus pares são então considerados anômalos.

A detecção de anomalias requer um mínimo de três alvos saudáveis no grupo-alvo. Quando um alvo é registrado em um grupo-alvo, ele precisa primeiro passar pelas verificações de saúde para começar a receber tráfego. Quando o alvo está recebendo o alvo, o ATW começa a monitorar o alvo e publica continuamente o resultado da anomalia. Para alvos sem anomalias, o resultado da anomalia é. normal Para alvos com anomalias, o resultado da anomalia é. anomalous

A detecção de anomalias do ATW funciona independentemente das verificações de saúde do grupo-alvo. Um alvo pode passar por todas as verificações de saúde do grupo-alvo, mas ainda assim ser marcado como anômalo devido a uma taxa de erro elevada. Alvos que se tornam anômalos não afetam o status de verificação de integridade do grupo-alvo.

Status de detecção de anomalias

A ATW publica continuamente o status das detecções de anomalias que realiza nos alvos. Você pode ver o status atual a qualquer momento usando o AWS Management Console ou AWS CLI.

Para visualizar o status de detecção de anomalias usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, em Load Balancing (Balanceamento de carga), escolha Grupos de destino.

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

  4. Na página de detalhes dos grupos-alvo, escolha a guia Alvos.

  5. Na tabela de alvos registrados, você pode ver o status de anomalia de cada alvo na coluna Resultado da detecção de anomalias.

    Se nenhuma anomalia foi detectada, o resultado é. normal

    Se anomalias foram detectadas, o resultado é. anomalous

Para visualizar os resultados da detecção de anomalias usando o AWS CLI

Use o comando describe-target-health com o valor do atributo definido como. Include.member.N AnomalyDetection

Mitigação de anomalias

Importante

A função de mitigação de anomalias do ATW só está disponível ao usar o algoritmo de roteamento aleatório ponderado.

A mitigação de anomalias do ATW direciona o tráfego para longe de alvos anômalos automaticamente, dando a eles a oportunidade de se recuperarem.

Durante a mitigação:

  • O ATW ajusta periodicamente a quantidade de tráfego roteado para alvos anômalos. Atualmente, o período é a cada cinco segundos.

  • O ATW reduz a quantidade de tráfego roteado para alvos anômalos até a quantidade mínima necessária para realizar a mitigação de anomalias.

  • Os alvos que não são mais detectados como anômalos terão gradualmente mais tráfego roteado para eles até atingirem a paridade com outros alvos normais no grupo-alvo.

Ativar a mitigação de anomalias do ATW

Você pode ativar a mitigação de anomalias a qualquer momento.

Para ativar a mitigação de anomalias usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, em Load Balancing (Balanceamento de carga), escolha Grupos de destino.

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

  4. Na página de detalhes dos grupos-alvo, na guia Atributos, escolha Editar.

  5. Na página Editar atributos do grupo-alvo, na seção Configuração de tráfego, em Algoritmo de balanceamento de carga, verifique se Aleatório ponderado está selecionado.

    Nota: Quando o algoritmo aleatório ponderado é selecionado inicialmente, a detecção de anomalias está ativada por padrão.

  6. Em Mitigação de anomalias, verifique se a opção Ativar mitigação de anomalias está selecionada.

  7. Escolha Salvar alterações.

Para ativar a mitigação de anomalias usando o AWS CLI

Use o comando modify-target-group-attributes com o atributo load_balancing.algorithm.anomaly_mitigation.

Status de mitigação de anomalias

Sempre que o ATW estiver realizando a mitigação em um alvo, você pode visualizar o status atual a qualquer momento usando o ou. AWS Management Console AWS CLI

Para visualizar o status de mitigação de anomalias usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, em Load Balancing (Balanceamento de carga), escolha Grupos de destino.

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

  4. Na página de detalhes dos grupos-alvo, escolha a guia Alvos.

  5. Na tabela de alvos registrados, você pode ver o status de mitigação de anomalias de cada alvo na coluna Mitigação em vigor.

    Se a mitigação não estiver em andamento, o status é. yes

    Se a mitigação estiver em andamento, o status é. no

Para visualizar o status de mitigação de anomalias usando o AWS CLI

Use o comando describe-target-health com o valor do atributo definido como. Include.member.N AnomalyDetection

Atraso do cancelamento do registro

O Elastic Load Balancing interrompe o envio de solicitações aos destinos cujo registro esteja sendo cancelado. Por padrão, o Elastic Load Balancing aguarda 300 segundos antes de concluir o processo de cancelamento do registro, o que pode ajudar na conclusão das solicitações em trânsito para o destino. Para alterar o tempo que o Elastic Load Balancing aguarda, atualize o valor de atraso de cancelamento de registro. .

O estado inicial de um destino que terá o registro cancelado é draining. Depois de decorrido o retardo de cancelamento do registro, processo será concluído e o estado do destino será unused. Se o destino for parte de um grupo do Auto Scaling, ele poderá ser encerrado e substituído.

Se um destino cujo registro esteja sendo cancelado não tiver solicitações em trânsito nem conexões ativas, o Elastic Load Balancing concluirá imediatamente o processo de cancelamento de registro, sem aguardar o término do tempo de espera. No entanto, mesmo que o cancelamento do registro de destino seja concluído, o status do destino será exibido como draining até que o tempo limite de atraso do cancelamento do registro termine. Depois que o tempo limite expirar, o destino passará para um estado unused.

Se cancelar o registro de um destino encerrar a conexão antes de o retardo de cancelamento do registro passar, o cliente receberá uma resposta de erro de nível 500.

Para atualizar o valor de retardo de cancelamento do registro usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, em Load Balancing (Balanceamento de carga), escolha 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 Atributos, escolha Editar.

  5. Na página Editar atributos, altere o valor do Atraso do cancelamento do registro conforme o necessário.

  6. Escolha Salvar alterações.

Para atualizar o valor do atraso de cancelamento de registro usando o AWS CLI

Use o comando modify-target-group-attributes com o atributo deregistration_delay.timeout_seconds.

Modo de iniciação lenta

Por padrão, um destino começa a receber toda sua parte de solicitações assim que for registrado com um grupo de destino e enviar uma verificação de integridade inicial. Usar o modo de iniciação lenta oferece tempo para que os destinos aqueçam antes que o load balancer envie toda a parte de solicitações.

Com a iniciação lenta habilitada para um grupo de destino, os destinos entrarão no modo de iniciação lenta quando forem considerados íntegros pelo grupo de destino. Um destino sai do modo de iniciação lenta quando a duração da iniciação lenta configurada expira ou o destino se torna não íntegro. O load balancer aumenta linearmente o número de solicitações enviadas a um destino no modo de iniciação lenta. Assim que um destino íntegro deixa o modo de iniciação lenta, o balanceador de carga pode enviar uma parcela total de solicitações para esse destino.

Considerações

  • Quando você habilita a iniciação lenta para um grupo de destino, os destinos íntegros que já estão registrados no grupo não entram no modo de iniciação lenta.

  • Ao habilitar a iniciação lenta para um grupo de destino vazio e registrar destinos usando uma única operação de registro, esses destinos não entram no modo de iniciação rápida. Os destinos recém-registrados entram no modo de iniciação lenta somente quando há pelo menos um destino íntegro que não esteja no modo de iniciação lenta.

  • Se você cancelar o registro de um destino no modo de iniciação lenta, o destino sai do modo. Se você registrar o mesmo destino novamente, ele entrará no modo de iniciação lenta quando for considerado íntegro pelo grupo de destino.

  • Se um destino no modo de iniciação lenta se tornar não íntegro, o destino sairá do modo de iniciação lenta. Quando o destino se tornar íntegro, ele entrará novamente no modo de iniciação lenta.

  • Você não pode ativar o modo de início lento ao usar as solicitações menos pendentes ou algoritmos de roteamento aleatório ponderado.

Para atualizar o valor de duração da iniciação lenta usando o console

  1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

  2. No painel de navegação, em Load Balancing (Balanceamento de carga), escolha 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 Atributos, escolha Editar.

  5. Na página Editar atributos, altere o valor da Duração da iniciação lenta conforme necessário. Para desativar o modo de iniciação lenta, defina a duração para 0.

  6. Escolha Salvar alterações.

Para atualizar o valor da duração do início lento usando o AWS CLI

Use o comando modify-target-group-attributes com o atributo slow_start.duration_seconds.