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

Edite os atributos do grupo-alvo para seu Application Load Balancer

Depois de criar um grupo-alvo para o Application Load Balancer, você pode editar os atributos do grupo-alvo.

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 do atraso de cancelamento de registro usando o AWS CLI

Use o modify-target-group-attributescomando com o deregistration_delay.timeout_seconds atributo.

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.

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

Use o modify-target-group-attributescomando com o slow_start.duration_seconds atributo.

Balanceamento de carga entre zonas para grupos-alvo 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.

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.

Para desativar o balanceamento de carga entre zonas usando o AWS CLI

Use o modify-target-group-attributescomando e defina o load_balancing.cross_zone.enabled atributo comofalse.

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=false

Esta é uma resposta de exemplo:

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "false"
        },
    ]
}

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.

Para ativar o balanceamento de carga entre zonas usando o AWS CLI

Use o modify-target-group-attributescomando e defina o load_balancing.cross_zone.enabled atributo comotrue.

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=true

Esta é uma resposta de exemplo:

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "true"
        },
    ]
}

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. ATWfornece 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, eles ATW podem tentar estabilizá-los automaticamente reduzindo a quantidade de tráfego para os quais são roteados, o que é conhecido como mitigação de anomalias. ATWotimiza continuamente a distribuição do tráfego para maximizar as taxas de sucesso por alvo e, ao mesmo tempo, minimizar as taxas de falha do grupo-alvo.

Detecção de anomalias

ATWmonitora a detecção de anomalias para quaisquer alvos que estejam 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 HTTP de erro. 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, 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

ATWa detecção de anomalias 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

ATWpublica 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 os resultados da detecção de anomalias usando o AWS CLI

Use o describe-target-healthcomando com o valor do Include.member.N atributo definido comoAnomalyDetection.

Mitigação de anomalias

ATWa mitigação de anomalias afasta automaticamente o tráfego de alvos anômalos, dando a eles a oportunidade de se recuperarem.

Ativar a mitigação de ATW anomalias

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

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

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

Status de mitigação de anomalias

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

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

Use o describe-target-healthcomando com o valor do Include.member.N atributo definido comoAnomalyDetection.

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 nem modificar 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.

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 que foi cancelado ou não está íntegro, o load balancer selecionará um novo destino e atualizará o cookie com informações sobre o novo destino.

Para solicitações de compartilhamento de recursos (CORS) de origem cruzada, alguns navegadores precisam ativar SameSite=None; Secure a aderência. Para oferecer suporte a esses navegadores, o balanceador de carga sempre gera um segundo cookie de aderênciaAWSALBCORS, que inclui as mesmas informações do cookie de aderência original, bem como o atributo. SameSite Os clientes recebem os dois cookies, incluindo não CORS solicitações.

Para ativar a aderência com base na duração usando o AWS CLI

Use o modify-target-group-attributescomando com stickiness.enabled os stickiness.lb_cookie.duration_seconds atributos e.

Use o comando a seguir para habilitar a persistência com base em duração.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

Sua saída deve ser similar ao exemplo a seguir.

     {     
        "Attributes": [
           ...
            {
                 "Key": "stickiness.enabled",
                 "Value": "true"
              },           
              {
                  "Key": "stickiness.lb_cookie.duration_seconds",
                  "Value": "86500"
              
              },
           ...
          ]
      }           

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 (CORS) de origem cruzada, para permitir a aderência, o balanceador de carga adiciona SameSite=None; Secure os atributos ao cookie do aplicativo gerado pelo balanceador de carga somente se a versão do agente do usuário for Chromium80 ou superior.

Como a maioria dos navegadores limita os cookies a 4 K, o balanceador de carga fragmenta cookies de aplicação com tamanho superior a 4 K 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.

Para ativar a aderência baseada em aplicativos usando o AWS CLI

Use o modify-target-group-attributescomando com os seguintes atributos:

Use o comando a seguir para habilitar a persistência com base em aplicação.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name,Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds,Value=time-in-seconds

Sua saída deve ser similar ao exemplo a seguir.

 
       {
            "Attributes": [
                ...
                {
                    "Key": "stickiness.enabled",
                    "Value": "true"
                },
                {
                    "Key": "stickiness.app_cookie.cookie_name",
                    "Value": "MyCookie"
                },
                {
                    "Key": "stickiness.type",
                    "Value": "app_cookie"
                },
                {
                    "Key": "stickiness.app_cookie.duration_seconds",
                    "Value": "86500"
                },
                ...
            ]
        }  
            
            

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: