pricing - Equilibrio de carga en Amazon EC2?
load balancer aws (5)
Hemos estado luchando con HAProxy durante unos días en Amazon EC2; la experiencia hasta ahora ha sido excelente, pero estamos estancados en exprimir más rendimiento del equilibrador de carga de software. No somos exactamente zorros de redes de Linux (normalmente somos una tienda .NET), pero hasta ahora hemos mantenido la nuestra, intentando establecer los límites adecuados, inspeccionando los mensajes kernel y tcpdumps en busca de irregularidades. Hasta el momento, hemos llegado a una meseta de aproximadamente 1.700 solicitudes / seg, momento en el que abundan los tiempos de espera de los clientes (hemos estado usando y modificando httperf para este fin). Un compañero de trabajo y yo estábamos escuchando el podcast de desbordamiento de pila más reciente, en el que los fundadores de Reddit observan 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 bien, de alguna manera no se ven tantas solicitudes simultáneas, estamos haciendo algo terriblemente incorrecto, o la naturaleza compartida de EC2 está limitando la pila de red de la instancia Ec2 (estamos usando un tipo de instancia grande). Teniendo en cuenta el hecho de que tanto los fundadores de Joel como los de Reddit están de acuerdo en que la red probablemente sea el factor limitante, ¿es posible que esa sea la limitación que estamos viendo?
¡Cualquier idea es grandemente apreciada!
Editar Parece que el problema real no era, de hecho, con el nodo del equilibrador de carga. El culpable era en realidad los nodos ejecutando httperf, en este caso. A medida que httperf construye y elimina un socket para cada solicitud, gasta una buena cantidad de tiempo de CPU en el kernel. A medida que subimos la tasa de solicitudes más alta, TCP FIN TTL (que era 60 por defecto) mantenía los conectores 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 cliente (httperf) creara y destruyera nuevos sockets constantemente, la cantidad de puertos no utilizados se agotó y las subsiguientes ''solicitudes'' se borraron en esta etapa, produciendo pocos pedidos / segundos y una gran cantidad de errores
También vimos nginx, pero hemos estado trabajando con RighScale, y tienen scripts para HAProxy. Oh, y tenemos una fecha límite demasiado ajustada [por supuesto] para cambiar los componentes a menos que resulte 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 cada una de las variables de sysctl bastante bien (ip_local_port_range y tcp_fin_timeout fueron sintonizados, en este caso).
Aunque tu problema fue resuelto. KEMP Technologies ahora tiene un equilibrador de carga completamente soplado para AWS. Podría ahorrarte un poco de molestia.
Me gustaría cambiar a un equilibrador de carga fuera del sitio, no en la nube y ejecutar algo así como IPVS en la parte superior. [La razón por la que estaría fuera de la nube de Amazon es debido a cosas del kernel]. Si Amazon no limita la IP de origen de los paquetes que salen de ella, podría ir con un mecanismo de equilibrio de carga unidireccional. Hacemos algo como esto, y nos da aproximadamente 800,000 solicitudes simultáneas [aunque no tratamos con la latencia]. También podría decir "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.
No es realmente una respuesta a su pregunta, pero nginx y pound tienen buena reputación como balanceadores de carga. Wordpress acaba de cambiar a nginx con buenos resultados.
Pero más específicamente, para depurar su problema. Si no está viendo el uso de 100% de la CPU (incluida la espera de E / S), entonces está vinculado a la red, sí. EC2 usa internamente una red gigabit, intente usar una instancia XL, de modo que tenga el hardware subyacente para usted y no tenga que compartir ese puerto de red gigabit.
No responde la pregunta directamente, pero EC2 ahora admite el equilibrio de carga a través de Elastic Load Balancing en lugar de ejecutar su propio equilibrador de carga en una instancia de EC2.
EDITAR: El servicio DNS de Route 53 de Amazon ahora ofrece una forma de apuntar un dominio de nivel superior en un ELB con un registro de "alias". 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, mientras sigue siendo libre de cambiar la IP de vez en cuando.
Sí, podría usar un equilibrador de carga fuera del sitio ... y en metal desnudo LVS es una gran opción, ¡pero su latencia será horrible! Corre el rumor de que Amazon solucionará el problema CNAME. Sin embargo, es poco probable que agreguen https, controles de estado detallados o personalizados, agentes de comentarios, correspondencia de url, inserción de cookies (y algunas personas con buena arquitectura dirían que también es correcto). Sin embargo, es por eso que Scalr, RightScale y otros usan HAProxy. detrás de una entrada DNS round robin. Aquí, en Loadbalancer.org, estamos a punto de lanzar nuestra propia balanza de carga EC2: http://blog.loadbalancer.org/ec2-load-balancer-appliance-rocks-and-its-free-for-now-anyway/ Estamos planeando usar scripts SSH para integrar con autoescala de la misma manera que lo hace escala de derechos, cualquier comentario apreciado en el blog. Gracias