🥇 Configurando ELB.

Es posible configurar muchos aspectos del ELB incluyendo.

La configuración puede ser definida mediante la consola o el AWS CLI.

🍿 Idle Connection Timeout.

Para cada conexion que el cliente hace el load balancer mantiene dos conexiones, una al cliente y otra a la instancia. Para cada una de estas dos conexiones el load balancer maneja un idle timeout que es dispado cuando no hay datos enviados sobre la conexión por un tiempo específico. Si despues de este periodo de tiempo (timeout), no hay datos enviados o recibidos, el load balancer cierra la conexion aun cuando haya datos en transito.

El valor por default es 60 segundos para ambas conexiones pero se puede ajustar a mayor o menos valor.

Si se usan listeners HTTP y HTTPS, se recomienda que se habilite la opción keep-alive (mantener vivo) para las instancias de EC2. Esto se puede habilitar en las propiedades del servidor web o en las propiedades del kernel de la instancia. Cuando keep-alive se habilita permite al load balancer reusar conexiones a las instancias, lo que reduce el uso de CPU.

Para asegurarse de que el load balancer es responsable de cerrar las conexiones a la instancia, asegurese que el valor de keep-alive es mayor que el idle timeout del load balancer.

🍿 Cross-Zone Load Balancing.

Para asegurarse de que el trafico es enrutado uniformemente a través de las instancias, sin importar su AZ, se debe habilitar cross-zone en el load balancer. Este reduce la necesidad de mantener el mismo numero de instancias en cada AZ y mejora la habilidad de la aplicación para manejar la perdida de una o mas instancias. Sin embargo en recomendable mantener aproximadamente el mismo numero de instancias en AZ para tolerancia a los posibles fallos.

Para ambientes en donde los clientes cachean la busqueda de DNS, las peticiones de entrada pueden favorecer una AZ. Al utilizar cross-zone, este desbalance de peticiones es distribuido a través de todas las instancias en la región, reduciendo el impacto de clientes mal configurados.

🍿 Connection Draining.

Permite que el load balancer deje de enviar peticiones a instancias que se desregistaron o que no estan en buen estado, manteniendo conexiones a aquellas que estan abiertas. Esto permite al load balancer completar peticiones en el aire realizadas a estas instancias.

🍿 Proxy Protocol.

Caundo se usa TCP o SSL, para conexiones a nivel del frontend y backend el load balancer reenvia las peticiones a las instancias sin modificar las peticiones de las cabeceras. Si se habilita Proxy Protocol, una cabecera leible es añadida a la cabecera de la peticion con informacion de la conexion como direccion IP, direccion IP destino, y numero de puerto. El header es enviado a la instancia como parte de la petición.

Antes de usar proxy protocol, verifique que que el load balancer no se encuentra tras un proxy server con proxy protocol habilidado, si esto es asi el load balancer agrega una cabecera mas al request, que ya se encuentra desde el proxy server. Esto puede generar errores.

🍿 Sticky Sessions.

El load balancer enruta cada petición de forma independiente a la instancia registrada con una pequeña carga. Sin embargo se puede utilizar sticky session (conocido tambine como session affinity), el cual habilita al load balancer para enlazar una sesion de usuario a una instancia especifica. Esto asegura que todas las sesiones serán enviadas a la misma instancia.

La clave es determinar cuanto tiempo el load balancer debe enrutar consistentemente al usuario a la misma instancia. Si su aplicación tiene su propia session cookie, usted puede configurar Elastic Load Balancing de tal forma que la cookie de la sesion siga la duración especificada por la cookie de la sesión de la aplicación. Si la aplicación no tiene su propia cookie, puede configurar a ELB para crear una cookie de sesión especificando su propia duración. ELB crea una cookie llamada AWSELB que es usada para mapear la sesión a la instancia.

🍿 Health Checks.

ELB soporta healt checks que verifican el estatus de una instancia sobre la cual se balancea. El estatus de una instancia es healthy (saludable) mientras el resultado de su check sea InService y unhealthy (no saludable) cuando sea OutOfService. El load balancer realiza verificaciones en todas las instancias registradas para determinar si la instancia esta saludable o no. Un healthcheck es un ping, un intento de conexión o una pagina que es verificada periodicamente. Se puede definir el internvalo de tiempo entre los healthchecks y el tiempo máximo de respuesta. Tambien es posible definir el numero máximo de healthchecks fallidos antes de marcar la instancia como unhealthy.

Listeners. CloudWatch.
comments powered by Disqus