Presentando LibreQoS Bakery

Presentando LibreQoS Bakery

Antes de la versión 1.5-RC1, LibreQoS leía ShapedDevices.csv y network.json (en el script LibreQoS.py) para determinar la jerarquía de red, configuración de dispositivos y diseñar la configuración de control de tráfico (TC). Una vez validados los archivos, el script creaba un gran conjunto de comandos tc, limpiaba el estado actual de TC y aplicaba la nueva configuración.

Este enfoque funcionaba, pero tenía limitaciones:

• Los usuarios experimentaban un retraso mientras se reconstruía el árbol, con algunos dispositivos sin ser regulados durante este tiempo. Normalmente esto era muy breve —y dedicamos mucho tiempo a optimizarlo— pero aún así era perceptible. Aparte, este problema se agravaba porque TC adquiría un bloqueo por cada comando.
• Los usuarios de toda la red experimentaban un pequeño “bache” en el tráfico cuando TC descartaba sus filas. En la mayoría de los casos no era perceptible.
• Incluso si nada había cambiado, el script seguía limpiando y reconstruyendo todo el árbol de TC.
• Cambios rápidos (como añadir usuarios de hotspot) provocaban que el script reconstruyera todo el árbol.
• Se pagaba el coste en RAM (y un poco de CPU) de crear clases TC para cada dispositivo/circuito, incluso si no estaban en uso.

“Bakery” es una nueva función que mejora la forma en que LibreQoS crea y gestiona configuraciones de control de tráfico. No está completa: la próxima versión incluirá aún más mejoras. La nueva versión ayuda de varias maneras.

Configurando Bakery

En /etc/lqos.conf (o vía la interfaz web), ahora puede configurar Bakery. Está desactivada por defecto. En la sección queues de la configuración, puede añadir dos nuevas opciones:

lazy_queues = "Htb"
lazy_expire_seconds = 300

Sus opciones para lazy_queues son:

• Htb - El árbol HTB (Hierarchical Token Bucket) es creado, incluyendo los límites de velocidad de todos los dispositivos. No se crean filas CAKE al inicio. Esta es la mejor opción para la mayoría de los usuarios; las filas HTB son ligeras, mientras que las filas CAKE consumen más RAM y CPU.
• Full - Solo se crea la jerarquía de red, sin entradas para los dispositivos. Es una buena opción para usuarios con recursos limitados, pero significa que todos los dispositivos tendrán alrededor de 1 segundo de tráfico sin estar regulado al conectarse por primera vez.
• No (valor predeterminado) - no se utiliza la versión dinámica de Bakery y todas las filas se crean al inicio. Las filas no expiran. ¡Aun así se beneficia de Bakery!

La opción lazy_expire_seconds establece el tiempo tras el cual se eliminan las filas no utilizadas. Esto es útil para dispositivos que no siempre están conectados, como teléfonos móviles o computadoras portátiles.

¿Qué Pasa Después?

Entonces, ¿en qué se diferencia la nueva función Bakery?

Construcción del Árbol

Una vez configurada la función Bakery, el planificador se ejecuta con normalidad. LibreQoS.py sigue leyendo network.json y ShapedDevices.csv. En lugar de ejecutar directamente los comandos tc, crea un búfer de comandos - describiendo la red. También incluye algunas modificaciones al algoritmo:

• Cada nodo del árbol ahora tiene “espacios” entre las filas. Esto permite añadir nuevas filas sin reconstruir todo el árbol.
• Cada nodo se ordena por ID de circuito, reduciendo enormemente la probabilidad de que “este cliente era 03:04 y no cambió, pero ahora es 03:05”.

El búfer TC incluye todos los comandos CAKE y HTB, independientemente de la configuración de lazy_queues.

Envío

Los comandos en lote se envían al bus de comandos de LibreQoS y son recogidos por lqosd - la parte central en Rust de LibreQoS. Luego se despachan al subsistema de Bakery. Esta es una operación muy rápida a través de un socket de dominio UNIX local.

Actualización de Estado

Al llegar, Bakery compara los comandos recibidos con su mapa del estado actual de regulación. Si los comandos son idénticos, no hace nada - no se realizan cambios en el estado de TC (¡primera optimización!). Si los comandos difieren, el comportamiento varía:

• Si los únicos cambios son los límites de velocidad de network.json, Bakery actualiza las filas HTB con tc change sin impacto en tiempo de ejecución.
• Si los únicos cambios son eliminaciones de nodos de red en network.json, Bakery elimina las filas HTB con tc delete sin impacto en tiempo de ejecución.
• Si se añadieron circuitos, Bakery agrega la nueva fila al árbol de estado (y la agrega inmediatamente si esta en modo No). Sin impacto en tiempo de ejecución en otros circuitos.
• Si se eliminaron circuitos, Bakery elimina la fila del árbol de estado (y la elimina inmediatamente si esta en modo No). Sin impacto en tiempo de ejecución en otros circuitos.
• Los circuitos cuyos límites cambiaron, actualmente provocan una recarga completa del árbol. Este es un objetivo para la próxima versión, pero nos encontramos con limitaciones del sistema tc de Linux.
• Grandes cambios en el árbol HTB (como mover nodos) también provocarán una recarga completa del árbol.

Filas Dinámicas

Si Bakery está en modo Htb o Full, una vez por segundo el monitor de tráfico de lqosd enviará a Bakery una lista de circuitos que han tenido tráfico en el último segundo (solo IDs hash rápidos, nuevamente - muy veloz). Bakery luego verificará el árbol de estado para esos circuitos. En modo Htb, si un circuito no tiene una fila CAKE, la creará. En modo Full, creará tanto la fila HTB como la fila CAKE para ese circuito.

Cada circuito en el árbol tiene una marca de tiempo de “última vez visto”. Cualquier circuito cuya marca sea más antigua que lazy_expire_seconds será eliminado del árbol de estado, liberando recursos tc. (Nota: 0 significa “sin expiración”.)

Esta es una forma mucho más eficiente de gestionar el control de tráfico: solo pagas por lo que usas (RAM y CPU), y no reconstruir todo el árbol cada vez que se hace un cambio puede tener un gran impacto en el rendimiento. En mis pruebas en iZones, Bakery ha reducido el conteo de circuitos activos en aproximadamente un 20%, y las recargas han pasado de ser un evento regular a ocurrir una o dos veces por jornada laboral (cuando se hacen cambios).

El Futuro

Bakery es un gran paso hacia delante para LibreQoS, pero no es el final del camino. Algunas recargas completas son inevitables, pero ahora son raras. Estamos trabajando para reducirlas aún más:

• Los circuitos que se mueven - quizá porque la asignación inteligente mejorada con Insight detecta que es probable que se saturen - se pueden manejar creando una nueva fila y luego (tras un retraso de tiempo) eliminando la antigua (una transacción).
• Los circuitos que cambian de velocidad son problemáticos. Si ejecutas tc change en una clase HTB que tiene hijos, todo el subsistema de regulación de tráfico de Linux se bloquea y necesita reiniciarse. Esperamos usar el sistema de transacciones para crear una nueva clase, mover el mapeo de ID y luego eliminar la clase antigua.

Aun con estas limitaciones, Bakery representa una gran mejora. Combinada con StormGuard (¡escribiré pronto sobre ello!), LibreQoS se está volviendo muy robusto y eficiente.

¡Gracias a NLNet!