26 votos

¿Cómo puedo implementar una solución escalable, confiable haproxy clúster de Amazon EC2?

Necesitamos un poco más de funcionalidad avanzada de ELB proporciona (en su mayoría L7 de inspección), pero no es obvio cómo manejar las cosas como el latido del corazón y de alta disponibilidad con algo como haproxy el uso de EC2. Hay una alta probabilidad de que íbamos a necesitar 3 o más haproxy los nodos del clúster, así de simple latido del corazón entre dos nodos no va a funcionar.

Parece haber un latido del corazón iba de capa en la parte delantera de la haproxy nodos sería el camino a seguir, posiblemente usando IPVS, pero el manejo de los cambios de configuración como el clúster de EC2 de cambios (ya sea a través intencional cambios, como la expansión o no intencionales, como la pérdida de un EC2 nodo) parece no trivial.

Preferiblemente, la solución sería lapso de al menos dos Zonas de Disponibilidad.

En respuesta a Qs: No, las sesiones no son pegajosos. Y sí, vamos a necesitar SSL, pero que en teoría podrían ser manejado por otro la instalación de todo somos capaces de dirigir el tráfico SSL a una ubicación diferente de la no-tráfico SSL.

14voto

Zameer Manji Puntos 1213

OK, yo nunca he construido un AWS solución de equilibrio de carga con el tráfico en los niveles de SmugMug a mí mismo, pero solo de pensar en la teoría y servicios de AWS, un par de ideas vienen a la mente.

La pregunta original es que faltan un par de cosas que tienden a afectar el equilibrio de carga de diseño:

  1. Sticky sessions o no? Es muy preferible no utilizar pegajoso de la sesión, y dejar que todos los equilibradores de carga (LB) el uso de round robin (RR) o al azar de la selección del backend. RR o al azar backend selecciones simple, escalable, y proporcionar una distribución uniforme de carga en todas las circunstancias.
  2. SSL o no? Si SSL está en uso o no, y sobre la que el porcentaje de las solicitudes, por lo general tiene un impacto en el equilibrio de carga de diseño. A menudo es preferible terminar SSL tan pronto como sea posible, para simplificar el certificado de manipulación y mantener el SSL carga de la CPU lejos de servidores de aplicaciones web.

Yo estoy respondiendo desde la perspectiva de cómo mantener el equilibrio de carga de la capa de sí mismo altamente disponible. Mantenimiento de los servidores de la aplicación se HA hecho con los controles de salud incorporados en el L7 equilibradores de carga.

OK, un par de ideas que se debe trabajar:

1) "El camino AWS":

  • La primera capa, en la parte frontal, utilice ELB en L4 (TCP/IP) de modo.
  • La segunda capa, el uso de instancias de EC2 con su L7 equilibrador de carga de elección (nginx, HAProxy, Apache, etc).

Beneficios/idea: El L7 equilibradores de carga puede ser bastante simple EC2 AMI, todos clonados a partir del mismo AMI y con la misma configuración. Por lo tanto Amazon herramientas se puede controlar todo HA de necesidades: ELB supervisa el L7 equilibradores de carga. Si un L7 LB muere o deja de responder, ELB & Cloudwatch juntos generar una nueva instancia de forma automática, y en el ELB piscina.

2) "El DNS round robin con la supervisión manera:"

  • Uso básico de DNS round robin para obtener un grano grueso, la distribución de la carga de un par de direcciones IP. Digamos que usted publicar 3 direcciones IP para el sitio.
  • Cada una de estas 3 direcciones IP es una de AWS Elastic Dirección de IP (EIA), unido a una instancia de EC2, con un L7 equilibrador de carga de su elección.
  • Si un EC2 L7 LB muere, compatible con un agente de usuario (navegador) debe utilizar una de las otras IPs en su lugar.
  • Establecer un monitoreo externo del servidor. Supervisar cada uno de los 3 Cie. Si uno no responde, el uso de AWS herramientas de línea de comandos y algunas secuencias de comandos para mover la EIP a otra instancia de EC2.

Beneficios/idea: Compatible con los agentes de usuario deberían cambiar automáticamente a otra dirección IP si uno deja de responder. Así, en el caso de un fracaso, sólo 1/3 de los usuarios deberían ser afectadas, y la mayoría de estos no debería notar nada desde su UA silenciosamente se conmuta a otra IP. Y su supervisión externa de la caja te das cuenta de que un EIP es que no responde, y rectificar la situación dentro de un par de minutos.

3) DNS RR, a los pares de HA, servidores de:

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

  • El uso de DNS RR, publicar un número de direcciones IP para el servicio. Siguiendo el ejemplo anterior, digamos que usted publicar 3 IPs.
  • Cada una de estas IP se va a un par de EC2 servidores, así que 6 instancias de EC2 en total.
  • Cada uno de estos pares se utiliza Latido del corazón o de otra solución de HA, junto con las herramientas de AWS para mantener 1 dirección IP en vivo, en una configuración activa/pasiva.
  • Cada instancia de EC2 tiene su L7 equilibrador de carga de la opción instalada.

Beneficios/idea: En AWS' completamente entorno virtualizado en realidad no es tan fácil razonar sobre L4 servicios y modos de conmutación por error. Por simplificar a un par de servidores idénticos manteniendo solo 1 dirección IP de la vida, se hace más simple la razón acerca de y prueba.

Conclusión: de Nuevo, realmente no he probado ninguna de esta en producción. Solo de mi sensación de la tripa, la opción uno con ELB en L4 modo, y auto-administrado instancias de EC2 como L7 LBs parece más alineados con el espíritu de la plataforma de AWS, y donde Amazon tiene más probabilidades de invertir y ampliar más adelante. Esto probablemente sería mi primera opción.

14voto

Ben Jencks Puntos 886

Si usted no está haciendo sticky sessions, o si usted está usando tomcat/apache estilo (anexar ID de nodo a sessionid, como se opuso a que el estado de almacenamiento en el LB), entonces yo uso la ELB en frente de un grupo de haproxies. ELB tiene una comprobación integrada, de modo que usted puede tener que monitorear el haproxies y tomar cualquier abajo fuera de la piscina. Mucho menos para configurar que el latido del corazón de conmutación por error.

Tan lejos como la propagación de los cambios, no tengo una gran respuesta. La marioneta es ideal para la configuración inicial y la aplicación de los cambios, pero para añadir o quitar nodos que tienden a querer una respuesta más rápida que la de sus 30 minutos de intervalo de sondeo.

1voto

JamesRyan Puntos 6644

No lo he utilizado yo mismo, pero he visto un montón de gente menciona el uso de títeres para manejar este tipo de problemas en EC2

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: