Hemos estado peleando 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 ahora, 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?Load Balancing en Amazon EC2?
¡Cualquier pensamiento es muy apreciado!
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 miramos 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.
This page describe bastante bien cada una de las variables de sysctl (ip_local_port_range y tcp_fin_timeout fueron sintonizadas, en este caso).
Marc, debe escribir sus experiencias con la configuración de estas cosas y publicarlas en algún lado (¿su empresa tiene un blog?). Parece que podría ser útil para muchas personas. Vota tu pregunta. – SquareCog
Tu enlace está roto. – Ztyx
@Ztyx gracias! Solo lo actualicé Busqué una fuente más nueva y actualizada, parece que el sitio original todavía tiene un PageRank bastante alto y el contenido sigue siendo decente, así que solo lo estoy corrigiendo para reflejar la nueva URL. –