Hi, Thank you for the answer, this is very helpful. So to sum up my understanding, usually drain is used in operations by setting the server in this state for a specific amount of time and then put in maintenance state. So:
1. If I have an automated operation process which sets a server state to drain, which means the server will process only current connections and new sticky connections if any, I should not have any haproxy reload until the state is changed to maintenance since the drain state will be lost even if using server-state-file feature. 2. However, the automated operation process can use set weight 0 which means the server will process only current connections and new sticky connections if any (the same as point 1), then, after a specific time put it in maintenance state and after that set weight back to 100% and state to ready. In this case I can have a haproxy reload while "draining" with set weight 0 if using server-state-file feature. Is this correct ? Thank you, Alex On Thu, Jan 21, 2016 at 9:00 PM, Willy Tarreau <[email protected]> wrote: > Hi, > > On Wed, Jan 20, 2016 at 10:53:46AM +0200, Alex wrote: > > Hello, > > > > I've found another difference - regarding "seamless server states", > > according to my testing using version 1.6.3 administrative state DRAIN is > > not preserved after a reload but set weight 0 is preserved. > > For my use case, using DRAIN seems the logical choice but because of the > 2 > > issues that I have - state DRAIN is not preserved after a reload (this > > issue has a higher weight :) ) and state DRAIN is not highlighted blue in > > the stats page, I need to use set weight 0. > > Do you think these can be considered bugs and have a chance to be solved > ? > > No these are not bugs, they were done on purpose based on user demand. > The reason is double : > - a number of users want to be able to temporarily put a server in > drain mode without having to change its weight. One of the reasons > is that you may have some automatic tools adjusting the weight once > in a while using the CLI based on the overall load distribution. For > example think about a cache farm where you would adjust weights to > balance the disk I/O usage between the cache nodes. The second reason > was the agent, where it's convenient to have an agent report an > administrative state (up/down/drain) without touching the weights at > all that are managed a different way. > > - the second reason is that for people doing live operations, it was > problematic to see the same color on the stats page for a server which > uses a weight of zero based on its load or whatever agent, and a server > being stopping that requires specific care. > > So in the end the DRAIN status was added to match exactly these > expectations. > > In short, if you consider that your server is overloaded and should take > less load, you should lower its weight, even if that goes down to zero (it > will then not receive any traffic). But if you want your server to be > evicted > from load balancing to stop accepting new users but still process existing > users, what you want is a drain mode. That will not modify your servers' > weight and once you leave the drain mode, you'll get back up to speed with > the same weight as the one you were running on. > > When you think from a tools perspective, you'll figure that : > - weight is controlled by performance monitoring tools ; > - drain is controlled by operations processes > > Hoping this helps, > Willy > > -- Alex S
