|
Hello,
On Sun, 23 Jul 2000, Tim Wu wrote:
> Dear All:
>
> I am studying LVS source and trying to develop a new scheduler.
> I found that the infomation contained in ip_vs_dest is too less to write a
> more
> complicated scheduler. Many info I need is not provided by ip_vs_dest like
You can alloc ip_vs_service->sched_data. There is no
restriction for the size, the number of services is small compared
to the number of connections.
> the TCP state of each connection or the duration of them.
>
> Is there any plan to expand the interface between LVS kernel and LVS
> scheduler by
> add some extra info to ip_vs_dest or event hookers to ip_vs_scheduler? IMHO,
> it will be
> helpful in scheduler develop.
You have to add them in your source tree, then to test this new
scheduler, benchmarks, comparisons, etc. The last steps are including
your work in the LVS tree.
TCP state of each connection already exists: ms->state
Duration of time: Hm, there is one usage of the time for the
current state in todrop_entry().
Don't forget one thing. Any information in the director's
LVS structures about the real servers is incorrect. The real server
can be loaded from (oh, I don't remember how many times I wrote
this):
- other virtual services: if one schedulers uses information about
the real server load only from the virtual service, this is wrong,
there are other virtual services that use this real server
- other directors: if one scheduler uses information about the
real server load only from the LVS structures, this is wrong,
there are other directors that use this real server
- other processes in the real server: if all directors that use
the real server feed the scheduler with information only from
its structures, this is wrong. The local processes in the real
servers can change the load.
- the different real services increase the load in different ways.
One eats memory, other creates network traffic, etc. How is that
related to the connection time, connection state, number of packets
between the director and real server. How the director will know
if the real server is not with 100% CPU usage and 100% memory usage?
And there are forwarding methods (DR, TUN) that don't see the
outgoing traffic.
The result: any scheduler can die if there is no information
from the real server about the load.
Currently, LVS uses local info only to feed the defense
strategies with information about the connection. It is used in
OOM situations. WLC, LC and RR schedulers don't match the above
rules. But WRR with monitoring system in the user space can.
So, my proposal to you: nothing can stop you to change the
LVS source, you are free to test your new scheduler at home. If
the results are promising and your scheduler doesn't hurt the
performance (when collecting data) there is a big chance to be
included in LVS. It can be better than WLC but what about WRR?
Hm, this topic is going to be a FAQ, you can read these
postings too:
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=96268604328970&w=2
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=96252502113930&w=2
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=95959865123051&w=2
>
> //Tim Wu
>
>
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
