¿Cómo puedo implementar un clúster haproxy escalable y confiable en Amazon EC2?

Necesitamos una funcionalidad más avanzada que la que proporciona ELB (principalmente inspección L7), pero no es obvio cómo manejar cosas como los latidos del corazón y la alta disponibilidad con algo como haproxy usando EC2. Existe una alta probabilidad de que necesitemos 3 o más nodos haproxy en el clúster, por lo que un simple latido entre dos nodos no funcionará.

Parece que tener una capa de latidos delante de los nodos haproxy sería el camino a seguir, posiblemente usando IPVS, pero manejando los cambios de configuración a medida que cambia el clúster EC2 (ya sea a través de cambios intencionales, como expansión o no intencionales, como perder un Nodo EC2) parece no trivial.

Preferiblemente, la solución abarcaría al menos dos zonas de disponibilidad.

En respuesta a Qs: No, las sesiones no son pegajosas. Y sí, necesitaremos SSL, pero eso en teoría podría ser manejado por otra configuración completamente: podemos dirigir el tráfico SSL a una ubicación diferente que el tráfico que no es SSL.

OK, nunca he creado una solución de equilibrio de carga de AWS con tráfico en los niveles de SmugMug, pero solo pensando en la teoría y los servicios de AWS, se me ocurren un par de ideas.

A la pregunta original le faltan algunas cosas que tienden a afectar el diseño de equilibrio de carga:

1. ¿Sesiones pegajosas o no? Es muy preferible no usar una sesión fija, y simplemente dejar que todos los equilibradores de carga (LB) usen round robin (RR) o selección aleatoria de back-end. Las selecciones de RR o de fondo aleatorio son simples, escalables y proporcionan una distribución de carga uniforme en todas las circunstancias.
2. SSL o no? Si SSL está en uso o no, y sobre qué porcentaje de solicitudes, generalmente tiene un impacto en el diseño de equilibrio de carga. A menudo es preferible finalizar SSL lo antes posible, para simplificar el manejo de certificados y mantener la carga de CPU SSL lejos de los servidores de aplicaciones web.

Respondo desde la perspectiva de cómo mantener la capa de equilibrio de carga en sí misma altamente disponible. Mantener los servidores de aplicaciones HA se acaba de hacer con las comprobaciones de estado integradas en sus equilibradores de carga L7.

OK, un par de ideas que deberían funcionar:

1) "La forma AWS":

• La primera capa, en el frente, usa ELB en modo L4 (TCP / IP).
• Segunda capa, use instancias EC2 con su balanceador de carga L7 de elección (nginx, HAProxy, Apache, etc.).

Beneficios / idea: los equilibradores de carga L7 pueden ser AMI EC2 bastante simples, todos clonados desde el mismo AMI y utilizando la misma configuración. Por lo tanto, las herramientas de Amazon pueden manejar todas las necesidades de HA: ELB supervisa los equilibradores de carga L7. Si un L7 LB muere o deja de responder, ELB y Cloudwatch juntos generan una nueva instancia automáticamente y la llevan al grupo ELB.

2) "El round robin de DNS con forma de monitoreo:"

• Use la operación de round robin de DNS básica para obtener una distribución de carga de grano grueso en un par de direcciones IP. Digamos que publica 3 direcciones IP para su sitio.
• Cada una de estas 3 IP es una dirección IP elástica de AWS (EIA), vinculada a una instancia EC2, con un equilibrador de carga L7 de su elección.
• Si un EC2 L7 LB muere, un agente de usuario compatible (navegador) debería usar una de las otras IP en su lugar.
• Configurar un servidor de monitoreo externo. Monitoree cada uno de los 3 EIP. Si uno deja de responder, use las herramientas de línea de comandos de AWS y algunas secuencias de comandos para mover el EIP a otra instancia de EC2.

Beneficios / idea: los agentes de usuario conformes deberían cambiar automáticamente a otra dirección IP si uno deja de responder. Por lo tanto, en el caso de una falla, solo 1/3 de sus usuarios deberían verse afectados, y la mayoría de ellos no deberían notar nada, ya que su UA falla silenciosamente a otra IP. Y su caja de monitoreo externo notará que un EIP no responde y rectificará la situación en un par de minutos.

3) RR DNS a pares de servidores HA:

Básicamente, esta es la sugerencia de Don de un latido simple entre un par de servidores, pero simplificado para múltiples direcciones IP.

• Con DNS RR, publique varias direcciones IP para el servicio. Siguiendo el ejemplo anterior, digamos que publica 3 IP.
• Cada una de estas IP va a un par de servidores EC2, por lo que 6 instancias EC2 en total.
• Cada uno de estos pares utiliza Heartbeat u otra solución HA junto con las herramientas de AWS para mantener 1 dirección IP activa, en una configuración activa / pasiva.
• Cada instancia EC2 tiene instalado su balanceador de carga L7 de elección.

Beneficios / idea: en el entorno completamente virtualizado de AWS, en realidad no es tan fácil razonar sobre los servicios L4 y los modos de conmutación por error. Al simplificar a un par de servidores idénticos que mantienen viva solo una dirección IP, es más fácil razonar y probar.

Conclusión: Nuevamente, en realidad no he probado nada de esto en producción. Solo desde mi instinto, la opción uno con ELB en modo L4 y las instancias de EC2 autogestionadas como L7 LBs parecen estar más alineadas con el espíritu de la plataforma AWS, y donde es más probable que Amazon invierta y se expanda más adelante. Probablemente esta sea mi primera opción.

Si no está haciendo sesiones fijas, o si está usando el estilo tomcat / apache (agregar ID de nodo a sessionid, en lugar de almacenar el estado en el LB), entonces usaría ELB frente a un grupo de haproxies. ELB tiene una verificación de salud incorporada, por lo que puede hacer que monitoree las haproxies y elimine las que estén fuera de la piscina. Hay mucho menos que configurar que la conmutación por error de latidos.

En cuanto a la propagación de cambios, no tengo una gran respuesta. Puppet es ideal para la configuración inicial y la implementación de cambios, pero para agregar / eliminar nodos tiende a querer una respuesta más rápida que su intervalo de sondeo de 30 minutos.

No lo he usado yo mismo, pero he visto a muchas personas mencionar el uso de títeres para manejar este tipo de problemas en EC2