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á.
Editar atributos do grupo de destino para o Application Load Balancer
Depois de criar um grupo de destino para o Application Load Balancer, você pode editar os atributos do grupo de destino dele.
Atributos do grupo de destino
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.
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.
Balanceamento de carga entre zonas para grupos de destino do Application Load Balancer
Os nós do load balancer distribuem solicitações de clientes para destinos registrados. Quando o balanceamento de carga entre zonas estiver ativado, cada nó do balanceador de carga distribuirá o tráfego aos destinos registrados em todas as zonas de disponibilidade registradas. Quando o balanceamento de carga entre zonas estiver desativado, cada nó do balanceador de carga distribuirá o tráfego somente para os destinos registrados na respectiva zona de disponibilidade. Isso poderá ser usado se os domínios de falha de zona tiverem preferência em relação aos regionais, garantindo que uma zona íntegra não seja afetada por uma zona não íntegra ou para melhorias gerais na latência.
Com os Application Load Balancers, o balanceamento de carga entre zonas sempre está ativado por balanceador de carga e não pode ser desativado. Para grupos de destino, o padrão é usar a configuração do balanceador de carga, mas você pode substituir o padrão ativando ou desativando explicitamente o balanceamento de carga entre zonas em nível de grupo de destino.
Considerações
-
Não há compatibilidade com persistência do destino quando o balanceamento de carga entre zonas estiver desativado.
-
Não há compatibilidade com funções do Lambda quando o balanceamento de carga entre zonas estiver desativado.
-
A tentativa de desativar o balanceamento de carga entre zonas por meio da API
ModifyTargetGroupAttributesse algum destino tiver um parâmetroAvailabilityZonedefinido comoallresultará em um erro. -
Ao registrar destino, o parâmetro
AvailabilityZoneé obrigatório. Só é permitido usar valores específicos de zona de disponibilidade quando o balanceamento de carga entre zonas estiver desativado. Caso contrário, o parâmetro será ignorado e tratado comoall.
Práticas recomendadas
-
Planeje a capacidade de destino suficiente em todas as zonas de disponibilidade que você espera utilizar, por grupo de destino. Se você não conseguir planejar a capacidade suficiente em todas as zonas de disponibilidade participantes, recomendamos que você mantenha o balanceamento de carga entre zonas ativado.
-
Ao configurar seu Application Load Balancer com vários grupos de destino, certifique-se de que todos os grupos de destino estejam participando das mesmas zonas de disponibilidade na região configurada. Isso evita que uma zona de disponibilidade fique vazia enquanto o balanceamento de carga entre zonas estiver desativado, pois acionará um Erro 503 para todas as solicitações HTTP que entrarem na zona de disponibilidade vazia.
-
Evite criar sub-redes vazias. Os Application Load Balancers expõem endereços IP de zona por meio do DNS para as sub-redes vazias, o que acionará Erros 503 para solicitações HTTP.
-
Pode haver ocorrências nas quais um grupo de destino com o balanceamento de carga entre zonas desativado tenha capacidade de destino suficiente por zona de disponibilidade, mas todos os destinos em uma zona de disponibilidade não estejam íntegros. Quando houver pelo menos um grupo de destino com todos os destinos não íntegros, os endereços IP dos nós do balanceador de carga serão removidos do DNS. Depois que o grupo de destino tiver pelo menos um destino íntegro, os endereços IP serão restaurados para o DNS.
Desativar o balanceamento de carga entre zonas
Você pode desativar o balanceamento de carga entre zonas para seus grupos de destino do Application Load Balancer a qualquer momento.
Ativar o balanceamento de carga entre zonas
Você pode ativar o balanceamento de carga entre zonas para seus grupos de destino do Application Load Balancer a qualquer momento. A configuração de balanceamento de carga entre zonas por grupo de destino substitui a configuração por balanceador de carga.
Ponderações de destinos automáticos (ATW)
As ponderações de destinos automáticos (ATW) monitoram constantemente os destinos que executam suas aplicações, detectando desvios significativos de desempenho, conhecidos como anomalias. As ATW fornecem a capacidade de ajustar dinamicamente a quantidade de tráfego roteado para os destinos, por meio da detecção de anomalias de dados em tempo real.
As ponderações de destinos automáticos (ATW) realizam automaticamente a detecção de anomalias em cada Application Load Balancer da conta. Quando destinos anômalos são identificados, as ATW podem tentar estabilizá-los automaticamente reduzindo a quantidade de tráfego que roteiam, o que é conhecido como mitigação de anomalias. As ATW otimizam continuamente a distribuição de tráfego para maximizar as taxas de êxito por destino e, ao mesmo tempo, minimizar as taxas de falha do grupo de destino.
Considerações:
-
Atualmente, a detecção de anomalias monitora os códigos de resposta HTTP 5xx provenientes de seus destinos e as falhas de conexão com eles. A detecção de anomalias está sempre ativada e não pode ser desativada.
-
As ATW não são compatíveis ao usar o Lambda como destino.
Detecção de anomalias
As ATW monitoram a detecção de anomalias de qualquer destino que esteja exibindo um desvio significativo no comportamento de outros destinos no grupo de destino. Esses desvios, chamados de anomalias, são determinados comparando os erros percentuais de um destino com os erros percentuais de outros destinos no grupo de destino. Esses erros podem ser tanto erros de conexão quanto códigos de erro HTTP. Destinos que relatam 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 destinos íntegros no grupo de destino. Quando um alvo é registrado em um grupo-alvo, ele deve passar pelas verificações de saúde antes de receber tráfego. Depois que o alvo começa a receber tráfego, o ATW começa a monitorar o alvo e publica continuamente o resultado da anomalia. Em destinos sem anomalias, o resultado da anomalia é normal. Em destinos com anomalias, o resultado da anomalia é anomalous.
A detecção de anomalias das ATW funciona independentemente das verificações de integridade do grupo de destino. Um destino pode passar por todas as verificações de integridade do grupo de destino, mas ainda assim ser marcado como anômalo devido a uma taxa de erro elevada. Destinos que se tornam anômalos não afetam o status da verificação de integridade do grupo de destino.
Status de detecção de anomalia
Você pode ver o status atual de detecção de anomalias. Os valores possíveis são os seguintes:
-
normal— Nenhuma anomalia foi detectada. -
anomalous— Anomalias foram detectadas.
Mitigação de anomalias
A mitigação de anomalias das ATW direciona o tráfego para longe de destinos anômalos automaticamente, dando a eles a oportunidade de se recuperarem.
Requisito
A função de mitigação de anomalias das ATW só está disponível ao usar o algoritmo de roteamento aleatório ponderado.
Durante a mitigação:
-
As ATW ajustam periodicamente a quantidade de tráfego roteado para destinos anômalos. Atualmente, o período é a cada cinco segundos.
-
As ATW reduzem a quantidade de tráfego roteado para destinos anômalos até a quantidade mínima necessária para realizar a mitigação de anomalias.
-
Os destinos 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 destinos normais no grupo de destino.
Status de mitigação
Você pode verificar se o ATW está realizando a mitigação em um alvo. Os valores possíveis são os seguintes:
yes— A mitigação está em andamento.no— A mitigação não está em andamento.
Sessões persistentes para seu Application Load Balancer
Por padrão, um Application Load Balancer roteia cada solicitação de modo independente para um destino registrado com base no algoritmo de balanceamento de carga escolhido. No entanto, você pode usar o recurso sessão persistente (também conhecido como afinidade de sessão) para habilitar o balanceador de carga a vincular a sessão de um usuário a um destino específico. Isso garante que todas as solicitações do usuário durante a sessão sejam enviadas para o mesmo destino. Esse recurso é útil para servidores que mantêm as informações de estado para fornecer uma experiência contínua aos clientes. Para usar sessões persistentes, o cliente deve ser compatível com cookies.
Os Application Load Balancers são compatíveis a cookies baseados em duração e cookies baseados em aplicação. As sessões persistentes são habilitadas por grupo de destino. Você pode usar uma combinação de persistência baseada em duração, persistência baseada em aplicação e ausência de persistência em seus grupos de destino.
O segredo para o gerenciamento de sessões persistentes é determinar por quanto tempo o balanceador de carga deve rotear consistentemente a solicitação do usuário para o mesmo destino. Se sua aplicação tiver seu próprio cookie de sessão, você poderá usar a persistência baseada em aplicação, de forma que o cookie da sessão do balanceador de carga acompanhe a duração especificada pelo cookie de sessão da aplicação. Se sua aplicação não tiver seu próprio cookie de sessão, você poderá usar a persistência baseada na duração para gerar um cookie de sessão do balanceador de carga com uma duração que você especificar.
O conteúdo desses cookies gerados pelo balanceador de carga é criptografado usando uma chave alternante. Você não pode descriptografar ou modificar os cookies gerados pelo balanceador de carga.
Para os dois tipos de persistência, o Application Load Balancer redefine a expiração dos cookies que ele gera após cada solicitação. Se um cookie expirar, a sessão não continuará persistente e o cliente deverá remover o cookie de seu repositório de cookies.
Requisitos
-
Um HTTP/HTTPS balanceador de carga.
-
Pelo menos uma instância íntegra em cada Zona de disponibilidade.
Considerações
-
Não há compatibilidade com sessões persistentes se o balanceamento de carga entre zonas estiver desabilitado. A tentativa de habilitar sessões persistentes enquanto o balanceamento de carga entre zonas estiver desabilitado falhará.
-
Para cookies baseados em aplicação, os nomes dos cookies devem ser especificados individualmente para cada grupo de destino. No entanto, para cookies baseados em duração,
AWSALBé o único nome usado em todos os grupos de destino. -
Se você estiver usando várias camadas de Application Load Balancers, poderá habilitar sessões persistentes em todas as camadas com cookies baseados em aplicação. No entanto, com cookies baseados em duração, você só poderá habilitar sessões persistentes em uma camada, porque
AWSALBé o único nome disponível. -
Se o Application Load Balancer receber um cookie de persistência
AWSALBCORSeAWSALBbaseado em duração, o valor emAWSALBCORSterá precedência. -
A persistência baseada em aplicação não funciona com grupos de destino ponderados.
-
Se você tiver uma ação de encaminhamento com vários grupos de destino e um ou mais grupos de destino tiver sessões persistentes habilitadas, você deverá habilitar a persistência por grupo de destino.
-
WebSocket as conexões são inerentemente pegajosas. Se o cliente solicitar um upgrade de conexão para WebSockets, o destino que retorna um código de status HTTP 101 para aceitar o upgrade de conexão é o destino usado na WebSockets conexão. Depois que a WebSockets atualização for concluída, a aderência baseada em cookies não será usada.
-
Os Application Load Balancers usam o atributo
Expiresno cabeçalho do cookie em vez do atributoMax-Age. -
Os Application Load Balancers não são compatíveis com valores de cookie codificados por URL.
-
Se o Application Load Balancer receber uma nova solicitação enquanto o destino estiver sendo esgotado devido ao cancelamento do registro, a solicitação será roteada para um destino íntegro.
Tipos de viscosidade
Persistência com base em duração
A persistência baseada na duração encaminha as solicitações para o mesmo destino em um grupo de destino usando um cookie gerado pelo balanceador de carga (AWSALB). O cookie é usado para mapear a sessão para o destino. Se sua aplicação não tiver seu próprio cookie de sessão, você poderá especificar sua própria duração de persistência e gerenciar por quanto tempo seu balanceador de carga deve rotear consistentemente a solicitação do usuário para o mesmo destino.
Quando um balanceador de carga receber uma solicitação de um cliente pela primeira vez, ele roteará a solicitação para um destino (com base no algoritmo escolhido) e gerará um cookie com o nome AWSALB. Ele codifica informações sobre o destino selecionado, criptografa o cookie e inclui o cookie na resposta ao cliente. O cookie gerado pelo balanceador de carga tem sua própria expiração de 7 dias, que não é configurável.
Nas solicitações subsequentes, o cliente deverá incluir o cookie AWSALB. Quando o balanceador de carga receber uma solicitação de um cliente contendo o cookie, ele a detectará e encaminhará a solicitação para o mesmo destino. Se o cookie estiver presente, mas não puder ser decodificado, ou se ele se referir a um destino cujo registro foi cancelado ou não está íntegro, o balanceador de carga seleciona um novo destino e atualiza o cookie com informações sobre o novo destino.
Para solicitações de compartilhamento de recursos de origem cruzada (CORS), alguns navegadores exigem SameSite=None; Secure para habilitar a persistência. Para oferecer suporte a esses navegadores, o balanceador de carga sempre gera um segundo cookie de persistência, AWSALBCORS, que inclui as mesmas informações do cookie de persistência original, além do atributo SameSite. Os clientes recebem os dois cookies, incluindo solicitações não relacionadas ao CORS.
Persistência com base em aplicação
A persistência baseada em aplicação oferece a flexibilidade de definir seus próprios critérios de persistência entre cliente e destino. Quando você ativa a persistência baseada em aplicação, o balanceador de carga encaminha a primeira solicitação para um destino dentro do grupo de destino com base no algoritmo escolhido. Espera-se que o destino defina um cookie personalizado de aplicação que corresponda ao cookie configurado no balanceador de carga para viabilizar a persistência. Esse cookie personalizado pode incluir qualquer um dos atributos de cookie exigidos pela aplicação.
Quando o Application Load Balancer receber o cookie personalizado de aplicação do destino, ele gerará automaticamente um novo cookie criptografado de aplicação para capturar informações de persistência. Esse cookie de aplicação gerado pelo balanceador de carga captura informações de persistência para cada grupo de destino que esteja com a persistência baseada em aplicações habilitada.
O cookie de aplicação gerado pelo balanceador de carga não copia os atributos do cookie personalizado definido pelo destino. Ele tem seu próprio prazo de validade de 7 dias, que não é configurável. Na resposta ao cliente, o Application Load Balancer valida somente o nome com o qual o cookie personalizado foi configurado no grupo de destino e não o valor ou o atributo de expiração do cookie personalizado. Desde que o nome corresponda, o balanceador de carga enviará os dois cookies, o cookie personalizado definido pelo destino e o cookie de aplicação gerado pelo balanceador de carga, em resposta ao cliente.
Nas solicitações subsequentes, os clientes precisarão devolver os dois cookies para manter a persistência. O balanceador de carga descriptografa o cookie de aplicação e verifica se a duração configurada da persistência ainda é válida. Em seguida, ele usa as informações do cookie para enviar a solicitação para o mesmo destino dentro do grupo de destino a fim de manter a persistência. O balanceador de carga também transfere o cookie personalizado de aplicação para o destino sem inspecioná-lo ou modificá-lo. Nas respostas subsequentes, a expiração do cookie de aplicação gerado pelo balanceador de carga e a duração da persistência configurada no balanceador de carga serão redefinidas. Para manter a persistência entre o cliente e o destino, a expiração do cookie e a duração da persistência não devem expirar.
Se um destino falhar ou deixar de ser íntegro, o balanceador de carga interromperá as solicitações de roteamento para esse destino e escolherá um novo destino íntegro com base no algoritmo de balanceamento de carga escolhido. O balanceador de carga trata a sessão como “aderida” ao novo destino íntegro e continua a rotear solicitações para o novo destino íntegro, mesmo que o destino com falha retorne.
Com solicitações de compartilhamento de recursos de origem cruzada (CORS), para habilitar a persistência, o balanceador de carga só adiciona os atributos SameSite=None; Secure ao cookie de aplicação gerado pelo balanceador de carga se a versão de agente do usuário for Chromium80 ou superior.
Como a maioria dos navegadores limita os cookies a 4K, o balanceador de carga fragmenta cookies de aplicativos maiores que 4K em vários cookies. Os Application Load Balancers são compatíveis com cookies de até 16 K e, portanto, podem criar até 4 fragmentos que enviam ao cliente. O nome do cookie do aplicativo que o cliente vê começa com “AWSALBAPP-” e inclui um número de fragmento. Por exemplo, se o tamanho do cookie for de 0 a 4K, o cliente verá AWSALBAPP -0. Se o tamanho do cookie for de 4 a 8k, o cliente verá AWSALBAPP -0 e AWSALBAPP -1 e assim por diante.
Rebalanceamento manual
Ao aumentar a escala verticalmente, se o número de destinos aumentar consideravelmente, há potencial para uma distribuição desigual da carga devido à persistência. Nesse cenário, você poderá reequilibrar a carga em seus destinos usando as duas opções a seguir:
-
Defina uma expiração no cookie gerado pela aplicação que seja anterior à data e hora atuais. Isso impede que os clientes enviem o cookie para o Application Load Balancer, que reiniciará o processo de estabelecer a aderência.
-
Defina uma curta duração na configuração de aderência baseada em aplicativos do balanceador de carga; por exemplo, 1 segundo. Isso força o Application Load Balancer a restabelecer a aderência mesmo que o cookie definido pelo alvo não tenha expirado.
