¿Qué elementos se pueden configurar en un load balancer de Amazon AWS?
Es posible configurar muchos aspectos del ELB incluyendo.
- idle timeout
- cross-zone load balancing
- connection draining
- proxy protocol
- sticky sessions
- health checks
La configuración puede ser definida mediante la consola o el AWS CLI.
Idle Connection Timeout
Para cada conexión 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 disparado cuando no hay datos enviados sobre la conexión por un tiempo específico. Si después de este periodo de tiempo (timeout), no hay datos enviados o recibidos, el load balancer cierra la conexión 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 reutilizar 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, asegúrese 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 búsqueda 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 desregistraron o que no están en buen estado, manteniendo conexiones a aquellas que están abiertas. Esto permite al load balancer completar peticiones en el aire realizadas a estas instancias.
Proxy Protocol
Cuando se usa TCP o SSL, para conexiones a nivel del frontend y backend el load balancer reenvía las peticiones a las instancias sin modificar las peticiones de las cabeceras. Si se habilita Proxy Protocol, una cabecera leíble es añadida a la cabecera de la petición con información de la conexión como dirección IP, dirección 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 habilitado, si esto es así 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 también como session affinity), el cual habilita al load balancer para enlazar una sesión 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 sesión 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 AWS ELB 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 periódicamente. Se puede definir el intervalo de tiempo entre los healthchecks y el tiempo máximo de respuesta. También es posible definir el numero máximo de healthchecks fallidos antes de marcar la instancia como unhealthy.
