LibreQoS
LibreQoS copied to clipboard
LibreQoE
Failover and fault tolerance
being able to do failover using a tech like VRPP would be good for fault tolerance.
Doing multi-machine load balancing is much harder.
Very true. Right now the assumed use case / guide encourages ISPs include a redundant fail-over OSPF path around the LibreQoS appliance, to be prepared for any hardware failure. Has worked well on my network. Perhaps ISPs can use another OSPF path for any secondary / redundant LibreQoS middle-boxes? For this, some centralized controller could send config updates to both middle-boxes. I'll have to factor that into design considerations so it's more scalable.
you can even just use STP/RSTP to handle failover with two identically configured boxes. rsync from the primary to the secondary for the AP/client lists.
maybe storing these details in a database and having the scheduler do routine checks so no one box is really the primary would be a more load-balancing friendly model.
A network operator might want to try to split the load out between multiple shaping boxes via whatever means they like. with the high potential shaper count in v1 it wouldn't be a big deal to just have all shapers 'at the ready' and let the operator route subnets however they like caveat obviously being to lock an individual site down a specific path if you want shapers to be accurate. This is how I do it with preseem today and it works great. I have a pair of cheaper white boxes with 1G NICs with a head-end that handles 2 wisp segments and I just run one per wisp to balance it out.
Failover? Please don't do that.
It would be better to do active-active. Get two Libre QoS add two routes with different costs. Rsync ShapedDevices.csv and network.json.
Tadam it's done :-)
Better documenting and creating failover methods would be good. I like the active-active idea, and in fact replacing the internet facing router entirely seems feasible in v1.3 and beyond. punting for further discussion in 1.4