krzysztof.wilczynski at linux
Oct 23, 2011, 8:33 AM
Post #9 of 11
Re: [lvs-users] WLC Slow start for 2.6.x kernel
[In reply to]
>> Sounds nice, but please treat this as experimental feature and therefore be careful if your systems are mission critical,
>> and your production environment cannot run into an inconvenience at any time. I would want to avoid breaking your infrastructure if possible :-)
> I'll plan to install patched Kernel on backup LVS node and perform tests by directing traffic thru the slave node during night hours.
Again, thank you for helping :-)
> Could you please explain how exactly slow start mechanism works?
In principle, the idea behind a slow-start (which only really applies
to least-connection shedulers family) is to make a real server appear
as a little bit busier than it really is in terms of number of active
connections it handles, either when it is initially added to the pool
or when its weight has changed.
This will in turn lower the number of new connections that a scheduler
will be keen on allocating to it and should prevent a real server from
being overwhelmed by a substantial number of connections appearing
suddenly for it to handle.
In order to make that happen, we introduce a concept of artrificial
handicap factor (we are simply making a real server less attractive,
so to speak), which will decay over time allowing for more connections
to be gradually handed over to the real server by the scheduler.
I hope it makes sense :-)
> Is there any configuration for slow start period of time, limit for maximum connections or/and connection rate?
At present, there is no way to set and/or adjust handicap factor
(which is calculated automatically) and any other thresholds like
maximum connections and/or connection rate.
> For example, by now we are using the following shell script to bring up failed real servers:
> i=1; while [ $i -le 100 ]; do ipvsadm -e -t <VIP>:http -r <RS>:http -i -w $i; echo "$(date +"%F %T") Weight set to $i"; sleep 10; ((i++)); done
Are you starting with weight set to 0?
> It is not the best solution because depending of servers load sleep interval must be changed.
Which is quite a manual procedure :-(
> So limiting maximum connections or/and connection rate sounds more convenient.
Perhaps a completely new scheduler should be introduced to address
some of these problems, or perhaps we should expose some values from
existing schedulers for users to tweak as needed. No idea at this
point in time :-)
Please read the documentation before posting - it's available at:
LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users