Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Edite los atributos del grupo objetivo para su Application Load Balancer

Después de crear un grupo objetivo para su Application Load Balancer, puede editar los atributos del grupo objetivo.

Retardo de anulación del registro

Elastic Load Balancig deja de enviar solicitudes a los destinos que están en proceso de anulación del registro. De forma predeterminada, Elastic Load Balancing espera 300 segundos antes de completar el proceso de anulación del registro, para ayudar a que se completen las solicitudes en tránsito hacia el destino. Para cambiar la cantidad de tiempo que Elastic Load Balancing espera, actualice el valor del retardo de anulación de registro.

El estado inicial de un destino en proceso de anulación del registro es draining. Una vez transcurrido el retardo de anulación del registro, el proceso de anulación del registro se completa y el estado del destino es unused. Si el destino forma parte de un grupo de escalado automático, pueden terminarse y sustituirse.

Si un destino que anula el registro no tiene ninguna solicitud en tránsito y ninguna conexión activa, Elastic Load Balancing completa inmediatamente el proceso de anulación de registro, sin esperar a que transcurra el retardo de anulación de registro. Sin embargo, aunque se haya completado el proceso de anulación del registro del destino, se mostrará el estado del destino como draining hasta que transcurra el tiempo de anulación de registro. Una vez transcurrido el tiempo de espera, el destino pasa a un estado unused.

Si un destino en proceso de anulación del registro termina la conexión antes de que haya transcurrido el retardo de anulación del registro, el cliente recibe una respuesta de error de nivel 500.

Para actualizar el valor del retraso en la cancelación del registro mediante el AWS CLI

Utilice el modify-target-group-attributescomando con el deregistration_delay.timeout_seconds atributo.

Modo de inicio lento

De forma predeterminada, un destino comienza a recibir su cuota completa de solicitudes tan pronto como se registra con un grupo de destino y pasa una comprobación de estado inicial. Usar el modo de inicio lento proporciona a los destinos tiempo para calentarse antes de que el equilibrador de carga les envíe una cuota completa de solicitudes.

Después de habilitar el inicio lento para un grupo de destino, sus destinos entran en modo de inicio lento cuando el grupo de destino los considera en buen estado. Un destino en modo de inicio lento sale de este modo cuando transcurre el período de duración de inicio lento configurado o el destino deja de estar en buen estado. El equilibrador de carga aumenta linealmente el número de solicitudes que puede enviar a un destino en modo de inicio lento. Una vez que un destino en buen estado sale del modo de inicio lento, el equilibrador de carga puede enviarle una cuota completa de solicitudes.

Para actualizar el valor de duración del inicio lento, utilice el AWS CLI

Utilice el modify-target-group-attributescomando con el slow_start.duration_seconds atributo.

Equilibrio de carga entre zonas para los grupos objetivo de Application Load Balancer

Los nodos del equilibrador de carga distribuyen las solicitudes procedentes de los clientes entre los destinos registrados. Cuando el equilibrio de carga entre zonas está habilitado, cada nodo del equilibrador de carga distribuye el tráfico entre los destinos registrados de todas las zonas de disponibilidad habilitadas. Cuando el equilibrio de carga entre zonas está deshabilitado, cada nodo del equilibrador de carga distribuye el tráfico únicamente entre los destinos registrados de su zona de disponibilidad. Esto puede ser si se prefieren los dominios de fallos zonales en lugar de los regionales, para garantizar que una zona en buen estado no se vea afectada por una zona en mal estado o para mejorar la latencia general.

Con los equilibradores de carga de aplicaciones, el equilibrio de carga entre zonas siempre está activado en el nivel del equilibrador de carga y no se puede desactivar. Para los grupos de destino, la configuración del equilibrador de carga está predeterminada, pero puede anularla activando o desactivando explícitamente el equilibrio de carga entre zonas al nivel del grupo de destino.

Deshabilitar el equilibrio de carga entre zonas

Puede deshabilitar un equilibrador de carga entre zonas para sus grupos de destino del Equilibrador de carga de aplicación en cualquier momento.

Para desactivar el balanceo de carga entre zonas mediante el AWS CLI

Utilice el modify-target-group-attributescomando y defina false el load_balancing.cross_zone.enabled atributo en.

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

