On Fri, July 25, 2008 11:29, Joseph Mack NA3T wrote: > On Fri, 25 Jul 2008, David Dyer-Bennet wrote: > >> Here's a model that does what I want (but isn't supported by any current >> scheduler): > > you could feed your resource values to feedbackd
But not more often than once a second, it looks like. The usual problem is balancing loads where each request uses a small portion of the server, isn't it? So each server is handling a few hundred to a few thousand requests "at once"? Our workload is different in that the bigger services now (and bigger ones are expected in the future) will consume the entire server for almost half a second -- all 8 cores. I'm not dealing with statistical averages so much as with an actual scheduling problem. So yes, I'm aware that I'm looking at stretching (or even twisting) LVS to do stuff that's not really what it was designed for. Maybe it won't work. But while it would be interesting work, writing our own redirector-scheduler from scratch would be a rather big commitment. I need to make a reasonable try at finding existing tools that will do what we want before I propose that. Yet another approach is to do weighted connection scheduling and just buy enough hardware to get the response we need, using it somewhat inefficiently. That might well be cheaper than developing and maintaining a good scheduler for what we need. My career history has watched many, many attempts at implementing priority schemes in mainframe OS schedulers, lan media (token ring and FDDI), WAN links (between routers), and so forth, and not one of them ever seemed to be really successful, and the long-term solution has always been more resource rather than really clever management. >> I was wondering if it worked that way. That doesn't make much sense to >> me >> -- in real servers all processes draw from the same resource pools, so >> it >> doesn't make sense to firewall them that thoroughly from each other in >> scheduling. But I imagine most real-world uses have only one virtual >> service? > > the simple ones all do, but LVS has to be able to handle any > number of virtual services. The director can't tell how many > realservers aare behind it or whether the different virtual > services are running on the same or different machines. The > current way of assuming the serivces are independant is > simple at least. Simple is good; making something complex without really good evidence that it's the *right* thing is a frequently-explored resource black-hole. Wait, the director can't tell how many realservers are behind it? But isn't it doing the job of relaying the connections to those realservers? It can't do that if it doesn't know about them, surely? This probably means that "director" is a more specific piece that I don't know about, rather than a synonym for the whole thing. I've read an awful lot of on-line documentation, but I may have missed the clear architectural overview; at least I don't remember seeing one, what I know about the architecture is based on inference from more-detailed documents. -- David Dyer-Bennet, [EMAIL PROTECTED]; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
