|
Simon,
Thanks for the quick response.
So, we are new to LVS and completely not kernel developers. Fine...
So our thoughts are to first use sh as-is, because it'll work for testing,
development, and to some degree production.
So once we know we are using LVS as the project goes further, we can build
'sh2'.
I was going to find the sh code and at least get an idea of how difficult
it'd be to make a sh2. It sounds trivial to me, given that sh already
exists--but it would be a new environment so that'd be the main issue.
Regards,
Seth
On Mon, Sep 20, 2010 at 9:46 PM, Simon Horman <horms@xxxxxxxxxxxx> wrote:
> On Mon, Sep 20, 2010 at 09:29:05PM -0500, Seth Call wrote:
> > Hi there,
> >
> > Source hashing scheduling makes a lot of sense for a project we are
> > starting.
> >
> > One use-case gives us concern though; it's possible a large number of
> > clients sending UDP streams from the same source IP could occur (say a
> big
> > site behind a NAT), causing an unbalanced load to occur on one real
> server.
> >
> > The only thing that occurs to me is if source hashing also considered the
> > source port (and assuming the clients were good about picking from a
> decent
> > range of source ports), to help add granularity to the load-balancing
> > algorithm.
> >
> > What do you all think? Would adding source port to sh (or making a 9th
> > scheduling mechanism) be a good approach to the problem?
>
> It sounds like a reasonable approach to me
> assuming that source ip/port based scheduling makes
> sense for your expected traffic.
>
> I think it would need to be a new scheduler
> as it would break assumptions made by sh - that is
> that scheduling is per-host not per-connection.
>
>
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
