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 <[email protected]> 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 - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
