amazon-web-services - tutorial - security group aws
AWS ELB no distribuye solicitudes a las instancias EC2 del grupo de escalado automático en algunos casos (2)
Estoy intentando hacer pruebas de rendimiento para mi grupo de escalado automático de AWS usando jmeter.
En primer lugar, realicé las pruebas de escalamiento de entrada / salida. Establecí el umbral para que sea de 70% de utilización de la CPU durante 2 períodos, cada período es de 2 minutos. El ELB funciona bien y las solicitudes se distribuyeron a todas las instancias de EC2 en el grupo de escala automática, a pesar de la falta de igualdad, después de la ampliación del sistema.
A continuación, quiero probar si la carga de las dos instancias puede ser el doble de la de una instancia. Reparé el número de instancia del grupo de escalado automático, configuré el recuento de instancias min / max / desired en 2. Cuando presiono load desde un solo JMeter, siempre hay solo una instancia que funciona y su utilización de CPU alcanza casi el 100 por ciento, pero la utilización de la CPU de la otra instancia sigue siendo cero ... Si presiono la carga desde un clúster de JMeter que contiene varios esclavos, todas las instancias toman carga.
Alguien dijo, tal vez la carga no es lo suficientemente pesada, por lo que el ELB consideró que solo una instancia puede manejarla y no envió solicitudes a otra instancia. No lo creo, porque transfiero la carga de un solo esclavo de este clúster de JMeter; sin embargo, aumente la carga, solo solicita un único manejador de instancia.
Encontré un blog que decía que ELB es excelente en HA pero no en el equilibrio de carga. https://www.stackdriver.com/elb-affinity-problems Pero, no creo que el comportamiento, solo una solicitud de manejo de instancia, sea normal.
¿Qué diablos en el mecanismo de equilibrio de carga ELB? Estoy confundido.
Mecanismo elástico de equilibrio de carga
- El servidor DNS utiliza la operación por turnos de DNS para determinar qué nodo equilibrador de carga en una zona de disponibilidad específica recibirá la solicitud
- El equilibrador de carga seleccionado busca la cookie "sesión adhesiva"
- El equilibrador de oad seleccionado envía la solicitud a la instancia con menos carga
Y en mayores detalles:
Zonas de disponibilidad ( improbable su caso )
De forma predeterminada, el nodo del equilibrador de carga enruta el tráfico hacia instancias de servicios de fondo dentro de la misma Zona de disponibilidad. Para garantizar que las instancias de servicios de fondo puedan gestionar la carga de solicitudes en cada zona de disponibilidad, es importante contar con números de instancias aproximadamente equivalentes en cada zona. Por ejemplo, si tiene diez instancias en la zona de disponibilidad us-east-1a y dos instancias en us-east-1b, el tráfico se distribuirá equitativamente entre las dos zonas de disponibilidad. Como resultado, las dos instancias en us-east-1b tendrán que servir la misma cantidad de tráfico que las diez instancias en us-east-1a.
Sesiones ( muy probablemente su caso )
De forma predeterminada, un equilibrador de carga enruta cada solicitud de forma independiente a la instancia del servidor con la carga más pequeña. En comparación, una sesión adhesiva vincula la sesión de un usuario a una instancia de servidor específica para que todas las solicitudes provenientes del usuario durante la sesión se envíen a la misma instancia de servidor.
AWS Elastic Beanstalk utiliza cookies HTTP generadas por el equilibrador de carga cuando las sesiones fijas están habilitadas para una aplicación. El equilibrador de carga utiliza una cookie especial generada por el equilibrador de carga para rastrear la instancia de la aplicación para cada solicitud. Cuando el equilibrador de carga recibe una solicitud, primero verifica si esta cookie está presente en la solicitud. Si es así, la solicitud se envía a la instancia de la aplicación especificada en la cookie. Si no hay cookies, el equilibrador de carga elige una instancia de aplicación basada en el algoritmo de equilibrio de carga existente. Se inserta una cookie en la respuesta para vincular solicitudes posteriores del mismo usuario a esa instancia de la aplicación. La configuración de la política define un vencimiento de cookie, que establece la duración de la validez de cada cookie.
Algoritmo de enrutamiento ( menos probable es su caso )
El nodo del equilibrador de carga envía la solicitud a instancias sanas dentro de la misma zona de disponibilidad utilizando el algoritmo de enrutamiento de connotaciones mínimas . El algoritmo de enrutamiento de mínimos valores favorece las instancias de back-end con la menor cantidad de conexiones o solicitudes pendientes.
Fuente: Terminología de equilibrio de carga elástica y conceptos clave
Espero eso ayude.
Tuve este problema con el tráfico ELB desequilibrado cuando las instancias de back-end estaban en diferentes zonas de disponibilidad y el ELB recibía solicitudes de un pequeño número de clientes. En nuestro caso, estábamos usando un ELB interno dentro de los niveles de la aplicación. En su caso, "carga de inserción desde un solo JMeter" probablemente significa una pequeña cantidad de clientes según lo visto por el ELB. La solución fue habilitar el balanceo de carga entre zonas utilizando la API similar a este fragmento:
elb-modify-lb-attributes $ {ELB} --region $ {REGION} --crosszoneloadbalancing "enabled = true"