A continuación, se muestra un ejemplo de respuesta:

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

Habilitar equilibrio de carga entre zonas

Puede habilitar un equilibrador de carga entre zonas para sus grupos de destino del Equilibrador de carga de aplicación en cualquier momento. La configuración del equilibrio de carga entre zonas a nivel del grupo de destino anula la configuración a nivel del equilibrador de carga.

Para activar el balanceo de carga entre zonas mediante el AWS CLI

Utilice el modify-target-group-attributescomando y defina true el load_balancing.cross_zone.enabled atributo en.

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

A continuación, se muestra un ejemplo de respuesta:

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

Pesos objetivo automáticos (ATW)

Automatic Target Weights (ATW) supervisa constantemente los objetivos en los que se ejecutan sus aplicaciones y detecta desviaciones de rendimiento significativas, conocidas como anomalías. ATWofrece la posibilidad de ajustar dinámicamente la cantidad de tráfico que se dirige a los objetivos mediante la detección de anomalías en los datos en tiempo real.

Automatic Target Weights (ATW) detecta automáticamente las anomalías en todos los Application Load Balancer de tu cuenta. Cuando se identifican objetivos anómalos, ATW pueden intentar estabilizarlos automáticamente reduciendo la cantidad de tráfico a los que se enrutan, lo que se conoce como mitigación de anomalías. ATWoptimiza continuamente la distribución del tráfico para maximizar las tasas de éxito por objetivo y, al mismo tiempo, minimizar las tasas de fracaso del grupo objetivo.

Detección de anomalías

ATWla detección de anomalías monitorea cualquier objetivo que muestre una desviación significativa en su comportamiento con respecto a otros objetivos de su grupo objetivo. Estas desviaciones, denominadas anomalías, se determinan comparando el porcentaje de errores de un objetivo con el porcentaje de errores de otros objetivos del grupo objetivo. Estos errores pueden ser tanto errores de conexión como códigos de HTTP error. Los objetivos que reportan niveles significativamente más altos que sus pares se consideran anómalos.

La detección de anomalías requiere un mínimo de tres objetivos sanos en el grupo objetivo. Cuando un objetivo está registrado en un grupo objetivo, primero tiene que pasar los controles de estado para empezar a recibir tráfico. Una vez que el objetivo recibe el objetivo, ATW comienza a monitorizarlo y publica continuamente el resultado de la anomalía. En el caso de los objetivos sin anomalías, el resultado de la anomalía es. normal En el caso de los objetivos con anomalías, el resultado de la anomalía es. anomalous

ATWla detección de anomalías funciona independientemente de los controles de estado del grupo objetivo. Un objetivo puede superar todos los controles de estado del grupo objetivo, pero seguir marcándolo como anómalo debido a una elevada tasa de error. El hecho de que los objetivos pasen a ser anómalos no afecta al estado de las comprobaciones de estado del grupo objetivo.

Estado de detección de anomalías

ATWpublica continuamente el estado de las detecciones de anomalías que realiza en los objetivos. Puede ver el estado actual en cualquier momento mediante la AWS Management Console tecla o. AWS CLI

Para ver los resultados de la detección de anomalías mediante el AWS CLI

Utilice el describe-target-healthcomando con el valor del Include.member.N atributo establecido en. AnomalyDetection

Mitigación de anomalías

ATWla mitigación de anomalías desvía automáticamente el tráfico de los objetivos anómalos, lo que les da la oportunidad de recuperarse.

Activa la mitigación de anomalías ATW

Puedes activar la mitigación de anomalías en cualquier momento.

Para activar la mitigación de anomalías mediante la AWS CLI

Utilice el modify-target-group-attributescomando con el load_balancing.algorithm.anomaly_mitigation atributo.

Estado de mitigación de anomalías

Siempre que ATW esté realizando una mitigación en un objetivo, puede ver el estado actual en cualquier momento utilizando la tecla AWS Management Console o AWS CLI.

Para ver el estado de mitigación de anomalías mediante el AWS CLI

Utilice el describe-target-healthcomando con el valor del Include.member.N atributo establecido en. AnomalyDetection

Sesiones persistentes para Equilibrador de carga de aplicación

De forma predeterminada, un Equilibrador de carga de aplicación enruta cada solicitud de manera independiente a un destino registrado en función del algoritmo de equilibrio de carga elegido. Sin embargo, puede utilizar la característica de sesión persistente (también denominada afinidad de sesión) que permite que el equilibrador de carga vincule una sesión del usuario a una instancia concreta. Con ello se garantiza que todas las solicitudes de ese usuario durante la sesión se envían al mismo destino. Esta característica resulta útil para los servidores que mantienen información de estado, para ofrecer una experiencia de continuidad a los clientes. Para utilizar las sesiones persistentes, los clientes deben admitir las cookies.

Los equilibradores de carga de aplicaciones admiten cookies basadas en la duración y cookies basadas en aplicaciones. Las sesiones persistentes se habilitan para grupos de destino. Se puede usar una combinación de persistencia en función de la duración, persistencia en función de la aplicación y ausencia de persistencia en los grupos de destino.

La clave para administrar las sesiones persistentes consiste en determinar durante cuánto tiempo deberá direccionar el equilibrador de carga la solicitud del usuario a la misma instancia. Si la aplicación tiene su propia cookie de sesión, entonces puede usar la persistencia en función de la aplicación y la cookie de sesión del equilibrador de carga respeta la duración especificada por la cookie de sesión de la aplicación. Si la aplicación no tiene su propia cookie de sesión, entonces puede utilizar la persistencia en función de la duración para generar una cookie de sesión del equilibrador de carga con una duración especificada.

El contenido de estas cookies generadas por el equilibrador de carga se cifra mediante una clave rotativa. Las cookies generadas por el equilibrador de carga no se pueden descifrar ni modificar.

Para ambos tipos de persistencia, el Equilibrador de carga de aplicación restablece la caducidad de las cookies que genera después de cada solicitud. Si una cookie caduca, la sesión deja de ser persistente y el cliente debe eliminarla de su almacén de cookies.

Persistencia en función de la duración

La rigidez en función de la duración dirige las solicitudes al mismo destino de un grupo de destino mediante una cookie generada por el equilibrador de carga (AWSALB). La cookie se utiliza para asignar la sesión al destino. Si la aplicación no tiene su propia cookie de sesión, puede especificar su propia duración de persistencia y administrar durante cuánto tiempo el equilibrador de carga debe dirigir de manera consistente la solicitud del usuario al mismo destino.

Cuando un equilibrador de carga recibe una solicitud de un cliente por primera vez, la direcciona a un destino (según el algoritmo seleccionado) y genera una cookie denominada AWSALB. Codifica la información sobre el destino seleccionado, cifra la cookie y la incluye en la respuesta al cliente. La cookie generada por el equilibrador de carga tiene su propia caducidad de 7 días, que no se puede configurar.

En las solicitudes posteriores, el cliente debe incluir la cookie AWSALB. Cuando el equilibrador de carga recibe una solicitud de un cliente que contiene la cookie, la detecta y dirige la solicitud al mismo destino. Si la cookie está presente pero no se puede decodificar, o si hace referencia a un destino que cuyo registro se ha anulado o no está en buen estado, el equilibrador de carga selecciona un nuevo destino y actualiza la cookie con información sobre el nuevo destino.

En el caso de las solicitudes de intercambio de recursos entre orígenes (CORS), algunos navegadores deben SameSite=None; Secure habilitar la adherencia. Para admitir estos navegadores, el balanceador de cargas siempre genera una segunda cookie de adherenciaAWSALBCORS, que incluye la misma información que la cookie de persistencia original, así como el atributo. SameSite Los clientes reciben ambas cookies, incluidas las cookies no solicitadas. CORS

Para habilitar la adherencia basada en la duración, utilice la AWS CLI

Utilice el modify-target-group-attributescomando con los atributos y. stickiness.enabled stickiness.lb_cookie.duration_seconds

Use el siguiente comando para habilitar la persistencia en función de la duración.

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

El resultado debería ser similar al siguiente ejemplo.

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

Persistencia en función de la aplicación

