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