Pregunta

Hemos estado luchando con HAProxy durante unos días en Amazon EC2; La experiencia hasta ahora ha sido excelente, pero estamos atascados en exprimir más rendimiento del equilibrador de carga de software. No somos exactamente expertos en redes de Linux (normalmente somos una tienda .NET), pero hasta ahora nos hemos mantenido firmes, intentando establecer límites adecuados, inspeccionando los mensajes del kernel y tcpdumps por cualquier irregularidad. Sin embargo, hasta ahora, hemos alcanzado una meseta de aproximadamente 1.700 solicitudes / segundo, momento en el que abundan los tiempos de espera de los clientes (hemos estado usando y ajustando httperf para este fin). Un compañero de trabajo y yo estábamos escuchando el podcast más reciente de Stack Overflow, en el que los fundadores de Reddit notan que todo su sitio se ejecuta en un nodo HAProxy, y que hasta ahora no se ha convertido en un cuello de botella. Ack! O de alguna manera no vemos que haya muchas solicitudes concurrentes, estamos haciendo algo terriblemente mal, o la naturaleza compartida de EC2 está limitando la pila de red de la instancia de Ec2 (estamos usando un tipo de instancia grande). Teniendo en cuenta el hecho de que tanto Joel como los fundadores de Reddit están de acuerdo en que la red probablemente será el factor limitante, ¿es posible que esa sea la limitación que estamos viendo?

¡Cualquier idea es muy apreciada!

Editar ¡Parece que el problema real no era, de hecho, con el nodo del equilibrador de carga! El culpable fue en realidad los nodos que ejecutan httperf, en este caso. A medida que httperf crea y elimina un socket para cada solicitud, gasta una buena cantidad de tiempo de CPU en el kernel. A medida que aumentamos la tasa de solicitud, el TCP FIN TTL (que tiene 60 años por defecto) mantuvo los sockets demasiado tiempo, y el valor predeterminado de ip_local_port_range era demasiado bajo para este escenario de uso. Básicamente, después de unos minutos de que el nodo del cliente (httperf) crea y destruye constantemente nuevos sockets, el número de puertos no utilizados se agotó y las 'solicitudes' posteriores se erraron en esta etapa, produciendo números bajos de solicitud / segundo y una gran cantidad de errores

También habíamos analizado nginx, pero hemos estado trabajando con RighScale, y ellos tienen scripts para HAProxy. Ah, y tenemos una fecha límite demasiado ajustada [por supuesto] para cambiar los componentes a menos que sea absolutamente necesario. Afortunadamente, estar en AWS nos permite probar otra configuración usando nginx en paralelo (si está garantizado) y hacer el cambio durante la noche más tarde.

Esta página describe bastante bien cada una de las variables de sysctl (ip_local_port_range y tcp_fin_timeout se ajustaron, en este caso).

¿Fue útil?

Solución

No es realmente una respuesta a su pregunta, pero nginx y pound tienen buena reputación como equilibradores de carga. Wordpress simplemente cambió a nginx con buenos resultados.

Pero más específicamente, para depurar su problema. Si no está viendo un 100% de uso de CPU (incluida la espera de E / S), entonces está vinculado a la red, sí. EC2 utiliza internamente una red gigabit, intente usar una instancia XL, para que tenga el hardware subyacente para usted y no tenga que compartir ese puerto de red gigabit.

Otros consejos

No responde la pregunta directamente, pero EC2 ahora admite el equilibrio de carga a través de Elastic Load Balancing en lugar de ejecutarse su propio equilibrador de carga en una instancia EC2.

EDITAR: el servicio DNS de la Ruta 53 de Amazon ahora ofrece una forma de apuntar un dominio de nivel superior a un ELB con un "alias". grabar. Dado que Amazon conoce la dirección IP actual del ELB, puede devolver un registro A para esa IP actual en lugar de tener que usar un registro CNAME, sin dejar de cambiar la IP de vez en cuando.

Sí, podría usar un equilibrador de carga fuera del sitio ... y en LVS de metal desnudo es una gran opción, ¡pero su latencia será horrible! Se rumorea que Amazon solucionará el problema de CNAME. Sin embargo, es poco probable que agreguen https, revisiones de salud personalizadas o en profundidad, agentes de retroalimentación, coincidencia de URL, inserción de cookies (y algunas personas con buena arquitectura también dirían bastante bien). ellos detrás de una entrada DNS round robin. Aquí en Loadbalancer.org estamos a punto de lanzar nuestro propio dispositivo de equilibrio de carga EC2: http: // blog. loadbalancer.org/ec2-load-balancer-appliance-rocks-and-its-free-for-now-anyway/ Estamos planeando usar scripts SSH para integrarnos con el autoescalado de la misma manera que lo hace Rightscale, cualquier comentario apreciado en el blog. Gracias

Me gustaría cambiar a un equilibrador de carga fuera del sitio, no en la nube, y ejecutar algo como IPVS encima. [La razón por la que estaría fuera de la nube de Amazon es debido a las cosas del núcleo] Si Amazon no limita la IP de origen de los paquetes que salen del sistema, podría utilizar un mecanismo de equilibrio de carga unidireccional. Hacemos algo como esto, y nos da alrededor de 800,000 solicitudes simultáneas [aunque no tratamos con la latencia]. También diría usar '' ab2 '' (Apache bench), ya que es un poco más fácil de usar y más fácil de usar en mi humilde opinión.

Aunque su problema se resolvió. KEMP Technologies ahora tiene un equilibrador de carga totalmente desarrollado para AWS. Podría ahorrarte algunas molestias.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top