On 29/07/2014 10:55 πμ, Willy Tarreau wrote: > Hi Pavlos, > > On Mon, Jul 28, 2014 at 12:07:37AM +0200, Pavlos Parissis wrote: >> On 25/07/2014 07:28 ????, Willy Tarreau wrote: >>> Hi all, >> >> [..snip..] >> >> >>> - hot reconfiguration : some users are abusing the reload mechanism to >>> extreme levels, but that does not void their requirements. And many >>> other users occasionally need to reload for various reasons such as >>> adding a new server or backend for a specific customer. While in the >>> past it was not possible to change a server address on the fly, we >>> could now do it easily, so we could think about provisionning a few >>> extra servers that could be configured at run time to avoid a number >>> of reloads. Concerning the difficulty to bind the reloaded processes, >>> Simon had done some work in this area 3 years ago with the master- >>> worker model. Unfortunately we never managed to stabilize it because >>> of the internal architecture that was hard to adapt and taking a lot >>> of time. It could be one of the options to reconsider though, along >>> with FD passing across processes. Similarly, persistent server states >>> across reloads is often requested and should be explored. >>> >> >> Let's take this to another level and support on-line configuration >> changes for Frontends, backends and servers which don't require restart > > We've already improved things significantly in this direction. We're at a > point where it should be easy to support on-the-fly server address change. > However there are still a large number of things that cannot be easily > changed. All those which have many implications are in this area. For > example, people think that adding a server is easy, but it clearly is not. > The table-based LB algorithms already compute the largest table size when > all servers are up, according to their respective weights. Changing one > weight or adding one server can increase their least common multiple and > require to reallocate and rebuild a complete table. Also, servers are > checked, and for the checks we reserve file descriptors. We cannot easily > change the max number of file descriptors on the fly either. What can be > done however is to reserve some spare slots for adding new servers into an > existing backend. > > Also, for having worked many years with various products which support > on-line configuration changes, I don't count anymore the number of days, > weeks or months of troubleshooting of strange issues only caused by side > effect of these on-line changes, that simply went away after a reboot. I'm > not even blaming them because it's very hard to propagate changes correctly. > It always reminds me of a math professor I had at the uni who was able to > spot a mistake in an equation as large as the blackboard, who would fix it > there at the top of the blackboard and propagate the fix down to other lines. > The covered area looked like a pyramid. Here it's the same, performing a > minor change at the top of the configuration needs to take care of many > tiny implications far away from where the change is performed. And I'm > definitely not going to reproduce the lack of reliability that many products > can have just for the sake of allowing on-line reconfiguration. > > I'd rather invest more time ensuring that we can seamlessly reload (eg: not > lose stick-tables, stats nor server checks) to ensure that sensible changes > are done this way and not the tricky one. >
If you manage to implement this, especially the server checks, it would be a MAJOR improvement. It will probably reduce the requests of on-line changes as well, since people (including myself) will say "just reload dude, it is for free". Thanks Willy for taking the time to response on my mail, very much appreciated. Cheers, Pavlos
signature.asc
Description: OpenPGP digital signature
