He aprovisionado un servidor con 8 núcleos y planeo implementar un servicio de red. Para distribuir la carga de solicitudes, me gustaría ejecutar 8 instancias de mi servicio. Nada impactante aquí. No tengo acceso a un equilibrador de carga de hardware. Debo mencionar que actualmente tengo asignadas 5 direcciones IP públicas (pero puedo obtener más).
Por lo tanto, me gustaría escuchar sus recomendaciones para estructurar una solución de equilibrio de carga de software.
Las opciones obvias serían:
- utilizar HAProxy; o
- bifurcar previamente mi aplicación (como lo hacen Facebook Tornado y Unicorn);
- inserta tu idea aquí.
Mis objetivos son:
- distribuir la carga de solicitudes entre las instancias de servicio; y
- permitir reinicios continuos de mi servicio (actualizaciones de código).
Debo mencionar que este no es un servicio basado en HTTP, por lo que NGiNX y similares están descartados.
No me encanta HAProxy por sus requisitos de memoria; parece requerir un búfer de lectura y escritura por conexión de cliente. Por lo tanto, tendría buffers a nivel del kernel, en HAProxy y en mi aplicación. ¡Esto se está poniendo tonto! ¿Quizás me estoy perdiendo algo a este respecto?
¡Gracias!
Respuesta1
cualquiera que sea la solución, si instala un proceso para reenviar datos de flujo, requerirá buffers por conexión. Esto se debe a que no siempre puedes enviar todo lo que recibiste, por lo que debes guardar el exceso en un buffer. Dicho esto, el uso de la memoria dependerá de la cantidad de conexiones simultáneas. Un sitio grande ejecuta felizmente haproxy con la configuración predeterminada en 150000 conexiones simultáneas (4 GB de RAM). Si necesita más que eso, la versión 1.4 le permite ajustar el tamaño del búfer sin tener que volver a compilar. Sin embargo, tenga en cuenta que los buffers del kernel por socket nunca bajarán de 4 kB por dirección y por socket, por lo que al menos 16 kB por conexión. Eso significa que no tiene sentido hacer que haproxy se ejecute con menos de 8 kB por búfer, ya que consumirá menos que el kernel.
Además, si tu servicio es TCP puro y un proxy no tiene valor añadido, echa un vistazo a soluciones basadas en red como LVS. Es mucho más económico ya que procesa paquetes y no necesita mantener buffers, por lo que los buffers de socket descartarán los paquetes cuando estén llenos y se puede instalar en la misma máquina que el servicio.
Editar: Javier, los procesos prebifurcados que dependen del sistema operativo para realizar el equilibrio de carga no escalan tan bien en absoluto. El sistema operativo se despiertacadaprocesa cuando obtiene una conexión, solo uno de ellos la obtiene y todos los demás vuelven a dormir. Haproxy en modo multiproceso muestra su mejor rendimiento en torno a 4 procesos. A los 8 procesos, el rendimiento ya empieza a bajar. Apache usa un buen truco contra esto: bloquea la aceptación () para que solo un proceso esté esperando la aceptación. Pero eso elimina la función de equilibrio de carga del sistema operativo y deja de escalar entre 1000 y 2000 procesos. Debería utilizar una serie de algunos bloqueos para que algunos procesos se activen, pero no lo hace.
Respuesta2
sin ningún detalle sobre su servicio es muy difícil decirlo; pero en general me inclinaría por prebifurcar. Es una estrategia de servidor probada y verdadera (y no un truco novedoso como algunas personas piensan después de leer los sitios de fans de tornado/unicornio).
Más allá de eso, algunos consejos:
Cada proceso prebifurcado puede utilizar no
selectestrategias modernas (libres, en su mayoría) para manejar grandes cantidades de clientes.es muy raro que una relación 1:1 entre núcleos y procesos proporcione un rendimiento óptimo; Por lo general, es mucho mejor lograr cierta adaptabilidad dinámica a la carga.