¿Hay alguna sugerencia sobre cuándo debo usar roundrobiny cuándo debo usar leastconn?
Estoy usando roundrobinactualmente y observé que la carga de mi servidor back-end no se distribuye uniformemente. Por supuesto, puede haber otro problema, pero queremos leastconnintentarlo, pero como se trata de un servidor de misión crítica, quiero consultar otra experiencia antes de realizar los cambios.
¿Alguna idea para compartir?
No he experimentado con leastconn, pero entiendo que el caso de uso típico de leastconn es cuando estás equilibrando la carga de algo que puede tener conexiones de larga duración. La razón de esto es que el menor enfoque se centra en garantizar una concurrencia equilibrada donde, a medida que avanza el camino, proporcionar una tasa de llegada más equilibrada . Si esta distinción no está clara, vea mi respuesta sobre la diferencia .
Cuando dice que la carga no está distribuida uniformemente, podría ayudar definir un poco mejor la "carga". Si se refiere a los recursos del servidor, sugiero identificar exactamente qué está causando el aumento de la carga (es decir, ciertos tipos de conexiones) y trabajar hacia atrás desde allí.
Depende de cuál sea el protocolo y el caso de uso para equilibrar. Para cualquier cosa donde la cantidad de conexiones esté correlacionada con la carga / uso, es mejor usarla leastconn. Debido a la forma en que funcionan las redes y las aplicaciones, es casi siempre cierto y es mejor usarlo leastconnde forma predeterminada.
Por ejemplo, una empresa tiene un grupo de escritorios remotos a los que los empleados se conectan. Desea que los empleados se distribuyan de manera uniforme entre los escritorios.
El número de conexiones activas en ese caso de uso es aproximadamente "cuántos empleados están usando ese escritorio en este momento". El host con la menor cantidad de conexiones tiene la menor cantidad de empleados que la usan y probablemente sea la menos cargada. Use "leastconn" en estas circunstancias, distribuye la carga de manera uniforme con la cantidad de usuarios.
Un equilibrador de carga ideal debe tener en cuenta la carga del escritorio remoto. Cuantos usuarios Cuantas aplicaciones ¿Cuánta memoria y CPU consumió? Existen soluciones comerciales dedicadas a escritorios remotos (Microsoft / Citrix / etc ...), generalmente miden estas métricas para difundir el uso muy bien. HAProxy es un simple equilibrador de carga de red y no puede ser mejor que contar conexiones leastconn.
Con HTTP, una conexión activa significa que el servidor está ocupado procesando una solicitud. Las conexiones son directamente proporcionales a la carga. Desea seleccionar el servidor con la menor cantidad de conexiones activas (solicitudes en curso). Úselo leastconnpara el tráfico HTTP (S).
Imagine un escenario con dos servidores HTTP, donde un servidor es más lento para procesar solicitudes (tal vez esté sobrecargado, tal vez tenga hardware más antiguo).
roundrobindistribuirá las solicitudes a la mitad entre los dos servidores. Es muy ineficiente, el servidor más rápido debería tomar más. Peor aún, el servidor más lento podría sobrecargarse, se volverá aún más lento a medida que ingresen más solicitudes y podría comenzar a descartarlas en cualquier momento. No quieres eso.
leastconndetectaría que los servidores son desiguales. El servidor más lento mantiene las conexiones durante más tiempo, tiene un mayor recuento de conexiones. leastconnexplica eso y prefiere el otro servidor.
En mi experiencia, incluidos los roles en los que hacía pruebas de rendimiento exclusivamente para sitios web de moderados a grandes. leastconnpuede ser 300% tan eficiente como roundrobinpara HTTP (S). roundrobinno distribuye la conexión de manera justa y causará inestabilidad en una carga alta.
(Ignoremos que HAProxy no es compatible con UDP y UDP es menos conexión).
Un último ejemplo. DNS es un protocolo simple. Los clientes envían un solo mensaje UDP para solicitar un dominio y el servidor DNS responde en un solo mensaje.
En este caso, no hay realmente una conexión. Incluso si lo hubiera, se cerraría instantáneamente (teóricamente).
No tendría sentido contar conexiones en estas circunstancias, no es óptimo para leastconn. Un simple roundrobinpuede distribuir mensajes.
Las personas a veces creen que no deberían usar leastconnpara conexiones de corta duración (similar al último ejemplo). Incluso la documentación de HAProxy es engañosa al respecto.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
En el mundo real, short connectionsno es una cosa.
Las aplicaciones se crean sobre TCP. Los mensajes se entregan y a menudo se procesan en orden. Cuando un servidor es lento o está sobrecargado, las conexiones "cortas" se vuelven más largas. Si hay (más) conexiones, probablemente se esté haciendo algo (más) de trabajo. El recuento de conexiones y la duración de la conexión varían y tienen significado.
Piense en un servidor HTTP básico. Algunos activos tardan unos pocos milisegundos, algunas llamadas a la API tardan unos segundos, una página puede tardar un tiempo en cargarse con cualquier cantidad de solicitudes dentro de ella, etc. leastconncomprende la actividad en curso y ajusta la distribución, que es exactamente lo que desea de un equilibrador de carga.