La persistencia en función de la aplicación le brinda la flexibilidad de establecer sus propios criterios para determinar la persistencia a los destinos del cliente. Cuando se habilita la persistencia en función de las aplicaciones, el equilibrador de carga dirige la primera solicitud a un destino del grupo de destino en función del algoritmo elegido. Se espera que el destino establezca una cookie de aplicación personalizada que coincida con la cookie configurada en el equilibrador de carga para permitir la persistencia. Esta cookie personalizada puede incluir cualquiera de los atributos de cookie requeridos por la aplicación.

Cuando el Equilibrador de carga de aplicación recibe la cookie de aplicación personalizada del destino, genera automáticamente una nueva cookie de aplicación cifrada para capturar la información de persistencia. Esta cookie de aplicación generada por el equilibrador de carga captura la información sobre la persistencia de cada grupo de destino que tiene habilitada la persistencia en función de aplicaciones.

La cookie de aplicación generada por el equilibrador de carga no copia los atributos de la cookie personalizada establecida por el destino. Tiene su propia caducidad de 7 días, que no se puede configurar. En la respuesta al cliente, el Equilibrador de carga de aplicación solo valida el nombre con el que se configuró la cookie personalizada a nivel del grupo de destino y no el valor ni el atributo de caducidad de la cookie personalizada. Siempre que el nombre coincida, el equilibrador de carga envía ambas cookies, la cookie personalizada establecida por el destino y la cookie de aplicación generada por el equilibrador de carga, en la respuesta al cliente.

En las solicitudes posteriores, los clientes tienen que devolver ambas cookies para mantener la persistencia. El equilibrador de carga descifra la cookie de la aplicación y comprueba si el tiempo de permanencia configurado sigue siendo válido. Luego, utiliza la información de la cookie para enviar la solicitud al mismo destino dentro del grupo de destino con el fin de mantener la persistencia. El equilibrador de carga también envía por proxy la cookie de la aplicación personalizada al destino sin inspeccionarla ni modificarla. En las respuestas posteriores, se restablecen la fecha de caducidad de la cookie de aplicación generada por el equilibrador de carga y el tiempo de permanencia configurado en el equilibrador de carga. Para mantener la persistencia entre el cliente y el destino, la caducidad de la cookie y el tiempo de persistencia no deben llegar a su fin.

Si se produce un error en una instancia o esta pasa a encontrarse en mal estado, el equilibrador de carga deja de enrutar las solicitudes a esa instancia y elige una nueva en buen estado en función del algoritmo de equilibrio de carga existente. El equilibrador de carga trata la sesión como si estuviera "adherida" a la nueva instancia en buen estado y continúa direccionando las solicitudes a esa instancia aunque la instancia que sufrió el error vuelva a estar en buen estado.

En el caso de las solicitudes de intercambio de recursos (CORS) de origen cruzado, el balanceador de cargas añade los SameSite=None; Secure atributos a la cookie de la aplicación generada por el balanceador de cargas solo si la versión del agente de usuario es Chromium80 o superior.

Debido a que la mayoría de los navegadores limitan una cookie a 4 KB de tamaño, el equilibrador de carga fragmenta las cookies de más de 4 KB en varias cookies. Los equilibradores de carga de aplicaciones admiten cookies de hasta 16 KB y, por lo tanto, pueden crear hasta 4 particiones para enviarlos al cliente. El nombre de la cookie de la aplicación que ve el cliente comienza por «-» e incluye un número de fragmento. AWSALBAPP Por ejemplo, si el tamaño de la cookie es de 0 a 4 K, el cliente ve AWSALBAPP -0. Si el tamaño de la cookie es de 4 a 8 k, el cliente ve AWSALBAPP -0 y -1, y AWSALBAPP así sucesivamente.

Para habilitar la adherencia basada en aplicaciones, utilice el AWS CLI

Utilice el modify-target-group-attributescomando con los siguientes atributos:

Use el siguiente comando para habilitar la persistencia en función de aplicaciones.

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

El resultado debería ser similar al siguiente ejemplo.

 
       {
            "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"
                },
                ...
            ]
        }  
            
            

Reequilibrado manual

Al escalar verticalmente, si el número de destinos aumenta considerablemente, existe la posibilidad de que la carga se distribuya de forma desigual debido a la persistencia. En este escenario, puede reequilibrar la carga sobre los destinos mediante las dos opciones siguientes: